Re: [perl #47992] [RFE] 'parrot foo' automatically finds and invokes foo.pbc
On Sun, Sep 20, 2009 at 11:30:58PM -0700, Will Coleda via RT wrote: On Sat Aug 30 08:06:41 2008, pmichaud wrote: On Sat, Aug 30, 2008 at 07:45:08AM -0700, Allison Randal via RT wrote: As mentioned in RT #49168, I'm in favor of a --language flag, that selects the default PBC/PIR file to run, and passes all other arguments to the ':main' sub in that file. It can also select default paths based on the options set the the configuration file for that language. Agreed on the --language concept, although I think I prefer --prog (mentioned in #49168) to --language. Not everything we might want to invoke in this manner is actually a compiler or language. If we're agreed on this approach, I'll open a [todo] ticket for it. I might even write the patch to make it work. :-) Pm Do the fakecutables satisfy the spirit of this request? IMO, not really. I don't think we want to treat fakecutables as the official mechanism for creating command-line tools using Parrot. Pm
Re: [perl #53302] nsentry
On Sun, Sep 20, 2009 at 11:58:16PM -0700, Will Coleda via RT wrote: On Sun Nov 16 10:11:57 2008, tewk wrote: Code is in branch nsentry. Deprecated notice is going in. pmichaud has agreed to write tests This branch was last updated: r34228 | tewk | 2008-12-21 23:41:44 -0500 (Sun, 21 Dec 2008) | 2 lines I suspect merging this with trunk will be painful. Can we get a status update? (either simply closing this ticket or closing it and opening a new one on trac to trac the progress of this request?) There is already a ticket that discusses the current nsentry issues at TT #389. I think that 53302 can be closed/rejected with a link to TT #389. I've already created a backlink from TT #389 to this ticket, for people who want the historical context. The nsentry branch has only one commit in it; i.e., it was copied from trunk and then a single (relatively large) commit was applied. We could potentially store the diff in TT #389 in case someone wants to go back and look at it for reference. Either way, I think we can probably remove the nsentry branch itself as being unsalvageable. Pm
Re: [perl #43078] [DOCS] document how lexical naming works with non-ascii
On Wed, Jun 17, 2009 at 12:28:23PM -0700, Will Coleda via RT wrote: On Wed May 30 07:10:39 2007, coke wrote: Will Coleda (via RT) writes: # New Ticket Created by Will Coleda # Please include the string: [perl #43078] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43078 TODO: Describe how lexical naming system interacts with non-ASCII character sets. From the section =head3 LexPad PMC in docs/compiler_faq.pod Whoops, that's docs/pdds/pdd20_lexical_vars.pod After recent bugreports from pmichaud on behalf of rakudo (and corresponding fixes), the answer to this is it just works, no? It just works. Pm
Re: [perl #37245] [TODO] IMCC - fix symbol handling
On Wed, Apr 22, 2009 at 04:47:53AM -0700, Christoph Otto via RT wrote: This sounds like a good candidate for the new KnownIMCCBugs wiki page, since it's the kind of issue that users of imcc should be aware of, but probably isn't worth fixing. Any objections? +1 Pm
Re: [perl #56186] [TODO] Add --target=bytecode to HLLCompiler
On Thu, Feb 05, 2009 at 04:45:50PM -0800, James Keenan via RT wrote: On Sat Jun 21 07:39:32 2008, pmichaud wrote: Jonathan says that it's possible to generate and save bytecode within PIR -- see languages/dotnet/src/net2pbc.pir as an example. Pm Jonathan, Patrick: Are we going to go forward with this? Yes, it's going to be done as part of a larger refactor to PCT::HLLCompiler. I expect that to land in the next couple of weeks. Pm
Re: [perl #54478] [RFE] trace should be a number that can be decremented and incremented
On Sat, Jan 31, 2009 at 07:42:18PM -0800, James Keenan via RT wrote: On Thu May 22 17:02:41 2008, coke wrote: Allison, can you weigh in on this RFE? Have there been any developments on the issues raised in this ticket? Not really; I don't expect there to be any before 1.0. I vote that we reject the ticket, and possibly create a new ticket in Trac for it. Pm
Re: [perl #37578] [TODO] PIR - simple register allocation
On Thu, Feb 05, 2009 at 08:36:53AM -0800, Andrew Whitworth via RT wrote: On Tue Nov 01 09:03:54 2005, pmichaud wrote: From a discussion earlier today on #irc... It would be nice if the PIR compiler had a way to use a very basic register allocation algorithm for .subs that use only a small number of registers. pmichaud: This ticket was filed about 3 years ago. We have :unique_reg now, does this resolve your issue? If so, we can close this ticket. I'm okay with closing the ticket, assuming that :unique_reg does indeed cause the register allocation algorithm to be simple. (IIRC, as recently as a few months ago this wasn't the case.) Pm
Re: [perl #55308] [TODO] [MMD] add_sub sanely adds MultiSub PMCs to a namespace
On Mon, Feb 02, 2009 at 09:27:10AM -0800, Andrew Whitworth via RT wrote: On Wed Jun 04 16:04:07 2008, pmichaud wrote: I'm just about to commit a change to namespace.pmc that allows the 'add_sub' method to store MultiSub PMCs as well as Sub PMCs. However, the change I'm committing is a little naive in that a subsequent call to add_sub will overwrite any existing MultiSub. Instead, adding a MultiSub to a namespace symbol that already contains a MultiSub should probably merge them together. pmichaud: Any updates on the status of this? It probably needs a Parrot architect to design/decide what should really happen here. I wasn't planning to take it any further than I already have. Perhaps this RT ticket needs to be moved to Trac. Pm
Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
On Mon, Jan 19, 2009 at 08:35:26PM -0800, chromatic via RT wrote: I've done most of this in r35787, but we can't get rid of n_neg entirely until someone updates PCT and NQP not to use it for prefix:- rules. I poked at that, but couldn't make them work. What's the replacement opcode for n_neg ? Pm
Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
On Tue, Jan 20, 2009 at 09:33:17AM -0800, chromatic wrote: On Tuesday 20 January 2009 07:27:53 Patrick R. Michaud wrote: On Mon, Jan 19, 2009 at 08:35:26PM -0800, chromatic via RT wrote: I've done most of this in r35787, but we can't get rid of n_neg entirely until someone updates PCT and NQP not to use it for prefix:- rules. I poked at that, but couldn't make them work. What's the replacement opcode for n_neg ? If we remove n_neg, the replacement is likely a two-step operation: clone $P1, $P2 neg $P1 Please, not this -- it's terribly inconsistent. When we got rid of the other n_* opcodes, their non-n_* counterparts were given the create a new PMC semantics that the n_* version had. We should do the same for n_neg, such that what was previously n_add $P0, $P1, $P2# construct $P0 as sum of $P1 and $P2 n_neg $P0, $P1 # construct $P0 as negation of $P1 is now add $P0, $P1, $P2 # construct $P0 as sum of $P1 and $P2 neg $P0, $P1 # construct $P0 as negation of $P1 Pm
Re: [perl #41825] [BUG] morph vtable override not working in PIR
On Fri, Jan 16, 2009 at 11:34:05PM -0800, Allison Randal wrote: Not a string, a PMC (like Coke said). String type names are almost as bad as type IDs. And check the performance on the branch, as I'm not sure how heavily PGE is using morph. We may need both integer and PMC versions of morph for the internals, but only allow the PMC one to be overridden from PIR. Just for the record, AFAICT none of PGE/PCT/Rakudo make use of morph any longer. We now have the 'copy' opcode to do what the morph workaround was doing (and I don't think copy is using VTABLE_morph). Pm
Re: [perl #62432] Rakudo segfault when passing/calling sub
On Fri, Jan 16, 2009 at 01:43:11AM -0800, I Sop wrote:
With r35615.
Following script to perl6 segfaults:
sub yum() { }
sub callit(x) { x; }
callit yum;
This now responds with an appropriate exception:
$ cat x.pl
sub yum() { }
sub callit(x) { x; }
callit yum;
$ ./parrot perl6.pbc x.pl
Non-Callable argument for x in call to callit
current instr.: 'die' pc 15989 (src/builtins/control.pir:204)
[...]
$
Handing ticket over to moritz++ so we can get a spectest for it.
Thanks!
Pm
Re: [perl #57634] [RFC] Remove .globalconst from PIR
On Sat, Dec 27, 2008 at 07:22:40AM -0800, Klaas-Jan Stol via RT wrote: If we're going to remove one, let's deprecate .const outside of sub blocks, and make .globalconst mean a global constant everywhere. Consistency is a good thing, but so are clear distinctions between similar-but-different things. I thought a bit more on this, and global .consts are more common than sub-local consts (I think). Following the Huffman principle, I think it would be nicer then to use '.localconst' for a local const, only available in a sub, and .const for global constants. (and thus removing .globalconst). +1 Pm
Re: Optimizing PMC-based MMD
On Wed, Dec 24, 2008 at 09:55:58AM -0600, Allison Randal wrote: Within the cmp op bodies, we *know* the arity and most of the types of MMD- participant arguments at compile time. We can get the types of PMC participants within the body of the op itself. Thus we could avoid most of the argument marshalling and counting and analysis if we had a way to perform cached MMD lookup without constructing a CallSignature PMC. That would clear up a third of the work. This we should open up to general discussion. The consequence of short-cutting like this is that individual PMCs will no longer be able to override 'cmp' to do something other than multi-dispatch. Does individual PMCs here mean PMC instance or PMC classes? I.e., are you saying that a specific PMC instance could choose to override the cmp opcode for that individual PMC? If so, do we have any examples where this is being done now? At the moment, developers still have the option of providing their own quick comparison, which gives an even more extreme speedup than this shortcut. So, question for language developers and other PMC developers, how important is the ability to define a 'cmp' vtable function that's called when the 'cmp' opcode is invoked? Or, is defining a 'cmp' multi for your PMC type enough? From a Rakudo perspective, the ability to define custom 'cmp' vtable functions doesn't appear to be at all important. Comparisons are almost invariably done by invoking :multi Sub PMCs of one form or another and letting those handle the MMD dispatch. The opcode form seems to impose too many limitations to be used directly. To turn the question around a bit: I can tell that a lot of work has gone into Parrot to make MMD possible at the vtable level, but I haven't see how vtable MMD is at all useful or usable in languages where operator overloading is possible from the HLL itself. And most dynamic languages I'm looking at seem to support that in one form or another. If someone (Allison) could make an example of how vtable MMD is intended to improve things -- i.e., taking an HLL language statement and showing how that translates to PIR that is improved by vtable MMD, that would be very helpful. The calling conventions refactors are non-critical (some will likely land after 1.0), because the interface will stay the same, it's only the internals that will change. Oh, I'm very disappointed to hear this. Named and positional argument handling still has an odd behavior [*], and Perl 6 still really needs the :lookahead option described earlier in the year. I thought that was going to be made possible by the refactor, and is partially why PDS had calling conventions schedule for the December 2008 release. [*] Currently named parameters are filled from any leftover positionals in the argument list -- there's no way to declare an argument that can _only_ be filled by name, short of defining a :slurpy array that grabs any extra positional arguments and then checking that the slurpy is empty. And, Jonathan can correct me on this if I'm mistaken, but I suspect the other big reason that calling convention refactor was scheduled for the December 2008 release is that it's likely a blocker or important component for the custom dispatcher that Jonathan will be creating for Rakudo as part of his funded grant. That's due to be completed by the end of January, IIRC. Pm
Re: [perl #61286] [PATCH][PROPOSAL] box complements
On Thu, Dec 11, 2008 at 06:19:14AM -0800, Will Coleda via RT wrote: On Thu Dec 11 01:51:23 2008, fperrad wrote: The new opcode 'box' is limited by its 3 signatures that target Float, Integer String. I propose the 3 following new opcodes : - true - false These can be approximated with: $P0 = box 1 $P0 = box 0 Or, as Rakudo handles it: $P0 = get_hll_global ['Bool'], 'True' $P0 = get_hll_global ['Bool'], 'False' The reason for box going to Integer/Float/String is because these correspond directly to the int/num/string registers in Parrot, and also to mimic what happens when doing a subroutine call that autoboxes int/num/string, or certain vtable functions. - undef or nil (less Perlish) undef and null are two different things in parrot, but we do have an opcode for one of them, at least: $P0 = null And the other is simply $P0 = new 'Undef' After some experiments with bytecode translation, in WMLScript (r33655) and in Lua (r33760), it seems obvious that we need them. Can you explain why? I agree -- without a clear use case for why these need to be opcodes, and keeping my let's have fewer opcode, not more hat firmly in place, I don't see the utility of adding these without some specific use cases. Pm
Re: [perl #42267] [CAGE] Work out how to encourage good editor-independent formatting habits
On Tue, Dec 02, 2008 at 01:58:23PM -0800, Will Coleda via RT wrote: On Sun Apr 01 01:02:06 2007, pcoch wrote: Figure out how to encourage good formatting habits, without assuming that everyone uses emacs or vim, and with minimal clutter in our source code. Also write a coding standards test to codify this. We already have a suite of coding standards tests; is there something specific you had in mind that isn't specifically covered in the corresponding PDD? If not, I vote to reject the ticket. +1 Pm
Re: [perl #56458] Failure to promote RetContinuation objects -- fixed?
On Tue, Dec 02, 2008 at 11:39:43PM -0800, Stephen Weeks via RT wrote: I think this is fixed in r33451. Can anyone confirm? If nobody speaks up in a few days, we should close this ticket. I tried the test code in RT #56458 and if I remove the 'pop_eh' it appears to work correctly in r33451. The 'pop_eh' has to be removed because otherwise the context no longer has an exception handler in effect at the point where the continuation is invoked. Perhaps the continuation is expected to keep track of the handlers in effect at the time the continuation is taken -- if so, I suspect we need a lot more design/code work. In the meantime, I agree that the specific issue raised by this ticket is fixed in r33451, so we can close the ticket. Pm
Re: [perl #36330] [TODO] Create a BigNum PMC
On Mon, Dec 01, 2008 at 06:23:31AM -0800, Klaas-Jan Stol via RT wrote: On Sat Sep 08 10:39:31 2007, bernhard wrote: Just for the records, Andy Lester wrote on p2: bignum.c seems to be entirely unused. Everything builds just fine without it. There are many lint errors in it, such as int functions returning with return; and no value. Can we throw it away? Move it somewhere out of the way? If (1) bignum.c is not being used, and (2) we don't expect it to be used between now and Parrot 1.0, then I recommend we eliminate it for the time being. If someone in the future wants to recover this code as part of (re)implementing BigInt/BigNum/BigWhatever, they can easily do so from the svn repository. Until then, let's not carry around the code baggage and/or lead coders down false trails. Pm
Re: [perl #45979] [TODO] Use current namespace as base when nested?
On Mon, Dec 01, 2008 at 10:01:24AM -0800, Klaas-Jan Stol via RT wrote: On Tue Oct 02 10:49:05 2007, pcoch wrote: In src/objects.c:parrot_class_register() there is the todo item: /* XXX nested, use current as base ? */ Which is referring to namespaces. Make a decision about this and implement as appropriate. I can't find the function parrot_class_register in either src/oo.c or src/pmc/object.pmc Is this issue still relevant? (I think not). The issue is still relevant but is probably subsumed by trac #8, so I think we should reject this ticket and let the issue be addressed there. http://trac.parrot.org/parrot/ticket/8 Pm
Re: [perl #46147] [TODO] Print out more information about the macro in imcc
On Mon, Dec 01, 2008 at 10:07:20AM -0800, Klaas-Jan Stol via RT wrote: On Sat Oct 06 03:15:12 2007, pcoch wrote: In compilers/imcc/main.c:do_pre_process() there is the todo item: /* TODO: print out more information about the macro */ Is having more information about a macro, in IMCC's preprocessing option, useful, considering that IMCC's preprocessing function is not complete anyway, and IMCC will be replaced in the relatively short run (I'd say, within 1 year)? If not, then I propose to reject this ticket. +1 Pm
Re: [perl #47966] [DOCS] pdd23 doesn't list exception;death as a standard exception
On Mon, Dec 01, 2008 at 10:09:38AM -0800, Klaas-Jan Stol via RT wrote: On Sun Nov 30 05:51:34 2008, kjs wrote: On Thu Nov 29 11:35:12 2007, pmichaud wrote: In the list of Standard Parrot Exceptions in pdd23, there's no item given for exception;death even though it's mentioned as part of the die opcode earlier in the text. The same is true for the exception;exit type thrown by the exit opcode. Attached is a patch that adds the exception;exit and exception;death exception types. Just a quick note: I accidentally committed the above change myself when adding another change. Ah, it can't hurt. (It might need to be changed.) ... how exactly does one use Cexception;death, Cexception;exit, and the other exception types from PIR? I see them mentioned throughout pdd23, but I've never actually seen an example of how these constants (are they constants?) might appear in actual code, whether it's PIR, C, or otherwise. The only types I'm aware of for exceptions are the severity values and exception type values in include/parrot/exceptions.h and runtime/parrot/include/except_*.pasm, and none of these seem to have any real correspondence to the exception types given in pdd23. Pm
Re: [perl #60592] [TODO] change :lexid into :subid.
On Thu, Nov 20, 2008 at 11:38:11AM -0500, Will Coleda wrote: On Thu, Nov 20, 2008 at 11:36 AM, Klaas-Jan Stol [EMAIL PROTECTED] wrote: I'm not entirely sure whether it was *just* a rename... ISTR there was also something to do with a look-up of names. Pm knows more about it :-) (admittedly, the topic is not well-defined then.) kjs The note in the PDD indicated it was just a rename; If there's some other change that needs doing, we can open a new ticket. The other change that needs doing is RT #60590. This will cause .const 'Sub' $P0 = 'xyz' to look up subroutines by :subid instead of subroutine name. (If a subroutine doesn't specify a :subid flag, then its name is its subid.) Pm
Re: [perl #45857] [IMCC][RFC] #line vs .line
On Mon, Nov 24, 2008 at 02:31:58AM +0100, Jonathan Worthington wrote: Oh, argh, so .line now carries the file *and* the line number?.I wanted it to just carry the line number (the clue's in the name... ;-)) and have .file carry the filename. Then the source you compiled from one file has one .file 'foo.pir' directive, and then you just have .line 42 style things for lines. Either way works for me -- PCT can generate either without much difficulty. It probably makes more sense to have separate .file and .line directives. In particular, I wouldn't want to be repeating the .file annotation information throughout the bytecode! :-) Just a reminder that the central issue for PCT and other HLL's is that the current #line, setline, setfile, etc. instructions are currently intimately tied to lines of PIR source (RT #43269), and they probably shouldn't be. I agree that I don't see a strong need for setting file and line number dynamically -- at least not at this stage. Thanks! Pm
Re: [perl #45857] [IMCC][RFC] #line vs .line
On Mon, Nov 24, 2008 at 03:10:47AM +0100, Jonathan Worthington wrote: Patrick R. Michaud wrote: Just a reminder that the central issue for PCT and other HLL's is that the current #line, setline, setfile, etc. instructions are currently intimately tied to lines of PIR source (RT #43269), and they probably shouldn't be. Instead, I expect PCT will emit .annotate. This allows you to emit whatever annotations you wish. [...] And yes, I need to get this all into the PIR docs, though the storage scheme for all of this is in the bytecode PDD already. But it should give us plenty of flexibility. Sound good? Sounds fantastic! I can hardly wait! Pm
Re: Assignment of UnManagedStruct in Perl6
On Wed, Nov 19, 2008 at 04:57:34PM +0900, Simon Cozens wrote: [...] From this I can conclude that my PIR open() code correctly returns an UnManagedStruct PMC; however, when Perl 6's assignment operator assigns this to a variable, a new, empty UnManagedStruct PMC is created and no longer contains the right data. I have no idea how to fix this, but it looks like the assignment operator is broken. We haven't really dealt with assignment of non-Perl 6 types until now. In this case it was treating the UnManagedStruct as a scalar value, and thus it tried to copy the PMC instead of creating a reference to it. In r32873 I've updated assignment semantics so that it now tries to do the right thing when dealing with something coming from outside Rakudo's type system. In particular, assigning an UnManagedStruct to a scalar value should now properly take a reference instead of attempting to do the copy. Let us know if it helps. Pm
Re: [perl #60554] BUG: 'our' variables getting lost in NQP actions
On Sat, Nov 15, 2008 at 11:46:01AM -0800, Bernhard Schmalhofer wrote: In Pipp I encountered the problem that an our variables seem to get lost in NQP actions. This means that I had set an our variable in one action. When trying to look at the variable in a subsequently called action, the variable was not defined. However this was not reproducible. Using the variable in another action worked as expected. In t/compilers/pct/complete_workflow.t:84 I added a TODO test case that illustrates this behavior. The test case appears to have incorrect logic. $?MY_OUR_VAR appears to be set by the action method for TOP, but the action method for thingy will be called _before_ the action method for TOP. Thus it's pretty clear that thingy won't see the setting of $?MY_OUR_VAR because it hasn't occurred yet. Pm
Re: 'our' variables getting lost in NQP actions (was: #60554)
[Moving this thread out of the ticket queue because it's no longer
relevant to the original ticket.)
On Tue, Nov 18, 2008 at 07:26:47PM +0100, Bernhard Schmalhofer wrote:
So my real problem is:
In the action for thingy how do I determine that the match is below
TOP?
How do you mean determine that the match is below TOP? From the
example that was in the test file, it's clear that thingy is
below TOP because that's the only place it's called from.
I think you're wanting higher rules to be able to store state information
for subrules. There are at least a couple of ways to do something like
this:
1. With a special subrule:
grammar Foo {
token TOP{ .INIT thingy {*} }
token INIT { {*} }
token thingy { 'thingy' {*} }
}
...
method TOP($/) { make $( $thingy ); }
method INIT($/) {
our $?MY_OUR_VAR := 'was passed down';
}
method thingy($/) {
our $?MY_OUR_VAR;
my $past := PAST::Op.new(
:pirop('say'),
PAST::Val.new(
:value( 'our var ' ~ $?MY_OUR_VAR )
)
);
make $past;
}
Here the .INIT subrule gets called before thingy, so
its actions take place before thingy is parsed.
2. With action keys:
grammar Foo {
token TOP {
{*}#= init
thingy
{*}#= close
}
token thingy { 'thingy' {*} }
}
...
method TOP($/, $key) {
if $key eq 'init' {
our $?MY_OUR_VAR := 'was passed down';
}
if $key eq 'close' {
make $( $thingy );
}
}
Here the TOP action method gets called twice -- once
with a $key of 'init' when TOP is first entered, and again
with a key of 'close' after thingy has been parsed.
Note that in Rakudo we do this very rarely, though, as
the design of PCT is intended to be such that the compiler
doesn't have to always know exactly how something was
declared in an outer scope in order to generate the
correct thing in an inner scope.
That said, I am planning to have PCT provide a way to
quickly look up symbols in outer block nodes for when
it is needed.
Pm
Re: [perl #59660] Storable-2.13 requirement breaks build on OpenSolaris
On Mon, Nov 17, 2008 at 01:38:25PM -0800, chromatic wrote: Here are my assumptions: * anyone building Parrot now can install dependencies (working C compilation environment, potentially a bignum library, some CPAN modules, potentially flex/bison or equivalents) Personally, I'm fine with upgrading our requirement to Storable-2.18 (or whatever). But I do want to note that until this change was made, I was able to built Parrot in my base Linux distribution (Kubuntu 8.04) without having to install _any_ CPAN modules or even to set up the CPAN installer. Requiring Storable 2.18 changes that for me. So it's not just a question of whether I _can_ do something; it's that I now _must_ do something where before it was optional. Other considerations that come to my mind: - Some (e.g. students) may be in environments where they can build Parrot but might not be able to easily install CPAN modules. It's been a very long time since I've attempted to install a module in my home directory (instead of the system dirs), but ISTR it wasn't trivial. - Some interested in Parrot for languages _other_ than Perl 6 might be put off by having to learn about CPAN and install a CPAN module in order to get Parrot to work. Chromatic mentioned moving to 2.18 last night and at the time I didn't see any problems with it, but I think I mistakenly assumed that my distribution would already be running at least that version. It's only today when I attempted to rebuild on my desktop machine that I discovered there were now additional steps involved for me. And to repeat my first statement: it's perfectly okay with me if we increase the requirement to 2.18 -- I just wanted to add my experience of the results to the discussion. Pm
Re: [perl #54000] [DEPRECATED] get_array, get_list, get_scalar methods
On Thu, Nov 13, 2008 at 07:40:52AM -0800, Will Coleda via RT wrote:
I probably just need to remove the methods from the code,
see what breaks, and fix what breaks. I'll try to do that this
weekend before the release. If it doesn't happen then, we can
do it immediately following the release.
If you can provide a patch that does the removal, someone else can do
the grunt work of making sure everything still works.
Attached.
Pm
Index: runtime/parrot/library/Parrot/Capture_PIR.pir
===
--- runtime/parrot/library/Parrot/Capture_PIR.pir (revision 32625)
+++ runtime/parrot/library/Parrot/Capture_PIR.pir (working copy)
@@ -39,17 +39,6 @@
.end
-# deprecated RT#54000
-.sub 'get_array' :method
-.tailcall self.'list'()
-.end
-
-# deprecated RT#54000
-.sub 'get_hash' :method
-.tailcall self.'hash'()
-.end
-
-
.sub 'unshift_pmc' :vtable :method
.param pmc val
$P0 = self.'list'()
Index: src/pmc/capture.pmc
===
--- src/pmc/capture.pmc (revision 32625)
+++ src/pmc/capture.pmc (working copy)
@@ -463,7 +463,7 @@
*/
-METHOD get_array() {
+METHOD list() {
PMC *capt_array;
PMC *capt = SELF;
/* XXX: This workaround is for when we get here as
@@ -481,7 +481,7 @@
RETURN(PMC *capt_array);
}
-METHOD get_hash() {
+METHOD hash() {
PMC *capt_hash;
PMC *capt = SELF;
/* XXX: This workaround is for when we get here as
Index: t/pmc/capture.t
===
--- t/pmc/capture.t (revision 32625)
+++ t/pmc/capture.t (working copy)
@@ -243,9 +243,9 @@
0 0
OUTPUT
-pir_output_is( $PRE . 'CODE'. $POST, 'OUTPUT', get_hash, get_array );
-$P0 = capt.'get_array'()
-$P1 = capt.'get_hash'()
+pir_output_is( $PRE . 'CODE'. $POST, 'OUTPUT', hash, list );
+$P0 = capt.'list'()
+$P1 = capt.'hash'()
$S0 = typeof $P0
$S1 = typeof $P1
@@ -297,7 +297,7 @@
2
OUTPUT
-pir_output_is( 'CODE', 'OUTPUT', 'get_array method delegation' );
+pir_output_is( 'CODE', 'OUTPUT', 'list method delegation' );
.sub main :main
$P0 = subclass 'Capture', 'Match'
addattribute $P0, '$.abc'
@@ -310,7 +310,7 @@
$P2 = new 'String'
setattribute $P1, '$.xyz', $P2
-$P2 = $P1.'get_array'()
+$P2 = $P1.'list'()
$P2 = 0
$I0 = elements $P2
print $I0
[perl #60396] [BUG] escape opcode returns incorrect result
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #60396] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60396 There's a bug somewhere in the escape opcode (r32442, no libicu present). Here's the test case: $ cat y.pir .sub main $S0 = unicode:x/\u0445\u0440\u0435\u043d\u044c_09-10.txt say $S0 $S1 = escape $S0 say $S1 .end $ ./parrot y.pir x/хрень_09-10.txt x/\u0445\u0440\u0435\u043d\u044c9-10.txt We start by constructing a unicode string (originally from RT #58820) and displaying it, then we escape the string and display that. The escaped version should be the same as what appears in the quotes in the unicode:... literal, but as you can see above the _0 characters present in the original string are lost in the escaped version. A hex dump shows that they are being turned into NUL bytes somehow: $ ./parrot y.pir | xxd 000: 782f d185 d180 d0b5 d0bd d18c 5f30 392d x/.._09- 010: 3130 2e74 7874 0a78 2f5c 7530 3434 355c 10.txt.x/\u0445\ 020: 7530 3434 305c 7530 3433 355c 7530 3433 u0440\u0435\u043 030: 645c 7530 3434 6300 0039 2d31 302e 7478 d\u044c..9-10.tx 040: 740a t. $ This bug appears to be very sensitive to the contents of this paritcular string -- adding, removing, or otherwise changing the string contents causes the bug to disappear. Pm
Re: Known Bug in Rakudo?
On Thu, Oct 30, 2008 at 08:03:17AM -0700, Ovid wrote:
This code:
class Point {
has $.x is rw;
has $.y is rw;
method get_string () {
return $.x, $.y;
}
}
my Point $point .= new( :x1.2, :y-3.7 );
say $point.x;
say $point;
Generates this output:
1.2
get_string() not implemented in class 'Point'
Now fixed in r32373. The get_string() not implemented ...
message actually comes from Parrot -- in Perl 6 we define
stringification using the CStr method (see S13):
$ cat point.pl
class Point {
has $.x is rw;
has $.y is rw;
method Str() {
return $.x, $.y;
}
}
my Point $point .= new( :x1.2, :y-3.7 );
say $point.x;
say $point;
$ ./parrot perl6.pbc point.pl
1.2
1.2, -3.7
$
This problem was also addressed in RT #60350 (now resolved).
Hope this helps, and thanks!
Pm
Re: Known Bug in Rakudo?
On Thu, Oct 30, 2008 at 05:46:11PM +0100, Moritz Lenz wrote: I think that every class should have a default stringification. Dunno if there's a ticket for it yet. I don't think there's a _spec_ for a default stringification yet. So we should probably propose that first, and then see about an implementation. :-) Pm
[perl #60208] [BUG] pheme -- t/null test fails in r32229
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #60208]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60208
'make test' in pheme is giving an error in r32229:
[EMAIL PROTECTED]:~/parrot/r32229/languages/pheme$ make test
../../parrot ../../compilers/tge/tgc.pir --output=lib/ASTGrammar.pir
lib/pge2past.tg
../../parrot
/home/pmichaud/parrot/r32229/runtime/parrot/library/PGE/Perl6Grammar.pbc \
--output=lib/pheme_grammar_gen.pir lib/pheme.g
../../parrot -o pheme.pbc pheme.pir
/usr/bin/perl -Ilib t/harness
t/atomok
t/car.ok
t/cdr.ok
t/condok
t/consok
t/divide..ok
t/lambda..ok
t/minus...ok
t/multiplyok
t/nullerror:imcc:syntax error, unexpected $undefined, expecting
'\n' (''')
in file 'EVAL_1' line 67
t/nullok
t/plusok
t/quote...ok
t/write...ok
t/phemer/chapter_1ok
All tests successful.
Files=14, Tests=51, 4 wallclock secs ( 3.80 cusr + 0.28 csys = 4.08 CPU)
[EMAIL PROTECTED]:~/parrot/r32229/languages/pheme$
Pm
Re: [perl #60166] [BUG] Exception handling in parrot doesn't unwind stack.
On Wed, Oct 29, 2008 at 10:06:15PM +0100, NotFound wrote: do_loop: say i push_eh do_inc $P0 = find_method i, succ i.$P0() do_inc: pop_eh inc i goto do_loop I've noticed an anomaly: if you add .get_results($P0) after pop_eh nothing bag happens, but if you put it before, it starts leaking a lot of memory. Last time I checked any .get_results ($P0) call has to be the very first instruction executed as part of any exception handler -- even before any pop_eh. If any other instruction is executed, then .get_result gives back something other than the thrown exception. (I checked this a month or two ago -- sometime after the pdd25cx branch merge that updated exception handling.) Pm
Re: [perl #60166] [BUG] Exception handling in parrot doesn't unwind stack.
On Sun, Oct 26, 2008 at 10:05:21PM -0700, Vasily Chekalkin wrote: Exception handling in parrot doesn't unwind used stack frames. Simple example: .sub 'main' .local pmc i i = new 'Integer' do_loop: say i push_eh do_inc $P0 = find_method i, succ i.$P0() pop_eh do_inc: inc i goto do_loop .end Exception handling doesn't really use a stack (in spite of the opcode names push_eh and pop_eh). As discussed in #parrotsketch earlier today and summarized at [1], the correct form of the above loop would have the pop_eh line after the do_inc label, so that every exception handler created in the loop is removed before going on to the next loop iteration. With the following example (and the other patches to Parrot_ex_throw_from_op_args added by NotFound++), I'm able to run the following version and get to 250,000 without any difficulty. $ cat x.pir .sub 'main' .local pmc i i = new 'Integer' do_loop: say i push_eh do_inc $P0 = find_method i, succ i.$P0() do_inc: pop_eh inc i goto do_loop .end $ ./parrot x.pir 0 1 2 3 4 ... 249997 249998 24 25 250001 250002 ^C (The top(1) command on my machine seems to indicate a small memory leak in the above, but it does run a significant ways, and I didn't investigate further.) Pm
Re: [perl #60166] [BUG] Exception handling in parrot doesn't unwind stack.
On Tue, Oct 28, 2008 at 10:15:32PM -0500, Patrick R. Michaud wrote: ... As discussed in #parrotsketch earlier today and summarized at [1], the correct form of the above loop would have the pop_eh line after the do_inc label, so that every exception handler created in the loop is removed before going on to the next loop iteration. Forgot the reference: [1] http://lists.parrot.org/pipermail/parrot-dev/2008-October/000148.html Pm
Re: [perl #60124] MMD Fails to Resolve with Autoboxing and :optional Parameters
On Sun, Oct 26, 2008 at 09:37:36PM -0400, Bob Rogers wrote:
.sub 'main' :main
foo('Hello')
.end
.sub foo :multi(String)
.param pmc s
say s
.end
[...]
Which brings us to an interesting question: How can you decide what
type to use for autoboxing before you've determined the actual sub
you're going to call? And how can you find the sub without having the
correct dispatch types up front?
According to t/pmc/multidispatch.t, :multi can specify 'string',
'int', and 'num' to match the native (non-PMC) types:
.sub p :multi(string)
.param string s
print s
.end
.sub p :multi(string, string)
.param string opt
.param string s
if opt != '-twice' goto no_twice
print s
print s
.return()
no_twice:
print s
.end
Based on this, I would expect foo('hello') to dispatch to
a sub via :multi(string) and not dispatch to :multi(String).
As far as I can tell, this hasn't been deprecated anywhere, and
is explicitly recognized in pdd27 (line 43):
=item - Dispatch considers both low-level (register) types
and high-level (PMC) types, as well as inherited and composed types.
Returning to chromatic's original post, no applicable methods is
actually what I would expect from the code given, since there are
no methods defined taking the 'string' or 'int' type as the first
argument. If there's a version that does work using String and
Integer :multi's, then perhaps that's the one with the bug.
It's also possible that I'm completely misinterpreting the
:multi semantics, but that's the way things have tended to work
up to now, and I haven't seen any documentation or messages
that contradict it.
Pm
Re: [perl #60098] [BUG] load_bytecode couldn't find file 'P6object.pbc'
On Sat, Oct 25, 2008 at 06:50:29AM -0700, François PERRAD via RT wrote: In fact, perl6.exe contains some dependencies on build tree. Just after a build, perl6.exe works : This is a known item -- see line 32 of languages/perl6/README: This binary executable feature is still somewhat experimental, and may not work on all platforms. Also, the binary has hardcoded paths to the Parrot build tree (especially the dynamic libraries and modules), so removing the build tree will cause the binary to stop working. We're not likely to do anything about this until Parrot installation is handled properly. I couldn't find a unique ticket for that issue -- when we find or create such a ticket we should probably list this ticket as a dependency on that. In the meantime, I'm marking this ticket as stalled. Thanks! Pm
Re: [perl #60044] [BUG?] rethrow just throwing?
On Fri, Oct 24, 2008 at 12:18:40PM -0700, Allison Randal wrote: (I suppose technically we should stop calling this a stack trace since it's not a stack. But return continuation chain trace is just too verbose.) backtrace Pm
Re: [perl #60044] [BUG?] rethrow just throwing?
On Thu, Oct 23, 2008 at 08:04:41PM -0700, Allison Randal wrote: I don't understand the problem. Is it that you expect 'rethrow' to keep the stack trace of the original 'die'? ...this is what I would expect. If I catch and then rethrow an exception, I'd expect the stack trace to continue to show the location of the original throw, not the location of the rethrow. Pm
Re: [perl #60070] [BUG] make opsrenumber causes build to fail
On Thu, Oct 23, 2008 at 12:38:36AM -0700, chromatic wrote: On Wednesday 22 October 2008 22:49:37 Patrick R. Michaud (via RT) wrote: This patch fixes things for me, with minimal fuss and without inadvertently adding back in ops that we explicitly blacklist via src/ops/ops.skip. Patch works for me, and applied in r32134. I also regenerated the ops.num file, updated PBC_COMPAT, and fixed(?) a few other items relating to adding/removing opcodes that I encountered while working with this patch. Closing ticket, thanks! Pm
[perl #60070] [BUG] make opsrenumber causes build to fail
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #60070] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60070 In the lex branch I'm trying to add a new opcode, but I'm running into a build issue with opcode renumbering -- after adding an opcode and running make opsrenumber, attempting to rebuild parrot fails with: /usr/bin/perl tools/build/ops2pm.pl src/ops/core.ops src/ops/bit.ops src/ops/cmp.ops src/ops/debug.ops src/ops/experimental.ops src/ops/io.ops src/ops/math.ops src/ops/object.ops src/ops/pic.ops src/ops/pmc.ops src/ops/set.ops src/ops/stm.ops src/ops/string.ops src/ops/sys.ops src/ops/var.ops skipped opcode is also in src/ops/ops.num at lib/Parrot/Ops2pm.pm line 145, $op line 11. make: *** [lib/Parrot/OpLib/core.pm] Error 9 In fact, this failure appears even if a new opcode isn't added -- simply performing make opsrenumber followed by make results in the same error: $ svn up At revision 32122. $ make opsrenumber /usr/bin/perl tools/dev/opsrenumber.pl src/ops/core.ops src/ops/bit.ops src/ops/cmp.ops src/ops/debug.ops src/ops/experimental.ops src/ops/io.ops src/ops/math.ops src/ops/object.ops src/ops/pic.ops src/ops/pmc.ops src/ops/set.ops src/ops/stm.ops src/ops/string.ops src/ops/sys.ops src/ops/var.ops $ make [...] /usr/bin/perl tools/build/ops2pm.pl src/ops/core.ops src/ops/bit.ops src/ops/cmp.ops src/ops/debug.ops src/ops/experimental.ops src/ops/io.ops src/ops/math.ops src/ops/object.ops src/ops/pic.ops src/ops/pmc.ops src/ops/set.ops src/ops/stm.ops src/ops/string.ops src/ops/sys.ops src/ops/var.ops skipped opcode is also in src/ops/ops.num at lib/Parrot/Ops2pm.pm line 145, $op line 11. make: *** [lib/Parrot/OpLib/core.pm] Error 9 $ Since a number of steps have changed since the last time I worked with adding/removing opcodes (April 2008), and I have little idea what might be causing this, I'm filing this ticket in hopes that someone can clear things up for me. Thanks, Pm
[perl #60036] [BUG] inplace math fails post-MMD
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #60036] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60036 As of r31667 (pre-mmd), the following worked: r31667$ cat y.pir .sub 'main' :main $P1 = new 'Integer' assign $P1, 4 $P1 *= 3 say $P1 $P0 = subclass 'Integer', 'MyInt' $P1 = new 'MyInt' assign $P1, 4 $P1 *= 3 say $P1 .end r31667$ ./parrot y.pir 12 12 r31667$ In the current head it fails: $ ./parrot y.pir 12 Multiple Dispatch: No suitable candidate found for 'i_multiply_int', with signature 'PI' current instr.: 'main' pc 21 (y.pir:9) $ This causes some issues for Rakudo's inplace ops (RT #60016). This may also be related to the issues in #59788 and #59630 . Pm
Re: [perl #60016] [PATCH] Make basic Perl 6 tests pass
On Tue, Oct 21, 2008 at 12:21:24AM -0700, Ovid wrote: --- On Tue, 21/10/08, James Keenan via RT [EMAIL PROTECTED] Thanks. Hopefully this time there will be some traction because there does appear to be a bug in Perl 6, as evidenced by this one-liner: perl6 $ ../../parrot perl6.pbc -e 'my $x = 3; $x **= 2; say $x' 3 Unless, of course, this isn't supposed to be implemented yet, but that seems strange since it's in the basic tests. The infix:**= code broke as part of the mmd branch merge, because the meaning of Parrot's 'pow' opcode has changed. The infix:**= function used the Parrot opcode (src/builtins/assign.pir:80) a = a ** b # pow a, a, b Before the MMD merge, this opcode meant raise a to the power of b and store the result back in a. However, after the mmd branch merge this opcode now means create a new PMC containing the value of a raised to the b power and set register a to point to that new PMC, leaving the value of its original PMC alone. So, the pow opcode is no longer able to act as an inplace modifier. I've corrected this in r32071, by explicitly assigning the new result back to the PMC referenced by 'a'. I've also applied Ovid's patch (with some fixes) in r32072, so that the test correctly reports failures instead of simply saying there are misnumbered tests. Lastly, we've now reorganized the 'make test' target to make it more obvious when there is a failure in the t/00-parrot/ or t/01-sanity/ tests, and removed the coding standards tests from 'make test'. Thanks, closing ticket! Pm
Re: [perl #60036] [BUG] inplace math fails post-MMD
On Tue, Oct 21, 2008 at 11:01:21AM -0700, Andrew Whitworth via RT wrote: On Tue Oct 21 10:47:43 2008, Whiteknight wrote: On Tue Oct 21 07:53:35 2008, pmichaud wrote: As of r31667 (pre-mmd), the following worked: $P0 = subclass 'Integer', 'MyInt' $P1 = new 'MyInt' assign $P1, 4 $P1 *= 3 say $P1 In the current head it fails: If most of the n_* opcodes and their ilk have been removed, then the *= operator and other inplace operators need to be changed in IMCC to produce three-operand opcodes instead. I disagree. The n_* opcodes were all three-operand opcodes to begin with, while the inplace opcodes have always been two-operand opcodes. This hasn't changed (or, at least, it shouldn't have), and so shouldn't be affecting the inplace (two-operand) opcodes at all. The *= operator should be producing a mul_p_i opcode call (if I am reading all this correctly). mul_p_i should be calling VTABLE_i_multiply_int on p. It should fall back to VTABLE_i_multiply_int in Integer.pmc. Nowhere in here am I seeing an MMD call, because i_multiply_int is not a multi in Integer.pmc. The first statement about *= producing mul_p_i is certainly correct; I can't speak to any of the rest of what's written, though. Pm
Re: Fw: Running Perl 6 Tests
On Mon, Oct 20, 2008 at 09:42:12AM -0700, jerry gay wrote: However, in digging further, I found this: perl t/harness --verbosity 1 t/02-test-pm/1-basic.t testtest and 02-test-pm/ should either be ripped out or heavily modified. it was intended to be tests required to pass in order to run pugs' Test.pm. 02-test-pm/ should be ripped out, especially since we expect the testing functions to become Perl builtins. As such they'll be tested by either the 01-sanity/ suite or by the spectest. The 00-parrot/ set of tests are basic sanity tests for Parrot, to say do we have something that is at least running under Parrot? The 01-sanity/ tests are the tests needed to be able to start running Test.pm and the test suite. Everything else comes from the official test suite, in t/spec/ of the Pugs repository. Pm
Re: [perl #48549] [DEPRECATED] [PDD19] Let .namespace (no args) have empty brackets
The big hangup for this ticket is that various parts of PCT and the CodeString PMC do not support empty brackets, and therefore PCT does not emit .namespace [] in these situations. [...] I know pmichaud was talking about a major rewrite of PGE in the future, maybe this change could be included in the laundry list of things to do during that time? i've committed one-line changes to pge and tge that seem to have modified the behavior of .namespace with the root namespace to emit empty brackets in r32051. if this can be verified independently, this ticket can be closed. Before closing this ticket we probably still need to update the .key method in the CodeString PMC so that it returns [] instead of when it's given an empty namespace array (and then verify that everything based on PCT still functions properly). Pm
Re: [perl #58974] [TODO][IMCC] replace .return in tailcall context by .tailcall
On Sat, Oct 18, 2008 at 07:40:36AM -0700, Andrew Whitworth via RT wrote: On Sat Oct 18 07:38:32 2008, Whiteknight wrote: On Wed Sep 17 09:50:10 2008, kjs wrote: I've added .tailcall syntax to IMCC. It is supposed to be used instead of .return in tailcall context. Using .return for this is deprecated. I haven't tested yet, but i assume there are going to be a lot of uses of the old syntax throughout the repo that will need to be updated. Do any of our code generators like PCT use the old syntax? If so, how hard would it be to update them? A good first approximation might be to do the following: ack \.return\s+[^(] On my system this returns about 750 candidates. Pm
Re: [perl #59912] Re: hllmagic branch tests namespace changes
On Wed, Oct 15, 2008 at 10:02:39AM -0700, chromatic wrote:
On Wednesday 15 October 2008 05:54:59 Will Coleda wrote:
The namespace of the generated file should be changed, the subclass
should probably be updated. (TGE itself should probably be updated to
not live a namespace with a '::' in it. The actual transform sub can
keep the name it has, but the first parameter to add_rule() should
probably be updated as well. This /should/ work with the new automatic
translation of :: that PGE is doing.
Here's a patch for part of TGE to use the keyed form of classnames. PCT may
need some changes as well. In particular, the parsegrammar and astgrammar
methods in src/PCT/HLLCompiler.pir take strings as arguments, as in this
example from Pheme:
$P0 = get_hll_global ['PCT'], 'HLLCompiler'
$P1 = $P0.'new'()
$P1.'language'('Pheme')
$P1.'parsegrammar'( 'Pheme::Grammar' )
$P1.'astgrammar'( 'Pheme::AST::Grammar' )
They should probably transform these strings into keys internally, as
P6MetaObject does.
'parsegrammar' already knows to convert a string into a class --
we just need to update 'astgrammar' to do the same.
Pm
Re: [perl #59784] [PATCH] Enhancement : support for multiple optables in PGE
I'm a little reluctant to commit to any specific modifications to optables at the moment because much of this will be significantly refactored in the relatively near future as part of implementing protoregexes and longest token matching into PGE. As that's being done, I suspect we may discover a far superior mechanism for handling optables in general, including allowing multiple optables. I'm also not a fan of having proto subs (i.e., the operator token definitions) place themselves into the most recently defined optable. That sounds quite fragile, and it goes against the Perl 6 semantics that the grammar files are intended to be following. I do like the idea that the name of the $optable variable is based on the rulename, though -- that's definitely a step in the right direction. If we can come up with a better mechanism for associating operator tokens with the correct optable, then perhaps we should go with that. The ultimate answer will be to use protoregexes and categories, as STD.pm is currently doing. An intermediate answer might be to have an is optable trait for proto subs that can specify an optable to use other than the default. (Ideally the equiv/tighter/looser traits would also tie a new token to the optable of whatever it's being defined in relation to.) In particular, I don't want to provide too many new structures/ features that we may want to turn around and quickly deprecate when protoregexes come into play. Pm
Re: [perl #59816] TGE fails in r31893
On Sat, Oct 11, 2008 at 07:59:31PM -0700, Will Coleda wrote: After building parrot, cd compilers/tge make test; Test Summary Report --- ../../t/compilers/tge/basic.t (Wstat: 256 Tests: 3 Failed: 1) Failed test: 1 Non-zero exit status: 1 ../../t/compilers/tge/grammar.t (Wstat: 512 Tests: 3 Failed: 2) Failed tests: 1-2 Non-zero exit status: 2 Files=3, Tests=8, 0 wallclock secs ( 0.00 usr 0.01 sys + 0.36 cusr 0.12 csys = 0.49 CPU) Result: FAIL make: *** [test] Error 1 Odd, these tests all pass for me (r31900, Kubuntu 8.04). Perhaps prove -v t/compilers/tge would give us some information? Pm
[perl #59788] [BUG] inplace shift left (shl_p_p, shl_p_i) fails
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #59788] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59788 The inplace shift left and inplace shift right opcodes are failing after the mmd branch merge. Here's the test code: $ cat x.pir .sub main :main $P0 = new 'Integer' $P0 = 1 $P1 = $P0 3 say $P1 $P0 = 3 say $P0 .end $ ./parrot x.pir 8 1 $ Both should produce the same value (8), but don't. Pm
Re: [perl #59630] [BUG] Complex subtraction fails for subclasses of Complex
Just for the record, I went ahead and added a version of my test script in this ticket to the test suite (t/pmc/complex.t). (The test still fails as of r31755, let me know if it should be marked 'todo'.) Thanks, Pm
Re: [perl #59630] [BUG] Complex subtraction fails for subclasses of Complex
On Mon, Oct 06, 2008 at 06:05:20AM -0700, NotFound via RT wrote:
I've done some work in this problem. The attached patch is a way to make
the examples work but I think this is not the way to go, or a lot of
functions in a lot of pmc will need changes.
[...]
I agree this really isn't the way to go.
Also, I'm very curious about the use of VTABLE_morph here --
indeed, if we just look at the Integer PMC class we see some
oddities. For example, here is the code for adding and
subtracting an Integer PMC and a Complex PMC:
/* src/pmc/integer.pmc:341 */
MULTI PMC *add(Complex value, PMC *dest) {
const INTVAL a = SELF.get_integer();
dest = pmc_new(INTERP, VTABLE_type(interp, value));
VTABLE_set_number_native(INTERP, dest,
a + VTABLE_get_number_keyed_int(INTERP, value, 0));
VTABLE_set_number_keyed_int(INTERP, dest, 1,
VTABLE_get_number_keyed_int(INTERP, value, 1));
return dest;
}
/* src/pmc/integer.pmc:452 */
MULTI PMC *subtract(Complex value, PMC *dest) {
const INTVAL a = SELF.get_integer();
if (dest)
VTABLE_morph(INTERP, dest, value-vtable-base_type);
else
dest = pmc_new(INTERP, VTABLE_type(INTERP, value));
VTABLE_set_number_native(INTERP, dest,
a - VTABLE_get_number_keyed_int(INTERP, value, 0));
VTABLE_set_number_keyed_int(INTERP, dest, 1,
-VTABLE_get_number_keyed_int(INTERP, value, 1));
return dest;
}
The add operation always creates a new PMC and returns it
(never using the Cdest PMC passed in), but the subtract
operation tries to reuse an existing Cdest PMC if it's
not null. (Note: it actually tests for NULL and not PMCNULL,
which also seems odd.)
Seems like it should be one way or the other, but in the new
MMD code I'm not sure which.
Pm
svn commits via email missing?
We seem to have lost the svn-commit mail updates, I haven't seen a svn-commit message since r31606 on October 3 (parrot is currently at r31676). Any chance we get could this back? For me it's much easier to review commits and patches arriving by email than to have to go manually look them up via svn. Pm
Re: [perl #59576] [PATCH] 'property' scope for PAST::Var
On Fri, Oct 03, 2008 at 06:23:42AM -0700, I Sop wrote:
From: Patrick R. Michaud via RT [EMAIL PROTECTED]
On Thu, Oct 02, 2008 at 02:16:01PM -0700, I Sop wrote:
I just copied the 'attribute' method, renamed
everything, and changed the parameter order for the
'getprop' op.
Why should this be a PAST::Var node as opposed to simply
using a PAST::Op node with :pirop('getprop') and/or
:pirop('setprop') ?
Why is this different than attribute access?
I don't know -- I didn't add the attribute access code either. :-)
I'll have to think about it some. But the intent of PCT is to
model the most common constructs that appear in HLLs, not to
provide a separate node type for every possible construct
or operation that happens to be available.
So it may just come down to the fact that there are a lot of HLLs
that make use of object attribute access, but very few that
do properties.
Stated another way: I'm just looking for a compelling use case
that indicates that we really ought to have property support
in PAST::Var before actually adding it. The ideal use case for
PCT is because it makes writing a compiler easier, but I probably
want to see examples.
Pm
Re: [perl #59576] [PATCH] 'property' scope for PAST::Var
On Thu, Oct 02, 2008 at 02:16:01PM -0700, I Sop wrote:
I just copied the 'attribute' method, renamed everything, and changed the
parameter order for the 'getprop' op.
Why should this be a PAST::Var node as opposed to simply using a
PAST::Op node with :pirop('getprop') and/or :pirop('setprop') ?
Pm
Re: [svn:parrot] r31581 - in branches/hllmagic: runtime/parrot/library t/library
On Fri, Oct 03, 2008 at 01:23:14AM -0700, [EMAIL PROTECTED] wrote: +parrotclass = split '::', $S0 +$P0 = getinterp +$P0 = $P0['namespace';1] +$P0 = $P0.get_name() +$P0 = shift $P0 +unshift parrotclass, $P0 +parrotclass = get_root_namespace [parrotclass] The brackets in this last line look odd to me -- obtaining a namespace via an array of names is supposed to be (pdd21:377) $P1 = get_root_namespace $P2 Also, the p6object library tries to reserve the symbol name parrotclass for something that is actually an instance of (parrot) Class, which the array and namespace aren't. We should introduce another symbol here instead of re-using parrotclass. Pm
Re: [perl #59546] [PATCH] Combine hash exists/get into a new opcode (5% performance gain)
On Thu, Oct 02, 2008 at 04:51:32PM +0100, Nick Glencross wrote: NotFound, That would look cleaner, wouldn't it? I'll give it a go. Nick On Thu, Oct 2, 2008 at 3:35 PM, NotFound [EMAIL PROTECTED] wrote: I think will be better the other way, using the return value to flag existence, and passing a pointer to store the result. This will allow shorter and cleaner code. Another possibility might be to avoid the extra parameter altogether, returning NULL (not PMCNULL) if the element doesn't exist. Pm
[perl #59410] [PATCH] CONTROL_LOOP_NEXT support for pct. Rakudo won't build, though.
Patch applied in r31547 (by avoiding a push_eh/pop_eh mismatch). The problems with imcc hanging will be entered in a separate ticket. Thanks! Pm
[perl #59538] [BUG] imcc freezes (compute_dominance_frontiers)
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #59538] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59538 The attached hang.pir file causes imcc to freeze while compiling it. The code itself is derived from code generated by PCT from RT #59410. There is a runtime logic error in the code -- at runtime it would be possible for a pop_eh to be executed without a previous push_eh. Of course, that shouldn't be enough to cause imcc to hang. Commenting out any of the lines marked xxx allows the code to compile. It's also interesting that the myfoo *= $I0 statement is one of these (and is required to evoke the bug), even though it's in an entirely different sub. Pm .sub 'foo' .local num myfoo myfoo = 1.0 $I0 = 5 myfoo *= $I0 ## xxx ?!? .end .namespace [Perl6;Grammar;Actions] .sub _block1806 :anon :lexid(139) get_global $P1808, $/ set $P1809, $P1808[post] unless_null $P1809, vivify_548 ## xxx new $P1809, Undef ## xxx vivify_548: defined $I1811, $P1809 unless $I1811, for_1807_end ## xxx new $P1812, 'ExceptionHandler' set_addr $P1812, for_1807_next ## xxx $P1812.'handle_types'(63)## xxx push_eh $P1812 iter $P1810, $P1809 for_1807: unless $P1810, for_1807_end ## xxx shift $P1813, $P1810 $P1855 = find_name _block1814 $P1855($P1813) ## xxx goto for_1807## xxx for_1807_next: goto for_1807## xxx for_1807_end: pop_eh .return ($P1810) .end
Re: [perl #59410] [PATCH] CONTROL_LOOP_NEXT support for pct. Rakudo won't build, though.
Cardinal's works fine, but with this patch, rakudo hangs while building. Specifically, on parrot -o perl6.pbc perl6.pir. Oddly, if I comment out the builtins (line 25): .include 'src/gen_builtins.pir' then perl6.pbc compiles just fine. It doesn't run, of course, because the builtins are missing, but it does get things past the compile stage. This makes me think it's definitely an imcc bug of some sort. I have trouble conceiving what in src/gen_builtins.pir could be causing imcc to (later) hang when compiling the actions. Pm
[perl #59374] [BUG] pmc2c produces incorrect code for RETURN(INTVAL -1)
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #59374] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59374 Summary: pmc2c produces incorrect code for returning negative integer constants, as in RETURN(INTVAL -1) Longer description: In the set_readline_interactive method of the ParrotIO PMC line 200 reads RETURN(INTVAL -1); This is supposed to return a value of -1 when the method is called and the readline library is not present. However, when run this is actually returning 1 (readline is not present in the example below): $ cat z.pir .sub main :main .local pmc stdin stdin = getstdin $I0 = stdin.'set_readline_interactive'(1) say $I0 .end $ ./parrot z.pir 1 Looking at the code generated in src/pmc/parrotio.c (line 775 on my system), we see: /*BEGIN RETURN INTVAL -1 */ /*BEGIN GENERATED ACCESSORS */ #line 777 ./src/pmc/parrotio.pmc CTX_REG_INT(_ctx, 0) = 1; I think somewhere the minus sign is being lost when the code is being generated. This also occurs earlier in the method for a couple of instances of RETURN(INTVAL -2): /*BEGIN RETURN INTVAL -2 */ /*BEGIN GENERATED ACCESSORS */ #line 722 ./src/pmc/parrotio.pmc CTX_REG_INT(_ctx, 0) = 2; Pm
Re: [perl #59366] small fix to pod doc and interactive prompt
On Fri, Sep 26, 2008 at 07:25:35AM -0700, Chris Davaz wrote: Fixed a bug in the doc where the method name and doc where mismatched. Thanks. Fixed a small bug where, even if the user sets the prompt, a default prompt ' ' is still printed. Changed it so that a default prompt is only printed only if the user had not set a prompt (or set an empty prompt). Unfortunately, the patch causes the prompt to not work properly when readline is present -- i.e., pressing up-arrow to recover a previously entered line loses the prompt. Also, I think it should be possible for a compiler to set an empty prompt -- this patch makes that impossible. I've reworked the patch so that it defaults to ' ' unless a prompt has been set, in which case it uses that as the prompt. As far as readline goes, we need to generate our own prompt if readline isn't present, and allow readline to generate the prompt if it is. I've refactored the code to work this way -- unfortunately there's a bug (RT #59374) in the pmc2c generation for ParrotIO that causes ParrotIO to report that readline is available when it really isn't. So, I'm applying my changes to trunk now (r31439), and then when #59374 is fixed we should start seeing the prompts in non-readline environments as well. Thanks for the patch! Pm
[perl #59374] [BUG] pmc2c produces incorrect code for RETURN(INTVAL -1)
That fixes it, thanks! Closing ticket, Pm
Re: Revisiting lexicals, part 1
On Wed, Sep 24, 2008 at 10:44:23PM -0600, Tom Christiansen wrote: In-Reply-To: Message from Geoffrey Broadwell [EMAIL PROTECTED] Don't we have to solve all this to get the Perl 6 debugger working anyway? Although I'm unsure why that might be, I also recognize the possibility that there may well exist hypothetical documents, unread by me, which mandate some scenario or behavior wherein the answer to your question can only be yes. However, from a perl5 perspective, the answer is surely not. First, a big thank you to Tom for the time and effort spent in describing the perl5 perspective here. I've not had much (okay, any) experience with the debugger in perl5, so reading Tom's description has greatly increased my understanding of what we may be looking at for Perl 6, and calms a few minor anxieties I had on the topic. So, this message was a big help to me and I really appreciate it. :-) To respond to a couple of other items I saw in the message: I'm going to do a quick review of *why* that answer is surely not before then going on to consider whether perhaps this *might* not apply to perl6 and ask that, should this indeed be what's afoot, that I be gently enlightened. As far as I'm aware, there's nothing in the current Perl 6 design or synopses that indicate that things are substantially different in this area from Perl 5. So, I'm comfortable that what we have thus far in a lexicals redesign for Parrot doesn't cause a conflict here. [...] However, I have no idea whether Parrot might not change all of this existing situation around completely. I'm completely ignorant of this, but I'd not be astonished to learn it did. If you told me yes, that's what happens, and then pushed me into guessing why, I'd only get as far as making the uneducated guess that this must somehow be due to *its* own assumptions, constraints, or expectations about just what it means to execute newly eval code in scope. Is this so, or is it not so? Taking a pure Parrot perspective, Parrot doesn't and probably shouldn't impose a particular view of debugging on the languages it supports. Clearly we can support the style of debugging and interactive execution that you've described happens with perl 5, but Parrot might also come across a dynamic language where eval'd code is in scope and can modify the current lexical environment. So, while Parrot probably won't impose this view on Perl (5 or 6), it may still need to evolve to support it at some point. What I can say with confidence is that what we have so far in Parrot today acts pretty much as you've described, and that in the lexical redesign work I'm doing now I'm explicitly not (yet?) addressing the situation of an eval being able to modify the (outer) scope in which is embedded. But I'm also fairly comfortable that the design I'm putting together can (with not too much work) accommodate that capability if/when we decide that Parrot needs it. From a Perl 6 perspective, given that Pugs provides an interactive mode where one can do my $variable and have it stick, it may be that this becomes a standard feature in Perl 6 in general. Fortunately that's not my call, but I can see why people may want something like it for Rakudo as well, and people running Python on Parrot will certainly expect interactively entered lexical variable declarations to work. Anyway, none of what I've said above should be taken as Parrot or Perl's official stance; it's just how things currently look to me. Thanks again for the excellent and helpful message. Pm
Re: [perl #59250] [BUG] MMD bug in FixedPMCArray.sort
On Thu, Sep 25, 2008 at 05:05:16AM -0700, Vasily Chekalkin via RT wrote: This bug caused by runops_args which doesn't populcate interp-current_args which used in mmd_arg_tuple_func to calculate signature for MMD. chromatic has suggested that we should wait for the pdd27mmd branch to merge into trunk before spending too much more effort on this one; I agree. Many aspects of parameter passing and mmd are different in the branch and so are likely affect the resolution of this ticket. Pm
[perl #59336] [BUG] Parrot fails integer comparisons when integers are 2^31 apart
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #59336] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59336 Code says it all: $ cat w.pir .sub main $P0 = new 'Integer' $P0 = 2147483600 test_10: print $P0 print is if $P0 -10 goto skip_10 print not skip_10: say greater than -10 test_1000: print $P0 print is if $P0 -1000 goto skip_1000 print not skip_1000: say greater than -1000 .end $ ./parrot w.pir 2147483600 is greater than -10 2147483600 is not greater than -1000 $ I suspect the problem is that the integer greater than operation is performing a subtraction between the two (signed long) values being compared, but the result of the subtraction is outside of the range of signed longs. Pm
Re: Revisiting lexicals, part 1
On Wed, Sep 24, 2008 at 12:09:37PM +0200, François Perrad wrote:
Currently, the bigger issue in Lua on Parrot is lexical or upvalue in
Lua jargon (the reason for Lua on Parrot is not really Lua).
The following Lua code doesn't give the expected result (from
languages/lua/t/closure.t) :
a = {}
local x = 20
for i=1,10 do
local y = 0
a[i] = function () y=y+1; return x+y end
end
print(a[1]())
print(a[1]())
print(a[2]())
--[[
The loop creates ten closures (that is, ten instances of
the anonymous function). Each of these closures uses
a different y variable, while all of them share the same x.
]]
With the current Parrot, I never found a way to do it.
So, I'll be happy if this revisiting handles this issue.
Here's how I would expect this to look in PIR under the
new scheme (I'm not familiar with Lua, but I'm assuming 'local'
in Lua means 'lexical', and that the loop variable is lexical):
.sub 'main'
## set outer context of forbody_block
.const .Sub forbody = 'forbody_block'
capture_lex forbody
## a = {}
.local pmc a
a = new 'ResizablePMCArray'
store_global 'a', a
## local x = 20
.local pmc x
x = new 'Integer'
x = 20
.lex 'x', x
## for i = 1,10 do
.local pmc i
i = new 'Integer'
.lex 'i', i
for_loop:
if i 10 goto for_done
forbody()
inc i
goto for_loop
for_done:
## print(a[1]())
$P0 = a[1]
$P1 = $P0()
say $P1
## ...
.end
.sub 'forbody_block' :outer('main')
## set outer context of lambda_block
.const .Sub lambda = 'lambda_block'
capture_lex lambda
## local y = 0
.local pmc y
y = new 'Integer'
y = 0
.lex 'y', y
## a[i] = function () y = y+1; return x+y; end
.local pmc a,i
a = get_global 'a'
i = find_lex 'i'
$P0 = clone lambda ## this creates the closure
a[i] = $P0
.end
.sub 'lambda_block' :outer('forbody_block')
## y = y + 1;
.local pmc y
y = find_lex 'y'
n_add $P0, y, 1
copy y, $P0
## return x+y;
.local pmc x
x = find_lex 'x'
n_add $P1, x,y
.return ($P1)
.end
Pm
Re: Revisiting lexicals, part 1
On Tue, Sep 23, 2008 at 03:45:37AM -0500, Patrick R. Michaud wrote: I've put together a draft with my ideas and design for (re-)implementing lexicals in Parrot -- now available at http://www.pmichaud.com/perl6/lexical.txt . Earlier today chromatic asked about recursion in the new design, so I've now updated the document with a section illustrating how recursion works. It's still at the same location. Pm
Re: Revisiting lexicals, part 1
On Wed, Sep 24, 2008 at 10:05:25PM +0200, Stéphane Payrard wrote:
One of parrot current limitation is that eval is always a closure.
When using rakudo interactively, one want to introduce new
lexical variable that are not lost when accessing them from the
next prompt.
Pugs gets that right.
I would like to make sure we distinguish 'eval' from
'interactive prompt' -- they're probably not the same.
AFAICT while Perl 6's Ceval function is able to access lexical
variables in the scope where it is used, it's not necessarily
able to create new ones in that scope. In other words:
{
eval 'my $x = 4'
say $x; # compile-time failure, $x doesn't exist
}
{
eval 'my $x = 4';
eval 'say $x'; # run-time failure, $x doesn't exist
}
I think this is most consistent with the statements in S02:1780, that
seem to indicate that lexical symbol tables are currently fixed at
compile time:
You may not use any lexically scoped symbol table, either by name or
by reference, to add symbols to a lexical scope that is done compiling.
(We reserve the right to relax this if it turns out to be useful though.)
So, in order to get the behavior you're describing from the interactive
prompt, we'll probably need more than just Perl 6's 'eval'. In
particular, the interactive prompt mode will need to be able to
maintain it's own dynamic lexical pad (i.e., a DynLexPad) and have
some way of extracting any lexical changes from whatever code string
it evaluates.
At any rate, even though I don't discuss DynLexPad's in the new design,
I'm confident that it will be far easier to accommodate and use them
than the one that exists now, and to be able to achieve the
'interactive mode' semantics you've described above.
Pm
Re: Revisiting lexicals, part 1
On Thu, Sep 25, 2008 at 12:10:35AM +0200, Reini Urban wrote: 2008/9/24 Patrick R. Michaud [EMAIL PROTECTED]: So, in order to get the behavior you're describing from the interactive prompt, we'll probably need more than just Perl 6's 'eval'. In particular, the interactive prompt mode will need to be able to maintain it's own dynamic lexical pad (i.e., a DynLexPad) and have some way of extracting any lexical changes from whatever code string it evaluates. I wouldn't call them DynLexPad or lexicals at all, I would call them just globals. lexvars could shadow them though, but this a user problem then. This approach might expose some rough edges, though -- things like MY::, OUTER::, *::, etc. might not work as expected, or those constructs would have to know when they're dealing with interactive mode pseudo-lexical-globals instead of what the rest of the system is using. Still, we might consider something along these lines -- perhaps as a stopgap approach if nothing else. Pm
Re: [svn:parrot] r31385 - trunk/docs/book
On Wed, Sep 24, 2008 at 05:00:31PM -0700, jerry gay wrote:
On Wed, Sep 24, 2008 at 4:31 PM, chromatic [EMAIL PROTECTED] wrote:
They're not really methods in any PIR or C sense though (I usually use the
term entry), as they're not really inherited nor invoked through a
dispatch scheme [...]
[...]
i really wish the vtable methods meme would die. they're not
methods. they are a collection functions which define the api to
access the pmc, parrot's abstract data type.
I'm curious about the not really inherited part -- if I declare
a new PMC class with
pmclass MyString extends String provides string ... {
}
then doesn't the MyString PMC inherit the vtable entries from
String?
I grant that there may be reasons why this isn't truly inheritance,
but I think the use of the keyword extends (c.f. Java) may be
what makes all of this look like classes and methods.
Similarly, VTABLE_get_integer(pmc) acts an awful lot like a
polymorphic dispatch mechanism, even if it's a very simplistic
one.
I'm not at all arguing that this automatically means we should call
them methods, but at a conceptual level they certainly seem a lot
like methods, and the vtable implementations contain references to
things like SELF and STATICSELF that make them look awfully method-like.
Regardless, I'll be happy to call them entries, methods, functions
or whatever the consensus and documentation ends up saying they are. :-)
Pm
Re: Revisiting lexicals, part 1
On Wed, Sep 24, 2008 at 10:11:07PM -0400, Bob Rogers wrote: Just a few: 1. In the translation of your Perl 6 example in Runtime part 3: Closures and cloning, I notice that you do get_global 'bar' twice: .sub 'foo' ## bind inner sub 'bar' to current lexical environment $P0 = get_global 'bar' capture_lex $P0 ## ['bar' updated by side-effect] [...] ## return bar $P2 = get_global 'bar'## [updated 'bar' refetched] ## clone 'bar', preserving current lexical environment $P2 = clone $P2 ## [new 'bar' copy created] .return ($P2) .end Is this just an artifact, or is there something I'm missing? It's just an artifact of how I was originally thinking code generation might look -- you're correct, we only need it once. In any case, this looks like it has a race condition. If another copy of 'foo' is running concurrently, the other copy's capture_lex might happen before our capture_lex and clone. Perhaps it would be better to suggest the following as the standard idiom: $P2 = get_global 'bar'## [original 'bar'] $P2 = clone $P2 ## [new 'bar' copy created] capture_lex $P2 ## [copy updated] That's a valid approach also (and one I also considered that the design should support -- taking a clone prior to capture_lex). I _hadn't_ thought of the concurrency angle, though, and I agree there could be a race condition here. However, the way I described it (capture_lex then clone) is the way that Synopsis 4 currently describes the bindings to take place, so I went with that. It'll be interesting to see how that plays with concurrency. 2. Compilers often know how many contexts outward to look when resolving a lexical reference; it might be useful to add another integer parameter to find_lex in order to support this optimization. I agree it could be a useful optimization, but I'll leave that decision to Allison and others. I'm just trying to get something that works for Perl 6. :-) 3. Since the whole context is captured, all of the :outer sub variables are preserved from GC for the life of all closures made for inner subs. That could be avoided if the LexPad stored the PMCs directly and not just their register indices. Doing so would require that the :outer sub also do store_lex and find_lex on lexical variables, and not just the inner ones. (That could be a drawback or a feature, depending on your point of view.) Given the way that code generation is currently working in PCT and Perl 6, I'm finding that register mapping of lexicals has _very_ limited utility, at least for languages (such as Perl 6) where binding is a much less common operation than assignment. So converting LexPads to store PMCs instead of register mapping might indeed be an improvement. It would probably also help with things like iterating over LexPads (which we can't seem to do at the moment). Pm
Revisiting lexicals, part 1
I've put together a draft with my ideas and design for (re-)implementing lexicals in Parrot -- now available at http://www.pmichaud.com/perl6/lexical.txt . It's a first draft and might be a bit confusing in places, but overall I think it's a far cleaner design than the current implementation but also handles the vast bulk of what we need (or can be made to do so easily). Anyway, comments greatly appreciated. Pm
[perl #59250] [BUG] FixedPMCArray.sort(cmp) fails on MultiSub PMC comparators
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #59250] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59250 The .sort method on FixedPMCArray fails with no applicable methods when given a MultiSub PMC as a comparison function. Here's a sample PIR program: $ cat x.pir .sub 'main' .local pmc arr arr = new 'FixedPMCArray' arr = 4 arr[0] = 'just' arr[1] = 'another' arr[2] = 'perl' arr[3] = 'hacker' ## called with normal Sub, works $P0 = get_global 'cmpfn1' arr.'sort'($P0) $S0 = join ' ', arr say $S0 ## called with MultiSub, fails $P0 = get_global 'cmpfn2' arr.'sort'($P0) $S0 = join ' ', arr say $S0 .end .sub 'cmpfn1' .param pmc a .param pmc b $I0 = cmp_str a, b .return ($I0) .end .sub 'cmpfn2' :multi(_, _) .param pmc a .param pmc b $I0 = cmp_str a, b .return ($I0) .end $ ./parrot x.pir another hacker just perl No applicable methods. current instr.: 'main' pc -34072556 ((unknown file):-1) called from Sub 'main' pc 49 (x.pir:18) $ See also some of the analysis I did on the parrot-dev mailing list (subject: References to multis (at PIR level))-- I can repost that to the ticket if it would be helpful. Pm
Re: [perl #59006] stringifying Floats into PIR literals loses (a lot of) precision
On Tue, Sep 23, 2008 at 08:47:15PM -0700, chromatic wrote: On Thursday 18 September 2008 06:13:30 Patrick R. Michaud (via RT) wrote: When generating PIR output (e.g., from the compiler tools), we often need to convert a Float value into an equivalent representation for PIR. Unfortunately, all of the mechanisms I've looked at for doing this lose a lot of precision, which really isn't acceptable. How about 15 digits of precision? The attached patch (which requires a reconfigure) does so. It also drops trailing zeroes, which may or may not be what you want. It's much more precise though: set_p_s : 2.71828182845905 get_repr : 2.718281828459045 printf %g: 2.718282 The patch works very well -- I even tried it with very large (1.234e+34) and very small (1.234e-34) positive numbers and always got back a reasonable string that preserved the level of precision I was looking for. Dropping the trailing zeroes is fine (and preferred). +1 in favor of applying this patch (and updating any tests to match) -- this will _really_ improve things for PCT and Rakudo. Thanks! Pm
[perl #59202] [BUG] [PATCH] Perl 6 code class A::A {}; class A::A {} crashes parrot
Patch rejected -- this patch modifies core OO-handling of Parrot to assume that '::' is a valid classname separator. Parrot doesn't use '::' as a separator -- that's strictly a Perlism. Pm
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Thu, Sep 18, 2008 at 09:23:50AM +0200, Allison Randal wrote: What's the language-agnostic term for this, then? Well, 'gather' is basically a clever use of a coroutine, and 'take' is basically a 'yield'. But, what's unique about the construct is that it aggregates the results. So, 'gather' is an aggregating coroutine and 'take' is an aggregating yield. It's also a little unique that the take/yield can happen from called subs deep within the coroutine, and doesn't have to occur within the coroutine itself. To allow for a distinction in the control exception types, call it 'CONTROL_YIELD_AGGREGATE'. Aggregating coroutine and aggregating yield aren't nearly as zippy as 'gather' and 'take', but they're more meaningful to a broader audience, which may help the feature spread. I'm rather hoping and expecting that gather and take become the meaningful names for this feature, much like grep started out as a Unix shell command but is now the language-agnostic term for extract things from a list matching a pattern. Pm
[perl #59006] stringifying Floats into PIR literals loses (a lot of) precision
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #59006] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59006 When generating PIR output (e.g., from the compiler tools), we often need to convert a Float value into an equivalent representation for PIR. Unfortunately, all of the mechanisms I've looked at for doing this lose a lot of precision, which really isn't acceptable. The prime candidate for this seems to be the Cget_repr opcode, which AFAICT is intended for this purpose. However, it appears to provide only about 7 digits of precision. The approaches I've tried thus far are simple stringification, the get_repr opcode, and variations on sprintf formats. Here's an example showing the difficulty: $ cat x.pir .sub 'main' $N0 = exp 1.0 'as_pir'($N0) .end .sub 'as_pir' .param pmc value print set_p_s : $S0 = value say $S0 print get_repr : $S0 = get_repr value say $S0 print printf %g: $P0 = new 'ResizablePMCArray' push $P0, value $S0 = sprintf '%g', $P0 say $S0 .end $ ./parrot x.pir set_p_s : 2.71828 get_repr : 2.718282 printf %g: 2.71828 By way of comparison, Perl 5 gives a far more reasonable result: $ perl -e 'print exp(1),\n' 2.71828182845905 One approach might be to take whatever algorithm Perl 5 uses for stringifying its floats (or something close to it), and adopt that for get_repr and/or Float stringification. The current situation blocks PCT's (and thus HLLs such as Rakudo) ability to generate reasonably accurate PIR involving floating point constants. Phrased another way: to get reasonable floating point semantics HLLs are currently having to restrict themselves to supporting floating point literal syntaxes that directly or easily translate to PIR output and don't rely on actually computing the float value. Pm
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Thu, Sep 18, 2008 at 09:06:44AM -0700, jerry gay wrote: On Thu, Sep 18, 2008 at 8:37 AM, Geoffrey Broadwell [EMAIL PROTECTED] wrote: On Thu, 2008-09-18 at 07:34 -0500, Patrick R. Michaud wrote: Aggregating coroutine and aggregating yield aren't nearly as zippy as 'gather' and 'take', but they're more meaningful to a broader audience, which may help the feature spread. I don't buy this. The Perl 6 terms are well chosen, and as soon as you know what they mean in the context of programming, you won't forget. The other versions ... well, let's leave it at easy to forget. (OK, one more thing -- the word coroutine scares people. Gather does not.) I'm rather hoping and expecting that gather and take become the meaningful names for this feature, much like grep started out as a Unix shell command but is now the language-agnostic term for extract things from a list matching a pattern. Now *this* I agree with. The first system to make a feature standard gets first try at standardizing the name. If they've chosen the name well, there's a decent chance it will stick. what some refer to as traits, perl 6 calls roles. what some refer to as associative arrays, perl calls hashes. [...] we need to be precise in naming constructs, rather than using common names. scientists call a chanterelle mushroom by its proper name, Cantharellus cibarius. Other languages have adopted the Perl shortname of hash as well, including Ruby and this odd little creature known as Parrot. Perhaps we should rename Parrot's Hash class to AssociativePMCArray? 1/2 ;-) we should call gather and take by their proper names where they're defined. aggregating coroutine is more precise and descriptive than is gather, however gather is much easier to say in polite company, and is therefore a better name to use at the language level. By this reasoning, we should also change the other exceptions: .CONTROL_RETURN = .CONTROL_SUB_RETURN (or .CONTROL_SUB_EXIT) .CONTROL_BREAK= .CONTROL_LOOP_EXIT .CONTROL_CONTINUE = .CONTROL_LOOP_NEXT and perhaps add .CONTROL_LOOP_REPEAT there as well. Note that I'm not at all opposed to this -- if we're going to do it for one, we really ought to do it for all. a related point: wherever these constructs are defined, they need to be documented. you may think CONTROL_RETURN is obviously for return statements, but many will find it quite strange that return is an Exception at all. Agreed that we should document them all somewhere. I vote that we do it in the Exceptions PDD. :-P Pm
Re: New Parrot mailing list
On Thu, Sep 18, 2008 at 11:00:31AM +0200, Allison Randal wrote: We'll likely end up with messages scattered between both lists for a little while, but the perl6-internals/parrot-porters addresses are deprecated and will be disabled after a sensible deprecation cycle (and after the automatic RT posts have been shifted to parrot-dev). Will we also be able to get svn commits to the new mailing list, or at least to *a* mailing list? The new mailing list will not automatically update tickets in the RT queue, for that CC [EMAIL PROTECTED] on the message. Wouldn't it be possible to have the new mailing list manager check for [perl #n] in the message subject and automatically forward it (controlling for loops as appropriate)? Or, if the MLM can't do it, then perhaps subscribe an address to parrot-dev that performs this action for us? Pm
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Wed, Sep 17, 2008 at 10:57:31AM +0200, Allison Randal wrote: Patrick R. Michaud wrote: I'm not sure about this last comment -- I think I can imagine that other language implementations (including new ones we haven't thought of yet but suddenly becomes possible with Parrot) might want to make use of gather/take semantics if they're readily available -- especially because they can be very hard to otherwise implement when they're not readily available. And compile-time constants are pretty cheap. :-) Absolutely. But for that it shouldn't be called CONTROL_TAKE, because that's meaningless outside Perl 6. [...] The principle is that global things should be language-agnostic, and not use terminology that's confusing to all the other languages. What's the language-agnostic term for this, then? Pm
Re: Parrot 0.7.1 Manu Aloha released
On Wed, Sep 17, 2008 at 08:08:47PM +0200, Reini Urban wrote: http://www.parrotcode.org/release/devel still points to 0.7.0 I sent the appropriate patch to the webmaster, but it hasn't been applied yet (and I lack a commit bit for the parrotcode.org site). Once that's applied, the url should be fixed. Pm
[perl #58932] [DEPRECATED] P6object .new_class('Foo::Bar') will create ['Foo';'Bar']
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #58932]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58932
Sometime after the 0.7.1 release, the P6object library will change
so that double-colons will be treated as separators in class names
passed to the 'new_class' method.
Consider the following code:
.local pmc p6meta
p6meta = get_hll_global 'P6metaclass'
p6meta.'new_class'('Foo::Bar')
Previously this would create a class ['Foo::Bar'] that
would look for its methods in the ['Foo::Bar'] namespace.
At some point after 0.7.1, the above will instead create
a class ['Foo';'Bar'] that looks for its methods in the ['Foo';'Bar']
namespace.
A method that is guaranteed to always bind the new class properly
to the namespace (even for other HLLs) is to pass the namespace
itself as the first parameter to new_class:
.local pmc p6meta, classns
p6meta = get_hll_global 'P6metaclass'
classns = get_hll_global ['Foo';'Bar']
p6meta.'new_class'(classns)
If there is a case where the class name really needs to contain
double-colons, this can be done via a namespace parameter (above)
or by placing the name into an array of some sort:
classns = get_hll_global ['Foo::Bar']
p6meta.'new_class'(classns)
or
$P0 = split(' ', 'Foo::Bar')
p6meta.'new_class'($P0)
Pm
Re: throw oddities in pdd23
On Tue, Sep 16, 2008 at 10:14:24PM +0200, Allison Randal wrote: Okay, PDD cleaned up. The code to directly support throwing any arbitrary type would require significant circumlocution (read: inefficient, difficult to maintain), so it's not desirable. [...] But, an individual HLL can store any arbitrary PMC value as the payload of an exception object, and act as if it had thrown an arbitrary PMC as an exception. Works for me, thanks. Now I'm just eagerly awaiting comments on Stephen Weeks' proposals. :-) Pm
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Tue, Sep 16, 2008 at 11:45:17PM +0200, Allison Randal wrote: Patrick R. Michaud wrote: What's TAKE? TAKE is like CONTROL_RETURN except that it signals that we expect execution to continue after the point of the TAKE. It's quite similar to a .yield operation for coroutines. Would CONTROL_YIELD make more sense? I would have known what yield meant. It might be a bit misleading, because it doesn't actually correspond to a .yield (and thus I can envision CONTROL_YIELD as yet another exception type). Eventually we'll need to stop defining exception types as a global enum, and let individual languages define their own. EXCEPTION_TAKE really doesn't make sense for anything other than Perl 6. Not today, but someday. I'm not sure about this last comment -- I think I can imagine that other language implementations (including new ones we haven't thought of yet but suddenly becomes possible with Parrot) might want to make use of gather/take semantics if they're readily available -- especially because they can be very hard to otherwise implement when they're not readily available. And compile-time constants are pretty cheap. :-) In particular, having gather/take readily available may make it easier to implement many internal functions and libraries, even if gather/take itself isn't directly exposed at the HLL layer. Similar arguments probably hold for other core features of Parrot. So, I think we can't always say oh, only one dynamic language needs this feature so it shouldn't be global -- we need to also consider those dynamic-languages-yet-to-be-written because Parrot is such an incredible platform for creating them. Pm
[perl #58946] [META] October 2008 release
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #58946] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58946 This metaticket is for issues related to the October 2008 release of Parrot, planned for October 21st 2008. The release manager will be Jerry Gay. Pm
Parrot 0.7.1 Manu Aloha released
On behalf of the Parrot team, I'm proud to announce Parrot 0.7.1 Manu Aloha. Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. Parrot 0.7.1 is available via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html . For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on the source code repository to get the latest and best Parrot code. Parrot 0.7.1 News: - Implementation + add -I and -L command line options + support for null strings in NCI calls + preliminary support for resumable exceptions + add '.hll_map' method for dynamic HLL type mapping + more parrot_debugger fixes + remove obsolete '.past' extension - Languages + Rakudo (Perl 6) - now over 3300 passing spectests - precompiled modules - precompiled scripts (--target=pir can now be executed standalone) - Support for @*INC and %*INC varialbes - additional builtin methods and subs - added 'fail' function, warnings on use of undefined values - m/.../ regexes - qq, qw, q quoting forms - run tests in parallel - gather/take - Perl6MultiSub + Cardinal (Ruby): - 'require' and precompiled modules - many new tests - all Array tests pass - regexes - default arguments to functions - new committer - Compilers + PCT: - add :loadinit attribute for PAST::Block + PIRC: - major refactoring to allow all PIR keywords as identifiers - links to libparrot now, so all Parrot ops are recognized as such - implemented .loadlib, .HLL_map, .HLL - Miscellaneous + add Xlib and Mysql modules and test programs to NCI examples + many updates and cleanups to PDD documents Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 21 Oct 2008. Enjoy!
Re: [perl #52778] [RFC] Are resizable arrays too Perlish?
On Sun, Sep 14, 2008 at 12:41:42AM -0700, Christoph Otto via RT wrote: I got impatient and committed this as r31101. I'm marking this ticket as resolved. According to [1], r31101 causes Rakudo to stop building with the following error: $ make ../../parrot /home/pmichaud/parrot/trunk/runtime/parrot/library/PGE/Perl6Grammar.pbc \ --output=src/gen_grammar.pir \ src/parser/grammar.pg src/parser/grammar-oper.pg ../../parrot /home/pmichaud/parrot/trunk/compilers/nqp/nqp.pbc --output=src/gen_actions.pir \ --encoding=fixed_8 --target=pir src/parser/actions.pm Null PMC access in get_bool() current instr.: 'parrot;NQP::Grammar::Actions;routine_def' pc 33982 (src/Grammar/Actions.pir:403) called from Sub 'parrot;NQP::Grammar;routine_def' pc 20036 (src/Grammar_gen.pir:7553) called from Sub 'parrot;NQP::Grammar;noun' pc 25828 (src/Grammar_gen.pir:9806) called from Sub 'parrot;NQP::Grammar;term' pc 22730 (src/Grammar_gen.pir:8622) called from Sub 'parrot;PGE::OPTable;parse' pc 1959 (compilers/pge/PGE/OPTable.pir:554) [...] As a temporary fix, Reini Urban reverted parts of the r31101 patch in r31108. I've traced the problem back to NQP; it was testing a value retrieved from a ResizablePMCArray for truth without first checking it for PMCNULL. I've since fixed that part of NQP (r31115). However, this does point out that there may be other languages and tools in Parrot that likewise depend on the old behavior of the various *Array types, so I'm reopening this ticket until all of those have been tested. In fact, it may be that we should revert r31101 entirely and go through a complete deprecation cycle before changing the behaviors of the core Array types in this manner, in case there are other libraries or languages depending on it. Pm 1. http://groups.google.com/group/perl.perl6.internals/msg/2cd7d9ede7a3cd4e
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Sat, Sep 13, 2008 at 09:09:58AM -0400, Will Coleda wrote: --- trunk/include/parrot/exceptions.h (original) +++ trunk/include/parrot/exceptions.h Fri Sep 12 21:05:37 2008 @@ -87,7 +87,8 @@ CONTROL_OK, CONTROL_BREAK, CONTROL_CONTINUE, -CONTROL_ERROR +CONTROL_ERROR, +CONTROL_TAKE } exception_type_enum; Tcl can currently deal with OK, CONTINUE, BREAK, ERROR, and RETURN. What's TAKE? TAKE is like CONTROL_RETURN except that it signals that we expect execution to continue after the point of the TAKE. It's quite similar to a .yield operation for coroutines. Speaking of exception type names, I have a question about CONTROL_BREAK and CONTROL_CONTINUE. An interesting artifact of Perl 6 is that it has break and continue keywords, but they don't apply to looping constructs the way that break and continue do in other languages. (The Perl analogues of C's break and continue are last and next.) I know that we're explicitly not trying to make Parrot directly follow Perl's models, but perhaps the rationale for having Perl (both 5 and 6) choose next/last instead of the traditional break/continue might be applicable to Parrot nomenclature as well. So, perhaps CONTROL_BREAK and CONTROL_CONTINUE should really be CONTROL_NEXT and CONTROL_LAST (and we may also want a CONTROL_REDO in there somewhere also). Pm
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Sat, Sep 13, 2008 at 01:55:05PM -0400, Will Coleda wrote: +CONTROL_TAKE } exception_type_enum; Tcl can currently deal with OK, CONTINUE, BREAK, ERROR, and RETURN. What's TAKE? TAKE is like CONTROL_RETURN except that it signals that we expect execution to continue after the point of the TAKE. It's quite similar to a .yield operation for coroutines. Would CONTROL_YIELD make more sense? I would have known what yield meant. It might be a bit misleading, because it doesn't actually correspond to a .yield (and thus I can envision CONTROL_YIELD as yet another exception type). I'm still brainstorming ways to get the gather/take semantics we need by using Parrot's .yield, but so far I haven't come up with a good way to do it. Pm
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
On Fri, Sep 12, 2008 at 03:47:27PM +0200, NotFound wrote: Defining the hash entries for the subs in PIR syntax is awful. So I envision Makefile.pl, Makefile.nqp or Makefile.p6 for this syntax. For p6 we must ensure that every parrot package has a perl6 also then. Not good. So pl, pir or the simple nqp. The libs and scripts could be written in Perl 6 and compiled to bytecode. In this way the languages would need no full Perl 6, just some *.pbc files. That can open a can of worms. The .pbc generated from perl6 will need installed perl6 .pbc files for perl6 objects, builtins, who knows what more. Worse, it can use eval'ed strings that needs the compiler. It will not be nice to talk about language neutrality while requiring perl6 to install a completely unrelated language. Agreed. This is exactly the niche that NQP is meant to fill. If we need to add some features to NQP to make this possible, then that can be done. Pm
Re: Where did the toggle switch go?
On Thu, Sep 11, 2008 at 08:11:50AM -0400, James E Keenan wrote: Is it just me ...? When I went to rt.perl.org just now to reply to a ticket, I could not find the toggle for automatically CC-ing [EMAIL PROTECTED] I know it was there just last night. I am clearly logged in to RT. What gives? Perhaps you were looking at a ticket in the perl6 queue? The automatic Cc: for perl6-internals only applies to tickets in the parrot queue. Pm
Re: [perl #54000] [DEPRECATED] get_array, get_list, get_scalar methods
On Wed, Sep 10, 2008 at 07:53:13PM -0700, James Keenan via RT wrote: Patrick: Where do we stand in the deprecation cycle re these three methods? I probably just need to remove the methods from the code, see what breaks, and fix what breaks. I'll try to do that this weekend before the release. If it doesn't happen then, we can do it immediately following the release. Pm
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Tue, Sep 09, 2008 at 08:46:33AM -0400, Andy Dougherty wrote: Parrot's also not using AIO anywhere either, so the whole probe is kind of pointless right now. Mainly, I was just hoping that a minor fix would help solve Patrick's problem of Configure.pl hanging during the aio probe. I don't know if it actually made any difference. The minor fix (preventing the infinite loop in the probe) has made a _huge_ difference, thanks. Pm
Re: [perl #54110] [BUG] segfault in infix/n_infix with string arguments
On Fri, Sep 05, 2008 at 05:20:45PM -0700, Christoph Otto via RT wrote: On Tue, May 13, 2008 at 9:48 AM, via RT Patrick R. Michaud The infix and n_infix opcodes cause segfaults when invoked with string arguments. (Kubuntu 8.04, x86, r27472) $ cat z.pir .sub main :main $P0 = new 'Float' $P0 = 3 n_mul $P1, $P0, 4 say $P1# 12 .end $ ./parrot z.pir Segmentation fault $ Is this bug going to continue to be relevant, since the pdd27mmd branch has removed the n_* opcodes (and presumably trunk will too after the branch is merged back)? Just for clarification: IIUC, the n_* opcodes and their semantics aren't really going away -- they're simply being renamed to not have the leading n_ prefix. It's the existing add, sub, mul, div, etc. opcodes that are being eliminated. So, trying the above code in the pdd27mmd branch (and changing the 'n_mul' to 'mul'), I now get: $ cat x.pir .sub main :main $P0 = new 'Float' $P0 = 3 mul $P1, $P0, '4' say $P1# 12 .end $ ./parrot x.pir error:imcc:The opcode 'mul_p_p_sc' (mul3) was not found. Check the type and number of the arguments in file 'x.pir' line 5 $ This would seem to indicate that the string variants of the various math opcodes are also going away (and that's okay with me). So, if we can just get an official ruling that the add_p_p_s, sub_p_p_s, etc. opcodes are going away, then we can close this ticket as moot. If they're not going away, then this ticket is still relevant. It would also be relevant because Parrot trunk fails on the non-n_ versions of the opcodes in the same way: $ cat x.pir .sub main :main $P0 = new 'Float' $P0 = 3 $P1 = new 'Float' mul $P1, $P0, '4' say $P1# 12 .end $ ./parrot x.pir Segmentation fault Pm
Re: [perl #58278] [BUG] Slurpy params give Cannot morph a Perl6Scalar. error
Patch rejected; the patch appears to eliminate Perl6Scalar
entirely from the 'is copy' semantics, this means we'd be without
an appropriate Scalar container for something like
sub foo($a is copy) { ... }
In general I think much of the signature handling in Rakudo needs
a significant refactor, so I'm a bit reluctant to apply small
tweaks until that happens.
Thanks!
Pm
@@ -1089,8 +1090,7 @@ method signature($/) {
),
PAST::Op.new(
:inline(
-'%r = new Perl6Scalar',
-'%r.infix:=(%0)'
+'%r = clone %0'
),
PAST::Var.new(
:name($parameter.name()),
Re: [perl #46457] [BUG][IMCC] long sub invocation with named parameters
On Mon, Sep 08, 2008 at 09:28:47AM -0700, NotFound via RT wrote:
The code in this ticket does not parse. Is using obsolete syntax? Can
someone provide an updated version?
Perhaps:
.sub main
.local pmc foo
foo = get_global 'foo'
foo('x' = 1, 'y' = 2)
foo(1 :named('x'), 2 :named('y'))
.begin_call
.arg 1 :named('x')
.arg 2 :named('y')
.call foo
.end_call
.end
.sub foo
.param int i :named('y')
.param int j :named('x')
say i
say j
.end
Running this on r30913 gives me the same message as the original post:
$ ./parrot x.pir
error:imcc:Named parameter with more than one name.
in file 'x.pir' line 10
Pm
pdd23 - subs as exception handlers
PDD23:41 says : =item Bpush_eh IINVOCABLE_PMC : : Push an invocable PMC -- usually a closure or, in rarer cases, a subroutine or : continuation -- onto the exception handler stack. : ... : If a IINVOCABLE_PMC is provided, Parrot pushes the pmc which will execute : if invoked, which has the effect of unconditionally handling all errors, : replacing the stack with that execution context of the invocable pmc. 1. Can someone create or point me to a working example that uses this form of exception handler (i.e., with an invocable pmc instead of a label as the target of push_eh)? The variations I've tried all seem to result in segfaults. 2. The phrase ...pushes the pmc which will execute if invoked... sounds very odd to me. I think it should be something like ...pushes a pmc to be invoked as an exception handler... Pm
