Re: PyOpenGL-ctypes (3.0) on Mac OS X

On 13/10/2006, at 1:33 AM, Mike C. Fletcher wrote:

> Josh Marshall wrote:
>> Mike,
>>
>> I have commited updates to platform/__init__.py and darwin.py  
>> that  fix up extension handling on OS X. All the tests involving  
>> extensions  now seem to be working.
>>
> That's great!  Blake was just asking me how he could help with OS X  
> testing.
>> I had to modify __init__.py with:
>>  > if sys.platform == 'darwin':
>>  >     createExtensionFunction = createBaseFunction
>>
>> This is since OS X just includes all the extension functions  
>> straight  in the library, so there is no need for the  
>> createExtensionFunction  to be different.
>>
> That should be fine, but why not make the alias within the  
> darwin.py file?  I'm trying (strongly) to avoid platform-specific  
> code outside of the particular platform's module, and this really  
> seems like something that's an "on this platform getting an  
> extension function is the same as getting a base function" item,  
> rather than something that all platforms need to know about.

I didn't see how the alias could be done within the darwin.py file.  
The swap relies on createExtensionFunction and createBaseFunction  
being available, which are defined after darwin.py is imported.

I agree that platform specific functionality should remain in the  
particular module, so I am looking for a workaround.
May I suggest that we take all the definitions from __init__.py and  
put them in platform/base.py. The individual platform modules would  
start with "from base import *" and continue with all the platform  
specific code. Finally, the __init__.py would just import the  
particular platform module, no more, no less.
This would give us more leeway in making more severe platform- 
specific alterations. I can make the change if you are okay with it.

My other thought was to retrieve the original function pointer from  
the _FuncPtr returned by the call:
 > def getExtensionProcedure( name ):
 >     fnptr =  GL.__getattr__(name)
 >     return <get void* from fnptr>
but I couldn't figure out how to do this in ctypes. Do you know?

>> I think this should bring it up to parity with Linux and Win32.  
>> There  seem to be some issues with some of the OpenGLContext  
>> demos, but the  base functionality certainly works.
>>
> There are still some OpenGLContext demos that don't work on Linux  
> (AMD64), particularly the evaluators and nurbs seem to be messed up  
> in OpenGL-ctypes there for some reason, so if the majority of the  
> demos are working you may actually be *ahead* of the other two  
> platforms.
Not having spent much time using PyOpenGL2.0, I'm not sure what the  
results of the demos should look like, so it's a bit tricky telling  
whether they do work right. However, nurbsobject.py definitely works.  
Which demos test evaluators? Let me know and I'll test them. Can we  
possibly put up a table in the development docs showing test results  
per file, per platform?

I also have problems with any OpenGLContext tests that rely on the  
VRML part. They crash with Unbound-something-or-other all the time. I  
haven't looked into it much.

>> My next step is to start some testing with numpy arrays. Do you  
>> know  of which other areas need to be worked on?
>>
> Numpy arrays should be fairly well handled (they're the default in  
> most cases).  Once I figure out the nurbs and evaluator problems  
> we're probably good to go for a first packaged alpha release.  We  
> have a number of extensions that will likely need custom coding,  
> but the basic structures should be there.  Particularly ARB imaging  
> and the shader objects are things we'll want to have working  
> properly if possible.  Marco is doing some work on the shader  
> objects stuff, but it's still going to want some love.
I started on a few Pythonising changes to ARB/framebuffer_objects.py.  
As I said at the beginning, my primary interest is in GPGPU  
processing using Python. Numpy is wicked for quickly banging out  
algorithms, and I want to be able to then directly port those  
algorithms into shaders. So I have fair bit on interest in the  
imaging and shader extensions. The only problem is time, as I'm sure  
you'll concur!

> What we really need, though, is the testing and it's probably  
> better to just get the early release out and let people bang on it  
> with their code-bases.  Let's try to get our first packaged alpha  
> out this weekend.  I should have part of Sunday available to work  
> on it.

> Part of that early shakedown process is that I want to start  
> collecting user documentation for how to transition between  
> PyOpenGL and OpenGL-ctypes, there aren't a *lot* of differences,  
> but there are some, and we'll want to document those to make the  
> transition easier.  Things which are really annoying to users we  
> can look at providing backwards-compatibility mechanisms for.
As I said, I haven't used PyOpenGL much in the past, so I don't have  
an old code base to test.

>> Once the alpha is out, I presume it'll be released on the  
>> CheeseShop?  I want to announce on the Mac Python and OpenGL  
>> lists, in order to  get people banging on it, but as you say, it  
>> should be easy to  install first.
>>
> We will be doing register calls against the CheeseShop.  The goal  
> is eventually to have the whole system, including the dependencies  
> capable of being installed with a single line as:
>
>    easy_install  my_cool_opengl_using_program
>
> with OpenGL-ctypes, ctypes, Togl, numpy, etceteras all being pulled  
> in *as required* via setuptools dependency declarations.  But to  
> start off with we'll just register ourselves with the CheeseShop.   
> The .egg versions should be fairly trivial to install (assuming the  
> dependencies (including setuptools) are in place).  I haven't  
> investigated yet to see whether the Linux binary eggs are usable  
> across machines, but anyway, those will be for ancillary mechanisms  
> (such as Togl) anyway.  We'll likely want to hack the ez_setup  
> script a little (and maybe push those changes back upstream) so  
> that it's more reasonable about alternate installation directories  
> and the like.
You will need separate eggs for binary extensions, but the core egg  
will be multi-platform.

At the moment when building the egg, it's called OpenGL-ctypes. I  
presume this will be changed to OpenGL-3.0a or similar when the  
release is made.

> Okay, I have to get back to paying work.  Have fun,
> Mike

ditto. Have a good day.
Josh

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net