Re: [pygame] Tests crashing Automatic Build page + Compiling PyGame on Windows

[Lenard Lindstrom]

When I run the tests in the same, alphabetical, order as the automated 
build page I get :


ERROR: test_surfarray_ref (surflock_test.SurfaceLockTest)
--
Traceback (most recent call last):
 File "test\surflock_test.py", line 141, in test_surfarray_ref
   ar = pygame.surfarray.pixels2d (sf)
 File "C:\PRG\PYTHON25\lib\site-packages\pygame\surfarray.py", line 
122, in pix

els2d
   return numericsf.pixels2d (surface)
ValueError: unsupport bit depth for 2D reference array


So the tests are interacting with each other in unintended ways. In my 
case to set_mode in a previous unit test left the default surface bit 
depth at 24, the same as my display. Without a call to set_mode the 
default is 32. This also explains the errors with transform_test.py and 
a 16 bit display. The freezing of the unit tests remains a mystery.


Lenard



Brian Fisher wrote:
buffer over-runs and bad memory access are not guaranteed to crash - 
especially when they depend on uninitialized memory or the behavior is 
dependent on timing. If it crashed before, but not now, that may be why.


FYI, the crashes that are stopping my automated build page from 
passing tests appears to be in _numericsurfarray.pyd - I haven't 
looked into it more yet.


On Sat, Jun 21, 2008 at 5:39 PM, Nicholas Dudfield 
<[EMAIL PROTECTED] > wrote:


All is working fine now, I briefly had a weird crash of HEAD
compiled here but I can't repeat it. The tests work and are
passing now.

Re: [pygame] Tests crashing Automatic Build page + Compiling PyGame on Windows

[Nicholas Dudfield]

Lenard,

>> I have both numpy and Numeric installed. surfarray defaults to Numeric.

I had neither; essentially a clean install of python 2.5

