Mark Dickinson dicki...@gmail.com added the comment:
I've fixed test_itimer_virtual and test_itimer_prof to use a timeout
instead of an xrange/range(1) loop, in r75986 through r75989.
--
status: open - closed
___
Python tracker
Jan Hosang jan.hos...@gmail.com added the comment:
I updated the checkout of the 26 branch, and the test runs fine now.
I have no clue about virtual time as well. If this is about passing time,
there should be better ways (than those which break if your computer gets
faster).
--
Mark Dickinson dicki...@gmail.com added the comment:
If this is about passing time, there should be better ways (than
those which break if your computer gets faster).
Agreed. The challenge is to find ways that don't add too much in the
way of extra complexity, fragility, or dependencies to
Mark Dickinson dicki...@gmail.com added the comment:
Oops. That 5.0 should have been 30.0, of course.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7042
___
Jan Hosang jan.hos...@gmail.com added the comment:
I think a timing out while loop explains much better what is happening. I
mean we are trying to keep the cpu busy for 0.9 seconds (if I understand
the definition of virtual time correctly) and not do 1 increments
(which might be done
Mark Dickinson dicki...@gmail.com added the comment:
I'm seeing this failure too, on a 64-bit build of the trunk on OS X
10.6.1.
If I understand the test, it's setting up a timer that's supposed to run
for 0.3 seconds of 'virtual time', signal, and then signal every 0.2
seconds of virtual
Mark Dickinson dicki...@gmail.com added the comment:
Issue #5972 looks like the same problem.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7042
___
Mark Dickinson dicki...@gmail.com added the comment:
This may also explain why the x86 FreeBSD trunk buildbot is currently
hanging on test_signal.
(And I see Ned already mentioned issue 5972 above. Sorry for the noise.)
--
___
Python tracker
Mark Dickinson dicki...@gmail.com added the comment:
chuck: does the attached patch fix the problem for you?
--
keywords: +patch
Added file: http://bugs.python.org/file15038/issue7042.patch
___
Python tracker rep...@bugs.python.org
Mark Dickinson dicki...@gmail.com added the comment:
I've applied the above patch in r75236 (trunk), r75237 (release26-maint),
r75238 (py3k) and r75239 (release31-maint). With any luck this should fix
the issue. Jan Hosang, can you confirm that this is fixed?
--
resolution: - fixed
Jan Hosang jan.hos...@gmail.com added the comment:
This is a 64 bit machine and the test failed for the checkout of the
python26-maint branch. I just configured and made it without any flags.
(Does that produce a 64 bit build?)
--
___
Python
Ned Deily n...@acm.org added the comment:
By default, 10.6 prefers to run 64-bit architectures when available. You
can easily tell whether a python 2.x is running as 32-bit or 64-bit by
checking sys.maxint:
$ /usr/local/bin/python2.6 -c 'import sys; print sys.maxint'
2147483647
$
Jan Hosang jan.hos...@gmail.com added the comment:
$ ./python.exe -c 'import sys; print sys.maxint'
9223372036854775807
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7042
___
New submission from Jan Hosang jan.hos...@gmail.com:
==
FAIL: test_itimer_virtual (test.test_signal.ItimerTest)
--
Traceback (most recent call last):
File
Ned Deily n...@acm.org added the comment:
test_signal does not fail for me on 10.6 using the python.org 2.6.3
installer (which is 32-bit). The test hangs (presumably in the wait
loop) with a 10.6 64-bit build of Python 2.6.3rc1. FWIW, the 2.6.3
test_signal seems to run OK with Apple's
15 matches
Mail list logo
