On Feb 25, 2008, at 4:37 PM, Lenard Lindstrom wrote:
Lenard Lindstrom wrote:
[EMAIL PROTECTED] wrote:
Lenard Lindstrom <[EMAIL PROTECTED]>:
[snip]
I just bring this up since it shows possible problems with
testing more
than one version of Python on the same system. If it is a Pygame
bug it
is unpredictable and hard to pin down. So please keep a watch for
similar problems. Maybe someone using Python 2.4 and SVN version
1126
of Pygame can run the unit tests ten or more times consecutively to
check if it passes consistently? My installers are available at
http://www3.telus.net/len_l/pygame.htm along with SVN version
1126 of
the Pygame 1.8 documents and examples in compressed and installer
form.
Interesting issue. Do you use x64 hardware to test? Maybe it's
related by
the Py_ssize_t changes we made for backwards compatibility.
I'll recheck that for my systems and try to find out, what's going
on.
No, I just have a very old Win32 machine. The fail is sporadic and
appears linked to mixing Pythons. Deleting the .pyc files and
rebooting the computer cleared the problem for 2.4 until I ran 2.5
again. But it could be I am just seeing patterns where they don't
exist and it is something unrelated. So I have just tried it again
from the same Pygame source directory:
Python 2.4 three times - passed,
2.5 once - passed,
2.4 three times - passed,
2.5 once - passed,
2.4 twice - failed, passed.
The problem could be with the Python 2.4 unit testing framework
itself. I put pixelarray_test.py in its own directory and ran both
Python 2.4 and 2.5 on it multiple times. Everything passed.
Does the individual test case every fail in isolation? Sometimes tests
can interfere with one another and running with different versions of
python, a different machine or with a different copy of the file can
affect test execution order and cause seemingly random failures.
Should be easy to write a script that just runs that one test case
forever to see if it ever fails (within say 1000 runs).
-Casey
