pyopengl-devel — Discussion of PyOpenGL development.

[PyOpenGL-Devel] [ pyopengl-Bugs-2903797 ] 3.0.1a3 imports throw OSError

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

Bugs item #2903797, was opened at 2009-11-25 15:33
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2903797&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: Silverstein (herc111)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: 3.0.1a3 imports throw OSError

Initial Comment:
We recently upgraded to 3.0.1a3 from 2.0.2.01.  In v2 if the underlying GL library was missing the import of OpenGL.GL would raise an ImportError.  With v3.0 it now raises an OSError.  Shouldn't this throw an ImportError?

We distribute our software including Python and PyOpenGL but we do not distribute GL libraries (as we want any native hardware accelerated GL libraries/drivers to be used).  There are situations where users run our software and don't have GL libraries (like on a head node of a cluster).  To handle these circumstances we have been checking for ImportError's.  Unless I'm missing something this seems like the correct exception to raise.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2010-02-22 08:25

Message:
7WdxGn  <a href="http://piclnsjhsfkg.com/">piclnsjhsfkg</a>,
[url=http://thbtiuizqofy.com/]thbtiuizqofy[/url],
[link=http://xghvtjahrsti.com/]xghvtjahrsti[/link],
http://efevnryauvnd.com/

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

Comment By: Silverstein (herc111)
Date: 2009-11-25 20:36

Message:
Mike, ImportError for GL and null func errors for GLU sounds great.

With the holiday this week I won't get to test this until next week at the
earliest.  Will post back the results.

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

Comment By: Silverstein (herc111)
Date: 2009-11-25 20:08

Message:
I guess this change in behavior between pyopengl 2 and 3 is due to the use
of ctypes where ctypes is throwing an OSError whereas prior to using ctypes
it threw an ImportError.

Unfortunately, for us we can't control where users will run our software.
Some of our software requires OpenGL (and in those cases it isn't an
issue).  In some of our tools the use of OpenGL is a nice additional
feature, but if for some reason it isn't available, then we try, as much as
possible, to continue to allow the python scripts to work (ie be usable by
the user but with somewhat diminished feature sets).  In these cases we
need to trap the failed imports of the GL/GLU libraries.

It sounds like you don't want to catch and then throw an ImportError and
that you feel the right way to do this would be to NULL out the functions,
but that this is a lot of work (which I can see).  I take that to mean that
this won't be fixed.  If that's the case, we'll try to put our own
try-except catches into our own python classes.

BTW,  we've been very happy with PyOpenGL.  So thanks!

Herc




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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 20:07

Message:
Okay, I'm going to punt on the "No GL" case and raise an ImportError.  The
no GLU case on GLX and WGL platforms will now produce null-function errors
on attempts to call GLU functions (as with GLUT or GLE).  This is all in
bzr head now, if you could test in environments where this can actually
happen it would be helpful to me.

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 19:51

Message:
Hmm, I can see where the error is coming from, but it seems that the
correct approach would be that taken for the rest of the libraries (GLE and
GLUT), i.e. no import error, just a lot of NULL functions... thing is
there's lots of code that is going to fail because e.g. it tries to load
error handling functions.  Quite frankly I never considered the failure
case of "no GL" or a "GL without GLU" platform.

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

Comment By: Silverstein (herc111)
Date: 2009-11-25 19:17

Message:
Sorry about that.  I should have added that to the case.  I've done that
now.  Note that this is being run through our run-time environment, but
this would happen even if we did a direct OpenGL.GL import (which can be
seen in the stack trace).

The culprit seems to be that the _dlopen generates an OSError.  While
strictly speaking that may be the case, as a user of the module I would
have simply expected an ImportError.s.

On a perhaps somewhat related note I noticed that if I try to import just
GL but don't have a valid GLU library, that it complains.  I would have
thought that importing just GL would not try to load the GLU library. 
Should I file a separate bug case for that?

Thanks,

Herc


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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 19:06

Message:
Hmm, can you tell me *where* the OSError comes from (precisely, as in a
traceback).  It would make it much easier to catch the OSError.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2946226 ] glFramebufferTexture2DEXT causes error , etc.

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

Bugs item #2946226, was opened at 2010-02-04 22:59
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2946226&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: Nobody/Anonymous (nobody)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: glFramebufferTexture2DEXT causes error , etc.

Initial Comment:

I using PyOpenGL 3.0.1b2 on Windows 7 on a Dell XT 2 tablet PC
(http://www.dell.com/tablet). The tablet has a intel GMA  4500MHD
graphics chip with the newest drivers from intel installed. I'm having
problems creating a Framebuffer object using pyOpenGL.  The following
code runs fine on every machine I have access to except for this one.
I know the graphics chip has FBO support, and have successfully
compiled and run various C programs using FBO's.

The problem occurs when I call glFramebufferTexture2DEXT, to attach my
texture to the FBO.  The program crashes and prints a traceback with
GL error code 1286, which I believe is
INVALID_FRAMEBUFFER_OPERATION_EXT.

If anyone knows what I am doing wrong, has a workaround, or even just
a suggestion of identifying the problem better, I would be very
thankful.

I'm posting a code snippet and the output it produces.  I know teh
code isnt complete and nothing is actually done with the fbo etc.  but
its enough to crash the program, and demonstrates the first problem I
encounter on this machine.

The code:
=======================================================================
import pygame
from pygame.locals import *
from OpenGL.GL import *
from OpenGL.GL.EXT.framebuffer_object import *

def draw ():
  glClearColor(0.0,0.0,0.0,0.0)
  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
  #draw stuff here
  pygame.display.flip()

pygame.init()
pygame.display.set_mode((512,512),OPENGL | DOUBLEBUF)

#setup a texture
tex = glGenTextures(1);
glBindTexture(GL_TEXTURE_2D, tex);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, 512, 512, 0, GL_RGBA,
GL_UNSIGNED_BYTE, None);
glBindTexture(GL_TEXTURE_2D, 0);

#setup teh fbo
fbo = glGenFramebuffersEXT(1)
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo)
glBindTexture(GL_TEXTURE_2D, tex)

#this call produces an error!
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,
GL_COLOR_ATTACHMENT0_EXT,GL_TEXTURE_2D, tex, 0)

while 1:
 event=pygame.event.poll ()
 if event.type is QUIT:
  sys.exit(0)
 draw()


Here is the output:
===================================================================
Traceback (most recent call last):
 File "test.py", line 29, in <module>
   glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,
