pyopengl-devel — Discussion of PyOpenGL development.

Re: [PyOpenGL-Devel] Python 3- strings or bytes interface

[Greg E. <gre...@ca...>]

Rob Reilink wrote:
> So we could add a 
> glGetUnicode or glGetStr or glGetPyStr (suggestions for appropriate name 
> welcome) that always returns a 'str' -- 8 bit on Py2 and unicode on Py3.

And have it take an optional encoding, defaulting to ascii.
Then people won't be stuck if they happen to encounter a
non-ascii glGetString result for some reason.

-- 
Greg

Re: [PyOpenGL-Devel] Python 3- strings or bytes interface

[Mike C. F. <mcf...@vr...>]

On 12-04-05 09:32 AM, Rob Reilink wrote:
> Hi,
>
> The suggestion of checking for unicode objects makes sense to me -- 
> although I would suggest to use ascii encoding, unless someone could 
> point me to a document that explicitly states what encoding is used 
> for the GLubyte* arguments. Since ascii encoding raises an error upon 
> encountering bytes > 127, I think that is the safest bet unless we are 
> sure what encoding is actually used.
ASCII is fine for every use of GLchar* that I *know* about.  The problem 
is finding any corner cases (now or in the future) where some obscure 
extension uses GLchar* to mean an 8-bit string.  That said, I'd be fine, 
for now, making GLchar point use ASCII encoding on Unicode ingest (it 
just blows up now, after all), and requiring users to explicitly encode 
if they want to use an 8-bit-clean GLchar * API.
> As far as I know (but my OpenGL knowledge is limited) glGetString is 
> the only function that actually returns a string. So we could add a 
> glGetUnicode or glGetStr or glGetPyStr (suggestions for appropriate 
> name welcome) that always returns a 'str' -- 8 bit on Py2 and unicode 
> on Py3. And leave glGetString return a bytes object for the reasons 
> mentioned. This new function could then be used in the extensions 
> module; I think this way many of the as_8_bit calls can be avoided 
> because then the extensions module would just use the Python native 
> string type.
I'm pretty sure there's more than that, e.g. glGetActiveUniform.  My 
current preference is that we will *always* return 8-bit from API calls 
that are documented to return 8-bit values, while allowing ingest of 
unicode values IFF they are ASCII compatible (comments on my blog 
suggest this is the path Python 3.3 is taking anyway).  On output, I 
really don't want to mess up the API with lots of extra entry points 
which are non-standard and need to be documented, maintained, etc.

> I'd be happy to go and implement this solution, if you can point me to 
> the appropriate place to put the code. It will probably be a bit of 
> puzzling how to write it such that it works properly when transformed 
> by the 2to3 tool :-)
I'm fine with implementing it.  The generator knows the type of all 
variables, so it can generate wrapper-generating code to do the 
conversions (i.e. apply a decorator that wraps the raw operations on 
generation).  The wrappers will need to be written such that they are 
fairly fast, but that shouldn't be a huge problem.  The as_8_bit call 
survives 2to3 AFAIK.

Enjoy,
Mike

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

Re: [PyOpenGL-Devel] Python 3- strings or bytes interface

[Rob R. <r.r...@sc...>]

Hi,

The suggestion of checking for unicode objects makes sense to me -- although I would suggest to use ascii encoding, unless someone could point me to a document that explicitly states what encoding is used for the GLubyte* arguments. Since ascii encoding raises an error upon encountering bytes > 127, I think that is the safest bet unless we are sure what encoding is actually used.

As far as I know (but my OpenGL knowledge is limited) glGetString is the only function that actually returns a string. So we could add a glGetUnicode or glGetStr or glGetPyStr (suggestions for appropriate name welcome) that always returns a 'str' -- 8 bit on Py2 and unicode on Py3. And leave glGetString return a bytes object for the reasons mentioned. This new function could then be used in the extensions module; I think this way many of the as_8_bit calls can be avoided because then the extensions module would just use the Python native string type.

I'd be happy to go and implement this solution, if you can point me to the appropriate place to put the code. It will probably be a bit of puzzling how to write it such that it works properly when transformed by the 2to3 tool :-)

Rob


---------------------------------------------
Rob Reilink, M.Sc
Science Applied

phone: +31 6 187 26562
e-mail: r.r...@sc...
---------------------------------------------




Op 4 apr 2012, om 17:44 heeft Mike C. Fletcher het volgende geschreven:

