[perl #60178] Commit r32189 breaks Parrot on Mac OS X 10.5.4

[Carl Mäsak]

# New Ticket Created by  "Carl Mäsak" 
# Please include the string:  [perl #60178]
# in the subject line of all future correspondence about this issue. 
# 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.

[NotFound via RT]

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}}

[via RT]

# New Ticket Created by  Chris Dolan 
# Please include the string:  [perl #60186]
# in the subject line of all future correspondence about this issue. 
# 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

[via RT]

# New Ticket Created by  Moritz Lenz 
# Please include the string:  [perl #60182]
# in the subject line of all future correspondence about this issue. 
# 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

[Klaas-Jan Stol via RT]

fixed in r32209.

[perl #60184] [CAGE] Change the name of 'stacktrace' attribute to 'backtrace'

[via RT]

# New Ticket Created by  Allison Randal 
# Please include the string:  [perl #60184]
# in the subject line of all future correspondence about this issue. 
# 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 {}?

[chris]

> 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'

[Reini Urban]

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.

[Vasily Chekalkin]

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

[Carl Mäsak]

# New Ticket Created by  "Carl Mäsak" 
# Please include the string:  [perl #60176]
# in the subject line of all future correspondence about this issue. 
# 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

[James Keenan via RT]

No complaints.  No failures in Smolder tests.  Resolving ticket.

[perl #60178] Commit r32189 breaks Parrot on Mac OS X 10.5.4

[James Keenan via RT]

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

[Will Coleda]

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 {}?

[Patrick R. Michaud]

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}}

[Patrick R. Michaud]

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

[Patrick R. Michaud]

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}}

[Patrick R. Michaud]

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.

[Patrick R. Michaud]

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.

[Jonathan Worthington]

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.

[Moritz Lenz]

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

[[EMAIL PROTECTED] (via RT)]

# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #60190]
# in the subject line of all future correspondence about this issue. 
# 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

[Carl Mäsak]

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: .

Re: [perl #60178] Commit r32189 breaks Parrot on Mac OS X 10.5.4

[Will Coleda]

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: .
>

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


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

[chromatic]

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

[Will Coleda]

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.

[Bernhard Schmalhofer via RT]

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.

[NotFound]

> 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?

[Martin D Kealey]

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

[Chris Dolan]

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

[James Keenan via RT]

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

[James Keenan via RT]

On Tue Oct 28 12:08:05 2008, masak wrote:

> Good suggestions. Here we go: .
> 

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

[James Keenan via RT]

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

[James Keenan via RT]

On Tue Oct 28 12:08:05 2008, masak wrote:

> Good suggestions. Here we go: .
> 

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

[James Keenan via RT]

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: [perl #60166] [BUG] Exception handling in parrot doesn't unwind stack.

[Patrick R. Michaud]

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.

[Patrick R. Michaud]

On Tue, Oct 28, 2008 at 10:15:32PM -0500, Patrick R. Michaud wrote:
> ... As discussed in #parrotsketch
> earlier today and summarized at [1], the correct form of the
> above loop would have the "pop_eh" line after the do_inc label,
> so that every exception handler created in the loop is removed
> before going on to the next loop iteration.

Forgot the reference:

[1] http://lists.parrot.org/pipermail/parrot-dev/2008-October/000148.html

Pm

Re: Invoking PGE closures as Rakudo code

[Chris Dolan]

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  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 => + 
$m, gennum => +$m);

  $m.result_object($ref);
  return;
   }
}
grammar PDF__Grammar {
   rule pdf_reference {   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  overrode $/ until I cuddled my  
rule like "rule pdf_reference {  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