Re: Precompilation to PIR
Chris (): How safe is it today to pre-compile Rakudo code to PIR and expect that to behave identically to as if I compiled from .pm at runtime? I believe PCT is just generating PIR anyway, so my initial guess is that there should be no differences. Are there any gotchas, like compile-time dependency checks, that I should look out for? Precompilation to PIR currently doesn't work in the November project -- the difficulties occur when trying to call methods in the precompiled module. Right now our Makefile protests if someone tries to compile the modules to PIR. I think there is an rt ticket for this, but my attempts to dig it up fail. Maybe someone else is more lucky. // Carl
Re: Why {{}} for regexp closures instead of just {}?
On Sun, Oct 26, 2008 at 10:45 PM, Chris Dolan [EMAIL PROTECTED] wrote:
S05 always uses single curlies for closures, but throughout Parrot, code
seems to use double curlies in PGE regexps. Why is that?
That is, why this:
m/ foo {{ say found foo }} /
and not this:
m/ foo { say found foo } /
The latter complains about Statement not terminated properly.
this is old PGE syntax that hasn't yet been updated to match S05. it's a bug.
or maybe, you can say that closures inside regexes aren't supported
yet, but rakudo has a feature that allows {{PIR}}} to work.
~jerry
Re: Argument scoping error or bug?
On Sat, Oct 25, 2008 at 10:52:13AM +0200, Moritz Lenz wrote: Chris Dolan wrote: I stumbled across this issue while descending into a recursive Match structure. Consider the following reentrant subroutine: You have just experienced this bug: http://rt.perl.org/rt3/Ticket/Display.html?id=58392 Recursion and for loops interact badly in Rakudo. Patrick is working on it. That said, I'm also looking for others to help work on it. But it's not a pretty bug, and it's deeply embedded in Parrot internals. :-) Pm