> On 12-04-04 07:23 AM, Rob Reilink wrote:
>> Hi,
>> 
>> I've noticed that under Python3, PyOpenGL inconsistently expects 'str' 
>> and 'bytes' objects as function arguments. For some functions, I'd 
>> expect to use 'str' while in the current implementation 'bytes' is used.
>> 
>> E.g. in glGetUniformlocation, the name of the uniform is to be 
>> specified as a 'bytes' object, while I would expect to use 'str' since 
>> it is a name. Also, shaders.compileShader takes a 'str' for the shader 
>> code
>> 
>> Similarly, extensions.hasGLExtension() expects a 'str' object for the 
>> extension name, but extension.AVAILABLE_GL_EXTENSIONS is a list of 
>> 'bytes'.
>> 
>> Of course, for arguments dealing with binary data (e.g. glTexImage2D), 
>> a 'bytes' object is to be used.
>> 
>> Apart from the actual implementation, has there been any thought on 
>> how to expose things like uniform names to the user?
> My first reaction would be to do this:
> 
>     if isinstance( arg, unicode):
>         arg = arg.encode( 'latin-1' )
> 
> in the wrapper (the as_8_bit() hack has been added to the extensions 
> module, for instance), that is, for each argument which is current str, 
> make the argument capable of accepting a unicode argument... as for 
> producing them... I'm hesitant to convert the 8-bit values (which is 
> internally what OpenGL is specifying; GLchar * is an 8-bit value) to 
> unicode arbitrarily, as now code that uses formal, correct, byte-strings 
> is going to crash when it tries to interact with the generated unicode 
> values.
> 
> Everything in OpenGL is binary data. Everything has an expressly defined 
> binary representation, and that includes byte-strings.  Anything I do 
> here to paper over the difference is, I expect, going to come back to 
> byte us in the future.  Someone is going to do a glGetActiveUniform() in 
> my_unicode_shader and have it blow up on a unicode/bytes disagreement if 
> I convert on return, or is going to do glGetActiveUniform() in 
> my_bytes_shader if I don't, but I expect that the number of problems 
> with glGetUniform( 'myuniform' ) will be substantial.
> 
> Basically I don't have a good solution.  Either we create an API 
> inconsistency between Python 2 and Python 3 (returning "str" in both, 
> though they are different types), or we make Python 3 users explicitly 
> deal with the return-type of the GLchar* calls and/or use byte-strings 
> everywhere.
> 
> Enjoy,
> Mike
> 
> -- 
> ________________________________________________
>   Mike C. Fletcher
>   Designer, VR Plumber, Coder
>   http://www.vrplumber.com
>   http://blog.vrplumber.com
> 
> 
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second 
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Devel mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-devel

Re: [PyOpenGL-Devel] Python 3- strings or bytes interface

[Mike C. F. <mcf...@vr...>]

On 12-04-04 07:23 AM, Rob Reilink wrote:
> Hi,
>
> I've noticed that under Python3, PyOpenGL inconsistently expects 'str' 
> and 'bytes' objects as function arguments. For some functions, I'd 
> expect to use 'str' while in the current implementation 'bytes' is used.
>
> E.g. in glGetUniformlocation, the name of the uniform is to be 
> specified as a 'bytes' object, while I would expect to use 'str' since 
> it is a name. Also, shaders.compileShader takes a 'str' for the shader 
> code
>
> Similarly, extensions.hasGLExtension() expects a 'str' object for the 
> extension name, but extension.AVAILABLE_GL_EXTENSIONS is a list of 
> 'bytes'.
>
> Of course, for arguments dealing with binary data (e.g. glTexImage2D), 
> a 'bytes' object is to be used.
>
> Apart from the actual implementation, has there been any thought on 
> how to expose things like uniform names to the user?
My first reaction would be to do this:

     if isinstance( arg, unicode):
         arg = arg.encode( 'latin-1' )

in the wrapper (the as_8_bit() hack has been added to the extensions 
module, for instance), that is, for each argument which is current str, 
make the argument capable of accepting a unicode argument... as for 
producing them... I'm hesitant to convert the 8-bit values (which is 
internally what OpenGL is specifying; GLchar * is an 8-bit value) to 
unicode arbitrarily, as now code that uses formal, correct, byte-strings 
is going to crash when it tries to interact with the generated unicode 
values.

Everything in OpenGL is binary data. Everything has an expressly defined 
binary representation, and that includes byte-strings.  Anything I do 
here to paper over the difference is, I expect, going to come back to 
byte us in the future.  Someone is going to do a glGetActiveUniform() in 
my_unicode_shader and have it blow up on a unicode/bytes disagreement if 
I convert on return, or is going to do glGetActiveUniform() in 
my_bytes_shader if I don't, but I expect that the number of problems 
with glGetUniform( 'myuniform' ) will be substantial.

Basically I don't have a good solution.  Either we create an API 
inconsistency between Python 2 and Python 3 (returning "str" in both, 
though they are different types), or we make Python 3 users explicitly 
deal with the return-type of the GLchar* calls and/or use byte-strings 
everywhere.

Enjoy,
Mike

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

[PyOpenGL-Devel] Python 3- strings or bytes interface

[Rob R. <r.r...@sc...>]

Hi,

I've noticed that under Python3, PyOpenGL inconsistently expects 'str' and 'bytes' objects as function arguments. For some functions, I'd expect to use 'str' while in the current implementation 'bytes' is used.

E.g. in glGetUniformlocation, the name of the uniform is to be specified as a 'bytes' object, while I would expect to use 'str' since it is a name. Also, shaders.compileShader takes a 'str' for the shader code

Similarly, extensions.hasGLExtension() expects a 'str' object for the extension name, but extension.AVAILABLE_GL_EXTENSIONS is a list of 'bytes'.

Of course, for arguments dealing with binary data (e.g. glTexImage2D), a 'bytes' object is to be used.

Apart from the actual implementation, has there been any thought on how to expose things like uniform names to the user? 

Rob

ps. as a side note: I think for most cases the actual encoding to be used is not really an issue since shader code, uniform names etc are restricted to asci anyway.

