On Mon, May 01, 2006 at 01:27:43PM +0200, Jiba wrote: > > I think you should add some words about cleaning up the C and Pyrex > code, in particular about types and pointers ; whatever, you'll have > to do it for 64 bits support. It also involves memory management ; i > think using some tools like e.g. electric fence may help to locate 64 > bits related problems, as well as more general problems.
Sorry I didn't think of this earlier, but while I was working on libogg2 and libtheora last year I noticed how they did support for 16-bit and 64-bit processors: http://svn.xiph.org/branches/ogg2-arc/configure.in http://svn.xiph.org/branches/ogg2-arc/include/ogg/config_types.h.in The only remaining work after integrating something like this into the distutils system should be sorting out which types should actually be int and which need to actually be a static bit width. I'd imagine (thought don't take this as anything definitive!) that OpenGL's use of float should be platform-dependent on how wide that float needs to be. Most things that use int actually want an int on the system. So all in all, I think less would need to be changed than more. Anyways, this is about as elegant a solution as any.. just rename ogg_ to soya_ for the types so there's no collision anywhere (or prehaps Python even offers these as types? There may also be some work needed to record which conversion function is needed to put it into a Python type if Pyrex doesn't do that for you. The Python/C API seems to have PyInt_FromInt and PyInt_FromLong, while the PyFloat_FromDouble seems to be the only float conversion (there's no PyFloat_FromFloat). If anything has a static bit-size and later gets converted to a Python type, you'll have to take some careful work with Pyrex to make sure it can get exported properly. Course, Pyrex could always use some work along these lines :-) _______________________________________________ Soya-user mailing list [email protected] https://mail.gna.org/listinfo/soya-user
