Parrot Bug Summary
Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log.
[perl #40686] [TODO] release prep: update CREDITS and NEWS
# New Ticket Created by Jerry Gay # Please include the string: [perl #40686] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40686 in preparation for the upcoming (date pending) parrot release, we need to update CREDITS and NEWS files. if anyone has the ability and time to search through the svn log (http://nopaste.snit.ch:8001/8609) since the last release, and create a blurb that's NEWS-worthy, or add appropriate info to the CREDITS file, that would be most appreciated. patches applied directly to parrot, or attached to this ticket are very welcome. if you want to work on this, make yourself known by responding. ~jerry
[perl #40687] [TODO] Tcl - return the stacktrace for the current exception in src/macros.pir
# New Ticket Created by Paul Cochrane # Please include the string: [perl #40687] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40687 From the comment in languages/tcl/src/macros.pir: return the stacktrace for the current exception This is in the context of the get_stacktrace() macro. This ticket is in response to cage task #39704.
[perl #40688] [TODO] Tcl - split or rename src/grammar/expr/expression.pg
# New Ticket Created by Paul Cochrane # Please include the string: [perl #40688] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40688 From the file languages/tcl/src/grammar/expr/expression.pg: # XXX This began as an [expr] only grammar, and has since grown to # encompass the language itself. Either rename the whole thing, or, # preferentially, split out the non-expr specific bits into another # grammar that this one can then refer to. This ticket is in response to cage task #39704.
[perl #40689] [TODO] Tcl - test parsing hack in src/grammar/expr/functions.pir
# New Ticket Created by Paul Cochrane # Please include the string: [perl #40689] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40689 Test the parsing hack in languages/tcl/src/grammar/expr/functions.pir This ticket is in response to cage task #39704.
[perl #40690] [TODO] Tcl - correct workaround due to parrotbug #38896 in src/grammar/expr/past2pir.tg
# New Ticket Created by Paul Cochrane # Please include the string: [perl #40690] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40690 Correct floating point workaround due to parrotbug #38896 in languages/tcl/src/grammar/expr/past2pir.tg This ticket is in response to cage task #39704.
[perl #40691] [TODO] Tcl - is goto statement needed in src/grammar/expr/pge2past.tg
# New Ticket Created by Paul Cochrane # Please include the string: [perl #40691] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40691 Determine if goto statement is needed in languages/tcl/src/grammar/expr/pge2past.tg This ticket is in response to cage task #39704.
Re: set_pmc_keyed_int delegates to set_pmc_keyed...?
On Sun, Nov 05, 2006 at 05:41:12PM +0100, Leopold Toetsch wrote: Am Sonntag, 5. November 2006 15:22 schrieb Patrick R. Michaud: So, I can create the missing cases, but what do I put for the body of the method to get to the corresponding method of Capture? .namespace [ 'Match' ] .sub set_integer_keyed_int :vtable .param int key .param int value # ... how to do set_integer_keyed_int method of Capture? .end A subclass of a PMC delegates to that PMC (via deleg_pmc.pmc). The PMC is the first attribute of that class named '__value'. Your code would look like: .local pmc capt capt = getattribute SELF, '__value' capt[key] = value But this is all clumsy, and might/should change. Therefore I've ci'ed in r15111 another workaround in parrotobject.pmc, which checks, if the parent isa PMC and in that case calls the deleg_pmc method instead of the default. Alas, this seems to work only for immediate subclasses of a PMC. If we have a sub-subclass, then we're apparently back to the same problem as before: $ cat zz.pir .sub main :main $P0 = new .Capture # create Capture object $P0['alpha'] = 1 # store value in hash component $P0[0] = 2 # store value in array component $I0 = elements $P0 # display size of array (should be 1) print $I0 print \n # create a 'Match' subclass of Capture $P99 = subclass 'Capture', 'Match' $P1 = new 'Match' # create Match object $P1['alpha'] = 1 # store value in hash component $P1[0] = 2 # store value in array component $I1 = elements $P1 # display size of array (should be 1) print $I1 print \n # create a 'Exp' subclass of Match $P99 = subclass 'Match', 'Exp' $P2 = new 'Exp'# create Exp object $P2['alpha'] = 1 # store value in hash component $P2[0] = 2 # store value in array component $I2 = elements $P2 # display size of array (should be 1) print $I2 print \n .end $ ./parrot zz.pir 1 1 0 $ Looking at the above, it seems to me that the crux of the problem (short of an overall saner design) is that deleg_pmc is occuring after default.pmc. That seems backwards. Perhaps any deleg_pmc methods should be taking place before falling back to the PMC defaults. We also have a similar problem currently taking place with PMC methods -- methods defined in a PMC aren't being properly inherited or re-delegated in ParrotObject subclasses. For capture.pmc I've put some workarounds for this into Capture's 'get_array' and 'get_hash' methods (r15129), but it again points to something fundamentally wrong with the way that method inheritance/delegation is being handled in ParrotObjects. Pm
[svn:perl6-synopsis] r13463 - doc/trunk/design/syn
Author: larry
Date: Mon Nov 6 14:44:17 2006
New Revision: 13463
Modified:
doc/trunk/design/syn/S12.pod
Log:
Changed has= to autoclose for consistency with other temporal declarators.
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(original)
+++ doc/trunk/design/syn/S12.podMon Nov 6 14:44:17 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 27 Oct 2004
- Last Modified: 1 Nov 2006
+ Last Modified: 6 Nov 2006
Number: 12
- Version: 30
+ Version: 31
=head1 Overview
@@ -466,13 +466,25 @@
@.foo.(1,2,3); # ditto
Pseudo-assignment to an attribute declaration specifies the default
-value. The value on the right is evaluated at class composition
-time, that is, while the class is being compiled and the class
-object constructed. However, if the default value is a closure,
-that closure will be executed later at object initialization time.
-(Use a double closure to initialize to a closure value.) The topic
-of the closure will be the attribute being initialized, while self
-refers to the entire object being initialized.
+value. The value on the right is treated as an implicit closure and
+evaluated at object build time, that is, when the object is being
+constructed, not when class is being composed. To refer to a value
+computed at compilation or composition time, you can either use a
+temporary or a temporal block of some sort:
+
+has $.r = rand;# each object gets different random value
+
+constant $random = rand;
+has $.r = $random; # every object gets same value
+
+has $.r = BEGIN { rand };
+has $.r = INIT { rand };
+has $.r = ENTER { rand };
+has $.r = FIRST { rand };
+
+When it is called at BUILD time, the topic of the implicit closure
+will be the attribute being initialized, while self refers to the
+entire object being initialized.
Class attributes are declared with either Cmy or Cour. The only
difference from ordinary Cmy or Cour variables is that an accessor
Re: :init Where should we put the flag?
Am Montag, 30. Oktober 2006 22:58 schrieb Kevin Tew: Using either of those flags ( PObj_private0_FLAG or PObj_private2_FLAG ) break other tests. I'm up for more suggestions. Sorry for the very delayed answer. Reusing these compile-time flags isn't really safe obviously, as running the code of course might need the reused flags for runtime. I should have thought of that in the first place. Therefore we need: - a new field in the struct Parrot_sub / struct Parrot_coro: UINTVAL comp_flags [1] - it's usable as PMC_sub(pmc)-comp_flags then - all the compile time flags should go there (moving the new one first as a test is of course ok) - the flags can then be defined in sub.h and imcc can just reuse these defines (using the current imcc bits, which are more restricted) leo [1] include/parrot/sub.h please regard the common order of fields in these 2 structs
Re: set_pmc_keyed_int delegates to set_pmc_keyed...?
Am Montag, 6. November 2006 21:54 schrieb Patrick R. Michaud:
Alas, this seems to work only for immediate subclasses of a PMC.
If we have a sub-subclass, then we're apparently back to the
same problem as before:
I somehow thought that any object subclass would have a proper object vtable,
but as that is also inherited from the (already broken) parent vtable, this
of course doesn't work.
I've now removed [1] the default and the workaround for this one vtable call
as a test case and the impact seems to be very low: one String failure and
one explicit test for this case. It seems that these default vtable
redirections aren't very heavily used, and I'm inclined to go that direction,
i.e. remove the defualts. But that needs more testing by removing all such
keyed redirections and implementing a few keyed_int vtables in core PMCs.
leo
[1]
(pmc2c is ignoring unknown vtable names, thus the xxx_ ;)
Index: src/pmc/parrotobject.pmc
===
--- src/pmc/parrotobject.pmc(Revision 15139)
+++ src/pmc/parrotobject.pmc(Arbeitskopie)
@@ -368,7 +368,7 @@
}
}
-void set_integer_keyed_int (INTVAL key, INTVAL value) {
+void xxx_set_integer_keyed_int (INTVAL key, INTVAL value) {
STRING *meth = CONST_STRING(interpreter, __set_integer_keyed_int);
STRING *meth_v = CONST_STRING(interpreter, set_integer_keyed_int);
PMC *sub = find_vtable_meth(interpreter, pmc, meth_v);
Index: src/pmc/default.pmc
===
--- src/pmc/default.pmc (Revision 15139)
+++ src/pmc/default.pmc (Arbeitskopie)
@@ -680,7 +680,7 @@
*/
-void set_integer_keyed_int (INTVAL key, INTVAL value) {
+void xxx_set_integer_keyed_int (INTVAL key, INTVAL value) {
PMC* r_key = INT2KEY(INTERP, key);
DYNSELF.set_integer_keyed(r_key, value);
}
Re: RFC: Actions without barriers
From: Allison Randal [EMAIL PROTECTED] Date: Sun, 29 Oct 2006 22:52:03 -0800 Bob Rogers wrote: You want a patch that just gets rid of Error_Handler? This might be messier without the other changes . . . Not urgent. It may turn out that the experiment is really only useful with this solution. In the event, I think that is true. Folding the Error_Handler hackery into Continuation could be done in either of two ways, but the general way would involve inventing a whole new mechanism for C code (i.e. the error signaller) to return results via a continuation, while the simple way just moves the hackery into a different place without much gain. And it may be that Error_Handler is useful even if it is not that different from Continuation. If the continuation object was passed to an action when unwinding, testing the class of the object could be much more informative than the current practice of passing a simple boolean. So perhaps Error_Handler is worth keeping, at least for now. (Though maybe ExitContinuation would be a more general name for it.) -- Bob
Re: Anyone relying on objects stringifying to class names?
On Sat, Nov 04, 2006 at 08:46:37PM +, Jonathan Worthington wrote: Jonathan Worthington wrote: At the moment, if you have some ParrotObject instance, say foo, and do something like: $S0 = foo Then $S0 will contain the name of the class. =item CSTRING *name() Erm, what the heck was I smoking when I wrote this...the name method doesn't control what an object stringifies to at all. I managed to read it as get_string. :-( Sorry 'bout that. And while this is marked as being bad in the comment, I can't remove it since it's used (and I'm not even sure, how bad it is now). PGE uses it for example. Hmm, I can't recall where PGE might be using this -- could you point to an example so I can make sure it's relatively sane? Thanks, Pm