---------------------------------------------
Rob Reilink, M.Sc
Science Applied

phone: +31 6 187 26562
e-mail: r.r...@sc...
---------------------------------------------

Re: [PyOpenGL-Devel] Interest in PyOpenGL-related projects for Google's Summer of Code?

[René D. <re...@gm...>]

Hello,

if you want to do a gsoc project please submit a proposal as soon as
possible.  Apparently the website gets busy in the last 24 hours, and some
people miss out.  If the proposal is not 100% complete, please submit it
anyway, as you may be able to make revisions later.  Deadline is April 6th.

If you're a university/college/tertiary(what ever it is called where you
live) student, then you can get $5000 from Google, and course credit to do
a pyopengl project over the summer with mentors helping you along the way.

See this page for various links with more information:
https://bitbucket.org/pygame/pygame/wiki/gsoc2012ideas

Here is the google faq on the Google summer of code:
http://www.google-melange.com/document/show/gsoc_program/google/gsoc2012/faqs


Please feel free to ask any questions.


cheers,



On Fri, Mar 30, 2012 at 5:27 PM, Mike C. Fletcher <mcf...@vr...>wrote:

> René Dudfield (of Pygame) has made an application to have PyGame (and
> PyOpenGL, and other "gamey/multimedia-ish" libraries) become part of the
> Python Software Foundation's GSoC project this year.  The deadline for
> student application is next Friday (April 6th).  If you are a student
> who qualifies for GSoC, and would like to work on a PyOpenGL or PyGame
> related project, you should look at getting your application in fairly
> soon.
>
> Possible project ideas are being collected on the PyGame wiki page here:
>
> https://bitbucket.org/pygame/pygame/wiki/gsoc2012ideas
>
> Non-students, if you're interested in mentoring, that's extremely
> helpful too,
> Mike
>
> --
> ________________________________________________
>   Mike C. Fletcher
>   Designer, VR Plumber, Coder
>   http://www.vrplumber.com
>   http://blog.vrplumber.com
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Devel mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-devel
>

[PyOpenGL-Devel] Interest in PyOpenGL-related projects for Google's Summer of Code?

[Mike C. F. <mcf...@vr...>]

René Dudfield (of Pygame) has made an application to have PyGame (and 
PyOpenGL, and other "gamey/multimedia-ish" libraries) become part of the 
Python Software Foundation's GSoC project this year.  The deadline for 
student application is next Friday (April 6th).  If you are a student 
who qualifies for GSoC, and would like to work on a PyOpenGL or PyGame 
related project, you should look at getting your application in fairly soon.

Possible project ideas are being collected on the PyGame wiki page here:

https://bitbucket.org/pygame/pygame/wiki/gsoc2012ideas

Non-students, if you're interested in mentoring, that's extremely 
helpful too,
Mike

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

[PyOpenGL-Devel] [ pyopengl-Bugs-3512397 ] FWAnFNQvdmX

[SourceForge.net <no...@so...>]

Bugs item #3512397, was opened at 2012-03-28 07:08
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3512397&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: build
Group: v1.5.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: FWAnFNQvdmX

Initial Comment:
Thanks for sharing, this is a fantastic article. Keep writing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3512397&group_id=5988

Re: [PyOpenGL-Devel] Porting to python 3

[Mike C. F. <mcf...@vr...>]

