Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Wed, Jul 09, 2008 at 01:27:29AM -0400, Bob Rogers wrote:
>What "foo" should do is create a closure and call that:
>
> .const .Sub inner = 'inner'
> inner = newclosure inner
> inner()
If I understand what you're saying, and then take it to what I see
as its ultimate conclusion, you're basically claiming that every
call to a subroutine involving lexicals requires a newclosure op.
Consider:
{
my $x = 1;
sub foo() { say $x; }
foo();
}
In effect this is little different from having 'foo' as an immediate
block. If we now say that a newclosure op is required to invoke 'foo',
then that means that the 'foo()' HLL subroutine has to be generated as:
.local pmc $P0
$P0 = find_name_not_null 'foo'
$P0 = newclosure $P0
$P0()
Of course, for any given subroutine call like 'foo()', the compiler
tools can't be certain at compile time that 'foo' is in fact a
Closure PMC, so we really have to generate:
$P0 = find_name_not_null 'foo'
$I0 = isa $P0, 'Closure'
unless $I0 goto xyz
$P0 = newclosure $P0
xyz:
$P0()
That 'isa' step presents a bad design smell to me -- why should we
have to test every sub for Closure-ness prior to invoking it?
It all gets worse if I have something like:
.sub 'abc' :multi('Integer')
...
.end
.sub 'abc' :multi('String') :outer('xyz')
...
.end
One of these is a Sub PMC, the other is a Closure PMC, and the thing
that is stored under symbol 'abc' is neither -- that's a MultiSub PMC.
I'm fairly certain I can't do "newclosure" on the MultiSub PMC. In
fact, the caller doesn't have any way of knowing which sub is going
to be invoked without actually invoking it, so we really can't do a
'newclosure' on it.
Ultimately I think that Closure PMCs need to be smart enough to take
a newclosure if they need one at the time they're invoked, rather than
trying to place that burden on the caller. (Note that I'm not arguing
that the current implementation is correct -- I'm just describing what
I think a correct implementation will need to do.) I also think we
probably still need to have a newclosure opcode available to allow
PIR to explicitly say when to take a closure, but I don't think it
should be required in the PIR generated for every HLL subroutine
invocation.
> [...]
>
>It may be possible to rescue Patrick's desired behavior by keeping
> track of whether the outer_sub was initialized by newclosure or not.
My 'desired behavior' is simply that we have something that works. :-)
But I suspect that this means that closure PMCs will have to keep
track of whether they've already been newclosured.
> Personally, I'd prefer if it were always an error to call a closure sub
> directly; implicitly initializing the outer context is bad enough, but
> re-initializing it is worse. (But we've had this discussion before [1],
> and I was not persuasive.)
Given the examples I listed above, I think we _have_ to provide a way for
Closure PMCs to be invoked directly from PIR, and then either the Closure PMC
vtable_invoke method or IMCC performs whatever context initialization
and/or fixups that are needed to have everything work.
(Also, a reminder that whatever we do to fix this ticket has to keep
RT #56184 working as well. :-)
Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
[typo clarification] On Wed, Jul 09, 2008 at 08:25:52AM -0500, Patrick R. Michaud wrote: > [...] If we now say that a newclosure op is required to invoke 'foo', > then that means that the 'foo()' HLL subroutine has to be generated as: > > .local pmc $P0 > $P0 = find_name_not_null 'foo' > $P0 = newclosure $P0 > $P0() That should read "...that the 'foo()' HLL subroutine *call* has to be..." Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Wed, Jul 09, 2008 at 04:46:19PM -0400, Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>...
>If we now say that a newclosure op is required to invoke 'foo',
>then that means that the 'foo()' HLL subroutine has to be generated as:
>.local pmc $P0
>$P0 = find_name_not_null 'foo'
>$P0 = newclosure $P0
>$P0()
>. . .
>
> Not true. The compiler always knows when it's compiling a closure. So
> if, at the point of definition, the emitted code does:
> foo_closure = newclosure foo_sub
> set_hll_global 'foo', foo_closure
> then the compiler doesn't have to treat calls to "foo" specially.
So, if I understand you correctly, for something like
for 1..10 -> $x {
sub foo() { say $x; }
foo();
}
you're saying we should replace the 'foo' symbol ten times -- each
time with a newclosure taken from whatever was previously stored there.
Also, we can't do this exactly at the point of definition, because
sub calls can lexically occur before the definition of the thing
they're calling. So it has to be moved higher in the block somehow.
>It all gets worse if I have something like:
>.sub 'abc' :multi('Integer')
> ...
>.end
>.sub 'abc' :multi('String') :outer('xyz')
> ...
>.end
>One of these is a Sub PMC, the other is a Closure PMC, and the thing
>that is stored under symbol 'abc' is neither -- that's a MultiSub PMC.
>I'm fairly certain I can't do "newclosure" on the MultiSub PMC . . .
>
> I think you're right, but that is probably for good reason; I don't
> think it makes sense. Instead, you should do newclosure on the method
> sub, and then define the closure as a method on the MultiSub. And if
> you can't do that, I claim that is a shortcoming of the Parrot MOP.
I don't know what you're meaning by "method sub" here, but I'm not
sure it's important that I know. As I said earlier, I'm not at all
arguing that Parrot's current model is correct, or that the way I've
been trying to do things is the right one -- I'm merely asking "What
is the correct way to do this stuff in Parrot?"
So, if the "correct" answer is that a sub definition should
rebind the sub's name to the result of a newclosure opcode, my
response is "okay, but that doesn't seem to work for MultiSubs".
If the response to that is "Parrot's MultiSub model is broken", I won't
argue with that, but then someone (probably shouldn't be me, but
I'll do it if there's no other option) needs to design and
implement a model that isn't broken, or suggest how languages
can work around it.
>Ultimately I think that Closure PMCs need to be smart enough to take
>a newclosure if they need one at the time they're invoked, rather than
>trying to place that burden on the caller. (Note that I'm not arguing
>that the current implementation is correct -- I'm just describing what
>I think a correct implementation will need to do.)
>
> That's good; we semi-agree. But I'm arguing further that making parrot
> guess the right context is also broken, certainly in some if not all
> situations.
My feeling is that the "some situations" where guessing the context
is wrong will be those where the HLL compiler inserts "newclosure"
opcodes to get parrot to do the right thing. I don't think that
guessing will be wrong in all (or even the majority) of situations--
immediate block/sub execution is *so* much more common than the
need to take an explicit closure that it feels like Parrot ought
to support that model by default. If that's not Parrot's default,
that's fine, but I'd like someone or a PDD to officially say that
every sub with :outer *must* have a newclosure op.
> I would like at least to persuade you that your badlex.pir
> case is incorrect (but will settle for only semi-agreeing. ;-)
As I said above, I don't have to be persuaded that badlex.pir
is incorrect -- I just need to be shown what "correct" is.
As I've already noted, simply replacing the symbol with a
newclosure PMC doesn't work in the case of MultiSubs.
> We *definitely* need newclosure; otherwise there can only ever be one
> closure at a time. Except perhaps by cloning the closure, and hoping
> that the runtime magic does the right thing. But I claim that compilers
> can always emit code that knows what the right context is; why should
> parrot
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Wed, Jul 09, 2008 at 03:45:31PM -0700, chromatic wrote: > > That example is fine with me. I almost deleted all of the hijinks necessary > in Closure PMC to attach to a never-initialized outer lexical scope before I > read the lexical spec again and realized that someone designed it that way. > ... > Given the simplicity of the workaround (which actually works) and the > difficulty of making the broken-as-designed feature work partially, I vote > for removing the brokenness. FWIW, I don't have any problem with having Parrot throw an exception if someone invokes an inner lexical scope for which its outer lexical scope has not been invoked yet. Let's solve that problem when we come to it (and I don't know that Perl 6 will ever come to it -- again, I haven't worried about that case yet). Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Wed, Jul 09, 2008 at 04:46:19PM -0400, Bob Rogers wrote:
Content-Description: message body text
>In effect this is little different from having 'foo' as an immediate
>block. If we now say that a newclosure op is required to invoke 'foo',
>then that means that the 'foo()' HLL subroutine has to be generated as:
>.local pmc $P0
>$P0 = find_name_not_null 'foo'
>$P0 = newclosure $P0
>$P0()
>. . .
>
> Not true. The compiler always knows when it's compiling a closure. So
> if, at the point of definition, the emitted code does:
>
> foo_closure = newclosure foo_sub
> set_hll_global 'foo', foo_closure
>
> then the compiler doesn't have to treat calls to "foo" specially.
...would we also have to generate code to restore the previous
value of 'foo' upon exiting the sub? (Think recursive calls here.)
sub bar($x) {
sub foo() { say $x; }
if ($x > 0) { bar($x-1); }
foo();
}
Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Thu, Jul 10, 2008 at 12:29:57AM -0400, Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>Date: Wed, 9 Jul 2008 18:49:53 -0500
>
>On Wed, Jul 09, 2008 at 04:46:19PM -0400, Bob Rogers wrote:
>> Not true. The compiler always knows when it's compiling a closure. So
>> if, at the point of definition, the emitted code does:
>> foo_closure = newclosure foo_sub
>> set_hll_global 'foo', foo_closure
>> then the compiler doesn't have to treat calls to "foo" specially.
>
> Yes; because I think that is what the code means. Indeed, I think you
> yourself have already suggest that making closures in a loop requires
> newclosure anyway [0]. Or are you saying that this case is different?
I think misread what you originally wrote, not seeing the difference
between 'foo_sub' and the global 'foo'. Sorry about that.
> Shouldn't
>for 1..10 -> $x {
> sub foo() { say $x; }
> push(@foos, \&foo);
>}
> produce the same result as
>for 1..10 -> $x {
> my $foo = sub { say $x; };
> push(@foos, $foo);
>}
> modulo global namespace mangling (and broken Perl 6 syntax)? And if
> not, why not?
Yes, the two examples above would be the effectively the same, but
neither of them are the same as my original. Perl 6 recognizes
taking a closure at the point where a sub is referenced (used as an rvalue),
so in the first example we would do the newclosure at the &foo
reference inside the push() call, the second example we would do
the newclosure as part of the "my $foo" assignment. But according to
Synopsis 4 [1], if we simply define foo and call it directly
(as opposed to taking a reference), we don't take that snapshot of its
lexical scope. (I'm making the leap that "takes a snapshot" in the
Synopsis means "newclosure" in Parrot.)
>Also, we can't do this exactly at the point of definition, because
>sub calls can lexically occur before the definition of the thing
>they're calling. So it has to be moved higher in the block somehow.
>
> Eh? Can't do what at the point of definition? Do you have an example?
By "this" I meant "take a newclosure and store it in the
symbol table". The following is valid Perl 6:
my $x = 'hello';
foo();
sub foo() { say $x; }
At the point of the foo() call, we have to have already stored
an entry in the symbol table for 'foo', thus if we wait until
the sub declaration to do that, it's too late. So, we have to
move the newclosure+store sequence to a point earlier in the block
than where the sub declaration itself occurs.
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>...would we also have to generate code to restore the previous
>value of 'foo' upon exiting the sub? (Think recursive calls here.)
>
>sub bar($x) {
> sub foo() { say $x; }
> if ($x > 0) { bar($x-1); }
> foo();
>}
>
> No. AFAIK, "sub foo() { ... }" always mangles the global definition of
> foo. So in Perl 5, the first call wins; in Perl 6, it might be the last
> call, but I don't really know.
Okay, I wasn't aware of this for Perl 5, so perhaps Perl 6 has similar
semantics. But in my head it doesn't seem to match what I read
in Synopsis 4 at [1], particularly where S04 says
my sub bar { print $x } # not cloned yet
(Again I'm making the leap that 'cloning' in the synopsis is what
we mean by 'newclosure' in Parrot.)
>To summarize, I am not arguing that relying on "autoclose" is
> necessarily wrong, and that we should therefore get rid of it.
> [...]
I don't exactly understand what "autoclose" is (even after reading
the other thread) -- my impression is that it refers to invoking
or taking a snapshot of an inner sub's lexical environment
even when its outer context hasn't been invoked yet. If this
limited understanding of "autoclose" is correct, then I don't think
my examples are relying on it; but if the examples I'm giving
do make use of the "autoclose" feature you keep referring to,
then I guess I need to learn more about "autoclose" to be able
to talk intelligently about it.
Pm
[1]
http://dev.perl.org/perl6/doc/design/syn/S04.html#When_is_a_closure_not_a_closure
Re: [perl #56806] [BUG] test failures in languages/pynie
On Thu, Jul 10, 2008 at 11:20:44AM -0700, Will Coleda wrote: > # New Ticket Created by Will Coleda > # Please include the string: [perl #56806] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=56806 > > > > pynie's test suite fails with [EMAIL PROTECTED] > > Test Summary Report > --- > t/00-parrot/05-vars.t(Wstat: 256 Tests: 0 Failed: 0) > Non-zero exit status: 1 > Parse errors: No plan found in TAP output > ... r28325 appears to be the culprit. Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Thu, Jul 10, 2008 at 09:35:29PM -0400, Bob Rogers wrote:
> Hmm. I have been assuming that when you say "taking a closure", that is
> equivalent to "using *the* closure" for a given :outer context. It's
> beginning to dawn on me that this might not be what you mean; more
> below.
I think I'm not certain exactly what I mean here either. :-|
>But I don't think this is out of the ordinary. As an example of
> another nontrivial case of BEGIN-time processing, consider the following
> Perl 5 code:
>
> sub foo {
> print "This is the original foo.\n";
> }
>
> my $old_foo;
> BEGIN {
> $old_foo = \&foo;
> }
>
> sub foo {
> print "Out with the old, in with the new.\n";
> $old_foo->();
> }
>
> foo();
Perl 6 disallows having multiple subs of the same
name unless they are explicitly declared 'multi' or
the later subs provide the "is instead" trait [1].
Yes, handling 'is instead' may mean we need some
adjustments to the compiler -- but I think it's
more likely that we'll have Perl 6 namespace PMCs
that throw an exception when something attempts
to overwrite an existing sub using the normal
'add_sub' mechanisms.
> [...] However, if some
> or all of these references were "downward" (i.e. not referenced after
> the containing block returns), then the compiler need not implement
> those subs via closures. In Parrot, the two available technologies for
> doing this are inlining, and generating bsr/ret subroutines.
...but those technologies are available only if the nested closures
don't have any local lexicals of their own. If they do, then we still
need a separate .sub to be able to hold their lexicals.
Unfortunately, at this point in the discussion I don't feel I
understand enough about closures and lexicals to be able to
posit what S04 is really talking about, or to helpfully respond to
the points and questions you're raising--which I'm sure are good
ones. I think I need to take a break from this topic for
a while, because it's highly frustrating to me right now.
(None of what you're saying or doing is the source of that
frustration -- it's simply that I feel like I'm stumbling
and speaking blindly about a topic that isn't clear to me
yet and for which I seem to be unable to find any concrete
answers about this topic in either Parrot or Perl 6 that
will enable me to build a framework of understanding.)
> Since at least October 2006, and up through r28762, "autoclose" meant
> the ability of subs marked with :outer to turn into working closures
> without the benefit of "newclosure".
OK, this part I understand better now. Yes, I'm using autoclose, as
you describe it here.
>So you are definitely using "autoclose." In fact, your RT#56398
> ticket effectively asks to extend this feature so that it updates the
> outer_ctx on *every* call, which (as implemented) breaks newclosure.
If that's what I was effectively asking in RT #56398, it was *completely*
unintentional on my part. All I'm really wanting to know is what
PIR the compilers and tools should be emitting for these very
common Perl 6 constructs, and to have that PIR work in Parrot.
Trying to get simple nested blocks and subs containing lexical
variables to work in Rakudo and NQP has been and continues to be
a very frustrating trial-and-error exercise, and I just want
(pardon the pun) closure.
Thanks again for bearing with me on this, and my apologies for
not really being able to respond to the points you're raising.
Pm
Re: [perl #56816] [BUG] issues with PMCProxy, 'typeof', and 'get_class'
On Thu, Jul 10, 2008 at 06:50:51PM -0700, chromatic wrote: > > Here's a first approach. It breaks a couple of tests, but it's a start: > > t/pmc/object-meths (Wstat: 1280 Tests: 37 Failed: 5) > Failed tests: 1-4, 16 > t/oo/proxy (Wstat: 256 Tests: 5 Failed: 1) > Failed test: 3 > > I believe a solution is to make a Class PMC stick the appropriate PMCProxy in > its attached NameSpace's class slot when created, but I haven't tested that > (and won't have a chance for a few hours). Okay, that confuses me a bit. I agree it makes sense to have the PMCProxy placed in the attached NameSpace's class slot... but IIUC a PMCProxy isn't created until it's explicitly requested (e.g., via the 'get_class' or 'typeof' opcodes). I don't think there's anything that automatically builds PMCProxy objects for all of the PMC types at initialization (i.e., "when created"). Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Thu, Jul 10, 2008 at 09:51:40PM -0500, Patrick R. Michaud wrote: > Perl 6 disallows having multiple subs of the same > name unless they are explicitly declared 'multi' or > the later subs provide the "is instead" trait [1]. Oops, I cut off the reference while sending: [1] http://dev.perl.org/perl6/doc/design/syn/S06.html#Stub_declarations Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Thu, Jul 10, 2008 at 11:23:03PM -0400, Bob Rogers wrote: >All I'm really wanting to know is what >PIR the compilers and tools should be emitting for these very >common Perl 6 constructs, and to have that PIR work in Parrot. > > Seriously, though, I've been wanting to learn more about Rakudo and PGE > for a while now. If you have some specific problems in this area that > you'd like to point me at, that might make a good start. (Not that I > have much Parrot-hacking time to spare. But you probably already know > that.) This is as simple as me providing some sample Perl 6 code that is giving me trouble and then we come up with the PIR that handles it. You've already helped with the case for this original ticket by saying it should do a newclosure and store the result into the namespace's symbol table. (I'm not sure that's ultimately the right answer for Perl 6, but we can try it and see what breaks.) I suspect we'll have to do a similar step for methods, except we'll have to dynamically use 'add_method' to place the method into the class instead of storing it in the namespace. I _think_ those are the only two cases where we have to do something like this, and I guess they aren't too onerous. It'll be interesting to see how PCT gets updated to cope with these, since it really belongs there and not strictly in Rakudo. Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Thu, Jul 10, 2008 at 11:06:55PM -0500, Patrick R. Michaud wrote: > > I _think_ [methods and subs] are the only two cases where we > have to do something like this, and I guess they aren't too onerous. I was wrong, the third case is MultiSubs, and at the moment it's _very_ onerous, because we can't just replace things in the symbol table. But having given myself permission to take a break, I think I may have come up with a workable answer that does almost everything we (both) want. I'll try to phrase it in the terminology you've been using (and apologies if I slip up). If I understand your messages correctly, the main problem with "autoclosures" is the "auto" portion -- i.e., trying to capture variable bindings automatically at the time a closure is invoked, and doing this only once on the closure's first invocation. Let's agree that this behavior is wrong. Let's go even further and explicitly make this an error, such that invoking a Closure PMC where its outer_ctx is null throws an exception. However, I'd still like the capability to give an existing Closure an outer_ctx without having to replace it in the symbol table, method table, or MultiSub PMC. Thus "newclosure" doesn't really do what I want, because it always creates a new Closure PMC, and then I have to somehow get that new PMC into its correct sub/method/multisub location. What I really want is a way to give an existing Closure PMC an outer_ctx (but not automatically as part of invocation). So, I propose that we add a "capture" method to Closure PMCs to set the outer_ctx for that PMC. This is roughly equivalent to what 'newclosure' does now, but doesn't clone the Closure PMC prior to capturing the variable bindings. This capture method would be called from the outer sub at whatever point we would otherwise be doing a "newclosure+store" operation. But now since we're not creating a new PMC, we don't have to worry about trying to fix up the symbol table, method table, or MultiSub entry that references the current Closure. (Side note: we _could_ make this a 'capture' opcode instead of a method, but I'm not a big fan of opcodes that only work on one PMC type. In fact, I often wonder if the 'newclosure' opcode should really be a method on Capture, since (at present) it only works on Capture PMCs. OTOH, perhaps an opcode is much faster than a method call, and perhaps capture/newclosure warrant speed here.) In fact, with a 'capture' method or opcode, we might not need 'newclosure' at all. A newclosure operation could potentially be done by: $P0 = clone $P0 # clone the Capture PMC $P0.capture() # capture outer context into the clone But this is a feature, and we can certainly keep 'newclosure' around if we want to do a clone+capture sequence. Just having something like the capture method described above seems like it would solve my problems without resorting to autoclosures. The PIR for my Perl 6 example could then look something like: .sub 'foo' .param pmc x .lex '$x', x .const 'Closure' inner = 'inner' ## capture variable bindings for inner inner.'capture'() print "outer foo " say x 'inner'() .end To repeat, in this scenario, invocation never does a capture on its own -- that's always up to the outer sub to handle by doing either a newclosure or capture operation prior to invocation. If you and others think this is workable, then this is good enough for me. But there's more. :-) Instead of having Parrot do autoclosures -- i.e., automatically capture outer_ctx when an inner Closure is invoked -- perhaps we could have a way for an outer sub to automatically perform the captures for all of its inner subs. In other words, every sub would maintain a list of its inner subs (automatically created from the inner subs' :outer flags), and then the outer sub can automatically set the outer_ctx for all of its inner closures. This could happen either as part of the outer sub's invocation, or it could be an explicit instruction or method call generated by the HLL compiler. Based on what Bob has been saying, I can't now think of a case where an inner closure _shouldn't_ go ahead and have its outer_ctx set whenever an outer sub is invoked. There might be a small optimization to be had if we can determine that some inner closure can't be invoked (and thus we don't need the capture operation), but I'm thinking that the cost of immediately assigning outer_ctx to all inner subs is far less than doing separate newclosure+store operations for each. (Perhaps there's another reason this approach can't work.) Anyway, that's my proposal for now -- feel free to shoot holes in it or tell me where I've overlooked something or misunderstood closures once again. :-) Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Fri, Jul 11, 2008 at 04:49:55PM -0400, Bob Rogers wrote: >Based on what Bob has been saying, I can't now think of a case where >an inner closure _shouldn't_ go ahead and have its outer_ctx set >whenever an outer sub is invoked . . . > > Foul! That's exactly what r28763 does to break my code. Okay, I give up. I don't see exactly how .sub 'outer' .const 'Sub' inner_sub = 'inner' inner_sub.'capture'() ... is substantially different from .sub 'outer' .const 'Sub' inner_sub = 'inner_sub' $P0 = newclosure inner_sub set_global 'inner', $P0 ... In each case, the capture is occurring at the beginning of the outer sub invocation, and the 'inner' symbol table entry points to a Closure that has 'outer' as its outer context. Also, the Perl 5 examples you're providing don't really help me understand the issues much, as I've never done a lot of work with closures in Perl 5, they don't map exactly to Perl 6, and Perl 5's notion of symbol table handling is a fair bit different from Parrot and Perl 6. I really need to see examples of PIR that don't work, or to have the Perl 5 translated into what you think the equivalent PIR should be. Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Fri, Jul 11, 2008 at 04:49:55PM -0400, Bob Rogers wrote:
Content-Description: message body text
>This is certainly not the case for recursive subs. Consider the
> attached example, a lightweight Perl 5 dumper. (It is slightly
> artificial to break the recursive step out into a sub, but that might
> make sense after adding hash support.) We need a distinct closure for
> each level of dump_thing call, lest $prefix refer to the wrong thing.
> And we need to call those closures from registers, to be sure that we
> are calling the right one.
In the attached example, I think the lines
> my $recur = sub {
> my $subthing = shift;
>
> dump_thing($subthing, $prefix.' ');
> };
guarantee that $recur gets a distinct closure for each level
of call, since a closure is cloned upon assignment. In other
words, the assignment is where a separate newclosure would be
performed (or, in my example, simply cloning the closure directly).
Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Sat, Jul 12, 2008 at 01:11:12AM +0200, Jonathan Worthington wrote: > This is consistent with my view of the specified Perl 6 semantics[1] for > closure handling. I translated Bob's Perl 5 example into PIR and put > newclosure where the Perl 6 specification would suggest to put it and it > produces the same output as the Perl 5 script. This is without doing > *any* newclosure calls prior to a call, just some when we are taking a > reference. > > Pm: I hope the PIR helps you understand Bob's example better. Notice > that we do newclosure whenever a block is referenced (where by block I > mean anything compiled down to a Parrot .sub) and the reference contains > the new closure, which makes sense because we're taking a closure > (recording a snapshot of it at that point) to invoke later. Yes, the translation helps a lot. But what you came up with is almost exactly what I would expect PCT/Rakudo to be generating _now_ for this code example (modulo a few minor details). So I'm still left without a good PIR counterexample that shows that PCT as presently designed will generate code that won't work. :-( > Note that this doesn't give any great answers yet about what happens > when we do newclosure on a multi, but I think we can make that do > something sane (snapshot the lot, perhaps? Need to think about what > falls out of that...) This is one of the possible advantages of the 'capture' approach proposed previously -- we can ensure that the capture operation always comes directly from the outer sub, so when iterating through the Closures in a MultiSub it's easy to determine which ones need a capture without having to chase up the caller chain for each one. Thanks a bunch, Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Sat, Jul 12, 2008 at 03:29:31AM +0200, Jonathan Worthington wrote: > But I'm not convinced that > we always take clones on referencing a block in Rakudo (OK, I've not > gone and looked, but I can't remember seeing anything that explicitly > does that, and I spend a lot of time staring at Rakudo... ;-)). At present we do not explicitly invoke newclosure in Rakudo, no. But at one point PCT did have that capability, and I temporarily removed it while trying to get the other lexical stuff to work. (Getting basic immediate blocks to work was far more important than block references.) It's no problem for me to put it back. Of course, if cloning works the same as newclosure than we don't need an explicit newclosure for the examples given, because assignment already makes a clone. > >So I'm still left without a good PIR counterexample that shows that PCT > >as presently designed will generate code that won't work. :-( > > > Do you have any good non-PIR examples (e.g. failing stuff in Perl 6)? Or > am I missing the point (which, at 3am, is very possible...) I don't have anything at present that fails in Perl 6 for reasons I can't explain. The only closure/lexical-related thing that might be failing at the moment is taking references to closures, and I already know why that wouldn't be working (because newclosure in PCT is currently disabled). The only thing I haven't really tried is simple recursion with inner lexical blocks or taking references, other than the example that you and Bob just put together. The reason this ticket was re-opened is because Bob is encountering problems after r28763 (http://rt.perl.org/rt3/Ticket/Display.html?id=56398#txn-440920). There he provides an example "recursive-lex.pir" file that illustrates the problem he is encountering, which I will have to study a bit more closely. > >>Note that this doesn't give any great answers yet about what happens > >>when we do newclosure on a multi, but I think we can make that do > >>something sane (snapshot the lot, perhaps? Need to think about what > >>falls out of that...) > >> > >This is one of the possible advantages of the 'capture' approach > >proposed previously -- we can ensure that the capture operation > >always comes directly from the outer sub, so when iterating through > >the Closures in a MultiSub it's easy to determine which ones need > >a capture without having to chase up the caller chain for each one. > > No, no. I'm thinking if we take a reference to an undisambiguated > multi...then we have to newclosure it (clone it) as we take a > reference...well, I guess then it just populates its clone to the > closures too. But we'd not want to close non-closures, I guess. So, hmm... With the 'capture' approach, we just clone it (this happens anyway upon assignment) so everything works as expected. We also don't have to worry about closing non-closures, as their outer_sub will always be NULL and so they are never candidates for captures. Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Fri, Jul 11, 2008 at 10:04:54PM -0400, Bob Rogers wrote:
> Absolutely, but that's not where the problem lies. The problem is that
> r28763 did so implicitly and unconditionally, overwriting anything
> newclosure might have done. If you meant "have its outer_ctx set
> I whenever an outer sub is invoked", then I apologize; I
> misunderstood you. (And in any case, it was rude to have honked.)
Let's see if I can make myself as clear as I can:
* I'm not at all trying to defend r28763 as being correct. Never
have been.
* In [1] I'm agreeing that capturing the lexical environment
at the time of closure invocation is wrong. Phrased another
way: In [1] I _think_ I'm completely agreeing that autoclosures
(capture at point of closure invocation) is bad, and we should
eliminate them. I guess I should've made this more explicit.
* What I suggested instead in [1] is that we capture the lexical
environment for the closure when its *outer sub* is invoked.
(This is not at all what r28763 does -- r28763 captures
the closure's lexical environment when the *closure*
is invoked, which I agree is wrong.)
* I don't see that it matters significantly if the automatic
capture for closures occurs explicitly (by PIR statements
placed at the beginning of the outer sub) or implicitly
(by Parrot when the closure's outer sub is invoked). The
second would be much more efficient if it can be done, and
would alleviate the need for the compiler to generate the
explicit calls, but as I said in [1], I'm willing to go with
the explicit version if need be.
[1] http://rt.perl.org/rt3/Ticket/Display.html?id=56398#txn-442254
>In the attached example, I think the lines
>> my $recur = sub {
>> my $subthing = shift;
>> dump_thing($subthing, $prefix.' ');
>> };
>guarantee that $recur gets a distinct closure for each level
>of call, since a closure is cloned upon assignment.
>
> Yes; this was intended as an example where "autoclose" clearly does not
> work.
Since I thought I had already stipulated that autoclose doesn't
work, I didn't understand the point of the example.
>But I must confess that I still don't understand what it means not to
> "clone" a closure. What is an "uncloned closure" anyway? Will @Larry
> deign to speak?
Instead of trying to answer "What is an uncloned closure", I'll
try answering "What is a cloned closure?" Based on my understanding
of things after figuring out the approach in [1], every closure
gets a capture from its outer sub, but we clone those closures that
we may need to return or reference in another context. Cloning
occurs whenever a closure is used in an rvalue context (but isn't
being immediately invoked).
>Let me try to clarify: The only reason I mentioned stuffing closures
> back into the symbol table was to show that "autoclose" is not
> necessary. (I failed, though, because Patrick correctly pointed out
> that "autoclose" is currently required for methods, with or without the
> "multi-", though I consider it a bug that you *have* to autoclose in
> these cases; I'm not convinced that can always be made to work.)
I think the approach I gave in [1] means we never have to autoclose
(again assuming autoclose means "capture at point of closure
invocation").
> IMHO, it does not make any sense to do newclosure on a MultiSub; I
> cannot imagine what that might mean.
Jonathan gave me the answer on IRC earlier tonight. Again, let's
consider "newclosure" as being a combination "capture + clone"
operation. Performing capture on a MultiSub simply means that
we loop through all of the elements of the MultiSub and perform
a capture on any of its individual closures where the outer_sub
matches the thing invoking the capture (since capture can only
be performed from a closure's outer sub). Perform a clone on
a MultiSub simply clones the MultiSub, which by virtue of the
'capture' operation on the MultiSub will have already had all
of the relevant closures set to the appropriate outer context.
To summarize:
1. AFAICT, after [1] I've completely come around to the idea that
performing a capture upon closure invocation (autoclose) is bad
2. We should provide a 'capture' operation that can be performed
at the beginning of any outer sub invocation to immediately bind
any closures specifying the current sub as :outer to the
current lexical environment.
3. Whenever a closure is to be returned or stored such that it
may be invoked from somewhere other than its outer context,
we simply clone it. (The closure will already have the
correct lexical environment by virtue of having performed
#2 above.)
Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Fri, Jul 11, 2008 at 08:00:40PM -0700, Bob Rogers via RT wrote: >Of course, if cloning works the same as newclosure than we don't >need an explicit newclosure for the examples given, because >assignment already makes a clone. > > Assignment seems to do assign_pmc, which for a closure invokes the Sub > method (there is no Closure method). Needless to say, Sub:assign_pmc > does nothing special to capture the current context; if that is NULL, > then "autoclose" takes over when the thing is called. You're _completely_ missing my point. If we follow my proposal to modify Parrot or code generation such that a capture operation is performed for closures at the beginning of every outer sub invocation, then by the time we get to an assign operation a closure would _already_ have its current context captured, so only a simple clone is needed (which is what assign normally does -- it makes a copy of whatever is being assigned). And again, under my proposal I've been saying (apparently ineffectively) that "autoclose" would be gone entirely, and invoking a Closure that hasn't already had its context captured (i.e, outer_ctx is NULL) will throw an exception. In other words, there's no chance that "autoclose takes over when the thing is called". Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Sat, Jul 12, 2008 at 01:07:20AM -0700, chromatic wrote: > > And again, under my proposal I've been saying (apparently > > ineffectively) that "autoclose" would be gone entirely, and > > invoking a Closure that hasn't already had its context captured > > (i.e, outer_ctx is NULL) will throw an exception. In other > > words, there's no chance that "autoclose takes over when the > > thing is called". > > Can I +1 more than once? I want this. I've found in several of my other projects that it's very useful to allow +2 and -2 votes as an indication of "strongly in favor" or "strongly opposed". I have much more to add about the example you provide, but it will take me a few hours to write it up and explain it properly. Hopefully it will point the way to a solution. Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Sat, Jul 12, 2008 at 12:30:02AM -0400, Bob Rogers wrote:
> ... But, as I quoted you:
>
> . . . if cloning works the same as newclosure than we don't need
> an explicit newclosure . . .
>
> Which seems to say something entirely different. So I thought I should
> point out that cloning does *not* work the same as newclosure.
Okay, now I understand where you were coming from. I should have said
"... in the new scheme, cloning the (already-bound) inner closures will
have the same effect that newclosure does now. Since assignment already
makes a copy (clone), we won't need an explicit newclosure."
> (And I still don't understand the *point* of cloning a closure.)
Short answer: cloning is what will enable the following to work:
for 1..10 -> $x {
sub foo() { say $x; }
push(@foos, &foo);
}
Longer answer: Assume under my proposal that we don't have
(or need) a newclosure opcode. Here's how things work: In the
above for loop, every time we execute the body of the loop, a
capture operation is performed on foo to give it the current
variable bindings. We don't get a new object for foo, we
just take the existing one and bind it to the new lexical
environment (losing any bindings we might have had from a
previous capture of foo).
In the push statement, however, we want to store a copy
of foo as it's currently bound. Thus we simply do a clone
of the current foo, which creates a copy (including its
current bindings) and stores it in the @foos array.
The & in &foo is what cues us to know that we need to
a clone, because we're using a closure in an rvalue context.
At the start of the next iteration of the for loop, we
again perform a capture on the foo sub to bind it to the
new lexical environment, However, this doesn't affect the
cloned copy that we saved in the previous iteration -- that
copy is still bound to the lexical environment of the previous
iteration. Which is exactly what we want.
Hope this helps. As I mentioned in my reply to chromatic
a few minutes ago, I have a *lot* more to add about this,
but it will take me a few hours to write it all up clearly.
Stay tuned.
Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Sat, Jul 12, 2008 at 08:50:44AM -0700, chromatic wrote:
> On Saturday 12 July 2008 08:06:33 Patrick R. Michaud wrote:
>
> > Short answer: cloning is what will enable the following to work:
> >
> > for 1..10 -> $x {
> > sub foo() { say $x; }
> > push(@foos, &foo);
> > }
>
> Is that really valid Perl 6 code? I can see "my sub foo" working there, but
> rebinding lexicals for global symbols goes against a decade of Perl 5 for me.
I don't know if it's valid or not.
Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Sat, Jul 12, 2008 at 11:05:35AM -0500, Patrick R. Michaud wrote:
> On Sat, Jul 12, 2008 at 08:50:44AM -0700, chromatic wrote:
> > On Saturday 12 July 2008 08:06:33 Patrick R. Michaud wrote:
> > > Short answer: cloning is what will enable the following to work:
> > >
> > > for 1..10 -> $x {
> > > sub foo() { say $x; }
> > > push(@foos, &foo);
> > > }
> >
> > Is that really valid Perl 6 code? I can see "my sub foo"
> > working there, but rebinding lexicals for global symbols goes
> > against a decade of Perl 5 for me.
>
> I don't know if it's valid or not.
However, I think it'd be basically equivalent to the
following non-loop (but recursive) version:
sub bar($x) {
sub foo() { say $x; }
push(@foos, &foo);
if $x < 10 { bar($x + 1); }
}
bar(1);
Perhaps it doesn't make any sense, but I'd be hard-pressed
to immediately say that this second version isn't valid.
And I might be able to make the argument that it's nearly
equivalent to
for 1..10 -> $x {
our &foo = -> { say $x; }
push(@foos, &foo);
}
with the exception that &foo is uninitialized prior to the loop
in this last version.
Comments and counter-arguments welcome.
Pm
Re: [perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
On Sat, Jul 12, 2008 at 08:47:32PM -0500, Patrick R. Michaud wrote:
> On Sat, Jul 12, 2008 at 11:05:35AM -0500, Patrick R. Michaud wrote:
> > On Sat, Jul 12, 2008 at 08:50:44AM -0700, chromatic wrote:
> > > On Saturday 12 July 2008 08:06:33 Patrick R. Michaud wrote:
> > > > Short answer: cloning is what will enable the following to work:
> > > > for 1..10 -> $x {
> > > > sub foo() { say $x; }
> > > > push(@foos, &foo);
> > > > }
>
> And I might be able to make the argument that it's nearly
> equivalent to
>
> for 1..10 -> $x {
> our &foo = -> { say $x; }
> push(@foos, &foo);
> }
>
> with the exception that &foo is uninitialized prior to the loop
> in this last version.
... and the exception that our &foo is a cloned closure instead
of an uncloned sub. So, perhaps not. (But the recursive version
still seems mostly identical.)
Pm
Re: [perl #56716] [TODO]: speed up the configure tests
On Sat, Jul 12, 2008 at 11:00:29AM -0700, James Keenan via RT wrote: > On Sat Jul 12 09:33:35 2008, coke wrote: > > > > Another solution here would be to not run them by default. The purpose > > of 'make test' > > should be to verify that the parrot functionality works on the target > > system. > > If speed is your concern, you can call 'make coretest'. We've had that > functionality available since r23209 (2007-11-28). That lops off not > only the pre- and post-configuration tests, but the coding standards > tests as well. I've used that many times, and it appears that some of > our smoke testers are set up for that as well. Here's a question I have -- what are the various use cases for running the various test targets? Perhaps if we enumerate the use cases we could understand it better and make our targets match. Here's a brief start: Case #1 - Testing prior to commit: In this case the person is a developer who has made some changes to Parrot or one of its subsystems and is about to commit back to the repository. Clearly we want to check that the change hasn't caused a regression in functionality, but we also want to make sure that the MANIFEST has been properly updated, svn properties are set correctly, and that coding standards are being followed. Unless the developer has been making changes to Parrot configuration, we probably don't need to run the configuration tests. Case #2 - Testing prior to release. Here we want to make sure all tests are run. Case #3 - Testing initial build after checkout/update. In this case the tester wants to verify that the version of Parrot just build is functioning properly. This may be because the tester is looking for a baseline report prior to introducing other changes, or because the tester is experimenting with Parrot and simply wants to know that it built properly on their specific platform. Case #4 - Intermediate testing in development. The developer is in an iterative process of changing things and wants to quickly test what (if any) functionality has been affected by the changes thus far. Unlike case #1 above, the developer isn't generally interested in manifest, svn properties, or coding standards yet. Are there any other cases? It also occurs to me that everyone wants "make test" to always do what they mean for their specific aspect of Parrot, which differs from developer to installer to tester to release manager. Perhaps a more radical solution is to have "make test" always present a short menu (less than 1 screen) of the common test targets, and require the tester to be more explicit about what types of tests they wish to perform. Speaking from Rakudo's case I know this might be useful -- especially in the case of the "committest" target. (People working in the languages/perl6/ directory often forget to run Parrot's coding standards tests, which is why I requested "make codetest" for addition to Rakudo's "make test" target.) Hope this helps, comments and criticisms welcomed. Pm
Re: encoding vs charset
On Tue, Jul 15, 2008 at 11:17:23PM +0200, Leopold Toetsch wrote: > 21:51 < pmichaud> so unicode:"«" and unicode:"\xab" would produce > exactly > the same result. > 21:51 < pmichaud> even down to being the same .pbc output. > 21:51 < allison> pmichaud: exactly > > The former is a valid char in an UTF8/iso-8859-1 encoded source file and only > there, while the latter is a single invalid UTF8 char part. How would you > interpret unicode:"\xab\x65" then? I'd want \xab and \x65 to represent two codepoints, not encoding bytes for a single codepoint. Pm
Re: [perl #57344] [TODO] Change runtime/parrot/* to runtime/*
On Sun, Jul 27, 2008 at 10:08:06AM -0700, Geoffrey Broadwell wrote: > In the source repository, the 'parrot' in runtime/parrot/foo is > pointless. It's a singleton directory, and it's redundant. I think that the point of runtime/parrot/ is that we may also someday have runtime/perl6/, runtime/pynie/, runtime/cardinal/, etc. directories, which will be the canonical location for language-specific runtime libraries. Pm
Re: [perl #57438] [DEPRECATED] [PDD19] .pragma n_operators
On Thu, Jul 31, 2008 at 10:07:49AM +0100, Klaas-Jan Stol wrote: > On Wed, Jul 30, 2008 at 9:06 PM, via RT Will Coleda wrote > > From PDD19: > > > > =item .pragma n_operators [deprecated] > > does this mean that by default all ops will have the n_ prefix by default? > That would imply some variants of these ops are removed (namely, the > non-n_-prefixed ones). > > I guess what my question is, what's the reason for removing this? I think all this means is that the pragma itself is deprecated. I would presume that the n_operators remain, and that programs can continue to generate both n_ and non-n_ opcodes as needed. Pm
Re: [perl #56786] [pdd25cx] Segfault with tcl
On Sat, Aug 02, 2008 at 09:31:44AM -0700, Allison Randal via RT wrote: > > Committed a fix to tcl in branch (r29940) to pull from the correct > > slot. All tests now pass. I'd like to see this segfault/assert/boom > > addressed before we merge back, just in case. > > Resolved in r29941, by throwing an exception when requesting an > attribute that doesn't exist, or an attribute assigned to the wrong > register type (an integer value assigned to a string register, for > example). Added example code as regression test in r29942. Out of curiosity, other symbol-like lookups such as get_global and hash lookups tend to return NULL when they don't exist, as opposed to throwing an exception. For consistency, should looking up a non-existent attribute do the same? A similar issue exists in RT #47894, where looking up a non-existent lexical throws an exception instead of returning NULL. I can envision arguments for having lexicals and attributes act differently from other symbols, but I did want to double-check that we really want C to act differently from C. Pm
Re: [perl #57636] [TODO][PDD19] Document the reason for :unique_reg flag
On Tue, Aug 05, 2008 at 10:51:08AM -0700, Klaas-Jan Stol wrote: > From pdd19: > > The optional C<:unique_reg> modifier will force the register allocator to > associate the identifier with a unique register for the duration of the > subroutine. > > > This, however, does not document /why/ you would want to do that. Why do we > have this flag? > Maybe add an example. Sometimes the register allocator will re-use a register when it's important that the register not be reused. The :unique_reg flag is supposed to guarantee that whatever register is allocated for a symbol is used _only_ for that symbol and not re-allocated. PGE has used :unique_reg to try to "turn off" the register allocator for the subs it generates, which tended to perform badly both in terms of speed and in terms of correctly allocating registers. (All of PGE's generated subs use a small fixed number of registers and so the register allocator is a detriment and not a help.) Pm
Re: [perl #57636] [TODO][PDD19] Document the reason for :unique_reg flag
On Thu, Aug 07, 2008 at 10:15:24AM -0400, Will Coleda wrote: > Now, if the problem is that the register allocator is broken, then > let's fix the register allocator. If :unique_reg is just a workaround > because fixing it is hard, let's document it as deprecated with the > expectation that it will be removed when the allocator is no longer > broken. Here's my slightly different interpretation: Before we had variable register frames, the register allocator was something of a necessary evil, because we needed something that could fit a large number of symbolic registers into a fixed number of absolute registers. However, now that we have variable register frames, the register allocator is really more of an optimizer than anything else -- i.e., it allows our code to run using fewer registers. And as with any other optimization, we ought to provide the compiler writers with an option to turn the optimization off. This is effectively what :unique_reg does on a per-symbol basis. Of course, ":unique_reg" on individual symbols might not be the best way to achieve this, but it does at least have historical precedent. If we eliminate ":unique_reg", I'd still like to have a way to generate PIR code where I know that the register allocator isn't re-using registers or doing other fancy allocation. Pm
Re: [perl #47972] [DEPRECATED] getclass opcode
On Tue, Aug 12, 2008 at 02:14:07PM +0200, Allison Randal wrote: > Will Coleda wrote: >> I agree that any removed feature should have a deprecation cycle; >> Here's my pitch for how we've already done that; the list of >> deprecated features has RTs; the RT listed what was going to have to >> happen for some time now; This covers us on the deprecation >> notification. I'm totally willing to go along with this pitch; I'm just thinking that someone watching DEPRECATED.pod would never have guessed that removing C (the note for this ticket) would also cause C, C, C, etc. to disappear as well. :-) > Let's do a quick query of other languages: Is anyone else affected by > the change? And, is a quick update to a method call instead of the > builtin a workable solution for you? > > Overall, I suspect updating any affected languages is less hassle than > backing out the patch (that is, I don't expect wide usage), so it's the > better path forward. +1. And Coke++ for having done the work to make this patch. Pm
Re: [perl #58030] Named parameter passing errors on subs with optional parameters
On Sat, Aug 16, 2008 at 07:16:19PM -0700, mhelix wrote: > Passing PMCs as named arguments fails when the called sub accepts > optional positional arguments unless all optional arguments are > passed. On my tests this bug only affected PMC arguments. > Passing an int, float or string works flawlessly. This issue is a duplicate of RT #54860, so I'm merging the two tickets. However, the newer ticket provides a lot of very useful additional details about the problem -- many thanks for the submission! Pm
Re: codingstd tests should pass in every release
On Sun, Aug 17, 2008 at 10:21:18PM -0400, Bob Rogers wrote: >From: James E Keenan <[EMAIL PROTECTED]> >Date: Sun, 17 Aug 2008 19:55:02 -0400 > >Yes, when one of the 'make codingstd_tests' accumulates sufficient >PASSes, we promote it to 'make test'. Those that are not yet passing >can generally be described as: "Requires cage-cleaner with vast number >of tuits." >. . . >So, no, failures in these files are not from showstoppers. They're a >TODO for my golden years (and those of several other Parrot developers). > >I committed a fuller explanation in r30292. Perhaps "make fulltest" should run the "make codetest" target instead of "make codingstd_tests"? The "codetest" target is the one that means "run the codingstd tests that are part of 'make test'". This would allow "make fulltest" to still run the required subset of coding standard tests (i.e., the same ones as "make test") without having to run the entire codingstd suite (which produces the ignorable failures). And we can remove the note from the release_manager guide entirely, since "make fulltest" will run exactly what we want (and any errors in coding tests are then significant). Pm
Resumable exceptions
Here's a simple test for resumable exceptions that I'm trying to get to work. I'm probably coding/understanding something wrong, so any suggestions or pointers would be greatly appreciated. .sub main :main push_eh catcher 'foo'() pop_eh say 'ok 4' .return () catcher: .get_results ($P0, $S0) $P1 = $P0['retcont'] $P1() .end .sub 'foo' say 'ok 1' $P0 = new 'Exception' throw $P0 say 'ok 2' $P0 = new 'Exception' throw $P0 say 'ok 3' .end What I'm trying to do is to test the ability to resume after exceptions thrown by C. The C sub above sets up a handler to catch exceptions, then calls C. The handler simply resumes any exception that is caught. The C sub prints 'ok 1', throws an exception, prints 'ok 2', throws another exception, and prints 'ok 3'. I can resume the first exception but not the second: $ ./parrot x.pir ok 1 ok 2 No exception handler and no message current instr.: 'foo' pc 46 (x.pir:20) called from Sub 'main' pc 29 (x.pir:10) $ Suggestions and corrections to my code welcomed. Pm
Re: [perl #58270] make fails @ src/null_config.c:29 on linux
On Fri, Aug 22, 2008 at 02:27:12PM -0700, Stephen Simmons wrote: > --- > make failed on the following compilation, on revisions 30353 and 30457 > (and a couple of others in between). Additional information follows > this output listing. > > -- > gcc -o miniparrot src/main.o src/null_config.o \ > -Wl,-rpath=/users/ssimmons/parrot/blib/lib -L/users/ssimmons/parrot/blib/lib > -lparrot -lresolv > -lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp -lreadline -lncurses > -lcrypto -Wl,-E > src/main.o(.text+0x39): In function `main': > src/main.c:52: undefined reference to `Parrot_new' > src/main.o(.text+0x46):src/main.c:53: undefined reference to `imcc_initialize' > src/main.o(.text+0x5b):src/main.c:58: undefined reference to > `string_from_cstring' > src/main.o(.text+0x67):src/main.c:58: undefined reference to > `Parrot_set_executable_name' > [...] ... often this means that there is an old version of libparrot hanging around on the system somewhere (i.e., as the result of a "make install"). That might not be it, but that's what I would check first. Pm
Re: implicit & explicit returns
On Tue, Aug 26, 2008 at 11:42:51PM +0300, luben karavelov wrote: > I can run the NQP generated PIR after addition of: > > load_bytecode 'compilers/nqp/nqp.pbc' > > in the first sub. But I can not find how to run rakudo generated PIR > code. The "load_bytecode" seems no be not enought (some months ago it > was running with just adding "load_bytecode > 'languages/perl6/perl6.pbc'"), Correct, the load_bytecode trick no longer works. The PIR code that is generated from rakudo contains some :immediate subs that require perl6.pbc to be loaded before they can be run (thus, a catch-22). I'm working to refactor the generated code to avoid the :immediate subs, but given other things on my work queue at the moment this may take a few days. Pm
Re: pdd19_pir.pod: See C
On Thu, Aug 28, 2008 at 02:10:27PM +0200, Reini Urban wrote:
> Open problem:
> For language pbc's a new dir like script_dir or lib_dir/parrot/bin
> would be required.
> They could also pollute $(DESTDIR)@lib_dir@/parrot/library where the other
> pbc's are.
> The language group and op shared libs go to $(DESTDIR)@lib_dir@/parrot/dynext
> for sure.
> e.g. tclsh.pbc, APL.pbc, ...
I'd be a bit surprised if the .pbc files went into dynext/ -- that doesn't
seem to match what currently exists there (which is all .so files on
my system).
At the moment I'm planning for language pbcs to go into
.../parrot/library/ so they can be easily accessed via
load_bytecode. I've found that in a dynamic environment like
Parrot there's very little difference between a language and
a library [1]. :-)
Also, I wonder if any of this relates to RT #47992 ("'parrot foo'
automatically finds and invokes foo.pbc")?
Pm
[1] "CPAN is my programming language of choice; the rest is just syntax."
--Audrey Tang
Re: [perl #58414] [TODO] review calling conventions
Two other items that ought to be taken into consideration: - We need an implementation of the :lookahead flag for Rakudo. (See discussion thread at [1].) - Per a conversation with Allison and Jonathan at YAPC::EU, it might be useful to have a :capture flag on parameters and return values to capture all arguments into a single (Capture) PMC. [1] http://groups.google.com/group/perl.perl6.internals/browse_thread/thread/fce44e38aa856be9/96417ed37799cd37 Pm
Re: pdd19_pir.pod: See C
On Thu, Aug 28, 2008 at 11:10:47PM +0200, Allison Randal wrote: > That's backwards. Loading the language module is what registers the > compiler. The user never needs to access the compiler object for a > particular language directly unless they're compiling code from a string. ...or if they want to parse a namespace string according to another HLL's rules, obtain a namespace from another HLL, or load a library associated with a different HLL. (See pdd21 - namespaces.) Pm
Re: pdd30_install
On Fri, Aug 29, 2008 at 06:10:21PM +0200, Reini Urban wrote: > 2008/8/29 Allison Randal: > > Reini Urban wrote: > >> Current exceptions for the "parrot-" prefix: > >> perl6 > > > > Actually, that probably won't be an exception to the "parrot-" prefix on the > > package name, since there are multiple implementations of Perl 6. > > Ok, so there will be pugs, perl -Mv6 and rakudo | parrot-perl6 > Maybe both /usr/bin/rakudo and /usr/bin/perl6 should be symlinked to > /usr/bin/parrot-perl6 then. > Currently there's only a /usr/bin/perl6 being installed. > > This really should be made ready for the September release. > > > Again, it should be a configuration option to install aliases for > > executables with the language "nicknames". Not a requirement for the > > packaged versions, but the $0 handling will be built in to Parrot, so the > > user could also easily create their own 'ln -s' aliases. > > Good idea. > Within the PCT::HLLCompiler I assume. PCT::HLLCompiler can't do it alone -- it will have to be part of the Parrot invocation in order to work. Thus my earlier comment/question [1] about this thread being related to the comments in RT #47992. [1] http://groups.google.com/group/perl.perl6.internals/msg/d9c8af92ed2ab04d Pm
Re: [perl #47992] [RFE] 'parrot foo' automatically finds and invokes foo.pbc
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
Re: [perl #58576] [RFE] Allow runtime manipulation of HLL_map tables
On Thu, Sep 04, 2008 at 09:48:09AM -0700, chromatic via RT wrote: > > I don't think we need any specialized opcodes for this -- simply > > being able to introspect and dynamically modify the current > > interpreter's HLL mapping tables ought to be sufficient. > > > > (Introspection of HLL mappings is likely to end up being important > > for the compiler toolkit related libraries anyway, so that a toolkit > > can generate correct mapping code in the places where Parrot doesn't > > already handle it.) > > How would the interface look? Are methods on the > Interpreter PMC appropriate, or do you have something else in mind? I don't have a specific interface in mind. Methods on an Interpreter PMC would be just fine, and are probably preferable: ## Map Parrot C to Perl 6 C .local pmc core_type, hll_type, interp core_type = get_class 'String' hll_type = get_class 'Str' interp = getinterp interp.'hll_map'(core_type, hll_type) But it could also be potentially be done with a hash-like interface of some sort similar to how we do other interpreter-introspection types of things: .local pmc interp, hllmap interp = getinterp hllmap = inter['hllmap'] ## use a hash-like interface on hllmap to query/set mappings hllmap['String'] = 'Str' I suspect that the hash-like interface is less likely now that we have eliminated integer type ids from the PIR-level programming interface -- which probably argues for a method-based approach instead. Pm
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Thu, Sep 04, 2008 at 08:31:10AM -0700, James Keenan via RT wrote: > On Thu Sep 04 06:33:41 2008, pmichaud wrote: > > I just wanted to comment that I see this problem on my Kubuntu system as > > well -- when running Configure.pl, I consistently get to the step for > > AIO and things hang (until I press control-C): > > Does Erik's patch clear up the problem on your Kubuntu system? If so, > then please go ahead and commit it to trunk. It does cause the auto::aio step to continue after about 10 seconds with a message of "wrong signal". 1. I think 10 seconds might be a bit too long -- 4 or 5 might be better. 2. It would be nice if "wrong signal" was suppressed, or otherwise incorporated into the output such that it didn't present a "break" in the configuration display. Pm
Re: [perl #58576] [RFE] Allow runtime manipulation of HLL_map tables
On Thu, Sep 04, 2008 at 12:25:36PM -0500, Patrick R. Michaud wrote: > On Thu, Sep 04, 2008 at 09:48:09AM -0700, chromatic via RT wrote: > > > I don't think we need any specialized opcodes for this -- simply > > > being able to introspect and dynamically modify the current > > > interpreter's HLL mapping tables ought to be sufficient. > > > > > > (Introspection of HLL mappings is likely to end up being important > > > for the compiler toolkit related libraries anyway, so that a toolkit > > > can generate correct mapping code in the places where Parrot doesn't > > > already handle it.) > > > > How would the interface look? Are methods on the > > Interpreter PMC appropriate, or do you have something else in mind? > > I don't have a specific interface in mind. Methods on an > Interpreter PMC would be just fine, and are probably preferable: > [...] I should also note that for what I'm looking at now, being able to set hll type mapping is the important feature that could be used relatively soon, while introspection of type mapping is something that we'll eventually want but isn't needed as urgently. Pm
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Thu, Sep 04, 2008 at 04:52:34PM -0700, James Keenan via RT wrote: > I applied the patch attached, aio.in.revised.patch.txt, in r30771. I > set the 'sleep' to 4 seconds. All the tests have been reactivated. Thanks. > This is a patch in the sense of "bandaid". What is it about the letter > 'K' that means that this probe gives sloppy results on Kubuntu when on > Ubuntu it has built cleanly for me every day since I started building > Parrot? The problem only appeared for me in Kubuntu a few weeks ago, and then only intermittently until a week or so ago. Prior to the beginning of August Parrot had been building cleanly for me on Kubuntu without any difficulty. As one of the earlier messages suggested, I think it may just be a race condition in the signal handling. Pm
pdd23 - subs as exception handlers
PDD23:41 says : =item B> : : Push an invocable PMC -- usually a closure or, in rarer cases, a subroutine or : continuation -- onto the exception handler stack. : ... : If a I 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
throw oddities in pdd23
PDD23:67 has: : =item B> : : Throw an exception consisting of the given I PMC. Active exception : handlers (if any) will be invoked with I as the only parameter. : : : =item B [ , I ]> : : Throw an exception consisting of the given I PMC after taking : a continuation at the next opcode. When a I is passed in, : it will use that instead. Active exception handlers (if any) will be : invoked with I and the given continuation as parameters. This looks weird in a couple of respects. The second C opcode shows I as an optional parameter, which would seem to be in conflict with the first form (i.e., they end up being identical if I is omitted). Next, reading the above makes it look as though exception handlers can sometimes be invoked with a single parameter (the exception) and sometimes with two parameters (the exception and a continuation). Perhaps it would be better to have a consistent calling interface? (I do suppose we could say that the second parameter is always optional.) I suspect much of the confusion comes from when C was (apparently) eliminated in favor of a single C opcode, but pdd23 wasn't made internally consistent. Also, note that the single-argument C opcode is currently doing more than simply cause exception handlers to be invoked -- it's also takes a resume continuation and stores it in the I PMC itself (src/ops/core.ops:817). This would seem to be in conflict with the next sentence at pdd23:80 : : Any type of PMC can be thrown as an exception. Clearly we cannot use the single-argument C on a PMC that doesn't have a "resume" attribute for us to store the resume continuation. Personally I like the idea that "any PMC can be thrown as an exception", which would seem to argue against forcing resume continuations into the thrown PMC (which might not have a slot for them). So, rather than saying that anything thrown as an exception contains its resume continuation, perhaps we should say that all handlers are invoked with the exception and resume continuation as arguments, and the single-argument throw simply takes a continuation at the next instruction to pass to the handler(s). Alternatively, we could say that C only places a resume continuation into PMCs that "does exception", but somehow I find this less desirable than the above approach. Pm
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
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' (mul<3>) 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: 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 #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: [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 #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: 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
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: [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
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
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
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
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
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 C 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
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
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
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
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
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 #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
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 #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 C PMC passed in), but the subtract
operation tries to reuse an existing C 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
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 Tue, Oct 07, 2008 at 05:47:57PM -0700, Mark Glines via RT wrote: > On Tue Oct 07 08:14:04 2008, pmichaud wrote: > > 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'.) > > The test you added in r31753 does more than just fail on my machine > (linux gentoo x86-64), it segfaults: The problem appears to be that src/pmc/complex.pmc makes use of RE() and IM() macros that no longer work for subclasses of the Complex PMC and try to poke float values directly into the PMC struct. Unfortunately, a PMC that is from a subclass of Complex isn't a Complex PMC but an Object PMC, so things go haywire from there. 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
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 #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: 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 #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: [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
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 #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 #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 #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
