Invoking PGE closures as Rakudo code
Earlier, I sent in a patch for PGE to support S05-style single-curly
closures (RT#60186). The next thing I'm trying to do is to get this
to work:
./perl6 -e ' ~~ m/:lang(Perl6) { say hi }/'
The PIR version works perfectly:
./perl6 -e ' ~~ m/:lang(PIR) { say hi }/'
Out of the box, the Perl6 version fails like this:
invoke() not implemented in class 'Perl6::Compiler'
current instr.: '_block17_corou' pc 209 (EVAL_11:87)
called from Sub '_block17' pc 84 (EVAL_11:40)
called from Sub 'parrot;Code;ACCEPTS' pc 5402 (src/
gen_builtins.pir:3517)
called from Sub '_block11' pc 28 (EVAL_11:14)
called from Sub 'parrot;PCT;HLLCompiler;eval' pc 864 (src/PCT/
HLLCompiler.pir:498)
called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1355 (src/
PCT/HLLCompiler.pir:725)
called from Sub 'parrot;Perl6;Compiler;main' pc 17089 (perl6.pir:184)
I edited perl6.pir to add this debug code:
.sub 'invoke' :vtable :method
say 'invoke called'
.return ()
.end
so now I get:
./perl6 -e ' ~~ m/:lang(Perl6) { say hi }/'
invoke called
invoke called
as expected (well, I don't understand why it's doubled, but I'm happy
that it's called). But I'm still a novice and I can't figure out the
next step. I know that this code is being called from code generated
in the [PGE;Exp;Closure;'pir'] method in compilers/pge/PGE/Exp.pir,
and the closure $P1 is being invoked like so:
($P0 :optional, $I0 :opt_flag) = $P1(mob)
I think mob is the default Match instance, aka $/. It looks like
$I0 is a boolean indicating whether the closure has significance to
the match (true) or is pure side effect (false). It also looks like
$P0 is the 'make' result for the closure. But, I'm not really sure
I'm interpreting that code correctly.
Can anyone offer some advice on how I should write the 'invoke'
method? My goal is to build arbitrarily complex data structures from
closures fired in my grammar. Specifically, I'm trying to write a
PDF parser -- my grammar is parsing correctly now, but I'd rather not
have to write the closures in PIR if I can help it.
Chris
[perl #60178] Commit r32189 breaks Parrot on Mac OS X 10.5.4
# New Ticket Created by Carl Mäsak # Please include the string: [perl #60178] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60178 I'm running Mac OS X 10.5.4, and can't compile Parrot r32189. I managed to compile the latest revision (r32196), but only after updating src/multidispatch.c down to r32188. The make output for the failing builds is long and not evidently informative, so I hesitate to post it. $ make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-apple-darwin9.0
[perl #60166] [BUG] Exception handling in parrot doesn't unwind stack.
This example fails because the op find_method uses Parrot_ex_throw_from_c_args, that handles the exception in an inner runloop. From an opcode is better to use Parrot_ex_throw_from_op, wich jumps to the handler in the current runloop. I'm working on a patch that defines the helper function Parrot_ex_throw_from_op_args to simplfy the throwing in cases like this. But we still need a way to handle the exceptions thrown from C.
[perl #60186] [PATCH] make PGE support {PIR} closures instead of just {{PIR}}
# New Ticket Created by Chris Dolan
# Please include the string: [perl #60186]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60186
As of parrot rev 32120, PGE only supports the old S05 closure syntax
that had double curlies like so
/foo {{ say matched foo }}/
The current S05 says this is legal:
/foo { say matched foo }/
This was discussed on perl6.users at:
http://www.nntp.perl.org/group/perl.perl6.users/2008/10/msg826.html
The attached patch allows one to use either single or double curlies
(or triple, etc, actually). I added disambiguation for the {*}
token which is now a special case of {...}. Perhaps that latter
bit was over-engineering, but I don't grok the optable yet well
enough to understand how it disambiguates on its own.
In the future, I think we should consider deprecating the extraneous
curlies, at least for PIR closures.
pge-single-bracket-closure.patch
Description: Binary data
[perl #60182] pirc/new codetest failures
# New Ticket Created by Moritz Lenz # Please include the string: [perl #60182] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60182 r32205 $ make codetest ... Test Summary Report --- t/codingstd/c_indent.t (Wstat: 256 Tests: 2 Failed: 1) Failed test: 1 Non-zero exit status: 1 t/codingstd/c_macro_args.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 t/codingstd/c_operator.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 t/codingstd/c_parens.t (Wstat: 768 Tests: 3 Failed: 3) Failed tests: 1-3 Non-zero exit status: 3 t/codingstd/linelength.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=24, Tests=39, 30 wallclock secs ( 0.07 usr 0.02 sys + 32.67 cusr 1.66 csys = 34.42 CPU) Result: FAIL -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
[perl #60182] pirc/new codetest failures
fixed in r32209.
[perl #60184] [CAGE] Change the name of 'stacktrace' attribute to 'backtrace'
# New Ticket Created by Allison Randal # Please include the string: [perl #60184] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60184 Quick task only requiring moderate C knowledge. In the Exception PMC, change the name of the 'stacktrace' attribute to 'backtrace'. Also change all accessors for the attribute. Grep or ack the repository to make sure you've caught all uses. Allison
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
Thanks for the info. I'll try to learn enough to write a PGE patch to
support {PIR} notation. Given the ubiquity of the {{PIR}} notation I will
probably try to see if I can make it backward compatible, with an eye
toward deprecating it.
Chris
Re: [perl #60098] [BUG] load_bytecode couldn't find file 'P6object.pbc'
2008/10/27 Patrick R. Michaud [EMAIL PROTECTED]: 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. I would say, RT #56996 fhs-runtime solves that. I'm still away from home, but will come back this weekend and try to prepare the merge of my pdd30_install branch. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #60168] [PATCH] Refactor Junction.
Patrick R. Michaud via RT wrote: On Mon, Oct 27, 2008 at 03:47:50AM -0700, Vasily Chekalkin wrote: I've (slightly) refactor Junction.pir. 1. Get rid of junction_comparision_helper. Use infix_junction_helper instead. 2. In infix and unary junction helpers store original value in ResultHash to avoid stringification of results. Okay to apply patch as long as spectest_regression still passes. Yes, it still passing. I would prefer to eliminate the 'ResultHash' altogether -- elimination of any duplicate values should be done in the Junction constructor itself, not in the helper. Please don't I tried this varian before submitting patch, but hit some parrot's bug that I didn't manage to fix. close this ticket until that has been done. Note that all of this effectively disappears when we have the dispatcher handling Junctions properly -- i.e., the specialized operator functions defined in Junction really should not exist. Indeed. But current state of MMD doesn't allow to implement auto-threading. For example Parrot_ex_throw_from_c doesn't specify continuation, etc. -- Bacek
[perl #60176] Rakudo fails on defining classes with core roles
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #60176]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60176
Rakudo r32151 can't create classes with roles from the Rakudo-defined classes.
$ ./perl6 -e 'role B {}; class A does B {}' # this works
$ perl6 -e 'class A does Int {}' # this doesn't
Method 'methods' not found
[...]
Now, Int is a class in Rakudo, so I'm not 100% sure this should work.
Still, strange error message.
[perl #60134] [TODO] Add tests for file-based interface to Configure.pl
No complaints. No failures in Smolder tests. Resolving ticket.
[perl #60178] Commit r32189 breaks Parrot on Mac OS X 10.5.4
This will be difficult to diagnose unless we do see 'make' output, so please attach a file. Alternative, go to IRC #parrot and use 'nopaste' to post.
Re: [perl #60178] Commit r32189 breaks Parrot on Mac OS X 10.5.4
On Tue, Oct 28, 2008 at 8:16 AM, James Keenan via RT [EMAIL PROTECTED] wrote: This will be difficult to diagnose unless we do see 'make' output, so please attach a file. Alternative, go to IRC #parrot and use 'nopaste' to post. To limit the verbosity, you could run make 2x and just send us the output of the second run, as presumably the interesting failure will be in that, and none of the pesky stuff that worked. -- Will Coke Coleda
Re: Why {{}} for regexp closures instead of just {}?
On Mon, Oct 27, 2008 at 04:07:39PM -0500, [EMAIL PROTECTED] wrote:
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.
Sometimes working with Parrot is a lesson in archaeology -- by
digging deep enough you see artifacts of a different age.
In order to properly parse curlies in regexes one has to have
a full-fledged (Perl 6 / Python / PHP/ whatever) parser available
to be able to find the closing curly. Long ago, before we had
any such parsers, people wanted to be able to embed executable
code inside of regexes -- indeed, the parsers themselves make use
of this capability. So, PGE used the double-curly notation as
a stop-gap -- it can easily scan ahead to the closing double-curly
to find the end of the embedded code and squirrel it away for
execution.
This was all done before S05 defined the :lang modifier for
embedded closures in regexes, and at the moment it only works
for embedding PIR.
Returning to present day, the next step will be to enable the
:lang modifier in regexes so that it can attach to any compiler.
However, since Perl 6 regular expression parsing is about to
receive a huge makeover anyway, I was waiting until then to
work out those details.
Thanks for the info. I'll try to learn enough to write a PGE patch to
support {PIR} notation.
Note that {PIR} is not valid by itself, it would need to be
:lang('PIR') {PIR}
or something like that. See S05 for the latest syntax. The default
interpretation of curlies with no :lang modifier will undoubtedly
be Perl 6 syntax (although we may make it default to whatever
language the regex is embedded in if we can do that).
Pm
Re: [perl #60186] [PATCH] make PGE support {PIR} closures instead of just {{PIR}}
On Mon, Oct 27, 2008 at 10:24:56PM -0700, Chris Dolan wrote:
The attached patch allows one to use either single or double curlies
(or triple, etc, actually). I added disambiguation for the {*}
token which is now a special case of {...}. Perhaps that latter
bit was over-engineering, but I don't grok the optable yet well
enough to understand how it disambiguates on its own.
Disambiguating the {*} isn't necessary, as the optable already
does longest token matching, and thus will recognize {*} before
the single curly.
Other comments on the other threads.
Pm
Re: Invoking PGE closures as Rakudo code
On Tue, Oct 28, 2008 at 01:50:42AM -0500, Chris Dolan wrote:
My goal is to build arbitrarily complex data structures from closures
fired in my grammar. Specifically, I'm trying to write a PDF parser --
my grammar is parsing correctly now, but I'd rather not have to write the
closures in PIR if I can help it.
Would it make sense to use action methods (the {*} tokens) for the
closures instead of embedding them directly into the grammar?
Pm
Re: [perl #60186] [PATCH] make PGE support {PIR} closures instead of just {{PIR}}
On Mon, Oct 27, 2008 at 10:24:56PM -0700, Chris Dolan wrote:
As of parrot rev 32120, PGE only supports the old S05 closure syntax
that had double curlies like so
/foo {{ say matched foo }}/
The current S05 says this is legal:
/foo { say matched foo }/
This was discussed on perl6.users at:
http://www.nntp.perl.org/group/perl.perl6.users/2008/10/msg826.html
The attached patch allows one to use either single or double curlies
(or triple, etc, actually). I added disambiguation for the {*}
token which is now a special case of {...}. Perhaps that latter
bit was over-engineering, but I don't grok the optable yet well
enough to understand how it disambiguates on its own.
In reality, what has to happen here is that encountering a opening
curly brace transfers parsing to the parser for the appropriate
language (e.g., Perl 6, PIR, etc.). For example, consider a regex
like:
/foo { if True { say '{yes}'; } } bar/
Upon encountering the first curly brace we cannot simply scan ahead
until the next closing curly brace we happen to find -- we actually
have to transfer parsing to a different compiler (one that understands
Perl 6), let that compiler parse as much as it can up to an unmatched
closing curly brace, and return that result back to the regex parser to
continue parsing the rest of the regex.
This is why PGE currently requires at least two braces for open and
closing, (1) to make it clearer that parsing is being done via
a lookahead scan and not an actual parse, and (2) to avoid confusion
if the embedded code has any single curlies within it.
Beyond that, Parrot and PIR don't currently provide an easy way to
switch to/from a PIR parser, so for embedding PIR for the time being
we'll have to use some sort of lookahead scan to find the end of
the PIR string.
Pm
Re: [perl #60168] [PATCH] Refactor Junction.
On Tue, Oct 28, 2008 at 07:10:15PM +1100, Vasily Chekalkin wrote: Note that all of this effectively disappears when we have the dispatcher handling Junctions properly -- i.e., the specialized operator functions defined in Junction really should not exist. Indeed. But current state of MMD doesn't allow to implement auto-threading. For example Parrot_ex_throw_from_c doesn't specify continuation, etc. I'm not too worried about throw_from_c right now, because it's very unlikely we'll be throwing Junctions as exceptions anytime soon. I'm just referring to the common use of junctions in comparisons and other function calls from within Rakudo. Pm
Re: [perl #60168] [PATCH] Refactor Junction.
Patrick R. Michaud wrote: Note that all of this effectively disappears when we have the dispatcher handling Junctions properly -- i.e., the specialized operator functions defined in Junction really should not exist. Yup, and I don't plan to spend any more time on those functions inside Junction myself, but rather move onto the dispatcher. Though fine with this patch being applied if things keep working. Meta: Back into Rakudo stuff proper within the next week...being hindered by a broken net connection (which takes time to fix thanks to non-commodity hardware and slow-ass cable company... *sigh*) Jonathan
Re: [perl #60168] [PATCH] Refactor Junction.
Patrick R. Michaud wrote: On Mon, Oct 27, 2008 at 03:47:50AM -0700, Vasily Chekalkin wrote: I've (slightly) refactor Junction.pir. 1. Get rid of junction_comparision_helper. Use infix_junction_helper instead. 2. In infix and unary junction helpers store original value in ResultHash to avoid stringification of results. Okay to apply patch as long as spectest_regression still passes. It does, even with a few passing TODO tests. So applied yesterday, but forgot which revision it was, sorry. Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
[perl #60190] [BUG] problems with the compiler-option -O2 on a 64bit-system
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #60190] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60190 Hello I want to build parrot-RPMs on a 64bit system under Fedora 9 for the parrot-version 0.8.0. The command make rpms failed. The reason is that the compiler-option -O2 prevent building parrot with languages on a 64bit system. The following commands shows this problem: perl Configure.pl --optimize=-O2 ... make perl6 ... gmake -C compilers/tge gmake[1]: Entering directory `/home/gz016/parrot-sources/test2/parrot-0.8.0/compilers/tge' ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pbc --output=TGE/Parser.pir TGE/Parser.pg gmake[1]: *** [TGE/Parser.pir] Segmentation fault gmake[1]: Leaving directory `/home/gz016/parrot-sources/test2/parrot-0.8.0/compilers/tge' make: *** [compilers.dummy] Error 2 So I build the RPMs without the compiler-option -O2. But perhaps there will someone be able to find a way to solve this problem. Gerd Pokorra
Re: [perl #60178] Commit r32189 breaks Parrot on Mac OS X 10.5.4
Will (), James (): This will be difficult to diagnose unless we do see 'make' output, so please attach a file. Alternative, go to IRC #parrot and use 'nopaste' to post. To limit the verbosity, you could run make 2x and just send us the output of the second run, as presumably the interesting failure will be in that, and none of the pesky stuff that worked. Good suggestions. Here we go: http://nopaste.snit.ch/14409.
Re: [perl #60178] Commit r32189 breaks Parrot on Mac OS X 10.5.4
On Tue, Oct 28, 2008 at 3:00 PM, Carl Mäsak [EMAIL PROTECTED] wrote: Will (), James (): This will be difficult to diagnose unless we do see 'make' output, so please attach a file. Alternative, go to IRC #parrot and use 'nopaste' to post. To limit the verbosity, you could run make 2x and just send us the output of the second run, as presumably the interesting failure will be in that, and none of the pesky stuff that worked. Good suggestions. Here we go: http://nopaste.snit.ch/14409. Here's the offending line: ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir --output=PGE/builtins_gen.pir PGE/builtins.pg To figure out why this is causing a bus error, try: $ cd compilers/pge $ gdb ../../parrot gdb run ../../runtime/parrot/library/PGE/Perl6Grammar.pir --output=PGE/builtins_gen.pir PGE/builtins.pg boom gdb bt and let us know what the backtrace is? (also, I presume you've done a make realclean and tried again, and haven't installed parrot on this machine in the past, no local modifications, etc.) -- Will Coke Coleda
Re: [perl #60190] [BUG] problems with the compiler-option -O2 on a 64bit-system
On Tuesday 28 October 2008 07:05:47 [EMAIL PROTECTED] (via RT) wrote: But perhaps there will someone be able to find a way to solve this problem. Can you provide a backtrace from GDB? -- c
Re: [perl #60178] Commit r32189 breaks Parrot on Mac OS X 10.5.4
On Tue, Oct 28, 2008 at 3:18 PM, Carl Mäsak [EMAIL PROTECTED] wrote: load_bytecode couldn't find file 'PGE.pbc' current instr.: 'parrot;PGE;Perl6Grammar;Compiler;__onload' pc 22 (../../runtime/parrot/library/PGE/Perl6Grammar.pir:72) called from Sub 'parrot;PGE;Perl6Grammar;Compiler;main' pc -1 ((unknown file):-1) Program exited with code 01. Ok. You don't have PGE.pbc. You might need to manually run this: $ cd compilers/pge $ ../../parrot -o PGE.pbc --output-pbc PGE.pir I'm guessing that the make deleted the intermediate file here. (If this step fails, let us know how) If this works, try my last email again. -- Will Coke Coleda
[perl #56382] [RFC] Making Test::Harness 3 available without including it in core parrot.
On So. 07. Sep. 2008, 15:31:49, [EMAIL PROTECTED] wrote: This ticket has not been addressed since early July. Re-reading it now, it seems to have two major discussion threads: one specific to Test::Harness 3 and one relating more generally to the versions of CPAN modules needed to configure, build and test Parrot. May I ask for those who have posted to this ticket to comment on where we stand? For testing Pipp I now explicitly require TAP::Harness 3.12 in languages/pipp/t/harness. So if T::H 3 is going to be generally required, it should be considered to require that version. Since T::H 3.12, a closure can be passed to the exec option. -- /* [EMAIL PROTECTED] */
Re: [perl #60166] [BUG] Exception handling in parrot doesn't unwind stack.
I'm working on a patch that defines the helper function Parrot_ex_throw_from_op_args to simplfy the throwing in cases like this. After discussion in #parrotsketch, added this function in r3 -- Salu2
Re: [perl #60044] [BUG?] rethrow just throwing?
On Fri, 24 Oct 2008, Allison Randal wrote: Will Coleda wrote: Allison Randal wrote: ...you expect 'rethrow' to keep the stack trace of the original 'die'? Yes. The way to do this is to add stack trace information to the Exception's 'stacktrace' attribute when the exception is first thrown, and print that out for an unhandled exception, instead of printing out the literal current path of execution. (This is why I added the 'stacktrace' attribute.) What about keeping track of where the exception was originally created? If we have lazy exceptions, then knowing where the fault they represent was detected is probably more important than were (exactly) it was triggered. Or does this all amount to the same thing? Is an exception only lazy because there's an enclosing dynamic scope that catches it and transmogrifies it into an Uncaught Exception? Or if not, could we have both back-traces available? A created_by back-trace and a thrown_by back-trace? -Martin
Re: Invoking PGE closures as Rakudo code
On Oct 28, 2008, at 10:06 AM, Patrick R. Michaud wrote:
On Tue, Oct 28, 2008 at 01:50:42AM -0500, Chris Dolan wrote:
My goal is to build arbitrarily complex data structures from closures
fired in my grammar. Specifically, I'm trying to write a PDF
parser --
my grammar is parsing correctly now, but I'd rather not have to
write the
closures in PIR if I can help it.
Would it make sense to use action methods (the {*} tokens) for the
closures instead of embedding them directly into the grammar?
Pm
Certainly, yes, but my goal was to learn, not to be productive. :-)
The {*} notation is not part of S05, so I thought I'd try to see
what was possible with real Perl6 and embedded closures. I did
indeed learn a lot!
But since you've said that PGE is getting an overhaul, I'll stow my
patches and wait.
Chris
[perl #59924] [BUG] t/examples/library.t: new failure
On Sat Oct 18 09:39:52 2008, [EMAIL PROTECTED] wrote: On Thu Oct 16 04:39:06 2008, [EMAIL PROTECTED] wrote: [snip] Here is more data concerning the above test failure. Between r31872 (Oct 10) and r31967 (Oct 14), I used 'apt-get' to install 4 additional Debian packages on the Linux box on which these tests were run. The packages were: ii libgmp3-dev4.2.1+dfsg-4 Multiprecision arithmetic library developers ii libgmp3-doc4.2.1+dfsg-4 Multiprecision arithmetic library example co ii libgmp3c2 4.2.1+dfsg-4 Multiprecision arithmetic library ii libgmpxx4 4.2.1+dfsg-4 Multiprecision arithmetic library (C++ bindi I installed these packages because on Linux, Configure.pl was telling me in step auto::gmp that it could not locate GMP. So I was never building Parrot with GMP. After installing these four packages, Configure.pl told me it was now locating GMP. But it was after this install that the test in t/examples/library.t began to fail. So I called 'apt-get remove' to remove the 4 packages above. At this point the test began to pass in both r31967 and HEAD. So, can anyone speculate as to why installation of these 4 packages would cause a failure in a test of PCRE? Any thoughts on this?
[perl #60178] Commit r32189 breaks Parrot on Mac OS X 10.5.4
On Tue Oct 28 12:08:05 2008, masak wrote: Good suggestions. Here we go: http://nopaste.snit.ch/14409. As a (probably misleading) point of reference, here's what I got on Mac OS X 10.4 PPC in the same vicinity (95% of the way thru 'make') in a recent build: make -C compilers/pge /usr/local/bin/perl -MExtUtils::Command -e rm_f PGE.pbc ../../runtime/parrot/library/PGE.pbc /usr/local/bin/perl -e PGE/builtins_gen.pir ../../parrot -o PGE.pbc --output-pbc PGE.pir ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir --output=PGE/builtins_gen.pir PGE/builtins.pg # The next line is where things go wrong for you: /usr/local/bin/perl -MExtUtils::Command -e rm_f PGE.pbc ../../parrot -o PGE.pbc --output-pbc PGE.pir /usr/local/bin/perl -MExtUtils::Command -e cp PGE.pbc ../../runtime/parrot/library make -C compilers/tge ../../parrot -o TGE/Rule.pbc --output-pbc TGE/Rule.pir ... I have no good insight into why this is happening.
[perl #59636] [BUG] t/op/bitwise.t fails on Darwin
On Wed Oct 22 19:03:27 2008, [EMAIL PROTECTED] wrote: After yesterday's release, this passed for me on Darwin PPC 10.4 at r32119. I'll keep my fingers crossed and keep watching the Smolder reports. This has continued to pass for me on 10.4/PPC. Coke, if it's passing for you as well (which, from Smolder reports, appears to be the case), then can you close the ticket? thanks. kid51
[perl #60178] Commit r32189 breaks Parrot on Mac OS X 10.5.4
On Tue Oct 28 12:08:05 2008, masak wrote: Good suggestions. Here we go: http://nopaste.snit.ch/14409. As a (probably misleading) point of reference, here's what I got on Mac OS X 10.4 PPC in the same vicinity (95% of the way thru 'make') in a recent build: make -C compilers/pge /usr/local/bin/perl -MExtUtils::Command -e rm_f PGE.pbc ../../runtime/parrot/library/PGE.pbc /usr/local/bin/perl -e PGE/builtins_gen.pir ../../parrot -o PGE.pbc --output-pbc PGE.pir ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir --output=PGE/builtins_gen.pir PGE/builtins.pg # The next line is where things go wrong for you: /usr/local/bin/perl -MExtUtils::Command -e rm_f PGE.pbc ../../parrot -o PGE.pbc --output-pbc PGE.pir /usr/local/bin/perl -MExtUtils::Command -e cp PGE.pbc ../../runtime/parrot/library make -C compilers/tge ../../parrot -o TGE/Rule.pbc --output-pbc TGE/Rule.pir ... I have no good insight into why this is happening.
[perl #60068] [BUG] t/pmc/packfile.t: set_integer_keyed_str test failing on Darwin PPC
Still failing as of r32225; cf http://smolder.plusthree.com/app/public_projects/tap_stream/7437/260 not ok 6 - set_integer_keyed_str # Failed test 'set_integer_keyed_str' # at t/pmc/packfile.t line 140. # Exited with error code: [SIGNAL 11] # Received: # # Expected: # not equal #
Re: Invoking PGE closures as Rakudo code
On Oct 28, 2008, at 10:06 AM, Patrick R. Michaud wrote:
On Tue, Oct 28, 2008 at 01:50:42AM -0500, Chris Dolan wrote:
My goal is to build arbitrarily complex data structures from closures
fired in my grammar. Specifically, I'm trying to write a PDF
parser --
my grammar is parsing correctly now, but I'd rather not have to
write the
closures in PIR if I can help it.
Would it make sense to use action methods (the {*} tokens) for the
closures instead of embedding them directly into the grammar?
Pm
Taking the {*} approach with the actions written in Perl6 instead of
NQP (or PIR) turned out to be significantly harder than I expected,
largely because I'm using a straight Perl6 grammar instead of PCT and
HLLCompiler. I encountered three problems, both solved temporarily:
1) how to tell Perl6 which action class to use, 2) how to get my
$/.result_object back, and 3) how to keep ws from blowing away my
overridden match object.
=== begin gory details ===
The Grammar.ACCEPTS nor Code.ACCEPTS methods don't pass an action
adverb to the PGE subrule, and there doesn't seem to be a way to set
a default action on a grammar. So, I changed my test code from this:
'1 0 R' ~~ PDF__Grammar::pdf_reference;
is(~$($/).WHAT, 'PDF__Syntax__Reference'); # fails, got 'Str'
because the action is not invoked
to the following, to force the action class:
my $method = PDF__Grammar::pdf_reference;
my $m = '1 0 R'.$method(action = PDF__Grammar__Actions.new);
is(~$m.WHAT, 'PDF__Syntax__Reference'); # succeeds
where my action looks like this:
class PDF__Grammar__Actions {
method pdf_reference($m) {
my $ref = PDF__Syntax__Reference.new(objnum = +
$mobjnum, gennum = +$mgennum);
$m.result_object($ref);
return;
}
}
grammar PDF__Grammar {
rule pdf_reference { objnum gennum R {*} };
}
I found that a bit confusing because: a) because I'm invoking the
subrule directly, $/ is not getting set and b) assigning back to $m
at the end apparently calls get_scalar() on the Match instance, so it
is dereferenced to get my result_object instead. Unexpected, but
convenient. I might wrap it in a superfluous $() in case that
get_scalar() is ever changed.
In retrospect, if I had been matching against the whole grammar
instead of the subrule, my second problem would not have happened
because Grammar.ACCEPTS sets $/.
The third problem was because I had whitespace between the {*} and
the terminal } of the rule. That ws overrode $/ until I cuddled my
rule like rule pdf_reference {objnum gennum R {*}}; Is there
an easy way to make my white space non-capturing? I'm sure I'm just
overlooking something...
=== end gory details ===
So, I have two change proposals. I'm not sure if either of them are
good ideas...
1) Make grammar rules be type Rule instead of Method, and add a
custom ACCEPTS that behaves like Grammar.ACCEPTS.
2) Add a Parrot-specific adverb to the Perl6 grammar declaration
to allow programmers to specify a default action class for the whole
grammar.
And bug reports:
1) Perl6 mangles Match instances when they are assigned to scalars
2) The rules incorrectly require a closing ; to avoid a syntax error
I'm happy to write up concise ticket for any of those if they aren't
insane or already known.
Chris