On 12-03-28 06:40 AM, Rob Reilink wrote:
> Hi,
>
> I'd like to help porting pyopengl to Python 3.
Great.
> I noticed there is already a Python 3 branch on launchpad made mainly 
> using the 2to3 tool. However, I can imagine that this branch cannot be 
> merged with the main branch since that would make pyopengl 
> incompatible with Python 2. My suggested approach would be to use the 
> 'use_2to3' flag of setuptools to make the source tree compatible with 
> both python 2 and 3 as discussed here: 
> http://packages.python.org/distribute/python3.html . The basic idea is 
> that the 2to3 conversion (possibly with custom fixers) is done at 
> build/install time.
IIRC we've already merged all of the Python 3 patches that have been 
generated, and we already have 2to3 included in the setup.
> As I understood from a colleague of mine (Almar Klein) who had 
> discussed porting to Py3 with Mike Fletcher a while ago, one of the 
> issues was that the 'testsuite' that was used for testing PyOpenGl is 
> also written in Py2 and thus needs porting before rigorous testing 
> could be performed. With the proposed approach, the source code can 
> still be tested under Py2 with the existing test suite. Until a proper 
> Py3 test suite comes available, Py3 support could be denominated as 
> 'untested'. The toolkit that we will be using PyOpenGl for (visvis, 
> http://code.google.com/p/visvis/) will be ported by us and will as 
> such be a basic test for PyOpenGL under Py3
That's basically where we are already.  That is, we have a test suite 
(OpenGLContext), which isn't likely to be ported to Python3 any time 
soon, as it depends on lots of other modules, each of which I need to 
port to Python3.  Since they tend to be very heavily optimized and 
"meta", they tend to take a lot of effort to port.  PyOpenGL should, in 
theory, work on Python 3, and it seems to from the testing that has been 
done so far.  OpenGLContext is *not* working on Python3, not so much 
because it couldn't be done, but because I haven't prioritized it, and 
I'm not likely to do so until I actually consider moving any code to 
Python3 myself (I just installed Python3 on this machine to see if 
PyOpenGL would install, it seems to, though with a warning from pip).
> I'd like to have suggestions on how to proceed in such a way that my 
> efforts can eventually be taken into the main branch, such that the 
> time spent by us (Sience Applied) will eventually be of benefit to all 
> PyOpenGL users.
I'm quite willing to accept Python 3 patches that don't introduce too 
much code-smell (there's going to be some code-smell, but I don't want 
the whole code-base rewritten with "run on both Python 2 and Python 3 
unmodified hacks").  As noted, we *should* have all of the current 
patches integrated in bzr and the latest alphas.

Basically, propose clean patches that don't negatively impact Python 2 
support and I'm very likely to accept them,
Mike

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

[PyOpenGL-Devel] Porting to python 3

[Rob R. <r.r...@sc...>]

Hi,

I'd like to help porting pyopengl to Python 3. 

I noticed there is already a Python 3 branch on launchpad made mainly using the 2to3 tool. However, I can imagine that this branch cannot be merged with the main branch since that would make pyopengl incompatible with Python 2. My suggested approach would be to use the 'use_2to3' flag of setuptools to make the source tree compatible with both python 2 and 3 as discussed here: http://packages.python.org/distribute/python3.html . The basic idea is that the 2to3 conversion (possibly with custom fixers) is done at build/install time.

As I understood from a colleague of mine (Almar Klein) who had discussed porting to Py3 with Mike Fletcher a while ago, one of the issues was that the 'testsuite' that was used for testing PyOpenGl is also written in Py2 and thus needs porting before rigorous testing could be performed. With the proposed approach, the source code can still be tested under Py2 with the existing test suite. Until a proper Py3 test suite comes available, Py3 support could be denominated as 'untested'. The toolkit that we will be using PyOpenGl for (visvis, http://code.google.com/p/visvis/) will be ported by us and will as such be a basic test for PyOpenGL under Py3

I'd like to have suggestions on how to proceed in such a way that my efforts can eventually be taken into the main branch, such that the time spent by us (Sience Applied) will eventually be of benefit to all PyOpenGL users.

Regards,

Rob

---------------------------------------------
Rob Reilink, M.Sc
Science Applied
www.science-applied.nl
---------------------------------------------

[PyOpenGL-Devel] [ pyopengl-Bugs-3504388 ] missing constant in 3.0.2a5

[SourceForge.net <no...@so...>]

Bugs item #3504388, was opened at 2012-03-14 06:46
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3504388&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: missing constant in 3.0.2a5

Initial Comment:
Missing constant in 3.0.2a5:

Python 2.7 (r27:82500, Sep 16 2010, 18:02:00) 
[GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import OpenGL
>>> OpenGL.__version__
'3.0.2a5'
>>> import OpenGL.GL
>>> OpenGL.GL.GL_VERTEX_SHADER_ARB
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'GL_VERTEX_SHADER_ARB'

Compare 3.0.2a2:
Python 2.7 (r27:82500, Sep 16 2010, 18:02:00) 
[GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import OpenGL
>>> OpenGL.__version__
'3.0.2a2'
>>> import OpenGL.GL
>>> OpenGL.GL.GL_VERTEX_SHADER_ARB
GL_VERTEX_SHADER_ARB

Other notes:
-- seen on Fedora 14 and 16
-- looking at source, PyOpenGL-3.0.1-py2.7.egg/OpenGL/raw/GL/constants.py appears to be the home of this constant, and it's missing in 3.0.2a5
-- presumably all constants in that file are affected; the constant above is just the first one hit in my code

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3504388&group_id=5988

Re: [PyOpenGL-Devel] Using PyOpenGL in threaded programs

[Ian M. <geo...@gm...>]

2012/3/12 Miguel Pérez <wis...@gm...>

> Any news on bug 2965754? (
> http://sourceforge.net/tracker/?func=detail&aid=2965754&group_id=5988&atid=105988)
>
> I'm writing an image viewer that was supposed to preload images in the
> background. However, it'll crash if I attempt to load images in one thread
> and show them in another thread once it has been successfully loaded. I
> verified I can use any number of threads, and PyOpenGL can be used from any
> thread, but it doesn't seem to be able to be called from different threads.
> In other words, the thread that loads textures must be the thread that uses
> them, and the thread that unloads them. There's an example of what I'm
> saying attached to said bug. Am I doing something wrong?
>
> Thanks
>
FYI, multithreading probably won't improve performance in Python due to the
GIL . . .

[PyOpenGL-Devel] Using PyOpenGL in threaded programs

[Miguel P. <wis...@gm...>]

Any news on bug 2965754? (
http://sourceforge.net/tracker/?func=detail&aid=2965754&group_id=5988&atid=105988)

I'm writing an image viewer that was supposed to preload images in the
background. However, it'll crash if I attempt to load images in one thread
and show them in another thread once it has been successfully loaded. I
verified I can use any number of threads, and PyOpenGL can be used from any
thread, but it doesn't seem to be able to be called from different threads.
In other words, the thread that loads textures must be the thread that uses
them, and the thread that unloads them. There's an example of what I'm
saying attached to said bug. Am I doing something wrong?

Thanks

[PyOpenGL-Devel] [ pyopengl-Bugs-3488693 ] GL_1_1.GL_TEXTURE_DEPTH and COMPONENT_COUNTS

[SourceForge.net <no...@so...>]

Bugs item #3488693, was opened at 2012-02-17 14:33
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3488693&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: GL_1_1.GL_TEXTURE_DEPTH and COMPONENT_COUNTS

Initial Comment:
When using glGetTexImage to read a 3D texture, this fails because GL_1_1.GL_TEXTURE_DEPTH is missing in OpenGL/GL/images.py, glGetTexImage.

In the same file, the call to images.COMPONENT_COUNTS.update should include
                     GL_RED_INTEGER,
                    GL_GREEN_INTEGER,
                    GL_BLUE_INTEGER,
                    GL_RG_INTEGER,
                    GL_RGB_INTEGER,
                    GL_RGBA_INTEGER,
                    GL_BGR_INTEGER,
                    GL_BGRA_INTEGER.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3488693&group_id=5988

Re: [PyOpenGL-Devel] problem installing PyOpenGL

[Ian M. <geo...@gm...>]

On Thu, Feb 9, 2012 at 3:24 PM, George LeCompte <ge...@le...> wrote:

> I used easy-install to install PyOpenGL and several of it's friends, but
> PykOpenGL is ont found. see thee two attached files.
>
> help please.
>
> --
> Please respond to ge...@le...
>
The provided files are mutually inconsistent (i.e., the traceback could not
have been provided by the source given).

However, you should try running the following imports:
from OpenGL.GL import *
from OpenGL.GLU import *

Ian

[PyOpenGL-Devel] [ pyopengl-Bugs-3472007 ] vbo.py fails to detect correct implementation

[SourceForge.net <no...@so...>]

Bugs item #3472007, was opened at 2012-01-10 13:28
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3472007&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Patrik (pjbutler)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: vbo.py fails to detect correct implementation

Initial Comment:
My system is OS X 10.7.2, Python 2.7.  Under a core, 3.2, forward-compatible context created via glfw (with OpenGL.FORWARD_COMPATIBLE_ONLY = True).  

In attempting to bind a VBO oibject the following occurs

Traceback (most recent call last):
  File "test.py", line 94, in <module>
    with vb:
  File "/Library/Python/2.7/site-packages/OpenGL/arrays/vbo.py", line 319, in bind
    buffers = self.create_buffers()
  File "/Library/Python/2.7/site-packages/OpenGL/arrays/vbo.py", line 269, in create_buffers
    self.buffers = [ long(self.implementation.glGenBuffers(1)) ]
AttributeError: 'Implementation' object has no attribute 'glGenBuffers'

I have tracked it down to lines 61-71 in vbo.py:
The code seems to build an implementation object based upon vertex buffer objects are implemented in the renderer (i.e. ARB or mainline).  To choose the correct implementation to use it does two checks
if not GL.glBufferData:
    ...
elif vertex_buffer_object.glBufferDataARB:
    ...

However on my system (after creating the opengl 3 context):
print bool(GL.glBufferData)
print bool(vertex_buffer_object.glBufferDataARB)

Results in 
True
False

And so no implementation is assigned.  If I add an "or True" to the second condition to force it down that path all seems to work.  Presumably an else or another elsif clause needs to be added here.  I unfortunately am not familiar enough with PyOpenGL to know the best way to fix this to submit a patch.  If there are some checks I can run to help build a correct elsif statement or if there is some other part that I can give more info on please let me know.

Incidentally this all seems to work when I use an old-fashion 2.1 context.

Thanks

----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2012-01-14 19:41

Message:
This should, I believe, now be fixed in bzr head.  The logic for choosing
implementations was overly complex; if we have core, we should use it, if
we have arb, use that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3472007&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-3472007 ] vbo.py fails to detect correct implementation

[SourceForge.net <no...@so...>]

Bugs item #3472007, was opened at 2012-01-10 13:28
Message generated for change (Tracker Item Submitted) made by pjbutler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3472007&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Patrik (pjbutler)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: vbo.py fails to detect correct implementation

Initial Comment:
My system is OS X 10.7.2, Python 2.7.  Under a core, 3.2, forward-compatible context created via glfw (with OpenGL.FORWARD_COMPATIBLE_ONLY = True).  

In attempting to bind a VBO oibject the following occurs

Traceback (most recent call last):
  File "test.py", line 94, in <module>
    with vb:
  File "/Library/Python/2.7/site-packages/OpenGL/arrays/vbo.py", line 319, in bind
    buffers = self.create_buffers()
  File "/Library/Python/2.7/site-packages/OpenGL/arrays/vbo.py", line 269, in create_buffers
    self.buffers = [ long(self.implementation.glGenBuffers(1)) ]
AttributeError: 'Implementation' object has no attribute 'glGenBuffers'

I have tracked it down to lines 61-71 in vbo.py:
The code seems to build an implementation object based upon vertex buffer objects are implemented in the renderer (i.e. ARB or mainline).  To choose the correct implementation to use it does two checks
if not GL.glBufferData:
    ...
elif vertex_buffer_object.glBufferDataARB:
    ...

However on my system (after creating the opengl 3 context):
print bool(GL.glBufferData)
print bool(vertex_buffer_object.glBufferDataARB)

Results in 
True
False

And so no implementation is assigned.  If I add an "or True" to the second condition to force it down that path all seems to work.  Presumably an else or another elsif clause needs to be added here.  I unfortunately am not familiar enough with PyOpenGL to know the best way to fix this to submit a patch.  If there are some checks I can run to help build a correct elsif statement or if there is some other part that I can give more info on please let me know.

Incidentally this all seems to work when I use an old-fashion 2.1 context.

Thanks

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3472007&group_id=5988

Re: [PyOpenGL-Devel] OpenGL 3.2 core profile

[Mike C. F. <mcf...@vr...>]

On 12-01-09 11:51 AM, Gregor Thalhammer wrote:
> Dear Mike,
>
> thanks for this great response! It seems all the mentioned problems I had with PyOpenGL are solved with the latest release. Now I just need to make my program work properly...
That's often the harder part...

> With the latest release 3.0.2a this problem is gone.
> Just to mention: previously with 3.0.2a1 and OpenGL_accelerate I observed strange errors and segfaults. I didn't dig into this further and deinstalled OpenGL_accelerate.
I'd be surprised if the problem was with OpenGL_accelerate; I use that 
*always* (since I write it), it would be more likely to be 
OpenGL_accelerate *missing* that would cause a problem.

Anyway, good luck,
Mike

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

Re: [PyOpenGL-Devel] OpenGL 3.2 core profile

[Gregor T. <gre...@gm...>]

Dear Mike,

thanks for this great response! It seems all the mentioned problems I had with PyOpenGL are solved with the latest release. Now I just need to make my program work properly...

Am 9.1.2012 um 15:19 schrieb Mike C. Fletcher:

> On 12-01-08 03:59 PM, Gregor Thalhammer wrote:
>> Hi,
>> 
>> first thanks to Mike Fletcher for creating this wonderful package!
>> I want to make use of the new OpenGL 3.2 core profile implementation 
>> on OS X 10.7 Lion. Now I experience some problems with PyOpenGL 
>> 3.0.2a, e.g. when I want to use glGenVertexArrays.
>> 
>> I could track some of the problems to the function 'hasGLExtension' in 
>> OpenGL/extensions.py, here the problematic lines:
>> 
>> try:
>>                AVAILABLE_GL_EXTENSIONS[:] = glGetString( 
>> GL_EXTENSIONS ).split()
>>            except error.GLError, err:
>>                # OpenGL 3.0 deprecates glGetString( GL_EXTENSIONS )
>>                from OpenGL.GL import GL_NUM_EXTENSIONS, glGetStringi, 
>> glGetIntegerv
>>                count = glGetIntegerv( GL_NUM_EXTENSIONS )
>>                for i in range( count ):
>>                    AVAILABLE_GL_EXTENSIONS.append(
>>                        glGetStringi( GL_EXTENSIONS, i )
>>                    )
>>        result = specifier in AVAILABLE_GL_EXTENSIONS
>> 
>> 1) glGetString(GL_EXTENSIONS) returns NULL, split() then throws an 
>> AttributeError.
>> I observed (with GL Profiler) that there is no error check (call of 
>> GetError after GetString), therefore the next GL function call fails 
>> with a false error.
> This is fixed in bzr head.
>> 
>> 2) later, GetStringi( GL_EXTENSIONS, i) produces an 
>> OpenGL.arrays.arraydatatype.GLubyteArray instead of a bytes string, 
>> which gives always a False result in the last line.
>> To fix this I duplicated in OpenGL/glget.py the code for glGetString 
>> accordingly for glGetStringi, and changed the import statement above 
>> to use this definition.
> Hrm, that one I haven't seen, nor do I see it when I create a 3.2 
> forward compatible context on Linux (Ubuntu 11.10).  Are you using 
> OpenGL_accelerate?  (It has a slightly different implementation for 
> Array data-types).

With the latest release 3.0.2a this problem is gone.
Just to mention: previously with 3.0.2a1 and OpenGL_accelerate I observed strange errors and segfaults. I didn't dig into this further and deinstalled OpenGL_accelerate.

>> 
>> 3) For glGenVertexArrays PyOpenGL expects that the 
>> extension GL_ARB_vertex_array_object is available. However, this 
>> extension is not present since glGenVertexArrays is part of OpenGL 3.0 
>> (and 3.2 core profile). Here I am stuck, I don't know how to fix this 
>> (and for other related GL functions)
> This is fixed in bzr head of PyOpenGL, with an explicit mapping of 
> version: implied-available-modules.  The later OpenGL specs do an 
> "include" of extensions rather than writing new versions of the entry 
> points, but the latest release of PyOpenGL assumed that the 
> implementation would still declare the extension available.
>> 
>> Please, I need help to proceed with these problems.
>> 
>> Gregor
> I've just done a very fast release of 3.0.2a2 (i.e. bzr head is now a 
> "release").  I would expect there will be some teething problems with 
> it, as I haven't had a chance to do a proper release (e.g. there's no 
> OpenGL_accelerate compiled for it), but it may help you (and other 
> OS-Xers) move forward.
> 
> HTH,
> Mike
> 
Thanks for your fantastic work, this helped me a lot!

Gregor

Re: [PyOpenGL-Devel] OpenGL 3.2 core profile

[Mike C. F. <mcf...@vr...>]

On 12-01-08 03:59 PM, Gregor Thalhammer wrote:
> Hi,
>
> first thanks to Mike Fletcher for creating this wonderful package!
> I want to make use of the new OpenGL 3.2 core profile implementation 
> on OS X 10.7 Lion. Now I experience some problems with PyOpenGL 
> 3.0.2a, e.g. when I want to use glGenVertexArrays.
>
> I could track some of the problems to the function 'hasGLExtension' in 
> OpenGL/extensions.py, here the problematic lines:
>
> try:
>                 AVAILABLE_GL_EXTENSIONS[:] = glGetString( 
> GL_EXTENSIONS ).split()
>             except error.GLError, err:
>                 # OpenGL 3.0 deprecates glGetString( GL_EXTENSIONS )
>                 from OpenGL.GL import GL_NUM_EXTENSIONS, glGetStringi, 
> glGetIntegerv
>                 count = glGetIntegerv( GL_NUM_EXTENSIONS )
>                 for i in range( count ):
>                     AVAILABLE_GL_EXTENSIONS.append(
>                         glGetStringi( GL_EXTENSIONS, i )
>                     )
>         result = specifier in AVAILABLE_GL_EXTENSIONS
>
> 1) glGetString(GL_EXTENSIONS) returns NULL, split() then throws an 
> AttributeError.
> I observed (with GL Profiler) that there is no error check (call of 
> GetError after GetString), therefore the next GL function call fails 
> with a false error.
This is fixed in bzr head.
>
> 2) later, GetStringi( GL_EXTENSIONS, i) produces an 
> OpenGL.arrays.arraydatatype.GLubyteArray instead of a bytes string, 
> which gives always a False result in the last line.
> To fix this I duplicated in OpenGL/glget.py the code for glGetString 
> accordingly for glGetStringi, and changed the import statement above 
> to use this definition.
Hrm, that one I haven't seen, nor do I see it when I create a 3.2 
forward compatible context on Linux (Ubuntu 11.10).  Are you using 
OpenGL_accelerate?  (It has a slightly different implementation for 
Array data-types).
>
> 3) For glGenVertexArrays PyOpenGL expects that the 
> extension GL_ARB_vertex_array_object is available. However, this 
> extension is not present since glGenVertexArrays is part of OpenGL 3.0 
> (and 3.2 core profile). Here I am stuck, I don't know how to fix this 
> (and for other related GL functions)
This is fixed in bzr head of PyOpenGL, with an explicit mapping of 
version: implied-available-modules.  The later OpenGL specs do an 
"include" of extensions rather than writing new versions of the entry 
points, but the latest release of PyOpenGL assumed that the 
implementation would still declare the extension available.
>
> Please, I need help to proceed with these problems.
>
> Gregor
I've just done a very fast release of 3.0.2a2 (i.e. bzr head is now a 
"release").  I would expect there will be some teething problems with 
it, as I haven't had a chance to do a proper release (e.g. there's no 
OpenGL_accelerate compiled for it), but it may help you (and other 
OS-Xers) move forward.