GL_COLOR_ATTACHMENT0_EXT,GL_TEXTURE_2D, tex, 0)
 File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\platform\baseplatform.py",
line 335, in __call__
   return self( *args, **named )
 File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\error.py",
line 208, in glCheckError
   baseOperation = baseOperation,
OpenGL.error.GLError: GLError(
       err = 1286,
       baseOperation = glFramebufferTexture2DEXT,
       cArguments = (
               GL_FRAMEBUFFER_EXT,
               GL_COLOR_ATTACHMENT0_EXT,
               GL_TEXTURE_2D,
               1L,
               0,
       )
)



So I think I figured out whats going on:

in pyOpenGL error.py from line 202, you guys have:
===========================================
 err = self._currentChecker()
 if err: # GL_NO_ERROR's guaranteed value is 0
     raise GLError(
     err,
     result,
     cArguments = cArguments,
     baseOperation = baseOperation,
  )
===========================================

Now, GL_NO_ERROR might always be 0.  but getting teh error code after
e.g. attaching a texture to an FBO, using glFramebufferTexture2DEXT
does not return GL_NO_ERROR, even though everything went great.  It's
supposed to return GL_FRAMEBUFFER_COMPLETE_EXT (36053 int value), which is what I get if i turn of ERROR_CHECK and check manually after attaching the texture.  So
I think the code generates an error, where there is none.  Not sure
why it works fine on my nvidia gpu's..maybe teh openGL spec isn't
definitive on this one?

Still not sure why I get a NullFunctionError for
glDeleteFrameBuffersEXT when I turn on ERROR_CHECK (again works fine
without).  Also, bool(glGenFrameBuffersEXT)  returns False, although
the function is available.


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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2943244 ] PyOpenGL-accelerate and numpy 1.4 numpy_formathandler error

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

Bugs item #2943244, was opened at 2010-01-31 08:16
Message generated for change (Comment added) made by jfpacker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2943244&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: 3
Private: No
Submitted By: jfpacker (jfpacker)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: PyOpenGL-accelerate and numpy 1.4 numpy_formathandler error

Initial Comment:
importing OpenGL.GL gives the error: "ValueError: numpy.dtype does not appear to be the correct type object". 

To reproduce this bug, install python 2.6 (my minor version 4, ie: 2.6.4), PyOpenGL 3.0.1b2-py26-win32 and PyOpenGL-accelerate-3.0.1b2-py26-win32 and numpy 1.4. In the interpreter type: 

import OpenGL
from OpenGL import GL

This gives the output:

  File "C:\Python26\lib\site-packages\GLavish\library\locals.py", line 7, in <mo
dule>
    from OpenGL import GL
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\GL
\__init__.py", line 2, in <module>
    from OpenGL.raw.GL import *
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ra
w\GL\__init__.py", line 6, in <module>
    from OpenGL.raw.GL.constants import *
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ra
w\GL\constants.py", line 7, in <module>
    from OpenGL import platform, arrays
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ar
rays\__init__.py", line 22, in <module>
    formathandler.FormatHandler.loadAll()
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ar
rays\formathandler.py", line 37, in loadAll
    cls.loadPlugin( entrypoint )
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ar
rays\formathandler.py", line 44, in loadPlugin
    plugin_class = entrypoint.load()
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\pl
ugins.py", line 14, in load
    return importByName( self.import_path )
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\pl
ugins.py", line 28, in importByName
    module = __import__( ".".join(moduleName), {}, {}, moduleName)
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ar
rays\numpymodule.py", line 25, in <module>
    from OpenGL_accelerate.numpy_formathandler import NumpyHandler
  File "c:\users\jeff\appdata\local\temp\easy_install-uwdslx\PyOpenGL_accelerate
-3.0.1b2-py2.6-win32.egg.tmp\OpenGL_accelerate\numpy_formathandler.py", line 7,
in <module>
  File "c:\users\jeff\appdata\local\temp\easy_install-uwdslx\PyOpenGL_accelerate
-3.0.1b2-py2.6-win32.egg.tmp\OpenGL_accelerate\numpy_formathandler.py", line 6,
in __bootstrap__
  File "numpy.pxd", line 30, in OpenGL_accelerate.numpy_formathandler (src\numpy
_formathandler.c:3543)
ValueError: numpy.dtype does not appear to be the correct type object

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

>Comment By: jfpacker (jfpacker)
Date: 2010-01-31 08:23

Message:
This only occurs if you easy_install PyOpenGL-accelerate as it downloads
the pre-built version win32 version. I downloaded the source and installed
from source and it works.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2943244 ] PyOpenGL-accelerate and numpy 1.4 numpy_formathandler error

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

Bugs item #2943244, was opened at 2010-01-31 08:16
Message generated for change (Tracker Item Submitted) made by jfpacker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2943244&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: jfpacker (jfpacker)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: PyOpenGL-accelerate and numpy 1.4 numpy_formathandler error

Initial Comment:
importing OpenGL.GL gives the error: "ValueError: numpy.dtype does not appear to be the correct type object". 

To reproduce this bug, install python 2.6 (my minor version 4, ie: 2.6.4), PyOpenGL 3.0.1b2-py26-win32 and PyOpenGL-accelerate-3.0.1b2-py26-win32 and numpy 1.4. In the interpreter type: 

import OpenGL
from OpenGL import GL

This gives the output:

  File "C:\Python26\lib\site-packages\GLavish\library\locals.py", line 7, in <mo
dule>
    from OpenGL import GL
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\GL
\__init__.py", line 2, in <module>
    from OpenGL.raw.GL import *
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ra
w\GL\__init__.py", line 6, in <module>
    from OpenGL.raw.GL.constants import *
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ra
w\GL\constants.py", line 7, in <module>
    from OpenGL import platform, arrays
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ar
rays\__init__.py", line 22, in <module>
    formathandler.FormatHandler.loadAll()
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ar
rays\formathandler.py", line 37, in loadAll
    cls.loadPlugin( entrypoint )
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ar
rays\formathandler.py", line 44, in loadPlugin
    plugin_class = entrypoint.load()
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\pl
ugins.py", line 14, in load
    return importByName( self.import_path )
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\pl
ugins.py", line 28, in importByName
    module = __import__( ".".join(moduleName), {}, {}, moduleName)
  File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ar
rays\numpymodule.py", line 25, in <module>
    from OpenGL_accelerate.numpy_formathandler import NumpyHandler
  File "c:\users\jeff\appdata\local\temp\easy_install-uwdslx\PyOpenGL_accelerate
