Hi René, René Dudfield wrote:
I chased down one memory access violation in pixelarray.c. A patch should be commited shortly. The other patch simply removes a memory leak.ah, nice one. I think Lenard made some fixes not long ago to the pixel array stuff, maybe that has something to do with it.
After the change to draw_test.py (SVN 1412) and my memory leak patch (SVN 1409) everything passes for me, though the memory access hasn't been dealt with yet.I tied uninstalling Numeric and running the tests, and didn't have any crashes -- on linux. So I'm not sure what it is. Maybe the pygame directory needs deleting because there's a conflict perhaps? Nicholas tried compiling and testing on windows with mingw gcc and it seems to work for him too.
As for the fmodf problem it is a mystery. For MinGW fmodf is a statically linked function defined in an MinGW specific library. For Visual C++ Toolkit 2003 fmodf is just an inline function, defined in math.h, that calls fmod. The only way this should fail is if Brian's build machine has an itanium processor or something, in which case fmodf would be declared as an external function.On Sat, Jun 28, 2008 at 3:38 PM, Brian Fisher <brian@xxxxxxxxxxxxxxxxxxx> wrote:fmod works fine with msvc. I don't know why fmodf doesn't. Know it's back to crashing in some unit test in _numericsurfarray.pyd, possibly because it doesn't run the tests with numeric installed... On Fri, Jun 27, 2008 at 6:35 PM, René Dudfield <renesd@xxxxxxxxx> wrote:hey, it looks like fmodf doesn't compile with msvc. I tried using fmod instead, so hopefully that works. I thought fmodf was quite portable, but seems maybe it's not. Maybe it needs the math library linked in or something? http://thorbrian.com/pygame/builds.php
-- Lenard Lindstrom <len-l@xxxxxxxxx>