HTH,
Mike

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

[PyOpenGL-Devel] OpenGL 3.2 core profile

[Gregor T. <gre...@gm...>]

Hi,

first thanks to Mike Fletcher for creating this wonderful package!
I want to make use of the new OpenGL 3.2 core profile implementation on OS X 10.7 Lion. Now I experience some problems with PyOpenGL 3.0.2a, e.g. when I want to use glGenVertexArrays. 

I could track some of the problems to the function 'hasGLExtension' in OpenGL/extensions.py, here the problematic lines:

                        try:
                AVAILABLE_GL_EXTENSIONS[:] = glGetString( GL_EXTENSIONS ).split()
            except error.GLError, err:
                # OpenGL 3.0 deprecates glGetString( GL_EXTENSIONS )
                from OpenGL.GL import GL_NUM_EXTENSIONS, glGetStringi, glGetIntegerv
                count = glGetIntegerv( GL_NUM_EXTENSIONS )
                for i in range( count ):
                    AVAILABLE_GL_EXTENSIONS.append(
                        glGetStringi( GL_EXTENSIONS, i )
                    )
        result = specifier in AVAILABLE_GL_EXTENSIONS

1) glGetString(GL_EXTENSIONS) returns NULL, split() then throws an AttributeError. 
I observed (with GL Profiler) that there is no error check (call of GetError after GetString), therefore the next GL function call fails with a false error.