-3.0.1b2-py2.6-win32.egg.tmp\OpenGL_accelerate\numpy_formathandler.py", line 7,
in <module>
  File "c:\users\jeff\appdata\local\temp\easy_install-uwdslx\PyOpenGL_accelerate
-3.0.1b2-py2.6-win32.egg.tmp\OpenGL_accelerate\numpy_formathandler.py", line 6,
in __bootstrap__
  File "numpy.pxd", line 30, in OpenGL_accelerate.numpy_formathandler (src\numpy
_formathandler.c:3543)
ValueError: numpy.dtype does not appear to be the correct type object

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2939786 ] glColor wrapper doesn't handle tuple of floats properly

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

Bugs item #2939786, was opened at 2010-01-25 22:47
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2939786&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: glColor wrapper doesn't handle tuple of floats properly

Initial Comment:
In the following fragment of exceptional.py 

Either  GLdoubleArray should be used or colorDispatch should refer to glColorXfv not glColorXdv. In simpler words types should match or there is no effect to glColor call

colorDispatch = {
    3: annotations.glColor3dv,
    4: annotations.glColor4dv,
}

def glColor( *args ):
    """glColor*f* -- convenience function to dispatch on argument type
       dispatches to glColor3f, glColor2f, glColor4f, glColor3f, glColor2f, glColor4f
       depending on the arguments passed...
    """
    arglen = len(args)
    if arglen == 1:
        arg = arrays.GLfloatArray.asArray( args[0] )
        function = glColorDispatch[arrays.GLfloatArray.arraySize( arg )]
        return function( arg )
    elif arglen == 2:
            return simple.glColor2d( *args )
    elif arglen == 3:
        return simple.glColor3d( *args )
    elif arglen == 4:
            return simple.glColor4d( *args )
    else:
        raise ValueError( """Don't know how to handle arguments: %s"""%(args,))

Tested on Gentoo linux, 
PyOpengl 3.0.1_beta1 and beta2 
Python 2.6.4

email: de...@gm...

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2935298 ] glShaderSource wrapper fail on ATI card ?

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

Bugs item #2935298, was opened at 2010-01-19 23:04
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2935298&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: v2.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: glShaderSource wrapper fail on ATI card ?

Initial Comment:
Hi everyone,

I got a problem on my framework with Shader + ATI card. By switching from pyglet to pyopengl, shader just not working anymore. After investigation, it seem that the wrapper on glShaderSource is not working properly.