>> The subunit module uses os.fork which is unavailable on Windows 
(http://www.robertcollins.net/unittest/subunit/README). I don't know how 
to handle hung processes in a portable way as the os.kill function is 
only available on Unix.


That's a pity. I didn't have the time before to have a good look at it.

We could use subprocess to wrap sysinternals pskill for an os.kill on 
windows?


>> Let's hope if this is a Pygame bug it shows up in some other, more 
predictable, way soon.


Yeah, definitely


Anyway, If you (or anyone else) has any ideas for wrapping the tests up 
in subprocesses please let me know.


Cheers.

Re: [pygame] Tests crashing Automatic Build page + Compiling PyGame on Windows

[Lenard Lindstrom]

Nicholas Dudfield wrote:

Yeah my display was at 16bit and I didn't have numpy installed.

I have both numpy and Numeric installed. surfarray defaults to Numeric.



All is working fine now, I briefly had a weird crash of HEAD compiled 
here but I can't repeat it. The tests work and are passing now.
Let's hope if this is a Pygame bug it shows up in some other, more 
predictable, way soon.




Any ideas for how to go about wrapping each in it's own process. 
Probably extending unittest would be the best way yeah?


The subunit module uses os.fork which is unavailable on Windows 
(http://www.robertcollins.net/unittest/subunit/README). I don't know how 
to handle hung processes in a portable way as the os.kill function is 
only available on Unix.




Lenard Lindstrom wrote:
What is your display's color setting? I have 24 bit True Color. 32 
bit True Color is more common. This affects the default surface 
format. I just managed to freeze the unit tests by setting my display 
to 16 bit High Color.







--
Lenard Lindstrom
<[EMAIL PROTECTED]>

Re: [pygame] Tests crashing Automatic Build page + Compiling PyGame on Windows

[Brian Fisher]

buffer over-runs and bad memory access are not guaranteed to crash -
especially when they depend on uninitialized memory or the behavior is
dependent on timing. If it crashed before, but not now, that may be why.

FYI, the crashes that are stopping my automated build page from passing
tests appears to be in _numericsurfarray.pyd - I haven't looked into it more
yet.

On Sat, Jun 21, 2008 at 5:39 PM, Nicholas Dudfield <[EMAIL PROTECTED]>
wrote:

> All is working fine now, I briefly had a weird crash of HEAD compiled here
> but I can't repeat it. The tests work and are passing now.
>
>

Re: [pygame] Tests crashing Automatic Build page + Compiling PyGame on Windows

[Nicholas Dudfield]

Hey guys my buddy wants his computer. I found a few unittest extensions, 
one called subunit, designed for pretty much what we have in mind.


Talk soon.


Lenard Lindstrom wrote:

Hi Nicholas,,,

Nicholas Dudfield wrote:

Lenard,

>> if it goes into the wiki then it could be corrupted by someone else

Sorry, I meant to say a link on the wiki to where it is now would be 
handy.


I am looking into getting the source bundle added to the Pygame 
download page.



>> Did you install MSYS-DTK-1.0.1?

Yes, I downloaded the MSYS developers tool kit, msysDTK-1.0.1.exe and 
installed it.


>>  Are the tests for revision 1376? Nothing causes problems like 
running the wrong tests.


Yeah, the tests were run from the svn co directory. The tests were 
for the svn HEAD at the time, 1376, which I had just built and 
installed.I even made sure to destroy old pyc files.


>> The subprocess module works better but requires pywin32 be 
installed for Windows.


Cheers. I'm sorry if popen4 caused any problems for you.

Though it worked most of the time for me I couldn't figure out how to 
get the "OK" check to work on the automated build site.




This is really odd, I'm nuking my site-packages/pygame directory, 
building and installing from HEAD and then running the HEAD  tests, 
but I'm still have crashing issues.


What's the difference between mine and your's and marcus's setup?

Compiling issues come to mind but then I recall I had the same 
problem after downloading your 1376 msi. I nuked the pygame directory 
before installing that also.




I realized that the surflock_test.py error that was taking down 
run_tests.py (for me anyway) was just that I needed to have numpy 
installed. Then the suite finished but with these errors.


==
ERROR: see if the destination surface can be passed in to use.
--
Traceback (most recent call last):
 File "D:\Losty\PyGame\trunk\test\transform_test.py", line 114, in 
test_scale_d

estination
   s2 = pygame.transform.smoothscale(s, (64,64))
ValueError: Only 24-bit or 32-bit surfaces can be smoothly scaled

==
FAIL: test_average_surfaces (transform_test.TransformTest)
--
Traceback (most recent call last):
 File "D:\Losty\PyGame\trunk\test\transform_test.py", line 239, in 
test_average

_surfaces
   self.assertEqual(sr.get_at((0,0)), (10,15,70,255))
AssertionError: (8, 12, 66, 255) != (10, 15, 70, 255)

==
FAIL: test_threshold_surface (transform_test.TransformTest)
--
Traceback (most recent call last):
 File "D:\Losty\PyGame\trunk\test\transform_test.py", line 145, in 
test_thresho

ld_surface
   self.assertEqual(num_threshold_pixels, s1.get_height() * 
s1.get_width())

AssertionError: 0 != 1024

--
Ran 264 tests in 5.703s

FAILED (failures=2, errors=1)


Then running transform_test.py independently:

D:\Losty\PyGame\trunk\test>transform_test.py
.
--
Ran 5 tests in 0.016s

OK


_What the_?

Any ideas guys? What am I doing wrong?

What is your display's color setting? I have 24 bit True Color. 32 bit 
True Color is more common. This affects the default surface format. I 
just managed to freeze the unit tests by setting my display to 16 bit 
High Color.

Re: [pygame] Tests crashing Automatic Build page + Compiling PyGame on Windows

[Nicholas Dudfield]

Yeah my display was at 16bit and I didn't have numpy installed.

All is working fine now, I briefly had a weird crash of HEAD compiled 
here but I can't repeat it. The tests work and are passing now.


Any ideas for how to go about wrapping each in it's own process. 
Probably extending unittest would be the best way yeah?



Lenard Lindstrom wrote:

Hi Nicholas,,,

Nicholas Dudfield wrote:

Lenard,

>> if it goes into the wiki then it could be corrupted by someone else

Sorry, I meant to say a link on the wiki to where it is now would be 
handy.


I am looking into getting the source bundle added to the Pygame 
download page.



>> Did you install MSYS-DTK-1.0.1?

Yes, I downloaded the MSYS developers tool kit, msysDTK-1.0.1.exe and 
installed it.


>>  Are the tests for revision 1376? Nothing causes problems like 
running the wrong tests.


Yeah, the tests were run from the svn co directory. The tests were 
for the svn HEAD at the time, 1376, which I had just built and 
installed.I even made sure to destroy old pyc files.


>> The subprocess module works better but requires pywin32 be 
installed for Windows.


Cheers. I'm sorry if popen4 caused any problems for you.

Though it worked most of the time for me I couldn't figure out how to 
get the "OK" check to work on the automated build site.




This is really odd, I'm nuking my site-packages/pygame directory, 
building and installing from HEAD and then running the HEAD  tests, 
but I'm still have crashing issues.


What's the difference between mine and your's and marcus's setup?

Compiling issues come to mind but then I recall I had the same 
problem after downloading your 1376 msi. I nuked the pygame directory 
before installing that also.




I realized that the surflock_test.py error that was taking down 
run_tests.py (for me anyway) was just that I needed to have numpy 
installed. Then the suite finished but with these errors.


==
ERROR: see if the destination surface can be passed in to use.
--
Traceback (most recent call last):
 File "D:\Losty\PyGame\trunk\test\transform_test.py", line 114, in 
test_scale_d

estination
   s2 = pygame.transform.smoothscale(s, (64,64))
ValueError: Only 24-bit or 32-bit surfaces can be smoothly scaled

==
FAIL: test_average_surfaces (transform_test.TransformTest)
--
Traceback (most recent call last):
 File "D:\Losty\PyGame\trunk\test\transform_test.py", line 239, in 
test_average

_surfaces
   self.assertEqual(sr.get_at((0,0)), (10,15,70,255))
AssertionError: (8, 12, 66, 255) != (10, 15, 70, 255)

==
FAIL: test_threshold_surface (transform_test.TransformTest)
--
Traceback (most recent call last):
 File "D:\Losty\PyGame\trunk\test\transform_test.py", line 145, in 
test_thresho

ld_surface
   self.assertEqual(num_threshold_pixels, s1.get_height() * 
s1.get_width())

AssertionError: 0 != 1024

--
Ran 264 tests in 5.703s

FAILED (failures=2, errors=1)


Then running transform_test.py independently:

D:\Losty\PyGame\trunk\test>transform_test.py
.
--
Ran 5 tests in 0.016s

OK


_What the_?

Any ideas guys? What am I doing wrong?

What is your display's color setting? I have 24 bit True Color. 32 bit 
True Color is more common. This affects the default surface format. I 
just managed to freeze the unit tests by setting my display to 16 bit 
High Color.

Re: [pygame] Tests crashing Automatic Build page + Compiling PyGame on Windows

[Lenard Lindstrom]

Hi Nicholas,,,

Nicholas Dudfield wrote:

Lenard,

>> if it goes into the wiki then it could be corrupted by someone else

Sorry, I meant to say a link on the wiki to where it is now would be 
handy.


I am looking into getting the source bundle added to the Pygame download 
page.



>> Did you install MSYS-DTK-1.0.1?

Yes, I downloaded the MSYS developers tool kit, msysDTK-1.0.1.exe and 
installed it.


>>  Are the tests for revision 1376? Nothing causes problems like 
running the wrong tests.


Yeah, the tests were run from the svn co directory. The tests were for 
the svn HEAD at the time, 1376, which I had just built and installed.I 
even made sure to destroy old pyc files.


>> The subprocess module works better but requires pywin32 be 
installed for Windows.


Cheers. I'm sorry if popen4 caused any problems for you.

Though it worked most of the time for me I couldn't figure out how to 
get the "OK" check to work on the automated build site.




This is really odd, I'm nuking my site-packages/pygame directory, 
building and installing from HEAD and then running the HEAD  tests, 
but I'm still have crashing issues.


What's the difference between mine and your's and marcus's setup?

Compiling issues come to mind but then I recall I had the same problem 
after downloading your 1376 msi. I nuked the pygame directory before 
installing that also.




I realized that the surflock_test.py error that was taking down 
run_tests.py (for me anyway) was just that I needed to have numpy 
installed. Then the suite finished but with these errors.


==
ERROR: see if the destination surface can be passed in to use.
--
Traceback (most recent call last):
 File "D:\Losty\PyGame\trunk\test\transform_test.py", line 114, in 
test_scale_d

estination
   s2 = pygame.transform.smoothscale(s, (64,64))
ValueError: Only 24-bit or 32-bit surfaces can be smoothly scaled

==
FAIL: test_average_surfaces (transform_test.TransformTest)
--
Traceback (most recent call last):
 File "D:\Losty\PyGame\trunk\test\transform_test.py", line 239, in 
test_average

_surfaces
   self.assertEqual(sr.get_at((0,0)), (10,15,70,255))
AssertionError: (8, 12, 66, 255) != (10, 15, 70, 255)

==
FAIL: test_threshold_surface (transform_test.TransformTest)
--
Traceback (most recent call last):
 File "D:\Losty\PyGame\trunk\test\transform_test.py", line 145, in 
test_thresho

ld_surface
   self.assertEqual(num_threshold_pixels, s1.get_height() * 
s1.get_width())

AssertionError: 0 != 1024

--
Ran 264 tests in 5.703s

FAILED (failures=2, errors=1)


Then running transform_test.py independently:

D:\Losty\PyGame\trunk\test>transform_test.py
.
--
Ran 5 tests in 0.016s

OK


_What the_?

Any ideas guys? What am I doing wrong?

What is your display's color setting? I have 24 bit True Color. 32 bit 
True Color is more common. This affects the default surface format. I 
just managed to freeze the unit tests by setting my display to 16 bit 
High Color.


--
Lenard Lindstrom
<[EMAIL PROTECTED]>

Re: [pygame] Tests crashing Automatic Build page + Compiling PyGame on Windows

[Nicholas Dudfield]

Damn, I'm still having problems :(

I was trying out Lenards 1376 msi + svn co -r 1376 tests. That was 
working fine.


Two problems solved anyway:
   16 bit display
   numpy not installed

Now the run_tests.py is crashing for me again on HEAD compiled.

AppName: python.exe AppVer: 0.0.0.0 ModName: pixelarray.pyd
ModVer: 0.0.0.0 Offset: 50b1

Has much changed since 1376 or is it compiling weirdness? That's the 
question.


I may try compiling 1376 + running tests, if the problem remains I'll 
know it's compiling issues. Perhaps I have different versions of 
dependencies or tools than Lenard?


Yeah, I think it will be worth splitting them up even it possibly makes 
the tests run a little slower.




Brian Fisher wrote:

cool.

BTW, I think it's great that you are splitting up the tests to be in 
their own process. I always thought it was very unnatural of the test 
runner to run all the tests in the same process - so that pygame will 
get init and quit and have the display surface created and all that 
over an over again. Not that it would be bad to have a test that tests 
recreating the display surface and all that - just that 99.9% of all 
pygame apps will be launch process, init, set mode, then process 
exits, so testing that model is important.


On Sat, Jun 21, 2008 at 5:05 PM, Nicholas Dudfield 
<[EMAIL PROTECTED] > wrote:


Nice Find! Thanks a million Brian.

There must have been other tests that initialized the display and
set the bit depth before hand implicitly.

That must be why it worked when run independently. The
transfrom_test themselves are probably explicit.

Again, thanks!




Brian Fisher wrote:

hey Nick,
 is your desktop set to 16-bit maybe?
I haven't looked at the test code, but if bit depth isn't
explicitly set it will use the desktop depth

On Sat, Jun 21, 2008 at 4:40 PM, Nicholas Dudfield
<[EMAIL PROTECTED] 
>> wrote:


 
 ==

   ERROR: see if the destination surface can be passed in to use.
 
 --

   Traceback (most recent call last):
File "D:\Losty\PyGame\trunk\test\transform_test.py", line
114, in
   test_scale_d
   estination
 s2 = pygame.transform.smoothscale(s, (64,64))
   ValueError: Only 24-bit or 32-bit surfaces can be smoothly
scaled

 
 ==

   FAIL: test_average_surfaces (transform_test.TransformTest)
 
 --

   Traceback (most recent call last):
File "D:\Losty\PyGame\trunk\test\transform_test.py", line
239, in
   test_average
   _surfaces
 self.assertEqual(sr.get_at((0,0)), (10,15,70,255))
   AssertionError: (8, 12, 66, 255) != (10, 15, 70, 255)

 
 ==

   FAIL: test_threshold_surface (transform_test.TransformTest)
 
 --

   Traceback (most recent call last):
File "D:\Losty\PyGame\trunk\test\transform_test.py", line
145, in
   test_thresho
   ld_surface
 self.assertEqual(num_threshold_pixels, s1.get_height() *
   s1.get_width())
   AssertionError: 0 != 1024

 
 --

   Ran 264 tests in 5.703s

   FAILED (failures=2, errors=1)


   Then running transform_test.py independently:

   D:\Losty\PyGame\trunk\test>transform_test.py
   .
 
 --

   Ran 5 tests in 0.016s

   OK


   _What the_?

   Any ideas guys? What am I doing wrong?

Re: [pygame] Tests crashing Automatic Build page + Compiling PyGame on Windows

[Brian Fisher]

cool.

BTW, I think it's great that you are splitting up the tests to be in their
own process. I always thought it was very unnatural of the test runner to
run all the tests in the same process - so that pygame will get init and
quit and have the display surface created and all that over an over again.
Not that it would be bad to have a test that tests recreating the display
surface and all that - just that 99.9% of all pygame apps will be launch
process, init, set mode, then process exits, so testing that model is
important.

On Sat, Jun 21, 2008 at 5:05 PM, Nicholas Dudfield <[EMAIL PROTECTED]>
wrote:

> Nice Find! Thanks a million Brian.
>
> There must have been other tests that initialized the display and set the
> bit depth before hand implicitly.
>
> That must be why it worked when run independently. The transfrom_test
> themselves are probably explicit.
>
> Again, thanks!
>
>
>
>
> Brian Fisher wrote:
>
>> hey Nick,
>>  is your desktop set to 16-bit maybe?
>> I haven't looked at the test code, but if bit depth isn't explicitly set
>> it will use the desktop depth
>>
>> On Sat, Jun 21, 2008 at 4:40 PM, Nicholas Dudfield <[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:
>>
>>
>>==
>>ERROR: see if the destination surface can be passed in to use.
>>--
>>Traceback (most recent call last):
>> File "D:\Losty\PyGame\trunk\test\transform_test.py", line 114, in
>>test_scale_d
>>estination
>>  s2 = pygame.transform.smoothscale(s, (64,64))
>>ValueError: Only 24-bit or 32-bit surfaces can be smoothly scaled
>>
>>==
>>FAIL: test_average_surfaces (transform_test.TransformTest)
>>--
>>Traceback (most recent call last):
>> File "D:\Losty\PyGame\trunk\test\transform_test.py", line 239, in
>>test_average
>>_surfaces
>>  self.assertEqual(sr.get_at((0,0)), (10,15,70,255))
>>AssertionError: (8, 12, 66, 255) != (10, 15, 70, 255)
>>
>>==
>>FAIL: test_threshold_surface (transform_test.TransformTest)
>>--
>>Traceback (most recent call last):
>> File "D:\Losty\PyGame\trunk\test\transform_test.py", line 145, in
>>test_thresho
>>ld_surface
>>  self.assertEqual(num_threshold_pixels, s1.get_height() *
>>s1.get_width())
>>AssertionError: 0 != 1024
>>
>>--
>>Ran 264 tests in 5.703s
>>
>>FAILED (failures=2, errors=1)
>>
>>
>>Then running transform_test.py independently:
>>
>>D:\Losty\PyGame\trunk\test>transform_test.py
>>.
>>--
>>Ran 5 tests in 0.016s
>>
>>OK
>>
>>
>>_What the_?
>>
>>Any ideas guys? What am I doing wrong?
>>
>>
>>
>>
>

Re: [pygame] Tests crashing Automatic Build page + Compiling PyGame on Windows

[Nicholas Dudfield]

Nice Find! Thanks a million Brian.

There must have been other tests that initialized the display and set 
the bit depth before hand implicitly.


That must be why it worked when run independently. The transfrom_test 
themselves are probably explicit.


Again, thanks!




Brian Fisher wrote:

hey Nick,
 is your desktop set to 16-bit maybe?
I haven't looked at the test code, but if bit depth isn't explicitly 
set it will use the desktop depth


On Sat, Jun 21, 2008 at 4:40 PM, Nicholas Dudfield 
<[EMAIL PROTECTED] > wrote:



==
ERROR: see if the destination surface can be passed in to use.
--
Traceback (most recent call last):
 File "D:\Losty\PyGame\trunk\test\transform_test.py", line 114, in
test_scale_d
estination
  s2 = pygame.transform.smoothscale(s, (64,64))
ValueError: Only 24-bit or 32-bit surfaces can be smoothly scaled

==
FAIL: test_average_surfaces (transform_test.TransformTest)
--
Traceback (most recent call last):
 File "D:\Losty\PyGame\trunk\test\transform_test.py", line 239, in
test_average
_surfaces
  self.assertEqual(sr.get_at((0,0)), (10,15,70,255))
AssertionError: (8, 12, 66, 255) != (10, 15, 70, 255)

==
FAIL: test_threshold_surface (transform_test.TransformTest)
--
Traceback (most recent call last):
 File "D:\Losty\PyGame\trunk\test\transform_test.py", line 145, in
test_thresho
ld_surface
  self.assertEqual(num_threshold_pixels, s1.get_height() *
s1.get_width())
AssertionError: 0 != 1024

--
Ran 264 tests in 5.703s

FAILED (failures=2, errors=1)


Then running transform_test.py independently:

D:\Losty\PyGame\trunk\test>transform_test.py
.
--
Ran 5 tests in 0.016s

OK


_What the_?

Any ideas guys? What am I doing wrong?

Re: [pygame] Tests crashing Automatic Build page + Compiling PyGame on Windows

[Brian Fisher]

hey Nick,
 is your desktop set to 16-bit maybe?
I haven't looked at the test code, but if bit depth isn't explicitly set it
will use the desktop depth

On Sat, Jun 21, 2008 at 4:40 PM, Nicholas Dudfield <[EMAIL PROTECTED]>
wrote:

>
> ==
> ERROR: see if the destination surface can be passed in to use.
> --
> Traceback (most recent call last):
>  File "D:\Losty\PyGame\trunk\test\transform_test.py", line 114, in
> test_scale_d
> estination
>   s2 = pygame.transform.smoothscale(s, (64,64))
> ValueError: Only 24-bit or 32-bit surfaces can be smoothly scaled
>
> ==
> FAIL: test_average_surfaces (transform_test.TransformTest)
> --
> Traceback (most recent call last):
>  File "D:\Losty\PyGame\trunk\test\transform_test.py", line 239, in
> test_average
> _surfaces
>   self.assertEqual(sr.get_at((0,0)), (10,15,70,255))
> AssertionError: (8, 12, 66, 255) != (10, 15, 70, 255)
>
> ==
> FAIL: test_threshold_surface (transform_test.TransformTest)
> --
> Traceback (most recent call last):
>  File "D:\Losty\PyGame\trunk\test\transform_test.py", line 145, in
> test_thresho
> ld_surface
>   self.assertEqual(num_threshold_pixels, s1.get_height() * s1.get_width())
> AssertionError: 0 != 1024
>
> --
> Ran 264 tests in 5.703s
>
> FAILED (failures=2, errors=1)
>
>
> Then running transform_test.py independently:
>
> D:\Losty\PyGame\trunk\test>transform_test.py
> .
> --
> Ran 5 tests in 0.016s
>
> OK
>
>
> _What the_?
>
> Any ideas guys? What am I doing wrong?
>
>
>

Re: [pygame] Tests crashing Automatic Build page + Compiling PyGame on Windows

[Nicholas Dudfield]

Lenard,

>> if it goes into the wiki then it could be corrupted by someone else

Sorry, I meant to say a link on the wiki to where it is now would be handy.

>> Did you install MSYS-DTK-1.0.1?

Yes, I downloaded the MSYS developers tool kit, msysDTK-1.0.1.exe and 
installed it.


>>  Are the tests for revision 1376? Nothing causes problems like 
running the wrong tests.


Yeah, the tests were run from the svn co directory. The tests were for 
the svn HEAD at the time, 1376, which I had just built and installed.I 
even made sure to destroy old pyc files.


>> The subprocess module works better but requires pywin32 be installed 
for Windows.


Cheers. I'm sorry if popen4 caused any problems for you.


This is really odd, I'm nuking my site-packages/pygame directory, 
building and installing from HEAD and then running the HEAD  tests, but 
I'm still have crashing issues.


What's the difference between mine and your's and marcus's setup?

Compiling issues come to mind but then I recall I had the same problem 
after downloading your 1376 msi. I nuked the pygame directory before 
installing that also.




I realized that the surflock_test.py error that was taking down 
run_tests.py (for me anyway) was just that I needed to have numpy 
installed. Then the suite finished but with these errors.


==
ERROR: see if the destination surface can be passed in to use.
--
Traceback (most recent call last):
 File "D:\Losty\PyGame\trunk\test\transform_test.py", line 114, in 
test_scale_d

estination
   s2 = pygame.transform.smoothscale(s, (64,64))
ValueError: Only 24-bit or 32-bit surfaces can be smoothly scaled

==
FAIL: test_average_surfaces (transform_test.TransformTest)
--
Traceback (most recent call last):
 File "D:\Losty\PyGame\trunk\test\transform_test.py", line 239, in 
test_average

_surfaces
   self.assertEqual(sr.get_at((0,0)), (10,15,70,255))
AssertionError: (8, 12, 66, 255) != (10, 15, 70, 255)

==
FAIL: test_threshold_surface (transform_test.TransformTest)
--
Traceback (most recent call last):
 File "D:\Losty\PyGame\trunk\test\transform_test.py", line 145, in 
test_thresho

ld_surface
   self.assertEqual(num_threshold_pixels, s1.get_height() * s1.get_width())
AssertionError: 0 != 1024

--
Ran 264 tests in 5.703s

FAILED (failures=2, errors=1)


Then running transform_test.py independently:

D:\Losty\PyGame\trunk\test>transform_test.py
.
--
Ran 5 tests in 0.016s

OK


_What the_?

Any ideas guys? What am I doing wrong?





Lenard Lindstrom wrote:

Finally I can get to this posting:

Nicholas Dudfield wrote:

Greetings all.

Computer Died
=


Sorry to hear that.

[snip]



Compiling Pygame


The instructions for building pygame on windows using MSYS involved 
downloading and compiling dependencies. It was not until afterwards 
that I found out that prebuilts were available. It would probably be 
helpful to link to them somewhere on the wiki.

Done.

It was not until afterwards that I found out that prebuilts were 
available. I will do that myself once my computer is operational 
again. In fact there is a note on the wiki, "*note* We should have a 
download with everything included.
It's available at http://www3.telus.net/len_l/pygame/ , but has never 
been copied to the pygame site. If it goes into the wiki then it could 
be corrupted by someone else. So it should be on the download page.



As well as patches for each one that we need. "

No patches needed.



Anyway, I went to the pains of downloading all the dependencies and 
compiling. The msys_build_deps.py script works very nicely, the only 
issue I had was that SMPEG wouldn't compile. I just got a copy of the 
config and dll from the page with the prebuilts.


This was the error message from the script:

$ msys_build_deps.py SMPEG

=== Starting build ===
aclocal: configure.in: 133: macro `AM_PATH_SDL' not found in library
aclocal: configure.in: 219: macro `AM_PATH_GTK' not found in library
'./autogen.sh' failed to run properly
Build aborted: The build for SMPEG failed with code 1

Did you install MSYS-DTK-1.0.1?



Failing Tests
=

I built revision 1376 and running run_tests.py here crashes before 
completion of all the tests. I traced it to surflock_test.py.
I renamed it temporarily so it wouldn't be picked up by run_tests.py 
and then the suite ran to completion, showing failures in 
transform_test.py. Bizarrely, I ran that test discretely and it passed.


Ar

Re: [pygame] Tests crashing Automatic Build page + Compiling PyGame on Windows

[Lenard Lindstrom]

Finally I can get to this posting:

Nicholas Dudfield wrote:

Greetings all.

Computer Died
=


Sorry to hear that.

[snip]



Compiling Pygame


The instructions for building pygame on windows using MSYS involved 
downloading and compiling dependencies. It was not until afterwards 
that I found out that prebuilts were available. It would probably be 
helpful to link to them somewhere on the wiki.

Done.

It was not until afterwards that I found out that prebuilts were 
available. I will do that myself once my computer is operational 
again. In fact there is a note on the wiki, "*note* We should have a 
download with everything included.
It's available at http://www3.telus.net/len_l/pygame/ , but has never 
been copied to the pygame site. If it goes into the wiki then it could 
be corrupted by someone else. So it should be on the download page.



As well as patches for each one that we need. "

No patches needed.



Anyway, I went to the pains of downloading all the dependencies and 
compiling. The msys_build_deps.py script works very nicely, the only 
issue I had was that SMPEG wouldn't compile. I just got a copy of the 
config and dll from the page with the prebuilts.


This was the error message from the script:

$ msys_build_deps.py SMPEG

=== Starting build ===
aclocal: configure.in: 133: macro `AM_PATH_SDL' not found in library
aclocal: configure.in: 219: macro `AM_PATH_GTK' not found in library
'./autogen.sh' failed to run properly
Build aborted: The build for SMPEG failed with code 1

Did you install MSYS-DTK-1.0.1?



Failing Tests
=

I built revision 1376 and running run_tests.py here crashes before 
completion of all the tests. I traced it to surflock_test.py.
I renamed it temporarily so it wouldn't be picked up by run_tests.py 
and then the suite ran to completion, showing failures in 
transform_test.py. Bizarrely, I ran that test discretely and it passed.


Are the tests for revision 1376? Nothing causes problems like running 
the wrong tests.


I think surflock_test.py crashed the automated builds for 
http://thorbrian.com/pygame/builds.php


I saw that builds for revision 1376 were recently posted to the list 
with a note saying it passed all unit tests. I downloaded it, removed 
my existing pygame install, deleting the whole pygame folder, and 
installed it. Same surflock_test.py crash, same transform_test.py 
failures and errors.


After a false start by setting SDL_VIDEODRIVER to an invalid value I can 
confirm that all tests pass for me as of revision 1382.


The surflock_test.py crash actually stalls the test suite and it 
reports nothing; no F, E or OK.



[snip test results]



We need to make the build page + test runner more resistant to tests 
that will possibly crash everything.


That last attempt to catch image__save_gl_surface_test.py crashes using 
popen4 caused problems. For me it would sometimes hang. When I fixed the 
save gl surface bug the automated build site failed to recognize a 
passing test for the Window builds. The subprocess module works better 
but requires pywin32 be installed for Windows.


--
Lenard Lindstrom
<[EMAIL PROTECTED]>

Re: [pygame] Tests crashing Automatic Build page + Compiling PyGame on Windows

[Lenard Lindstrom]

Marcus von Appen wrote:

On, Sat Jun 21, 2008, Nicholas Dudfield wrote:

[...]
 
  

Failing Tests
=

I built revision 1376 and running run_tests.py here crashes before 
completion of all the tests. I traced it to surflock_test.py.
I renamed it temporarily so it wouldn't be picked up by run_tests.py and 
then the suite ran to completion, showing failures in transform_test.py. 
Bizarrely, I ran that test discretely and it passed.


I think surflock_test.py crashed the automated builds for 
http://thorbrian.com/pygame/builds.php


I saw that builds for revision 1376 were recently posted to the list 
with a note saying it passed all unit tests. I downloaded it, removed my 
existing pygame install, deleting the whole pygame folder, and installed 
it. Same surflock_test.py crash, same transform_test.py failures and errors.


The surflock_test.py crash actually stalls the test suite and it reports 
nothing; no F, E or OK.



[...]

Anything fine on my end here with an XP installation. All tests pass. If
you are removing the surflock tests, does the issue still occur?

  
Everything passes for me now (SVN 1382). I had SDL_VIDEODRIVER set to an 
invalid driver name. image__save_gl_surface_test.py complained.


--
Lenard Lindstrom
<[EMAIL PROTECTED]>

Re: [pygame] Tests crashing Automatic Build page + Compiling PyGame on Windows

[Marcus von Appen]

On, Sat Jun 21, 2008, Nicholas Dudfield wrote:

[...]
 
> Failing Tests
> =
> 
> I built revision 1376 and running run_tests.py here crashes before 
> completion of all the tests. I traced it to surflock_test.py.
> I renamed it temporarily so it wouldn't be picked up by run_tests.py and 
> then the suite ran to completion, showing failures in transform_test.py. 
> Bizarrely, I ran that test discretely and it passed.
> 
> I think surflock_test.py crashed the automated builds for 
> http://thorbrian.com/pygame/builds.php
> 
> I saw that builds for revision 1376 were recently posted to the list 
> with a note saying it passed all unit tests. I downloaded it, removed my 
> existing pygame install, deleting the whole pygame folder, and installed 
> it. Same surflock_test.py crash, same transform_test.py failures and errors.
> 
> The surflock_test.py crash actually stalls the test suite and it reports 
> nothing; no F, E or OK.

[...]

Anything fine on my end here with an XP installation. All tests pass. If
you are removing the surflock tests, does the issue still occur?

Regards
Marcus


pgp2TPln9pWsP.pgp
Description: PGP signature

[pygame] Tests crashing Automatic Build page + Compiling PyGame on Windows

[Nicholas Dudfield]

Greetings all.

Computer Died
=

My computer recently decided it needed to go into early retirement and I 
have been forced to use my friends old Windows box when able. He has 
alot of assignments at the moment and I can only really use it while 
he's at school. My computer should be back in operation in a few days 
hopefully when a replacement cooling fan arrives.


As I am on Windows I need to get access to binaries of the pygame svn 
HEAD. This is normally no trouble as the automatic build page usually 
has them posted. Lately though, some surface lock tests are crashing the 
build script. The windows builds crashed a few revisions ago so I 
decided to compile from source.


Compiling Pygame


The instructions for building pygame on windows using MSYS involved 
downloading and compiling dependencies. It was not until afterwards that 
I found out that prebuilts were available. It would probably be helpful 
to link to them somewhere on the wiki. It was not until afterwards that 
I found out that prebuilts were available. I will do that myself once my 
computer is operational again. In fact there is a note on the wiki, 
"*note* We should have a download with everything included. As well as 
patches for each one that we need. "


Anyway, I went to the pains of downloading all the dependencies and 
compiling. The msys_build_deps.py script works very nicely, the only 
issue I had was that SMPEG wouldn't compile. I just got a copy of the 
config and dll from the page with the prebuilts.


This was the error message from the script:

$ msys_build_deps.py SMPEG

=== Starting build ===
aclocal: configure.in: 133: macro `AM_PATH_SDL' not found in library
aclocal: configure.in: 219: macro `AM_PATH_GTK' not found in library
'./autogen.sh' failed to run properly
Build aborted: The build for SMPEG failed with code 1

Failing Tests
=

I built revision 1376 and running run_tests.py here crashes before 
completion of all the tests. I traced it to surflock_test.py.
I renamed it temporarily so it wouldn't be picked up by run_tests.py and 
then the suite ran to completion, showing failures in transform_test.py. 
Bizarrely, I ran that test discretely and it passed.


I think surflock_test.py crashed the automated builds for 
http://thorbrian.com/pygame/builds.php


I saw that builds for revision 1376 were recently posted to the list 
with a note saying it passed all unit tests. I downloaded it, removed my 
existing pygame install, deleting the whole pygame folder, and installed 
it. Same surflock_test.py crash, same transform_test.py failures and errors.


The surflock_test.py crash actually stalls the test suite and it reports 
nothing; no F, E or OK.


D:\Nick\PyGame\trunk>run_tests.py
loading base_test
loading blit_test
loading color_test
loading display_test
loading font_test
loading image_test
loading image__save_gl_surface_test
loading key_test
loading mask_test
loading mixer_test
loading movie_test
loading pixelarray_test
loading rect_test
loading sndarray_test
loading sprite_test
loading surface_test
loading surfarray_test
loading surflock_test
loading transform_test



..

We need to make the build page + test runner more resistant to tests 
that will possibly crash everything.


Cheers,

Akalias.

ps. Sorry in anticipation of being late in replying to replies.