2) later, GetStringi( GL_EXTENSIONS, i) produces an OpenGL.arrays.arraydatatype.GLubyteArray instead of a bytes string, which gives always a False result in the last line. 
To fix this I duplicated in OpenGL/glget.py the code for glGetString accordingly for glGetStringi, and changed the import statement above to use this definition.

3) For glGenVertexArrays PyOpenGL expects that the extension GL_ARB_vertex_array_object is available. However, this extension is not present since glGenVertexArrays is part of OpenGL 3.0 (and 3.2 core profile). Here I am stuck, I don't know how to fix this (and for other related GL functions)

Please, I need help to proceed with these problems.

Gregor

[PyOpenGL-Devel] [ pyopengl-Bugs-3468306 ] OpenGLContext tests/shadow_2.py on Mac

[SourceForge.net <no...@so...>]

Bugs item #3468306, was opened at 2012-01-01 17:06
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3468306&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Context
Group: OpenGLContext v2.0
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: OpenGLContext tests/shadow_2.py on Mac

Initial Comment:
I was going through splendid OpenGLContext tutorials on Mac, and shadow_2.py tutorial gave a little bit of trouble. By fiddling around, I noticed that it needs a color buffer to be bound, just like win32 does.

So in current trunk, change tests/shadow_2.py line 95 (and perhaps the comment below):

            if sys.platform == 'win32':