If i use the pyopengl wrapper (glShaderSource(shader, source)), i got an error at glLinkProgram() :
Fragment shader was successfully compiled to run on hardware.
Fragment shader(s) failed to link,  vertex shader(s) failed to link.
ERROR: 1:1: error(#132) Syntax error: 'v' parse error
ERROR: error(#273) 1 compilation errors.  No code generated
ERROR: 1:1: error(#132) Syntax error: 'v' parse error
ERROR: error(#273) 1 compilation errors.  No code generated

If i'm doing ctype myself like:
glShaderSource = platform.createBaseFunction( 
    'glShaderSource', dll=platform.GL,
    resultType=None, 
    argTypes=(constants.GLhandle, constants.GLsizei, ctypes.POINTER(ctypes.c_char_p), arrays.GLintArray,),
    doc = 'glShaderSource( GLhandle(shaderObj), str( string) ) -> None',
    argNames = ('shaderObj', 'count', 'string', 'length',),
)

from ctypes import *
source = c_char_p(source)
length = c_int(-1)
glShaderSource(shader, 1, byref(source), byref(length))

-> no more error message at glLinkProgram.

Where i can debug more the wrapper function ? Is it a converter problem ?

Thanks,

Mathieu

Note: i'm running the 3.0.0-0ubuntu1 from Ubuntu Karmic.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2903797 ] 3.0.1a3 imports throw OSError

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

Bugs item #2903797, was opened at 2009-11-25 07:33
Message generated for change (Comment added) made by herc111
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2903797&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: Silverstein (herc111)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: 3.0.1a3 imports throw OSError

Initial Comment:
We recently upgraded to 3.0.1a3 from 2.0.2.01.  In v2 if the underlying GL library was missing the import of OpenGL.GL would raise an ImportError.  With v3.0 it now raises an OSError.  Shouldn't this throw an ImportError?

We distribute our software including Python and PyOpenGL but we do not distribute GL libraries (as we want any native hardware accelerated GL libraries/drivers to be used).  There are situations where users run our software and don't have GL libraries (like on a head node of a cluster).  To handle these circumstances we have been checking for ImportError's.  Unless I'm missing something this seems like the correct exception to raise.


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

>Comment By: Silverstein (herc111)
Date: 2009-11-25 12:36

Message:
Mike, ImportError for GL and null func errors for GLU sounds great.

With the holiday this week I won't get to test this until next week at the
earliest.  Will post back the results.

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

Comment By: Silverstein (herc111)
Date: 2009-11-25 12:08

Message:
I guess this change in behavior between pyopengl 2 and 3 is due to the use
of ctypes where ctypes is throwing an OSError whereas prior to using ctypes
it threw an ImportError.

Unfortunately, for us we can't control where users will run our software.
Some of our software requires OpenGL (and in those cases it isn't an
issue).  In some of our tools the use of OpenGL is a nice additional
feature, but if for some reason it isn't available, then we try, as much as
possible, to continue to allow the python scripts to work (ie be usable by
the user but with somewhat diminished feature sets).  In these cases we
need to trap the failed imports of the GL/GLU libraries.

It sounds like you don't want to catch and then throw an ImportError and
that you feel the right way to do this would be to NULL out the functions,
but that this is a lot of work (which I can see).  I take that to mean that
this won't be fixed.  If that's the case, we'll try to put our own
try-except catches into our own python classes.

BTW,  we've been very happy with PyOpenGL.  So thanks!

Herc




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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 12:07

Message:
Okay, I'm going to punt on the "No GL" case and raise an ImportError.  The
no GLU case on GLX and WGL platforms will now produce null-function errors
on attempts to call GLU functions (as with GLUT or GLE).  This is all in
bzr head now, if you could test in environments where this can actually
happen it would be helpful to me.

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 11:51

Message:
Hmm, I can see where the error is coming from, but it seems that the
correct approach would be that taken for the rest of the libraries (GLE and
GLUT), i.e. no import error, just a lot of NULL functions... thing is
there's lots of code that is going to fail because e.g. it tries to load
error handling functions.  Quite frankly I never considered the failure
case of "no GL" or a "GL without GLU" platform.

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

Comment By: Silverstein (herc111)
Date: 2009-11-25 11:17

Message:
Sorry about that.  I should have added that to the case.  I've done that
now.  Note that this is being run through our run-time environment, but
this would happen even if we did a direct OpenGL.GL import (which can be
seen in the stack trace).

The culprit seems to be that the _dlopen generates an OSError.  While
strictly speaking that may be the case, as a user of the module I would
have simply expected an ImportError.s.

On a perhaps somewhat related note I noticed that if I try to import just
GL but don't have a valid GLU library, that it complains.  I would have
thought that importing just GL would not try to load the GLU library. 
Should I file a separate bug case for that?

Thanks,

Herc


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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 11:06

Message:
Hmm, can you tell me *where* the OSError comes from (precisely, as in a
traceback).  It would make it much easier to catch the OSError.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2903797 ] 3.0.1a3 imports throw OSError

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

Bugs item #2903797, was opened at 2009-11-25 07:33
Message generated for change (Comment added) made by herc111
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2903797&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: Silverstein (herc111)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: 3.0.1a3 imports throw OSError

Initial Comment:
We recently upgraded to 3.0.1a3 from 2.0.2.01.  In v2 if the underlying GL library was missing the import of OpenGL.GL would raise an ImportError.  With v3.0 it now raises an OSError.  Shouldn't this throw an ImportError?

We distribute our software including Python and PyOpenGL but we do not distribute GL libraries (as we want any native hardware accelerated GL libraries/drivers to be used).  There are situations where users run our software and don't have GL libraries (like on a head node of a cluster).  To handle these circumstances we have been checking for ImportError's.  Unless I'm missing something this seems like the correct exception to raise.


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

>Comment By: Silverstein (herc111)
Date: 2009-11-25 12:08

Message:
I guess this change in behavior between pyopengl 2 and 3 is due to the use
of ctypes where ctypes is throwing an OSError whereas prior to using ctypes
it threw an ImportError.

Unfortunately, for us we can't control where users will run our software.
Some of our software requires OpenGL (and in those cases it isn't an
issue).  In some of our tools the use of OpenGL is a nice additional
feature, but if for some reason it isn't available, then we try, as much as
possible, to continue to allow the python scripts to work (ie be usable by
the user but with somewhat diminished feature sets).  In these cases we
need to trap the failed imports of the GL/GLU libraries.

It sounds like you don't want to catch and then throw an ImportError and
that you feel the right way to do this would be to NULL out the functions,
but that this is a lot of work (which I can see).  I take that to mean that
this won't be fixed.  If that's the case, we'll try to put our own
try-except catches into our own python classes.

BTW,  we've been very happy with PyOpenGL.  So thanks!

Herc




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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 12:07

Message:
Okay, I'm going to punt on the "No GL" case and raise an ImportError.  The
no GLU case on GLX and WGL platforms will now produce null-function errors
on attempts to call GLU functions (as with GLUT or GLE).  This is all in
bzr head now, if you could test in environments where this can actually
happen it would be helpful to me.

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 11:51

Message:
Hmm, I can see where the error is coming from, but it seems that the
correct approach would be that taken for the rest of the libraries (GLE and
GLUT), i.e. no import error, just a lot of NULL functions... thing is
there's lots of code that is going to fail because e.g. it tries to load
error handling functions.  Quite frankly I never considered the failure
case of "no GL" or a "GL without GLU" platform.

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

Comment By: Silverstein (herc111)
Date: 2009-11-25 11:17

Message:
Sorry about that.  I should have added that to the case.  I've done that
now.  Note that this is being run through our run-time environment, but
this would happen even if we did a direct OpenGL.GL import (which can be
seen in the stack trace).

The culprit seems to be that the _dlopen generates an OSError.  While
strictly speaking that may be the case, as a user of the module I would
have simply expected an ImportError.s.

On a perhaps somewhat related note I noticed that if I try to import just
GL but don't have a valid GLU library, that it complains.  I would have
thought that importing just GL would not try to load the GLU library. 
Should I file a separate bug case for that?

Thanks,

Herc


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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 11:06

Message:
Hmm, can you tell me *where* the OSError comes from (precisely, as in a
traceback).  It would make it much easier to catch the OSError.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2903797 ] 3.0.1a3 imports throw OSError

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

Bugs item #2903797, was opened at 2009-11-25 10:33
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2903797&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: Silverstein (herc111)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: 3.0.1a3 imports throw OSError

Initial Comment:
We recently upgraded to 3.0.1a3 from 2.0.2.01.  In v2 if the underlying GL library was missing the import of OpenGL.GL would raise an ImportError.  With v3.0 it now raises an OSError.  Shouldn't this throw an ImportError?

We distribute our software including Python and PyOpenGL but we do not distribute GL libraries (as we want any native hardware accelerated GL libraries/drivers to be used).  There are situations where users run our software and don't have GL libraries (like on a head node of a cluster).  To handle these circumstances we have been checking for ImportError's.  Unless I'm missing something this seems like the correct exception to raise.


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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 15:07

Message:
Okay, I'm going to punt on the "No GL" case and raise an ImportError.  The
no GLU case on GLX and WGL platforms will now produce null-function errors
on attempts to call GLU functions (as with GLUT or GLE).  This is all in
bzr head now, if you could test in environments where this can actually
happen it would be helpful to me.

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 14:51

Message:
Hmm, I can see where the error is coming from, but it seems that the
correct approach would be that taken for the rest of the libraries (GLE and
GLUT), i.e. no import error, just a lot of NULL functions... thing is
there's lots of code that is going to fail because e.g. it tries to load
error handling functions.  Quite frankly I never considered the failure
case of "no GL" or a "GL without GLU" platform.

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

Comment By: Silverstein (herc111)
Date: 2009-11-25 14:17

Message:
Sorry about that.  I should have added that to the case.  I've done that
now.  Note that this is being run through our run-time environment, but
this would happen even if we did a direct OpenGL.GL import (which can be
seen in the stack trace).

The culprit seems to be that the _dlopen generates an OSError.  While
strictly speaking that may be the case, as a user of the module I would
have simply expected an ImportError.s.

On a perhaps somewhat related note I noticed that if I try to import just
GL but don't have a valid GLU library, that it complains.  I would have
thought that importing just GL would not try to load the GLU library. 
Should I file a separate bug case for that?

Thanks,

Herc


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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 14:06

Message:
Hmm, can you tell me *where* the OSError comes from (precisely, as in a
traceback).  It would make it much easier to catch the OSError.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2903797 ] 3.0.1a3 imports throw OSError

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

Bugs item #2903797, was opened at 2009-11-25 10:33
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2903797&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: Silverstein (herc111)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: 3.0.1a3 imports throw OSError

Initial Comment:
We recently upgraded to 3.0.1a3 from 2.0.2.01.  In v2 if the underlying GL library was missing the import of OpenGL.GL would raise an ImportError.  With v3.0 it now raises an OSError.  Shouldn't this throw an ImportError?

We distribute our software including Python and PyOpenGL but we do not distribute GL libraries (as we want any native hardware accelerated GL libraries/drivers to be used).  There are situations where users run our software and don't have GL libraries (like on a head node of a cluster).  To handle these circumstances we have been checking for ImportError's.  Unless I'm missing something this seems like the correct exception to raise.


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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 14:51

Message:
Hmm, I can see where the error is coming from, but it seems that the
correct approach would be that taken for the rest of the libraries (GLE and
GLUT), i.e. no import error, just a lot of NULL functions... thing is
there's lots of code that is going to fail because e.g. it tries to load
error handling functions.  Quite frankly I never considered the failure
case of "no GL" or a "GL without GLU" platform.

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

Comment By: Silverstein (herc111)
Date: 2009-11-25 14:17

Message:
Sorry about that.  I should have added that to the case.  I've done that
now.  Note that this is being run through our run-time environment, but
this would happen even if we did a direct OpenGL.GL import (which can be
seen in the stack trace).

The culprit seems to be that the _dlopen generates an OSError.  While
strictly speaking that may be the case, as a user of the module I would
have simply expected an ImportError.s.

On a perhaps somewhat related note I noticed that if I try to import just
GL but don't have a valid GLU library, that it complains.  I would have
thought that importing just GL would not try to load the GLU library. 
Should I file a separate bug case for that?

Thanks,

Herc


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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 14:06

Message:
Hmm, can you tell me *where* the OSError comes from (precisely, as in a
traceback).  It would make it much easier to catch the OSError.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2903797 ] 3.0.1a3 imports throw OSError

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

