Yeah, good point. Another thing to try might be to try removing one of the other tests at a time until the test stops failing.
On Tue, Feb 26, 2008 at 11:55 AM, Casey Duncan <[EMAIL PROTECTED]> wrote: > > 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 >
