Hi René,
René Dudfield wrote:
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.
I chased down one memory access violation in pixelarray.c. A patch
should be commited shortly. The other patch simply removes a memory leak.
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.
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.
On Sat, Jun 28, 2008 at 3:38 PM, Brian Fisher <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
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.
--
Lenard Lindstrom
<[EMAIL PROTECTED]>