Bugs item #2903797, was opened at 2009-11-25 07:33
Message generated for change (Comment added) made by herc111
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2903797&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: Silverstein (herc111)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: 3.0.1a3 imports throw OSError

Initial Comment:
We recently upgraded to 3.0.1a3 from 2.0.2.01.  In v2 if the underlying GL library was missing the import of OpenGL.GL would raise an ImportError.  With v3.0 it now raises an OSError.  Shouldn't this throw an ImportError?

We distribute our software including Python and PyOpenGL but we do not distribute GL libraries (as we want any native hardware accelerated GL libraries/drivers to be used).  There are situations where users run our software and don't have GL libraries (like on a head node of a cluster).  To handle these circumstances we have been checking for ImportError's.  Unless I'm missing something this seems like the correct exception to raise.


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

>Comment By: Silverstein (herc111)
Date: 2009-11-25 11:17

Message:
Sorry about that.  I should have added that to the case.  I've done that
now.  Note that this is being run through our run-time environment, but
this would happen even if we did a direct OpenGL.GL import (which can be
seen in the stack trace).

The culprit seems to be that the _dlopen generates an OSError.  While
strictly speaking that may be the case, as a user of the module I would
have simply expected an ImportError.s.

On a perhaps somewhat related note I noticed that if I try to import just
GL but don't have a valid GLU library, that it complains.  I would have
thought that importing just GL would not try to load the GLU library. 
Should I file a separate bug case for that?

Thanks,

Herc


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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 11:06

Message:
Hmm, can you tell me *where* the OSError comes from (precisely, as in a
traceback).  It would make it much easier to catch the OSError.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2903797 ] 3.0.1a3 imports throw OSError

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

Bugs item #2903797, was opened at 2009-11-25 10:33
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2903797&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: Silverstein (herc111)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: 3.0.1a3 imports throw OSError

Initial Comment:
We recently upgraded to 3.0.1a3 from 2.0.2.01.  In v2 if the underlying GL library was missing the import of OpenGL.GL would raise an ImportError.  With v3.0 it now raises an OSError.  Shouldn't this throw an ImportError?

We distribute our software including Python and PyOpenGL but we do not distribute GL libraries (as we want any native hardware accelerated GL libraries/drivers to be used).  There are situations where users run our software and don't have GL libraries (like on a head node of a cluster).  To handle these circumstances we have been checking for ImportError's.  Unless I'm missing something this seems like the correct exception to raise.


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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 14:06

Message:
Hmm, can you tell me *where* the OSError comes from (precisely, as in a
traceback).  It would make it much easier to catch the OSError.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2903797 ] 3.0.1a3 imports throw OSError

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

Bugs item #2903797, was opened at 2009-11-25 07:33
Message generated for change (Tracker Item Submitted) made by herc111
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2903797&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: Silverstein (herc111)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: 3.0.1a3 imports throw OSError

Initial Comment:
We recently upgraded to 3.0.1a3 from 2.0.2.01.  In v2 if the underlying GL library was missing the import of OpenGL.GL would raise an ImportError.  With v3.0 it now raises an OSError.  Shouldn't this throw an ImportError?

We distribute our software including Python and PyOpenGL but we do not distribute GL libraries (as we want any native hardware accelerated GL libraries/drivers to be used).  There are situations where users run our software and don't have GL libraries (like on a head node of a cluster).  To handle these circumstances we have been checking for ImportError's.  Unless I'm missing something this seems like the correct exception to raise.


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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2897786 ] glTexImage

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

Bugs item #2897786, was opened at 2009-11-14 14:25
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2897786&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: glTexImage

Initial Comment:
glTexImage does not accept the external pixel data type (last parameter of glTexImage) GL_UNSIGNED_INT_24_8 for GL_DEPTH24_STENCIL8 textures. Get a key error in images.TYPE_TO_ARRAYTYPE

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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-14 19:14

Message:
Image-type registrations were missing for the 3 variants (NV, EXT and ARB).
 Added in bzr head.  Thanks.  Example registration should you wish to do a
