The original bug is resolved. I'll move the Solaris/SPARC test
failures to a new ticket.
Allison
On Fri, 10 Feb 2006, Allison Randal wrote:
> On Feb 10, 2006, at 9:56, Andy Dougherty via RT wrote:
> >
> > I too had seen this memory problem before on Solaris/SPARC, but I'm
> > pretty sure I saw it even when running t/past_node_5.pir directly.
> > However, trying again today, I'm happy to repo
On Feb 10, 2006, at 9:56, Andy Dougherty via RT wrote:
I too had seen this memory problem before on Solaris/SPARC, but I'm
pretty sure I saw it even when running t/past_node_5.pir directly.
However, trying again today, I'm happy to report that that particular
problem seems to be gone.
Excellen
On Sat, 4 Feb 2006, Allison Randal wrote:
> On Feb 3, 2006, at 17:33, Joshua Isom via RT wrote:
> >
> > But, I've encountered two major problems. On darwin, I can't finish
> > past_node.t, first parrot takes over 100 megs of ram, then perl(5.8.7)
> > wants 180 megs. On freebsd, it's actually wo
On Feb 6, 2006, at 10:04, Leopold Toetsch via RT wrote:
Allison Randal wrote:
What's the difference between :optional and :opt_flag? I found a few
lines of documentation on these once I knew what to grep for, but
that's all.
Seed pdd03. :optional is the argument. :opt_flag is 1/0 if the
arg
On 2/6/06, Allison Randal <[EMAIL PROTECTED]> wrote:
> On Feb 5, 2006, at 3:05, Leopold Toetsch via RT wrote:
> >
> > .sub "dump" method
> > .param int level
> >
> > The level argument isn't optional at all. Turning on argument count
> > checks would prevent such errors.
> > It has to be:
> >
You use :optional to denote an optional parameter, and :opt_flag on an
int that is set to "true" if there's a parameter in :optional. The
fact that :opt_flag is optional could be construed to be a bug. But
all tests successful for me now for punie, and fairly quickly, so I'm
going to assume t
Allison Randal wrote:
On Feb 5, 2006, at 3:05, Leopold Toetsch via RT wrote:
... Turning on argument count
checks would prevent such errors.
What's the difference between :optional and :opt_flag? I found a few
lines of documentation on these once I knew what to grep for, but
that's all.
On Feb 5, 2006, at 3:05, Leopold Toetsch via RT wrote:
.sub "dump" method
.param int level
The level argument isn't optional at all. Turning on argument count
checks would prevent such errors.
It has to be:
.sub "dump" method
.param int level :optional
Okay, thanks, changed. Joshua
On Feb 5, 2006, at 8:17, Allison Randal wrote:
On Feb 4, 2006, at 16:51, Joshua Isom via RT wrote:
41 callmethodcc P1, "dump" -
P1=Object(PAST::Node)=PMC(0x50ba68),
102 get_params PMC_C[29] (2), P0, I0 - , P0=PMCNULL,
I0=5289976
106 repeat S0, "", I0- , ,
On Feb 4, 2006, at 16:51, Joshua Isom via RT wrote:
41 callmethodcc P1, "dump" -
P1=Object(PAST::Node)=PMC(0x50ba68),
102 get_params PMC_C[29] (2), P0, I0 - , P0=PMCNULL,
I0=5289976
106 repeat S0, "", I0- , , I0=5289976
110 add I0, 1- I0=5289976,
Well, here's the xxd dump's head.
[languages/punie/t] jisom% xxd past_node_5.out | head
000: 2020 2020 2020 2020 2020 2020 2020 2020
010: 2020 2020 2020 2020 2020 2020 2020 2020
020: 2020 2020 2020 2020 2020 2020 2020 2020
030: 2020 2020 2020 2020 2020 2020 2020 2020
040: 2020
On Feb 4, 2006, at 14:23, Joshua Isom via RT wrote:
Apparently I have a 267 megabyte past_node_5.out file... And if
past_op_2.pir and past_val_2.pir were printed to a file, I imagine
it'd
do the same(printing a lot of spaces). Seems to be more than just
Parrot::Test for me.
Could you send
Apparently I have a 267 megabyte past_node_5.out file... And if
past_op_2.pir and past_val_2.pir were printed to a file, I imagine it'd
do the same(printing a lot of spaces). Seems to be more than just
Parrot::Test for me.
On Feb 4, 2006, at 12:54 PM, Allison Randal wrote:
On Feb 3, 2006,
On Feb 4, 2006, at 12:26, Leopold Toetsch via RT wrote:
Both on OS/X darwin and x86/linux 'make test' as well as
./parrot -p languages/punie/punie.pbc languages/punie/t/
problematic_1.p1
are succeeding here.
The error is gone here too now. Not sure if it's Leo's fix or unrelated.
Allison
On Feb 4, 2006, at 0:47, Allison Randal wrote:
It's only in my local svk repository. I'll push it so others can work
on the bug (and try it out on multiple platforms). I temporarily added
a test file language/punie/t/problematic.t that isolates the failing
test (makes it easier to filter thro
On Feb 4, 2006, at 8:09, Patrick R. Michaud via RT wrote:
Like others, problematic.t seems to runs okay on my system
(Linux x86_64). :-( Maybe I can get access to a platform on
which it fails...?
Long ago we had an OS X box available to developers. Is that still
around? If not, I can tempo
On Feb 3, 2006, at 17:33, Joshua Isom via RT wrote:
But, I've encountered two major problems. On darwin, I can't finish
past_node.t, first parrot takes over 100 megs of ram, then perl(5.8.7)
wants 180 megs. On freebsd, it's actually worse, but more confusing.
It fails with past_*.t and post_*.
On Fri, Feb 03, 2006 at 03:47:11PM -0800, Allison Randal wrote:
>
> It's only in my local svk repository. I'll push it so others can work
> on the bug (and try it out on multiple platforms). I temporarily
> added a test file language/punie/t/problematic.t that isolates the
> failing test (ma
I've tested on FreeBSD 6.0 and OS X 10.3.9, and t/problematic.t is
successful for both, both with r11418.
But, I've encountered two major problems. On darwin, I can't finish
past_node.t, first parrot takes over 100 megs of ram, then perl(5.8.7)
wants 180 megs. On freebsd, it's actually worse
On Feb 2, 2006, at 15:10, Patrick R. Michaud via RT wrote:
...as of r11409, I'm not seeing the 'make test' error for punie
(on my Linux/x86_64 box).
I don't know if this is because it's now working, or because you've
routed around the particular problem you were seeing, so let
me know if you're
On Wed, Feb 01, 2006 at 05:33:29PM -0800, Allison Randal wrote:
> # New Ticket Created by Allison Randal
> # Please include the string: [perl #38406]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/rt3/Ticket/Display.html?id=38406 >
>
>
> I've sp
Leopold Toetsch wrote:
.sub main :method
.local int a
(a,$S0) = self."foo"()
self."bar"()
.end
and
> ... get_results PMC_C[236] (5), I3, I0, I4, I1, S-1
This is solved now with r11408 / r11409.
leo
On Thu, Feb 02, 2006 at 01:32:49PM -0800, jerry gay wrote:
> > This may or may not be related, but I'm getting a segfault for
> > building PGE itself (x86_64/linux), when trying to run mklib.pir
> > to generate the built-in rules.
> >
> i'm getting this, too, on win32. as are others, i think, on ma
Patrick R. Michaud wrote:
This may or may not be related, but I'm getting a segfault for
building PGE itself (x86_64/linux), when trying to run mklib.pir
to generate the built-in rules.
Yep. Working on that currently. I've simplied it to this testcase now:
.sub main :method
.local int a
On 2/2/06, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 02, 2006 at 11:33:25AM +0100, Leopold Toetsch wrote:
> > On Feb 2, 2006, at 2:33, Allison Randal (via RT) wrote:
> >
> > >I've spent too much time on this error, so I'm routing around it, but
> > >I'd love to figure out what's c
On Thu, Feb 02, 2006 at 11:33:25AM +0100, Leopold Toetsch wrote:
> On Feb 2, 2006, at 2:33, Allison Randal (via RT) wrote:
>
> >I've spent too much time on this error, so I'm routing around it, but
> >I'd love to figure out what's causing it. In my local version of
> >Punie I get this error when I
On Thu, Feb 02, 2006 at 11:33:25AM +0100, Leopold Toetsch wrote:
:
: On Feb 2, 2006, at 2:33, Allison Randal (via RT) wrote:
:
: >I've spent too much time on this error, so I'm routing around it, but
: >I'd love to figure out what's causing it. In my local version of
: >Punie I get this error whe
On Feb 2, 2006, at 2:33, Allison Randal (via RT) wrote:
I've spent too much time on this error, so I'm routing around it, but
I'd love to figure out what's causing it. In my local version of
Punie I get this error when I run 'make test':
[ ... ]
... Also, if I modify the Punie compiler to d
29 matches
Mail list logo
