On 13-04-04 11:55 AM, Chris Barker - NOAA Federal wrote:
On Wed, Apr 3, 2013 at 10:24 AM, Cyrille Rossant
<cyrille.rossant@gmail.com> wrote:
well, that is a bigger-than-32bit address -- I suppose it's possible
that this is a 32/64 bit issue.

Can you test it with 32 bit python? Even if you don't want to
ultimatley go that route, it may give you a hint.

Also, from teh ctypes docs:

c_uint	is a unsigned int

you may have some issues there, an "int" is a really poorly defined
type, and depending on the compiler, it may be 32 bits on 32bit
systems, and 32 or 64 bit on 64 bit systems (and the MS compilers and
gnu do it differently), so there couldn be some mis-match there.

It's beyond me that C has survived this long with such soft defining
of type sizes! Here's hoping that people start using the C99 defined
size integer types sooner than later...

(though from the looks of it, ctypes doesn't support those either...)
Actually ctypes *does* now support sized types:

    ctypes.c_int8 ctypes.c_int16 ctypes.c_int32 ctypes.c_int64

(this is on python 2.7.3 Linux 64-bit).  I actually am using them while working on the EGL wrapper, and will likely switch to using them on the GL level too (since e.g. GLint is explicitly 32-bit, *not* platform specific).

is also pretty useful, and I will likely use that as appropriate.

As for the original error, it *could* be that there's a problem with 64-bit windows there, but I'm a bit skeptical, as 64-bit Linux doesn't show any problems, and the test_core.py script actually generates a framebuffer during testing if glGenFrameBuffers is available.  That's my very first smoke-test for the build working on any platform.

Something to verify to debug the issue:

if we're looking at different values, then we likely have the wrapper wrong (i.e. somehow it is changing the value passed in), if they are the same, then there's something preventing the writing to that address... which I don't have much to contribute...