work-around (note, don't have any test case, so have not been able to test
that this does what it's supposed to do):

--- OpenGL/GL/ARB/framebuffer_object.py 2009-08-30 02:28:09 +0000
+++ OpenGL/GL/ARB/framebuffer_object.py 2009-11-14 19:48:04 +0000
@@ -30,4 +30,9 @@                                                
     if framebuffers is None:                                    
         framebuffers = arrays.GLuintArray.asArray( n )          
         n = arrays.GLuintArray.arraySize( framebuffers )        
-    return baseOperation( n, framebuffers )                     
\ No newline at end of file                                      
+    return baseOperation( n, framebuffers )                     
+                                                                
+# Setup the GL_UNSIGNED_INT_24_8 image type                     
+from OpenGL import images                                       
+images.TYPE_TO_ARRAYTYPE[ GL_UNSIGNED_INT_24_8 ] = GL_UNSIGNED_INT
+images.TIGHT_PACK_FORMATS[ GL_UNSIGNED_INT_24_8 ] = 4

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2897786 ] glTexImage

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

Bugs item #2897786, was opened at 2009-11-14 19:25
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2897786&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: glTexImage

Initial Comment:
glTexImage does not accept the external pixel data type (last parameter of glTexImage) GL_UNSIGNED_INT_24_8 for GL_DEPTH24_STENCIL8 textures. Get a key error in images.TYPE_TO_ARRAYTYPE

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2895081 ] Unknown specifier GL_MAX_TEXTURE_IMAGE_UNITS

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

Bugs item #2895081, was opened at 2009-11-10 04:04
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2895081&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: https://www.google.com/accounts ()
Assigned to: Mike C. Fletcher (mcfletch)
Summary: Unknown specifier GL_MAX_TEXTURE_IMAGE_UNITS

Initial Comment:
Running:

print 'Max texture image units ', glGetInteger(GL_MAX_TEXTURE_IMAGE_UNITS)

Produces the following error:

  File "/usr/lib/python2.6/site-packages/OpenGL/wrapper.py", line 1282, in __call__
    return self._finalCall( *args, **named )
  File "/usr/lib/python2.6/site-packages/OpenGL/wrapper.py", line 552, in wrapperCall
    cArgs = tuple(calculate_cArgs( pyArgs ))
  File "/usr/lib/python2.6/site-packages/OpenGL/wrapper.py", line 355, in calculate_cArgs
    yield converter( pyArgs, index, self )
  File "/usr/lib/python2.6/site-packages/OpenGL/converters.py", line 195, in __call__
    return self.arrayType.zeros( self.getSize(pyArgs) )
  File "/usr/lib/python2.6/site-packages/OpenGL/converters.py", line 234, in getSize
    raise KeyError( """Unknown specifier %s"""%( specifier ))
KeyError: ('Unknown specifier GL_MAX_TEXTURE_IMAGE_UNITS (34930)', 'Failure in cConverter <OpenGL.converters.SizedOutput object at 0x187a140>', (GL_MAX_TEXTURE_IMAGE_UNITS,), 1, <OpenGL.wrapper.glGetIntegerv object at 0x1872f38>)


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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-13 11:16

Message:
Just implemented the first suite of truly automated tests, but they
wouldn't have caught this, as I don't have any code exercising the missing
features.

As for an ugly workaround, you can call OpenGL.GL.glget.addGLGetConstant(
constant, (1,) )

where (1,) is the dimension of the array to be created for the constant,
so e.g. (4,4) for most matrices.

I've also added a script that goes ahead and attempts to use glGet on
*every* constant in the core, but that's limited by the hardware/drivers I
have available.

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

Comment By: https://www.google.com/accounts ()
Date: 2009-11-10 23:12

Message:
Some automated tests might be helpful too =)

Is there some ugly workaround for this? I am not sure that people running
my software will have the desire/ability to upgrade to 3.0.1?

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-10 11:48

Message:
Wow, there were a *lot* of bugs hiding behind that one.  Any non-extension
glGet constant over about GL 1.1 was going to raise an error.  I've updated
the code to have all GL 2.1 constants, but there's going to be 3.0, 3.1 and
3.2 constants missing.  Need to get a better mechanism for determining what
can be used with glGet to make this automatic.

3.0.1 should have the fix for the particular bug here.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2872257 ] glutInit fails on windows 64-bit

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

Bugs item #2872257, was opened at 2009-10-03 08:29
Message generated for change (Comment added) made by cjgohlke
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2872257&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: GLUT
Group: v3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jason G (reirrac)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: glutInit fails on windows 64-bit

Initial Comment:
On a 64-bit Windows 7 machine, GLUT fails on glutInit with the following traceback:

Traceback (most recent call last):
  File "C:\Programming\NE\HyperNEAT\HyperNEAT_Visualizer\src\HyperNEATVisualizer.py", line 287, in <module>
    visualizer.main()
  File "C:\Programming\NE\HyperNEAT\HyperNEAT_Visualizer\src\HyperNEATVisualizer.py", line 233, in main
    glutInit(sys.argv)
  File "c:\Python26\Lib\site-packages\OpenGL\GLUT\special.py", line 322, in glutInit
    _base_glutInit( ctypes.byref(count), holder )
TypeError: 'NoneType' object is not callable


I tried copying the glut and gle dll's to my c:\windows\system32\ directory but that didn't change anything.

If I comment out the glutInit function, I get this:

Traceback (most recent call last):
  File "C:\Programming\NE\HyperNEAT\HyperNEAT_Visualizer\src\HyperNEATVisualizer.py", line 287, in <module>
    visualizer.main()
  File "C:\Programming\NE\HyperNEAT\HyperNEAT_Visualizer\src\HyperNEATVisualizer.py", line 240, in main
    glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GLUT_ALPHA | GLUT_DEPTH)
  File "c:\Python26\Lib\site-packages\OpenGL\platform\baseplatform.py", line 336, in __call__
    self.__name__, self.__name__,
OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling

I get the same error with any of the NeHe opengl lesson code.  It works fine on my linux machine and my windows 32-bit machine, so I think it's something to do with windows 64-bit.  Are there 64-bit versions of the glut and gle DLLs?

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

Comment By: Christoph Gohlke (cjgohlke)
Date: 2009-11-12 21:55

Message:
I had the same problem on Python 2.6.4 64-bit, PyOpenGL-3.0.1b1, Windows 7.
Turned out there was a 32-bit glut32.dll file in the PATH, which  was used
instead of the correct 64-bit glut32.dll in
Python26\Lib\site-packages\OpenGL\DLLS. Everything worked once I cleaned
the PATH environment variable. You can download a 64-bit version of
PyOpenGL for Windows at
<http://www.lfd.uci.edu/~gohlke/pythonlibs/#pyopengl>

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2895081 ] Unknown specifier GL_MAX_TEXTURE_IMAGE_UNITS

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

