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

Josh Marshall wrote:
> On 13/10/2006, at 1:33 AM, Mike C. Fletcher wrote:
>
>   
>> Josh Marshall wrote:
>>     
...
> 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.
>   
Basically could be done with a flag that's overridden on any platform 
that requires the functionality.  I've checked in something that does 
that, but see below.
> 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.
>   
This was my eventual plan.  The biggest annoyance is that the common 
code is referencing stuff in the platform-specific module (because it's 
using those entry points to implement the common API).  That can be 
resolved by using object encapsulation/inheritance, lazy lookups or 
whatever.  If you'd like to refactor it, be my guest.  I'm thinking an 
inheritance scheme would be best, though it means manually unpacking 
everything again to get the same "bald function" interface as in the 
current code.
> 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?
>   
Haven't had time to look into this yet, it doesn't look like the right 
approach anyway.
>> 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?
>   
dek*surf are the evaluator demos.  There are a number of OpenGLContext 
tests that really are "tests", that is, they aren't set up to produce 
any output at all, they just do something to see if it works.  I should 
probably move the "demo" stuff (the stuff that produces recognisable 
output) to a new directory so that running anything there should produce 
a described effect (i.e. it should print what's expected and you should 
see that on screen).

It's really beginning to look like the nurbsobject problems are solely 
an AMD64 issue.  It's possible we've uncovered another AMD64 bug in 
ctypes argument packing.  I'll have to rebuild and re-test with the CVS 
ctypes (I'm on 1.0.0) to be sure it's not an already-fixed error.  That 
said, it's worked in the past on this machine, so if it's a ctypes error 
it's probably a simple regression.
> 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.
>   
If you can just send me the error message I can likely fix it readily.
> 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!
>   
Marco has also been doing work on the shader extensions.  That's all 
great stuff, though I have to admit that I haven't had enough time to do 
more than the most basic shader work.  I'd love to just take a week or 
two and play with those to make OpenGL-ctypes support first-class all 
the way... but that won't pay the bills :) .
>> 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.
>   
No problem there.  I was referring to people who have used PyOpenGL in 
the past, there's probably hundreds of projects out there that have 
PyOpenGL code whose authors can't be bothered with CVS checkouts, but 
who might be willing to run their programs with a packaged alpha release 
to report bugs.
>> 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.
>   
Issues arise when we have accelerator modules.  I don't want to pollute 
the top-level namespace too much with packages that just add X (e.g. 
C-level wrapper module) to OpenGL-ctypes.  Maybe should reserve an 
OpenGL-accelerator top-level empty package into which to place all of 
our various accelerator extensions/packages.
> 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.
>   
Hmm, I'd actually intended to use "OpenGL-ctypes", but now that you 
bring it up and I actually think about it, yes, we probably should just 
rename it OpenGL.  PyOpenGL has already "reserved" the name 'OpenGL' as 
a top-level package for us, and we may as well commit up front to this 
being the official 3.0.0 release (given that I've pretty much stopped 
work on the SWIG code-base).
> ditto. Have a good day.
>   
Thanks, enjoy yourself,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com


-------------------------------------------------------------------------
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