to

            if sys.platform == 'win32' or sys.platform == "darwin":

Bumped into this on OS X 10.7.2 (Lion), 2.3GHz 13" Macbook Pro (early 2011).

As a side note, current release seems to be already two years old <http://pypi.python.org/pypi/OpenGLContext>. This is what installs through easy_install. Perhaps it would be time to update it?:)

----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2012-01-04 09:55

Message:
Thanks for bug-fix.  Yup, definitely should try to get a release out some
day.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3468306&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-3468306 ] OpenGLContext tests/shadow_2.py on Mac

[SourceForge.net <no...@so...>]

Bugs item #3468306, was opened at 2012-01-01 17:06
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3468306&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Context
Group: OpenGLContext v2.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: OpenGLContext tests/shadow_2.py on Mac

Initial Comment:
I was going through splendid OpenGLContext tutorials on Mac, and shadow_2.py tutorial gave a little bit of trouble. By fiddling around, I noticed that it needs a color buffer to be bound, just like win32 does.

So in current trunk, change tests/shadow_2.py line 95 (and perhaps the comment below):

            if sys.platform == 'win32':

to

            if sys.platform == 'win32' or sys.platform == "darwin":

Bumped into this on OS X 10.7.2 (Lion), 2.3GHz 13" Macbook Pro (early 2011).