Bugs item #2895081, was opened at 2009-11-10 09:04
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2895081&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: https://www.google.com/accounts ()
Assigned to: Mike C. Fletcher (mcfletch)
Summary: Unknown specifier GL_MAX_TEXTURE_IMAGE_UNITS

Initial Comment:
Running:

print 'Max texture image units ', glGetInteger(GL_MAX_TEXTURE_IMAGE_UNITS)

Produces the following error:

  File "/usr/lib/python2.6/site-packages/OpenGL/wrapper.py", line 1282, in __call__
    return self._finalCall( *args, **named )
  File "/usr/lib/python2.6/site-packages/OpenGL/wrapper.py", line 552, in wrapperCall
    cArgs = tuple(calculate_cArgs( pyArgs ))
  File "/usr/lib/python2.6/site-packages/OpenGL/wrapper.py", line 355, in calculate_cArgs
    yield converter( pyArgs, index, self )
  File "/usr/lib/python2.6/site-packages/OpenGL/converters.py", line 195, in __call__
    return self.arrayType.zeros( self.getSize(pyArgs) )
  File "/usr/lib/python2.6/site-packages/OpenGL/converters.py", line 234, in getSize
    raise KeyError( """Unknown specifier %s"""%( specifier ))
KeyError: ('Unknown specifier GL_MAX_TEXTURE_IMAGE_UNITS (34930)', 'Failure in cConverter <OpenGL.converters.SizedOutput object at 0x187a140>', (GL_MAX_TEXTURE_IMAGE_UNITS,), 1, <OpenGL.wrapper.glGetIntegerv object at 0x1872f38>)


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

>Comment By: https://www.google.com/accounts ()
Date: 2009-11-11 04:12

Message:
Some automated tests might be helpful too =)

Is there some ugly workaround for this? I am not sure that people running
my software will have the desire/ability to upgrade to 3.0.1?

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-10 16:48

Message:
Wow, there were a *lot* of bugs hiding behind that one.  Any non-extension
glGet constant over about GL 1.1 was going to raise an error.  I've updated
the code to have all GL 2.1 constants, but there's going to be 3.0, 3.1 and
3.2 constants missing.  Need to get a better mechanism for determining what
can be used with glGet to make this automatic.

3.0.1 should have the fix for the particular bug here.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2895081 ] Unknown specifier GL_MAX_TEXTURE_IMAGE_UNITS

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

Bugs item #2895081, was opened at 2009-11-10 04:04
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2895081&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: https://www.google.com/accounts ()
Assigned to: Mike C. Fletcher (mcfletch)
Summary: Unknown specifier GL_MAX_TEXTURE_IMAGE_UNITS

Initial Comment:
Running:

print 'Max texture image units ', glGetInteger(GL_MAX_TEXTURE_IMAGE_UNITS)

Produces the following error:

  File "/usr/lib/python2.6/site-packages/OpenGL/wrapper.py", line 1282, in __call__
    return self._finalCall( *args, **named )
  File "/usr/lib/python2.6/site-packages/OpenGL/wrapper.py", line 552, in wrapperCall
    cArgs = tuple(calculate_cArgs( pyArgs ))
  File "/usr/lib/python2.6/site-packages/OpenGL/wrapper.py", line 355, in calculate_cArgs
    yield converter( pyArgs, index, self )
  File "/usr/lib/python2.6/site-packages/OpenGL/converters.py", line 195, in __call__
    return self.arrayType.zeros( self.getSize(pyArgs) )
  File "/usr/lib/python2.6/site-packages/OpenGL/converters.py", line 234, in getSize
    raise KeyError( """Unknown specifier %s"""%( specifier ))
KeyError: ('Unknown specifier GL_MAX_TEXTURE_IMAGE_UNITS (34930)', 'Failure in cConverter <OpenGL.converters.SizedOutput object at 0x187a140>', (GL_MAX_TEXTURE_IMAGE_UNITS,), 1, <OpenGL.wrapper.glGetIntegerv object at 0x1872f38>)


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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-10 11:48

Message:
Wow, there were a *lot* of bugs hiding behind that one.  Any non-extension
glGet constant over about GL 1.1 was going to raise an error.  I've updated
the code to have all GL 2.1 constants, but there's going to be 3.0, 3.1 and
3.2 constants missing.  Need to get a better mechanism for determining what
can be used with glGet to make this automatic.

3.0.1 should have the fix for the particular bug here.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2895081 ] Unknown specifier GL_MAX_TEXTURE_IMAGE_UNITS

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

Bugs item #2895081, was opened at 2009-11-10 09:04
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2895081&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: https://www.google.com/accounts ()
Assigned to: Mike C. Fletcher (mcfletch)
Summary: Unknown specifier GL_MAX_TEXTURE_IMAGE_UNITS

Initial Comment:
Running:

print 'Max texture image units ', glGetInteger(GL_MAX_TEXTURE_IMAGE_UNITS)

Produces the following error:

  File "/usr/lib/python2.6/site-packages/OpenGL/wrapper.py", line 1282, in __call__
    return self._finalCall( *args, **named )
  File "/usr/lib/python2.6/site-packages/OpenGL/wrapper.py", line 552, in wrapperCall
    cArgs = tuple(calculate_cArgs( pyArgs ))
  File "/usr/lib/python2.6/site-packages/OpenGL/wrapper.py", line 355, in calculate_cArgs
    yield converter( pyArgs, index, self )
  File "/usr/lib/python2.6/site-packages/OpenGL/converters.py", line 195, in __call__
    return self.arrayType.zeros( self.getSize(pyArgs) )
  File "/usr/lib/python2.6/site-packages/OpenGL/converters.py", line 234, in getSize
    raise KeyError( """Unknown specifier %s"""%( specifier ))
KeyError: ('Unknown specifier GL_MAX_TEXTURE_IMAGE_UNITS (34930)', 'Failure in cConverter <OpenGL.converters.SizedOutput object at 0x187a140>', (GL_MAX_TEXTURE_IMAGE_UNITS,), 1, <OpenGL.wrapper.glGetIntegerv object at 0x1872f38>)


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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2844174 ] Bug in glGetShaderiv on Windows

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

Bugs item #2844174, was opened at 2009-08-25 07:18
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2844174&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: Leith Bade (ljbade)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: Bug in glGetShaderiv on Windows

Initial Comment:
I am using 3.0.1.a3 on Windows 7 with Python 2.5.4, and get this error whenever I use glCompileShader():
  File "opengl.py", line 97, in main
    glCompileShader(self.basicVert)
  File "C:\Python25\Lib\site-packages\OpenGL\GL\VERSION\GL_2_0.py", line 98, in
