Andy Armstrong wrote:
I uncommented the Parrot_cx calls and ran the tests twice - once with
CX_DEBUG = 1, once with CX_DEBUG = 0. It got through them all both times :)
Excellent!
Thanks,
Allison
On 12 Dec 2007, at 19:53, Allison Randal wrote:
So, I'm interested to see what your 10.5 box does.
I uncommented the Parrot_cx calls and ran the tests twice - once with
CX_DEBUG = 1, once with CX_DEBUG = 0. It got through them all both
times :)
--
Andy Armstrong, Hexten
Andy Armstrong wrote:
Again, let me know if you need more.
Could you give it another go with the latest revision? (You'll need to
uncomment the 'Parrot_cx...' lines in src/inter_create.c again, as I
commented them out in trunk while working on the hangs.)
I've eliminated the hangs on my du
Andy Armstrong wrote:
Again, let me know if you need more.
I pushed it far enough that I was able to repeat the deadlock hang on OS
10.4.11, that's good. The interesting thing was the order of operations.
The usual order is:
call to Parrot_cx_init_scheduler
initializing scheduler runloop
s
On 9 Dec 2007, at 21:02, Allison Randal wrote:
Andy Armstrong wrote:
And Instruments is telling me this:
http://hexten.net/junk/parrot1.png
Nice level of detail in this tool. Almost worth the cost of 10.5 all
on its own.
It seems rather lovely. Bear in mind that I didn't even launch it
u
Andy Armstrong wrote:
And Instruments is telling me this:
http://hexten.net/junk/parrot1.png
Nice level of detail in this tool. Almost worth the cost of 10.5 all on
its own.
It seems to hang much more readily with CX_DEBUG enabled - including
once during make rather than make test.
Good
On 07/12/2007, Allison Randal <[EMAIL PROTECTED]> wrote:
> Andy Dougherty wrote:
> >
> > Whether this is a defect in the vtables_4 test sourcefile for failing to
> > initialize the vtables, or whether pmc_new ought to be more defensive, I
> > can't say.
>
> Looks like a bug in the test, as there ar
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 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
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
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 threads).
>
> To test it, edit src/inter_create
Andy Dougherty wrote:
Whether this is a defect in the vtables_4 test sourcefile for failing to
initialize the vtables, or whether pmc_new ought to be more defensive, I
can't say.
Looks like a bug in the test, as there are other things in Parrot_exit
that won't behave appropriately without an
On Fri, 7 Dec 2007, 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 threads).
>
> To test it, edit src/inter_create.c and uncomme
On Fri, Dec 07, 2007 at 08:45:03PM +0200, Allison Randal wrote:
> jerry gay wrote:
> >>
> >looks good to me. commit away!
> >nice work.
>
> I've got a clean report on our core platform targets, so committed in
> r23574. As usual, please report any issues.
r23574 gives me failures in t/src/vtable
jerry gay wrote:
looks good to me. commit away!
nice work.
I've got a clean report on our core platform targets, so committed in
r23574. As usual, please report any issues.
Thanks!
Allison
On Dec 7, 2007 5:23 AM, Allison Randal <[EMAIL PROTECTED]> 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 threads).
>
> To test it, edit src/inte
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 threads).
To test it, edit src/inter_create.c and uncomment the two lines that
start with 'Parrot_cx...".
21 matches
Mail list logo
