Thread: [PyOpenGL-Devel] Extension functions in Python3 on Win32
Brought to you by:
mcfletch
From: Rob R. <r.r...@sc...> - 2012-04-27 11:07:04
|
Hi, We noted that extension functions do not work properly in Py3 on Win32. The problem is that the function name is passed as a (unicode) str to Win32Platform.getExtensionProcedure (which is a static method referring to OpenGL.wglGetProcAddress), which is called from BasePlatform.constructFunction The solution is of course to encode the the name, the question is where to do this? I expect that all platforms that use getExtensionProcedure (those that have self.EXTENSIONS_USE_BASE_FUNCTIONS==False, i.e. Win32, GLX, OSMESA) have a function that expects bytes, not str. So I would propose to put pointer = self.getExtensionProcedure( as_8_bit(functionName) ) in BasePlatform.constructFunction. Should I go ahead and implement this and create a pull request, or should this be implemented somewhere else? Rob --------------------------------------------- Rob Reilink, M.Sc Science Applied phone: +31 6 187 26562 e-mail: r.r...@sc... --------------------------------------------- |
From: Mike C. F. <mcf...@vr...> - 2012-04-27 13:04:41
|
On 12-04-27 07:06 AM, Rob Reilink wrote: > Hi, > > We noted that extension functions do not work properly in Py3 on > Win32. The problem is that the function name is passed as a (unicode) > str to Win32Platform.getExtensionProcedure (which is a static method > referring to OpenGL.wglGetProcAddress), which is called from > BasePlatform.constructFunction > > The solution is of course to encode the the name, the question is > where to do this? > > I expect that all platforms that use getExtensionProcedure (those that > have self.EXTENSIONS_USE_BASE_FUNCTIONS==False, i.e. Win32, GLX, > OSMESA) have a function that expects bytes, not str. So I would > propose to put > pointer = self.getExtensionProcedure( as_8_bit(functionName) ) > in BasePlatform.constructFunction. > > Should I go ahead and implement this and create a pull request, or > should this be implemented somewhere else? Ah, apparently function.__name__ has become unicode too, did not realize that. Yeah, that looks like a reasonable place to put the change. Feel free to create a pull request. BTW, is anyone actively using a Python3 version with bzr head? This bug seems like it would make the whole thing a non-starter (if no function will load, it doesn't seem anyone would get anywhere useful). If we're close, I'd prefer to get the major Python3 compatibility changes into at least one beta release of 3.0.2 before we roll out a final. I've got a TODO sitting in my inbox for allowing unicode in GLchar*, but AFAIK that's our only pending 3.x enhancement. If we're a long way from compatibility I may as well push a 3.0.2 beta and plan for 3.0.3 to have Python3 compatibility. Have fun, Mike |
From: Rob R. <r.r...@sc...> - 2012-04-27 13:44:03
|
Hi Anthony, We (Science Applied) are using Py3 with bzr head. I am on Mac OS X, Almar Klein is on Win32. It seems that the result of this bug was that only functions that are provided by extensions (or something the like) were influenced. Almar is going to work on his visualization toolkit (visvis) to get that to work on Python3 (he just started and this bug was the first issue in PyOpenGL that he encountered). We do now have some of our test cases working, while others are not yet. The problem(s) may be either in visvis or in PyOpenGL, that is to be seen in the coming weeks (he's on holidays next week but he'll probably do some more testing/Py3 porting after next week) Anyway, for now, I'll create a fork and a pull request. Rob --------------------------------------------- Rob Reilink, M.Sc Science Applied phone: +31 6 187 26562 e-mail: r.r...@sc... --------------------------------------------- Op 27 apr 2012, om 15:04 heeft Mike C. Fletcher het volgende geschreven: > > BTW, is anyone actively using a Python3 version with bzr head? This bug > seems like it would make the whole thing a non-starter (if no function > will load, it doesn't seem anyone would get anywhere useful). If we're > close, I'd prefer to get the major Python3 compatibility changes into at > least one beta release of 3.0.2 before we roll out a final. I've got a > TODO sitting in my inbox for allowing unicode in GLchar*, but AFAIK > that's our only pending 3.x enhancement. If we're a long way from > compatibility I may as well push a 3.0.2 beta and plan for 3.0.3 to have > Python3 compatibility. > > Have fun, > Mike > |
From: Almar K. <a....@sc...> - 2012-05-10 21:09:31
|
Hi, Just wanted to say that I've got our visualization toolkit (visvis) running in Python 3, based on the current Bazaar head of pyopengl. I've got all our examples working on both Linux and Windows. The only thing that doesn't feel right yet is that I have to pass the shading code as a str and names for uniforms as bytes. But I understood from Rob that this is on your todo list. Thanks for your support so far. Regards, Almar On 27 April 2012 15:43, Rob Reilink <r.r...@sc...> wrote: > Hi Anthony, > > We (Science Applied) are using Py3 with bzr head. I am on Mac OS X, Almar > Klein is on Win32. It seems that the result of this bug was that only > functions that are provided by extensions (or something the like) were > influenced. > > Almar is going to work on his visualization toolkit (visvis) to get that > to work on Python3 (he just started and this bug was the first issue in > PyOpenGL that he encountered). We do now have some of our test cases > working, while others are not yet. The problem(s) may be either in visvis > or in PyOpenGL, that is to be seen in the coming weeks (he's on holidays > next week but he'll probably do some more testing/Py3 porting after next > week) > > Anyway, for now, I'll create a fork and a pull request. > > Rob > > > --------------------------------------------- > Rob Reilink, M.Sc > Science Applied > > phone: +31 6 187 26562 > e-mail: r.r...@sc... > --------------------------------------------- > > > > > Op 27 apr 2012, om 15:04 heeft Mike C. Fletcher het volgende geschreven: > > > BTW, is anyone actively using a Python3 version with bzr head? This bug > seems like it would make the whole thing a non-starter (if no function > will load, it doesn't seem anyone would get anywhere useful). If we're > close, I'd prefer to get the major Python3 compatibility changes into at > least one beta release of 3.0.2 before we roll out a final. I've got a > TODO sitting in my inbox for allowing unicode in GLchar*, but AFAIK > that's our only pending 3.x enhancement. If we're a long way from > compatibility I may as well push a 3.0.2 beta and plan for 3.0.3 to have > Python3 compatibility. > > Have fun, > Mike > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Devel mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-devel > > -- Almar Klein, PhD Science Applied phone: +31 6 19268652 e-mail: a....@sc... |
From: Almar K. <a....@sc...> - 2012-04-27 21:45:06
|
> We noted that extension functions do not work properly in Py3 on Win32. For the record, I encountered the same bug on Linux (Mint). Almar |