GLSLCheckError
    getter( cArguments[0], key, ctypes.byref(status))
  File "C:\Python25\Lib\site-packages\OpenGL\lazywrapper.py", line 19, in __call
__
    return wrapper( baseFunction, *args, **named )
TypeError: glGetShaderiv() takes exactly 3 arguments (4 given)

Seems to be similar to bug #2645723

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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-07 23:22

Message:
Thanks for the bug report.  Should be fixed in trunk and released with the
3.0.1b1 release.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2882405 ] glGetActiveUniform broken.

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

Bugs item #2882405, was opened at 2009-10-20 11:11
Message generated for change (Settings changed) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2882405&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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Vickenty Fesunov (kent_turbo)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: glGetActiveUniform broken.

Initial Comment:
glGetActiveUniform wrapper in GL/VERSION/GL_2_0.py uses size variable to derive name length, which is incorrent. That variable contains size of the uniform itself, not the name length. Name length is returned separately in length parameter, which is not used in the wrapper.

It also calls glGetShaderiv with GL_OBJECT_ACTIVE_UNIFORMS and GL_OBJECT_ACTIVE_UNIFORM_MAX_LENGTH, which results in invalid operation exception. The right entry-point for this would be glGetProgramiv.

This problem occurs on both Intel (Mesa 7.6 DRI) and NVidia (174.14.09) hardware. Unfortunately, I can test it only on Linux.

Attached script fails on a unpatched fresh bzr branch of the lp:pyopengl, and works correctly with patch.

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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-07 02:01

Message:
Thank you.  Patch is integrated into trunk and will be released with the
first beta.  I've applied similar code to the ARB version of the operation.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2882405 ] glGetActiveUniform broken.

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

Bugs item #2882405, was opened at 2009-10-20 19:11
Message generated for change (Tracker Item Submitted) made by kent_turbo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2882405&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: Vickenty Fesunov (kent_turbo)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: glGetActiveUniform broken.

Initial Comment:
glGetActiveUniform wrapper in GL/VERSION/GL_2_0.py uses size variable to derive name length, which is incorrent. That variable contains size of the uniform itself, not the name length. Name length is returned separately in length parameter, which is not used in the wrapper.

It also calls glGetShaderiv with GL_OBJECT_ACTIVE_UNIFORMS and GL_OBJECT_ACTIVE_UNIFORM_MAX_LENGTH, which results in invalid operation exception. The right entry-point for this would be glGetProgramiv.

This problem occurs on both Intel (Mesa 7.6 DRI) and NVidia (174.14.09) hardware. Unfortunately, I can test it only on Linux.

Attached script fails on a unpatched fresh bzr branch of the lp:pyopengl, and works correctly with patch.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2873839 ] importing GL fails in 64bit Windows7

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

Bugs item #2873839, was opened at 2009-10-07 02:27
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2873839&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: importing GL fails in 64bit Windows7

Initial Comment:
On a Windows 7 64 bit machine
using:
- eclipse 
- pydev
- PyQt4
- Python 3.1
with only(in __init__.py):

"from OpenGL import GL"

the following error message is displayed on console:

"
Traceback (most recent call last):
  File "C:\Users\MyUserName\workspace\MyTest\src\root\__init__.py", line 1, in <module>
    from OpenGL import GL
  File "C:\Python31\lib\site-packages\OpenGL\GL\__init__.py", line 2, in <module>
    from OpenGL.raw.GL import *
  File "C:\Python31\lib\site-packages\OpenGL\raw\GL\__init__.py", line 6, in <module>
    from OpenGL.raw.GL.constants import *
  File "C:\Python31\lib\site-packages\OpenGL\raw\GL\constants.py", line 7, in <module>
    from OpenGL import platform, arrays
  File "C:\Python31\lib\site-packages\OpenGL\platform\__init__.py", line 36, in <module>
    _load()
  File "C:\Python31\lib\site-packages\OpenGL\platform\__init__.py", line 27, in _load
    plugin_class = plugin.load()
  File "C:\Python31\lib\site-packages\OpenGL\plugins.py", line 14, in load
    return importByName( self.import_path )
  File "C:\Python31\lib\site-packages\OpenGL\plugins.py", line 28, in importByName
    module = __import__( ".".join(moduleName), {}, {}, moduleName)
  File "C:\Python31\lib\site-packages\OpenGL\platform\win32.py", line 19
    except WindowsError, err:
                       ^
SyntaxError: invalid syntax
"

Running the same code through pydev/eclipse on a windows98 machine with Python 2.5 works fine.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-2872257 ] glutInit fails on windows 64-bit

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

Bugs item #2872257, was opened at 2009-10-03 10:29
Message generated for change (Tracker Item Submitted) made by reirrac
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2872257&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: GLUT
Group: v3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jason G (reirrac)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: glutInit fails on windows 64-bit

Initial Comment:
On a 64-bit Windows 7 machine, GLUT fails on glutInit with the following traceback:

Traceback (most recent call last):
  File "C:\Programming\NE\HyperNEAT\HyperNEAT_Visualizer\src\HyperNEATVisualizer.py", line 287, in <module>
    visualizer.main()
  File "C:\Programming\NE\HyperNEAT\HyperNEAT_Visualizer\src\HyperNEATVisualizer.py", line 233, in main
    glutInit(sys.argv)
  File "c:\Python26\Lib\site-packages\OpenGL\GLUT\special.py", line 322, in glutInit
    _base_glutInit( ctypes.byref(count), holder )
TypeError: 'NoneType' object is not callable


I tried copying the glut and gle dll's to my c:\windows\system32\ directory but that didn't change anything.

If I comment out the glutInit function, I get this:

Traceback (most recent call last):
  File "C:\Programming\NE\HyperNEAT\HyperNEAT_Visualizer\src\HyperNEATVisualizer.py", line 287, in <module>
    visualizer.main()
  File "C:\Programming\NE\HyperNEAT\HyperNEAT_Visualizer\src\HyperNEATVisualizer.py", line 240, in main
    glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GLUT_ALPHA | GLUT_DEPTH)
  File "c:\Python26\Lib\site-packages\OpenGL\platform\baseplatform.py", line 336, in __call__
    self.__name__, self.__name__,
OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling

I get the same error with any of the NeHe opengl lesson code.  It works fine on my linux machine and my windows 32-bit machine, so I think it's something to do with windows 64-bit.  Are there 64-bit versions of the glut and gle DLLs?

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

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