As a side note, current release seems to be already two years old <http://pypi.python.org/pypi/OpenGLContext>. This is what installs through easy_install. Perhaps it would be time to update it?:)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3468306&group_id=5988

[PyOpenGL-Devel] ¡Lee tu mensaje antes de que sea borrado!

[Badoo <no...@ba...>]

¡Lee el mensaje de Jun antes de que sea borrado!

Para leer el mensaje, haz clic en este enlace:
http://us1.badoo.com/01175423979/in/JAgmAVeb9FA/?lang_id=7&m=65&mid=4efd40c20000000000070000ba20a6dd

Más gente que también te está esperando:
Raul (Caracas, Venezuela)
Ana (Caracas, Venezuela)
Kenthebest (Caracas, Venezuela)

http://us1.badoo.com/01175423979/in/JAgmAVeb9FA/?lang_id=7&m=65&mid=4efd40c20000000000070000ba20a6dd

Si al hacer clic en el enlace de este mensaje no funciona, copia y pégalo en la barra de tu navegador.

Este email es parte del proceso de entrega del mensaje enviado por Jun. Si has recibido este email por error, por favor ignóralo. En un breve periodo de tiempo, la petición será eliminada del sistema.

¡Diviértete!
El Equipo de Badoo

Has recibido este email porque un usuario de Badoo te ha dejado un mensaje en Badoo. Este email ha sido generado de manera automática. Por favor, no respondas a este mensaje ya que no recibirás ninguna contestación. Si no quieres recibir más mensajes de Badoo, indícanoslo:
http://us1.badoo.com/impersonation.phtml?lang_id=7&mail_code=65&email=pyopengl-devel%40lists.sourceforge.net&secret=&action=block&block_code=c280eb&m=65&mid=4efd40c20000000000070000ba20a6dd

[PyOpenGL-Devel] Jun te ha dejado un mensaje...

[Badoo <no...@ba...>]

Jun te ha dejado un mensaje...

Sólo tú podrás ver tanto el mensaje como su remitente y lo puedes borrar en cualquier momento. Puedes responder a través del chat de Badoo. Para leer tu mensaje, haz clic en el siguiente enlace:
http://us1.badoo.com/01175423979/in/JAgmAVeb9FA/?lang_id=7&m=63&mid=4ef32ef500000000000700008a57c50a

Más gente que también te está esperando:
Elsable (Miami, Estados Unidos)
Adri (Miami, Estados Unidos)
Pierrot (Miami, Estados Unidos)

http://us1.badoo.com/01175423979/in/JAgmAVeb9FA/?lang_id=7&m=63&mid=4ef32ef500000000000700008a57c50a

Si al pinchar en el enlace de este mensaje no funciona, copia y pégalo en la barra de tu navegador.

Este email es parte del proceso de entrega del mensaje enviado por Jun. Si has recibido este email por error, por favor ignóralo. En un breve periodo de tiempo, la petición será eliminada del sistema.

¡Divértete!
El Equipo de Badoo

Has recibido este email porque un usuario de Badoo te ha dejado un mensaje en Badoo. Este email ha sido generado de manera automática. Por favor, no respondas a este mensaje ya que no recibirás ninguna contestación. Si no quieres recibir más mensajes de Badoo, indícanoslo:
http://us1.badoo.com/impersonation.phtml?lang_id=7&mail_code=63&email=pyopengl-devel%40lists.sourceforge.net&secret=&action=block&block_code=c280eb&m=63&mid=4ef32ef500000000000700008a57c50a