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
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:
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
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
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 are other
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.
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
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
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.
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
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
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
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
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
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
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
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.c
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 uncomment
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 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/vtables.t and
21 matches
Mail list logo
