[perl #45357] [TODO] Which exception should be thrown with register overflow?
# New Ticket Created by Paul Cochrane # Please include the string: [perl #45357] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45357 Having a look through PDD03 I noticed the TODO item left by Chip: =head3 Overflow If too many values are provided to fit into the given target registers, Parrot will throw an exception. Note that if the final target is a P register with FLAT set, then this exception can never occur. XXX - FIXME - which exception? We really could use an exception subsystem. Oh, wait, that's my job. Never mind. --Chip What should we do here? Do we already have an exception subsystem? Has this been designed/implemented?
[svn:parrot-pdd] r21179 - trunk/docs/pdds
Author: paultcochrane Date: Tue Sep 11 02:26:58 2007 New Revision: 21179 Modified: trunk/docs/pdds/pdd03_calling_conventions.pod Log: [pdds] Minor formatting and textual corrections. Modified: trunk/docs/pdds/pdd03_calling_conventions.pod == --- trunk/docs/pdds/pdd03_calling_conventions.pod (original) +++ trunk/docs/pdds/pdd03_calling_conventions.pod Tue Sep 11 02:26:58 2007 @@ -90,7 +90,7 @@ =head2 Passing Arguments, Returning Values Just before calling a subroutine with Cinvokecc or calling a method with -call_methodcc, use the Cset_args opcode to tell Parrot where the +Ccall_methodcc, use the Cset_args opcode to tell Parrot where the subroutine's or method's arguments will come from and how they should be expanded by the target. @@ -143,7 +143,7 @@ =head2 Accepting Parameters, Accepting Return Values As the Ifirst opcode in a subroutine that will be called with Cinvokecc or -a method that will be called with call_methodcc, use the Cget_params opcode +a method that will be called with Ccall_methodcc, use the Cget_params opcode to tell Parrot where the subroutine's or method's arguments should be stored and how they should be expanded. @@ -273,8 +273,8 @@ Positional targets can only be filled with positional values. -Named targets can be filled with either positional or named values. However, -if a named target was already filled by an positional (positional) value, and +Named targets can be filled with either positional or named values. +However, if a named target was already filled by a positional value, and then a named value is also given, this is an overflow error. =head3 Type Conversions
[perl #45359] [TODO] Enumerate all non-C89 assumptions that Parrot depends on
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #45359]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45359
In the coding standards PDD (pdd07) there is the todo item:
{{ TODO: Enumerate all other non-C89 assumptions that Parrot depends on. }}
For context, the rest of the section where this appears reads:
C code must generally depend on only those language and library features
specified by the ISO C89 standard.
In addition, C code may assume that any pointer value can be coerced to an
integral type (no smaller than typedef CINTVAL in Parrot), then back to its
original type, without loss.
Also C code may assume that there is a single NULL pointer representation
and that it consists of a number, usually 4 or 8, of '\0' chars in memory.
C code that makes assumptions beyond these must depend on the configuration
system, either to not compile an entire non-portable source where it will not
work, or to provide an appropriate #ifdef macro.
Ok, so the question is: what other assumptions does/should the Parrot
C-language source rely on which are C89 nonstandard?
[perl #45363] [TODO] Deprecate opcode lists surrounded by parentheses
# New Ticket Created by Paul Cochrane # Please include the string: [perl #45363] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45363 In pdd03, Chip deprecated the syntax of opcode lists as a whole surrounded by parentheses: (DEPRECATED: The list as a whole may be surrounded by parentheses.) Some more text for context: The common syntax of these opcodes is: set_opcode (flags0, flags1, ..., flagsN), VAL0, VAL1, ... VALN get_opcode (flags0, flags1, ..., flagsN), REG0, REG1, ... REGN get_opcode (..., 0x200, flags0, ...), ..., name, REG0, ... So, what should the syntax now be? Does the syntax given above fit the deprecated syntax or the correct syntax (it looks like it's deprecated to me, but I'm not an expert in these things)? Anyway, any files containing this syntax need to be changed to the appropriate syntax so that things are up to date.
[perl #45365] [TODO] Update parrot.el to remove return argument parenthesis requirement
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #45365]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45365
In the coding standards PDD (pdd07) there is the todo item (with context):
=item *
Return values should not be parenthesized without need. It may be necessary
to parenthesize a long return expression so that a smart editor will properly
indent it.
{{ TODO: Modify parrot.el so this rule is no longer required. }}
If this hasn't been seen to already, do it. :-)
[perl #45367] [TODO] Limit the required interface for PMCs
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #45367]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45367
In the pdd03 design document there is the todo item (with context):
=item 5 CFLAT (P only)
If this bit is set on a PMC value, then the PMC must be an aggregate. The
contents of the aggregate, rather than the aggregate itself, will be passed.
If the CNAMED bit is also set, the aggregate will be used as a hash; its
contents, as key/value pairs, will be passed as named parameters. The PMC
must implement the full hash interface. {{ TODO: Limit the required
interface. }}
What is the required interface? How should it be limited? This, I
suspect, needs to be discussed and decided upon, and then documented
in the PDD.
[svn:parrot-pdd] r21180 - trunk/docs/pdds
Author: paultcochrane
Date: Tue Sep 11 05:01:37 2007
New Revision: 21180
Modified:
trunk/docs/pdds/pdd03_calling_conventions.pod
trunk/docs/pdds/pdd07_codingstd.pod
Log:
[pdd] Converted TODO items to RT tickets.
Modified: trunk/docs/pdds/pdd03_calling_conventions.pod
==
--- trunk/docs/pdds/pdd03_calling_conventions.pod (original)
+++ trunk/docs/pdds/pdd03_calling_conventions.pod Tue Sep 11 05:01:37 2007
@@ -63,7 +63,7 @@
prefixed with 0b/0x, in binary/hexadecimal. There must be exactly one
integer for each value or register given.
-(DEPRECATED: The list as a whole may be surrounded by parentheses.)
+(RT#45363 DEPRECATED: The list as a whole may be surrounded by parentheses.)
For documentation purposes we'll number the bits 0 (low) through 30 (high).
Bit 31 (and higher, where available) will not be used.
@@ -117,7 +117,7 @@
If the CNAMED bit is also set, the aggregate will be used as a hash; its
contents, as key/value pairs, will be passed as named parameters. The PMC
-must implement the full hash interface. {{ TODO: Limit the required
+must implement the full hash interface. {{ RT#45367: Limit the required
interface. }}
If the CNAMED bit is not set, the aggregate will be used as an array; its
@@ -226,7 +226,7 @@
will throw an exception. Note that if the final target is a P register with
FLAT set, then this exception can never occur.
-XXX - FIXME - which exception? We really could use an exception subsystem.
+RT#45357 - which exception? We really could use an exception subsystem.
Oh, wait, that's my job. Never mind. --Chip
=head3 Underflow
Modified: trunk/docs/pdds/pdd07_codingstd.pod
==
--- trunk/docs/pdds/pdd07_codingstd.pod (original)
+++ trunk/docs/pdds/pdd07_codingstd.pod Tue Sep 11 05:01:37 2007
@@ -69,7 +69,7 @@
system, either to not compile an entire non-portable source where it will not
work, or to provide an appropriate #ifdef macro.
-{{ TODO: Enumerate all other non-C89 assumptions that Parrot depends on. }}
+{{ RT#45359: Enumerate all other non-C89 assumptions that Parrot depends on. }}
=item *
@@ -202,7 +202,7 @@
to parenthesize a long return expression so that a smart editor will properly
indent it.
-{{ TODO: Modify parrot.el so this rule is no longer required. }}
+{{ RT#45365: Modify parrot.el so this rule is no longer required. }}
=item *
[perl #45249] [BUG] r21103-21121 won't build on 64-bit intel
Agreed, r21175 appears to have resolved this problem, so I'm closing the ticket. Instead of filing a ticket for the t/pmc/fixedfloatarray.t problem, I just went ahead and fixed it (r21182). Pm
[svn:parrot-pdd] r21183 - trunk/docs/pdds
Author: paultcochrane Date: Tue Sep 11 06:27:26 2007 New Revision: 21183 Modified: trunk/docs/pdds/pdd07_codingstd.pod Log: [pdd] Minor textual and formatting cleanups. Modified: trunk/docs/pdds/pdd07_codingstd.pod == --- trunk/docs/pdds/pdd07_codingstd.pod (original) +++ trunk/docs/pdds/pdd07_codingstd.pod Tue Sep 11 06:27:26 2007 @@ -388,7 +388,7 @@ Parrot is a large program maintained by many people. Therefore: Don't use a Cchar * when a Parrot STRING would suffice. Don't use a C array -when a Parrot array PMC would suffice. If do use a Cchar * or C array, +when a Parrot array PMC would suffice. If you do use a Cchar * or C array, check and recheck your code for even the slightest possibility of buffer overflow or memory leak. @@ -489,10 +489,12 @@ svn propedit svn:ignore PATH In order to keep the two different checks synchronized, -the MANIFEST and MANIFEST.SKIP file should be regenerated with: +the MANIFEST and MANIFEST.SKIP files should be regenerated with: perl tools/dev/mk_manifest_and_skip.pl +and the files then committed to the Parrot svn repository. + =head3 svn:mime-type The Csvn:mime-type property must be set to Ctext/plain for all test @@ -506,6 +508,9 @@ [auto-props] *.t = svn:mime-type=text/plain +The Ft/distro/file_metadata.t test checks that the files needing +this property have it set. + =head3 svn:keywords The Csvn:keywords property should be set to: @@ -557,7 +562,7 @@ =item Subsystems and APIs The Parrot core will be split into a number of subsystems, each with an -associated API. For the purposes of naming files, data structures, etc, each +associated API. For the purposes of naming files, data structures, etc., each subsystem will be assigned a short nickname, e.g. Ipmc, Igc, Iio. All code within the core will belong to a subsystem; miscellaneous code with no obvious home will be placed in the special subsystem called Imisc. @@ -582,13 +587,13 @@ this is not essential. Each subsystem Ifoo should supply the following files. This arrangement is -based on the assumption that each subsystem will - as far as is practical - +based on the assumption that each subsystem will -- as far as is practical -- present an opaque interface to all other subsystems within the core, as well as to extensions and embeddings. =over 4 -=item foo.h +=item Cfoo.h This contains all the declarations needed for external users of that API (and nothing more), i.e. it defines the API. It is permissible for the API to include @@ -596,7 +601,7 @@ with its use in extensions and embeddings. In this case, the extra stuff within the file is enabled by testing for the macro CPERL_IN_CORE. -=item foo_private.h +=item Cfoo_private.h This contains declarations used internally by that subsystem, and which must only be included within source files associated the subsystem. This file @@ -605,20 +610,20 @@ used to define shorter working names for functions without the perl prefix (see below). -=item foo_globals.h +=item Cfoo_globals.h This file contains the declaration of a single structure containing the private global variables used by the subsystem (see the section on globals below for more details). -=item foo.sym +=item Cfoo.sym This file (format and contents TBD) contains information about global symbols associated with the subsystem, and may be used by scripts to auto-generate such stuff as the include files mentioned above, linker map tables, documentation -etc, based upon portability and extensibility requirements. +etc., based upon portability and extensibility requirements. -=item foo_bar.[ch] etc +=item Cfoo_bar.[ch] etc. All other source files associated with the subsystem will have the prefix foo_ @@ -626,7 +631,7 @@ =item Names of code entities -Code entities such as variables, functions, macros etc (apart from strictly +Code entities such as variables, functions, macros etc. (apart from strictly local ones) should all follow these general guidelines. =over 4 @@ -645,8 +650,8 @@ =item * -All entities should be prefixed with the name of the subsystem they appear in, -e.g. Cpmc_foo(), Cstruct io_bar. +All entities should be prefixed with the name of the subsystem in which they +appear, e.g. Cpmc_foo(), Cstruct io_bar. =item * @@ -707,8 +712,8 @@ =item * Macros can be defined to cover common flag combinations, in which case they -should have C_SETALL, CCLEARALL, C_TESTALL or _TESTANY suffixes as -appropriate, to indicate aggregate bits, e.g. CPMC_valid_CLEARALL(foo) +should have C_SETALL, C_CLEARALL, C_TESTALL or C_TESTANY suffixes as +appropriate, to indicate aggregate bits, e.g. CPMC_valid_CLEARALL(foo). =item * @@ -719,7 +724,7 @@ A macro indicating the compilation 'location' should be prefixed with CIN_, e.g. CPERL_IN_CORE, CPERL_IN_PMC, CPERL_IN_X2P. Individual include file -visitations should
Re: [perl #45255] [PATCH] Add Generated File Warning to Externally-Generated Files
On Tuesday 11 September 2007 06:53:13 Jerry Gay via RT wrote: it'd be even better if the patch included the perl code used to do the fixup. without it, the idea is made clear, but it will remain unproven on any system but your own. oops! Er, yeah. -- c fixup_gen_file.pl Description: Perl program
Re: [perl #45023] SUGGESTION inlining subs
Patrick R. Michaud schrieb: On Tue, Aug 28, 2007 at 09:37:39AM -0700, Debbie Harry wrote: # New Ticket Created by Debbie Harry # Please include the string: [perl #45023] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45023 Maybe it would be useful to support inlining of subs (at PIR level?) This would support good programming style. Well, I'm a bit confused as to what's being asked here, so I'll go ahead and ask for some clarification. Are you asking for the ability to define subs in PIR such that any PIR-based calls to those subs are then inlined? Or are you looking at this from more of a high-level language (HLL) perspective, such that someone writing in a HLL can designate certain blocks as being suitable for inlining? I remember this as a conversation I had with a German guy at YAPC::EU. The idea was optimisation of PIR code. Avoid the overhead of argument passing by inlining subs in the PBC. My suggestion was to start a discussion by submitting an RT ticket for that idea. Regards, Bernhard
[perl #43513] [docs] new content in book/ch01_overview.pod
Hi all, On Wed Jul 11 13:14:15 2007, bernhard wrote: On Di. 03. Jul. 2007, 13:19:56, smash wrote: Hi all, I spent some time around docs/book/ch01_overview.pod. Since most of this chapter is not very technical it's still pretty much up to date. I added a lot of info about roles and responsabilities to the project overview based in RESPONSIBLE_PARTIES, docs/roles_responsibilities.pod and docs/project/*. I'm still in a bit of a struggle with pseudopod tags, so bear with me on this please. You can find a patch for ch01_overview.pod attached to this message. Any comments / ideias would be nice, thank you in advance. I suggest to apply that patch, as it is an improvement. Bringing the whole book up to date, or starting on a new book, is IMHO a major undertaking. A saner organisation of the 'docs' directory might be a start. Committed in revision 21181, closing ticket. Thanks. ./smash
Re: [perl #44101] Parrot 0.4.14 fails: src/pmc/object.c, line 153: void function cannot return value
On Tue, 11 Sep 2007, Bernhard Schmalhofer via RT wrote: On Mo. 23. Jul. 2007, 10:35:38, doughera wrote: As of version 0.4.14, parrot no longer builds for me with Sun's Workshop compiler on Solaris 8/SPARC. I get 66 errors of the form: src/pmc/object.c, line 153: void function cannot return value I believe this is the same issue as in RT#44009. It looks like the issue has been fixed. Can you confirm that for Solaris 8/SPARC ? Yes, that one's fixed. I'll close the ticket. -- Andy Dougherty [EMAIL PROTECTED]
[perl #42769] Should 'object' and basic PMC names be keywords in PIR
We will deprecate all types for .local other than string, num, int, and pmc. Allison
[perl #45387] [BUG] languages/lua/pmc/lua_private.h generating error in t/codingstd/c_header_guards.t
# New Ticket Created by James Keenan # Please include the string: [perl #45387] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45387 I've been getting these errors: [parrot] 504 $ prove -v t/codingstd/c_header_guards.t t/codingstd/c_header_guards1..5 # Failed test (t/codingstd/c_header_guards.t at line 129) # missing guard: # /Users/jimk/work/parrot/languages/lua/pmc/lua_private.h # Failed test (t/codingstd/c_header_guards.t at line 133) # missing define: # /Users/jimk/work/parrot/languages/lua/pmc/lua_private.h # Failed test (t/codingstd/c_header_guards.t at line 137) # missing endif comment: # /Users/jimk/work/parrot/languages/lua/pmc/lua_private.h # Looks like you failed 3 tests of 5. ok 1 - identical PARROT_*_GUARD macro names used in headers ok 2 - multiple PARROT_*_GUARD macros found in headers not ok 3 - missing or misspelled PARROT_*_GUARD ifndef in headers not ok 4 - missing or misspelled PARROT_*_GUARD define in headers not ok 5 - missing or misspelled PARROT_*_GUARD comment after the endif in headers dubious Test returned status 3 (wstat 768, 0x300) DIED. FAILED tests 3-5 Failed 3/5 tests, 40.00% okay Failed Test Stat Wstat Total Fail List of Failed --- t/codingstd/c_header_guards.t3 768 53 3-5 Failed 1/1 test scripts. 3/5 subtests failed. Files=1, Tests=5, 8 wallclock secs ( 0.93 cusr + 0.32 csys = 1.25 CPU) Failed 1/1 test programs. 3/5 subtests failed. I tried to fix them but failed. I probably don't understand the PARROT_*_GUARD macros. This test file appears to have no 'ifndef' headers; that may be part of the problem. kid51
