On Saturday 08 December 2007 18:17:17 chromatic wrote:
> Test #9 in t/oo/new.t consumes ever-increasing amounts of memory for me. I
> ran it in the debugger, caused a segfault, and stopped the backtrace at:
>
> #17283 0xb7e39340 in Parrot_Key_get_string (interp=0x804f008,
> pmc=0x8262790) at ./sr
# New Ticket Created by chromatic
# Please include the string: [perl #48365]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=48365 >
Test #9 in t/oo/new.t consumes ever-increasing amounts of memory for me. I
ran it in the
On Saturday 08 December 2007 14:59:32 Andy Lester wrote:
> When last I was playing with Parrot, I recall noises that imcc was not
> useful, and was effectively dead.
>
> Is this right, or am I misremembering?
You're misremembering. IMCC still handles all PIR, and you can't do much with
Parrot w
# New Ticket Created by Allison Randal
# Please include the string: [perl #48357]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=48357 >
Original Message
Subject: Re: Platform testing for concurrency sched
When last I was playing with Parrot, I recall noises that imcc was not
useful, and was effectively dead.
Is this right, or am I misremembering? Is it worth my time to const &
headerize it? If not, I'm pretty much done with headerizing.
xoxo,
Andy
--
Andy Lester => [EMAIL PROTECTED] => ww
On 8 Dec 2007, at 20:22, Allison Randal wrote:
Could you edit src/scheduler.c and change the value of CX_DEBUG to
1, recompile, and run the test suite? Most of the tests will fail
because of the additional output on stderr, but if you can catch a
hang, we'll have a little more detail on what
Andy Armstrong wrote:
On 8 Dec 2007, at 14:18, Andy Armstrong wrote:
Please let me know if there's anything you'd like me to investigate.
I'm afraid I don't know my way around parrot, er, at all - but I'm
willing to learn.
Ah, Mac OS 10.5 has dtrace - which I hadn't tried before but turns ou
On Saturday 08 December 2007 08:29:05 Jonathan Worthington wrote:
> chromatic wrote:
> > On Thursday 06 December 2007 15:49:45 Jonathan Worthington wrote:
> >> What it implemented (when I get chance, which should be this weekend) as
> >> an arity method on the Sub PMC?
> > That would be much nice
On Friday 07 December 2007 11:22:10 Klaas-Jan Stol wrote:
> According to the spec, this is a bug.
>
> Now, this isn't a big deal, because the semantics of the program aren't
> changed. The only problem I can imagine is for embedders, but I'm not sure
> if you can poke into parrot registers from a
chromatic wrote:
On Thursday 06 December 2007 15:49:45 Jonathan Worthington wrote:
What it implemented (when I get chance, which should be this weekend) as
an arity method on the Sub PMC?
That would be much nicer
Implemented in r23598 for the Sub PMC.
(which doesn't make sense with
On 8 Dec 2007, at 14:18, Andy Armstrong wrote:
Please let me know if there's anything you'd like me to investigate.
I'm afraid I don't know my way around parrot, er, at all - but I'm
willing to learn.
Ah, Mac OS 10.5 has dtrace - which I hadn't tried before but turns out
to be rather cool
On 8 Dec 2007, at 13:42, Allison Randal wrote:
Are you sure you've got the very latest version of all files on this
box ('make realclean', etc)?
Yup. I've just done make realclean && make && make test again and this
time it hung at
t/pmc/parrotlibrary1/1
(time
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #48326]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=48326 >
ACcording to PDD19:
If you directly reference P99, Parrot will blindly allocate 100 r
Andy Armstrong wrote:
But on Mac OS 10.5 I get random hangs. First at
t/op/01-parse_ops..287/335
for about ten minutes until I interrupted it and then
t/op/string_cs.1/50
for another ten or so minutes.
Are you sure you've got the
chromatic wrote:
On Ubuntu 7.10:
t/src/vtables..1/4
# Failed test (t/src/vtables.t at line 142)
# Exited with error code: [SIGNAL 139]
[...]
This didn't go away on a realclean. I even moved ending the runloop to before
the full DOD when destroying an interpreter, but to no effect.
On 7 Dec 2007, at 16:32, chromatic wrote:
On Friday 07 December 2007 05:23:39 Allison Randal wrote:
I'm about to turn on the concurrency scheduler runloop in Parrot
trunk.
Before I do, I'd like test results on as many platforms as possible
(especially Windows, since it doesn't use POSIX threa
16 matches
Mail list logo
