What I should probably concentrate on for Open Source (Maximise the value for the world...)

For the non-business Open Source stuff I'm thinking I need to throw all of my spare time at the OpenGL-ctypes stuff. The SDL-ctypes stuff seems to be moving along at quite a clip, and it would be really nice if both of these media-heavy packages could convert to ctypes just after the 2.5 final release.

There's still quite a bit of work to do on the Win32 side (probably the OSX side too). I'm seeing problems with the Numeric/numpy support under Linux (same old, same old, the libraries seem to interfere with each other when installed serially, and the include headers for numpy don't seem to be accessible by default).

Maybe I need to go nuts and create ctypes versions of the extensions that have tests that can tell the system whether we're getting the proper offset into the arrays... hmm, that would be pretty darn cool... might even create something that walks through the structure byte-by-byte doing the tests until it finds them, recording the result for later runs.

[Update: turns out that numpy arrays now have the oft-mentioned __array_data__ member. With that the entire numpy C extension can go away. Doesn't help for the "Numeric" extension, but much cleaner for the numpy code. Have checked that into CVS. Now, on to the rest of the launch of the VoIP project...]


  1. Mark Heslep

    Mark Heslep on 06/13/2006 11:36 a.m. #

    I'm also very interested in seeing how pygame-sdl-ctypes and pyopengl ctypes progress. One difference AFAICT is that Holkner (Pygame SDL Google SOC guy) is completely hand coding his wrappers as opposed to making use, at least in part, of the ctypes codegenerator. No doubt the manual method provides a more elegant python interface than a blindly automatic method might, but I believe it inevitably creates a maintenance problem, at least it would with a preexisting library like OpenGL. PyGame is about more than just SDL and has its own momentum tied to Python so it might be okay with a hand-coded wrap . But with existed-prior-to-the-wrapper C/C++ projects, my observation has been that often the developer / maintainer of the scripting language interface moves on before it becomes the primary interface and, without a fairly automatic and transparent method of rebuilding the wrapper as the underlying library changes, the wrapper becomes stale or the community just drops it, a huge waste.<br />
    <br />

  2. Richard Jones

    Richard Jones on 06/13/2006 6:53 p.m. #

    @Mike: OpenGL please please! I'm more interested in being able to use modern OpenGL features than the ctypes stuff specifically.<br />
    <br />
    @Mark: Alex used a code generator right at the start.<br />

  3. Mark Heslep

    Mark Heslep on 06/14/2006 10:08 a.m. #

    Richard wrote: "@Mark: Alex used a code generator right at the start."<br />
    <br />
    No thats not correct, he went manual: (SDL-ctypes 3 post)<br />

  4. Richard Jones

    Richard Jones on 06/14/2006 5:04 p.m. #

    OK, I'll clarify. He ran a code generator at the start, and found it wanting.

  5. Richard Jones

    Richard Jones on 06/14/2006 10:02 p.m. #

    @Mike: since OpenGL-ctypes is a re-write, perhaps you don't need to support all the different flavours of numeric extensions? Perhaps just numpy, and the built-in array type if it lands in py2.6?

  6. Mike Fletcher

    Mike Fletcher on 06/15/2006 1:06 a.m. #

    Could be that I don't need to support all of the types... but I *feel* like I should support at least Numeric (for the legacy code (and you might be surprised how much legacy PyOpenGL code there is)) and Numpy (for the forward-looking code). Numarray support is a fairly minor tweak once those two are there.

  7. hugo

    hugo on 06/15/2006 1:11 p.m. #

    how do ctypes and pyrex compare? what are the advantages/disadvantages of them? just curious...<br />
    <br />
    i am looking forward to the new pyopengl! i also hope that ctypes means that it will be easier to keep it up to date regarding shader extensions and so on. :)

  8. Bill Baxter

    Bill Baxter on 07/05/2006 4:37 a.m. #

    Is there anything you could use help with as you push towards an OpenGL-ctypes release?<br />
    <br />
    I just checked out the current source from SourceForge CVS, though I'm not sure what to do with it yet. I'm on Windows/MSVC++.

  9. Mike Fletcher

    Mike Fletcher on 07/06/2006 10:42 a.m. #

    Biggest need right now is porting work for Win32 and Apple. Josh is doing some work on Apple already (and he's offerred to produce an overview document for the project). Win32 is partially working, but there are large swaths of functionality that just don't work yet. IIRC the entire GLU and GLUT interface set is still non-functional.<br />
    <br />
    Other than that, testing and bug reports (preferably with test cases and/or patches). On Linux we should be getting close to PyOpenGL-level functionality, so most PyOpenGL-using code should be working now (there will be *some* code that breaks, but that's the point). If it's not working with OpenGL-ctypes but is with PyOpenGL, it's likely a bug that needs to be fixed.

Comments are closed.


Pingbacks are closed.