pyopengl-devel Mailing List for PyOpenGL (Page 11)
Brought to you by:
mcfletch
Menu
▾
▴
pyopengl-devel — Discussion of PyOpenGL development.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(4) |
Nov
(9) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(1) |
Feb
(6) |
Mar
(3) |
Apr
(5) |
May
(10) |
Jun
(6) |
Jul
(10) |
Aug
|
Sep
(3) |
Oct
(9) |
Nov
(20) |
Dec
(31) |
| 2003 |
Jan
(36) |
Feb
(44) |
Mar
(16) |
Apr
(35) |
May
(59) |
Jun
(17) |
Jul
(11) |
Aug
(14) |
Sep
(9) |
Oct
(29) |
Nov
(10) |
Dec
(5) |
| 2004 |
Jan
(17) |
Feb
(8) |
Mar
(6) |
Apr
(3) |
May
(4) |
Jun
(2) |
Jul
(42) |
Aug
(7) |
Sep
(17) |
Oct
(32) |
Nov
(7) |
Dec
(5) |
| 2005 |
Jan
(11) |
Feb
(11) |
Mar
(7) |
Apr
(8) |
May
(3) |
Jun
(3) |
Jul
(3) |
Aug
(5) |
Sep
|
Oct
(2) |
Nov
(5) |
Dec
(1) |
| 2006 |
Jan
(1) |
Feb
(2) |
Mar
(5) |
Apr
(6) |
May
(9) |
Jun
(6) |
Jul
(7) |
Aug
(8) |
Sep
(8) |
Oct
(23) |
Nov
(29) |
Dec
(5) |
| 2007 |
Jan
(4) |
Feb
(3) |
Mar
(7) |
Apr
(10) |
May
(7) |
Jun
(12) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(5) |
Nov
(6) |
Dec
(3) |
| 2008 |
Jan
(38) |
Feb
(10) |
Mar
(3) |
Apr
(13) |
May
(8) |
Jun
(12) |
Jul
(6) |
Aug
(3) |
Sep
(2) |
Oct
(7) |
Nov
(21) |
Dec
(1) |
| 2009 |
Jan
(7) |
Feb
(8) |
Mar
(4) |
Apr
(6) |
May
(4) |
Jun
(4) |
Jul
(38) |
Aug
(4) |
Sep
|
Oct
(3) |
Nov
(16) |
Dec
|
| 2010 |
Jan
(4) |
Feb
(17) |
Mar
(2) |
Apr
(6) |
May
(1) |
Jun
(4) |
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
(10) |
Nov
(3) |
Dec
(8) |
| 2011 |
Jan
|
Feb
(2) |
Mar
|
Apr
(6) |
May
(3) |
Jun
(19) |
Jul
(6) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
(6) |
Dec
(6) |
| 2012 |
Jan
(8) |
Feb
(3) |
Mar
(26) |
Apr
(12) |
May
(2) |
Jun
(8) |
Jul
(6) |
Aug
(4) |
Sep
(1) |
Oct
(10) |
Nov
(5) |
Dec
(1) |
| 2013 |
Jan
(2) |
Feb
(5) |
Mar
(1) |
Apr
(3) |
May
(6) |
Jun
|
Jul
(7) |
Aug
|
Sep
(4) |
Oct
(1) |
Nov
(4) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: René D. <re...@gm...> - 2009-08-28 14:55:24
|
Hi, can we remove all of the tabs from pyopengl, and replace them with 4 spaces? Most python code uses no tabs and 4 spaces instead, and pep8 recommends it. |
|
From: Ben De L. <bd...@gm...> - 2009-08-26 16:39:38
|
I found an issue accessing GL.glGetActiveUniform the patch bellow fixes the issue accessing GL_OBJECT_ACTIVE_UNIFORMS === modified file 'OpenGL/GL/VERSION/GL_2_0.py' --- OpenGL/GL/VERSION/GL_2_0.py 2009-07-19 03:44:43 +0000 +++ OpenGL/GL/VERSION/GL_2_0.py 2009-08-26 16:13:10 +0000 @@ -13,6 +13,8 @@ import OpenGL from OpenGL.raw.GL.ARB.shader_objects import GL_OBJECT_COMPILE_STATUS_ARB as GL_OBJECT_COMPILE_STATUS from OpenGL.raw.GL.ARB.shader_objects import GL_OBJECT_LINK_STATUS_ARB as GL_OBJECT_LINK_STATUS +from OpenGL.raw.GL.ARB.shader_objects import GL_OBJECT_ACTIVE_UNIFORMS_ARB as GL_OBJECT_ACTIVE_UNIFORMS + from OpenGL.GL.ARB.shader_objects import glGetInfoLogARB as glGetInfoLog from OpenGL.lazywrapper import lazy |
|
From: SourceForge.net <no...@so...> - 2009-08-25 11:18:38
|
Bugs item #2844174, was opened at 2009-08-25 23:18 Message generated for change (Tracker Item Submitted) made by ljbade 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2844174&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-08-02 22:33:33
|
Bugs item #2829309, was opened at 2009-07-29 19:02 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&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: Luca Bruno (lethalman) Assigned to: Mike C. Fletcher (mcfletch) Summary: glCallLists calls lists twice Initial Comment: Hello, I'm using pyopengl 3.0.0~c1 from debian and mesa 7.6 from git. I'm almost pretty sure that glCallLists ([1]) calls the list 1 twice, so it happens for more than one list. Reproduce as follows: 1. glRenderMode(GL_SELECT) 2. ... glCallLists([1]) 3. glRenderMode(GL_RENDER) If the list 1 pushed only one name, you get two hits. This doesn't happen if you glCallList(1), you only get one hit as expected. I'm currently doing (glCallList(list) for list in lists) instead of glCallLists as temporarly workaround. I don't know if this happens with C++ directly, couldn't test so I've reported it here. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-08-02 18:33 Message: Not getting records was just because of interference from previous test case for the same problem (duh!) With current test case I pass on both Win32 and Linux AMD64 (two different Linux AMD64 machines, with ATI and nVidia cards). Test case is in the 3.0.1a2 release if you wish to download that and test on your machine (tests/test_core.py script). ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-30 10:34 Message: Hmm, I'm seeing exactly the same behaviour from both call-types, namely I'm not getting any records at all (just ([],) don't have time to investigate why just now. ---------------------------------------------------------------------- Comment By: Luca Bruno (lethalman) Date: 2009-07-30 01:41 Message: I rectify, it happens with GL_COMPILE_AND_EXECUTE (not necessary other lists) and glCallLists must be in a list to call other lists: glMatrixMode(GL_PROJECTION) glLoadIdentity() gluPerspective(40.0, 1.0, 1.0, 10.0) glTranslatef (0, 0, -3) glMatrixMode (GL_MODELVIEW) glLoadIdentity () glNewList(1, GL_COMPILE_AND_EXECUTE) glInitNames () glCallLists([2]) # replace with gCallList(2) glEndList () glNewList(2, GL_COMPILE) glPushName (1) glBegin (GL_POINTS) glVertex3f (0, 0, 0) glEnd () glPopName () glEndList () glSelectBuffer (100) glRenderMode (GL_SELECT) glCallList(1) print glRenderMode (GL_RENDER) ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-30 00:53 Message: I can't replicate this failure condition. I am using this code, on an Ubuntu 3.0.1 Jaunty Linux Box with current BZR head of PyOpenGL: def test_glCallLists_twice( self ): """SF#2829309 report that glCallLists doubles operation""" l = glGenLists(1) try: glEnd() except error.GLerror, err: pass glSelectBuffer( 23 ) glRenderMode( GL_SELECT ) glNewList( l, GL_COMPILE ) glPushName( 222 ) glEndList() depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (0,), depth # shouldn't have added in compile mode glCallLists( [l] ) depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (1,), depth # should have a single record glCallLists( [l] ) depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (2,), depth # should have a second (identical) record glPopName() glPopName() glRenderMode( GL_RENDER ) which test passes. Please provide a test that fails on your platform so I can test whether we're looking at a bug that was fixed in the meantime or an error in usage or a subtle corner case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-30 14:34:22
|
Bugs item #2829309, was opened at 2009-07-29 19:02 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&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: Luca Bruno (lethalman) Assigned to: Mike C. Fletcher (mcfletch) Summary: glCallLists calls lists twice Initial Comment: Hello, I'm using pyopengl 3.0.0~c1 from debian and mesa 7.6 from git. I'm almost pretty sure that glCallLists ([1]) calls the list 1 twice, so it happens for more than one list. Reproduce as follows: 1. glRenderMode(GL_SELECT) 2. ... glCallLists([1]) 3. glRenderMode(GL_RENDER) If the list 1 pushed only one name, you get two hits. This doesn't happen if you glCallList(1), you only get one hit as expected. I'm currently doing (glCallList(list) for list in lists) instead of glCallLists as temporarly workaround. I don't know if this happens with C++ directly, couldn't test so I've reported it here. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-30 10:34 Message: Hmm, I'm seeing exactly the same behaviour from both call-types, namely I'm not getting any records at all (just ([],) don't have time to investigate why just now. ---------------------------------------------------------------------- Comment By: Luca Bruno (lethalman) Date: 2009-07-30 01:41 Message: I rectify, it happens with GL_COMPILE_AND_EXECUTE (not necessary other lists) and glCallLists must be in a list to call other lists: glMatrixMode(GL_PROJECTION) glLoadIdentity() gluPerspective(40.0, 1.0, 1.0, 10.0) glTranslatef (0, 0, -3) glMatrixMode (GL_MODELVIEW) glLoadIdentity () glNewList(1, GL_COMPILE_AND_EXECUTE) glInitNames () glCallLists([2]) # replace with gCallList(2) glEndList () glNewList(2, GL_COMPILE) glPushName (1) glBegin (GL_POINTS) glVertex3f (0, 0, 0) glEnd () glPopName () glEndList () glSelectBuffer (100) glRenderMode (GL_SELECT) glCallList(1) print glRenderMode (GL_RENDER) ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-30 00:53 Message: I can't replicate this failure condition. I am using this code, on an Ubuntu 3.0.1 Jaunty Linux Box with current BZR head of PyOpenGL: def test_glCallLists_twice( self ): """SF#2829309 report that glCallLists doubles operation""" l = glGenLists(1) try: glEnd() except error.GLerror, err: pass glSelectBuffer( 23 ) glRenderMode( GL_SELECT ) glNewList( l, GL_COMPILE ) glPushName( 222 ) glEndList() depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (0,), depth # shouldn't have added in compile mode glCallLists( [l] ) depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (1,), depth # should have a single record glCallLists( [l] ) depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (2,), depth # should have a second (identical) record glPopName() glPopName() glRenderMode( GL_RENDER ) which test passes. Please provide a test that fails on your platform so I can test whether we're looking at a bug that was fixed in the meantime or an error in usage or a subtle corner case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-30 05:41:03
|
Bugs item #2829309, was opened at 2009-07-30 01:02 Message generated for change (Comment added) made by lethalman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&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: Luca Bruno (lethalman) Assigned to: Mike C. Fletcher (mcfletch) Summary: glCallLists calls lists twice Initial Comment: Hello, I'm using pyopengl 3.0.0~c1 from debian and mesa 7.6 from git. I'm almost pretty sure that glCallLists ([1]) calls the list 1 twice, so it happens for more than one list. Reproduce as follows: 1. glRenderMode(GL_SELECT) 2. ... glCallLists([1]) 3. glRenderMode(GL_RENDER) If the list 1 pushed only one name, you get two hits. This doesn't happen if you glCallList(1), you only get one hit as expected. I'm currently doing (glCallList(list) for list in lists) instead of glCallLists as temporarly workaround. I don't know if this happens with C++ directly, couldn't test so I've reported it here. ---------------------------------------------------------------------- >Comment By: Luca Bruno (lethalman) Date: 2009-07-30 07:41 Message: I rectify, it happens with GL_COMPILE_AND_EXECUTE (not necessary other lists) and glCallLists must be in a list to call other lists: glMatrixMode(GL_PROJECTION) glLoadIdentity() gluPerspective(40.0, 1.0, 1.0, 10.0) glTranslatef (0, 0, -3) glMatrixMode (GL_MODELVIEW) glLoadIdentity () glNewList(1, GL_COMPILE_AND_EXECUTE) glInitNames () glCallLists([2]) # replace with gCallList(2) glEndList () glNewList(2, GL_COMPILE) glPushName (1) glBegin (GL_POINTS) glVertex3f (0, 0, 0) glEnd () glPopName () glEndList () glSelectBuffer (100) glRenderMode (GL_SELECT) glCallList(1) print glRenderMode (GL_RENDER) ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-30 06:53 Message: I can't replicate this failure condition. I am using this code, on an Ubuntu 3.0.1 Jaunty Linux Box with current BZR head of PyOpenGL: def test_glCallLists_twice( self ): """SF#2829309 report that glCallLists doubles operation""" l = glGenLists(1) try: glEnd() except error.GLerror, err: pass glSelectBuffer( 23 ) glRenderMode( GL_SELECT ) glNewList( l, GL_COMPILE ) glPushName( 222 ) glEndList() depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (0,), depth # shouldn't have added in compile mode glCallLists( [l] ) depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (1,), depth # should have a single record glCallLists( [l] ) depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (2,), depth # should have a second (identical) record glPopName() glPopName() glRenderMode( GL_RENDER ) which test passes. Please provide a test that fails on your platform so I can test whether we're looking at a bug that was fixed in the meantime or an error in usage or a subtle corner case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-30 04:53:20
|
Bugs item #2829309, was opened at 2009-07-29 19:02 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&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: Luca Bruno (lethalman) Assigned to: Mike C. Fletcher (mcfletch) Summary: glCallLists calls lists twice Initial Comment: Hello, I'm using pyopengl 3.0.0~c1 from debian and mesa 7.6 from git. I'm almost pretty sure that glCallLists ([1]) calls the list 1 twice, so it happens for more than one list. Reproduce as follows: 1. glRenderMode(GL_SELECT) 2. ... glCallLists([1]) 3. glRenderMode(GL_RENDER) If the list 1 pushed only one name, you get two hits. This doesn't happen if you glCallList(1), you only get one hit as expected. I'm currently doing (glCallList(list) for list in lists) instead of glCallLists as temporarly workaround. I don't know if this happens with C++ directly, couldn't test so I've reported it here. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-30 00:53 Message: I can't replicate this failure condition. I am using this code, on an Ubuntu 3.0.1 Jaunty Linux Box with current BZR head of PyOpenGL: def test_glCallLists_twice( self ): """SF#2829309 report that glCallLists doubles operation""" l = glGenLists(1) try: glEnd() except error.GLerror, err: pass glSelectBuffer( 23 ) glRenderMode( GL_SELECT ) glNewList( l, GL_COMPILE ) glPushName( 222 ) glEndList() depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (0,), depth # shouldn't have added in compile mode glCallLists( [l] ) depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (1,), depth # should have a single record glCallLists( [l] ) depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (2,), depth # should have a second (identical) record glPopName() glPopName() glRenderMode( GL_RENDER ) which test passes. Please provide a test that fails on your platform so I can test whether we're looking at a bug that was fixed in the meantime or an error in usage or a subtle corner case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-29 23:02:56
|
Bugs item #2829309, was opened at 2009-07-30 01:02 Message generated for change (Tracker Item Submitted) made by lethalman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&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: Luca Bruno (lethalman) Assigned to: Mike C. Fletcher (mcfletch) Summary: glCallLists calls lists twice Initial Comment: Hello, I'm using pyopengl 3.0.0~c1 from debian and mesa 7.6 from git. I'm almost pretty sure that glCallLists ([1]) calls the list 1 twice, so it happens for more than one list. Reproduce as follows: 1. glRenderMode(GL_SELECT) 2. ... glCallLists([1]) 3. glRenderMode(GL_RENDER) If the list 1 pushed only one name, you get two hits. This doesn't happen if you glCallList(1), you only get one hit as expected. I'm currently doing (glCallList(list) for list in lists) instead of glCallLists as temporarly workaround. I don't know if this happens with C++ directly, couldn't test so I've reported it here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 04:21:52
|
Patches item #1827167, was opened at 2007-11-06 16:45 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=1827167&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 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Chris Waters (crwaters) Assigned to: Nobody/Anonymous (nobody) Summary: glGet Constant Sizes for EXT_framebuffer_object Initial Comment: Added glGet sizes to states defined in EXT_framebuffer_object. The following constants were given sizes: GL_MAX_RENDERBUFFER_SIZE_EXT GL_FRAMEBUFFER_BINDING_EXT GL_RENDERBUFFER_BINDING_EXT GL_MAX_COLOR_ATTACHMENTS_EXT Sizes were added to: src/glgetsizes.csv Updated OpenGL/raw/GL/EXT/framebuffer_object.py using: src/get_gl_extensions.py ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-19 00:21 Message: Sorry, this patch was missed. The constants are all in current bzr head with glget registrations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=1827167&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 04:17:36
|
Patches item #2481940, was opened at 2009-01-02 01:49 Message generated for change (Settings changed) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=2481940&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 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Rafe Kaplan (slobberchops) Assigned to: Nobody/Anonymous (nobody) Summary: Library error on Mac using case sensitive file-system Initial Comment: OpenGL/platform/darwin.py:46 The string passed in to ctypesloader.loadlibrary is 'glut'. It should be 'GLUT'. The causes problems on Mac installations that use a case-sensitive file system. Not a problem on most Mac installations. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-19 00:17 Message: Branch was merged. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-02-02 20:30 Message: committed a fix to my branch https://code.launchpad.net/~illume/pyopengl/pyopengl.illume ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=2481940&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 03:09:38
|
Bugs item #2079402, was opened at 2008-08-27 19:32 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2079402&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: GLE Group: v3.0.0 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 'DarwinPlatform' object has no attribute 'getExtensionProced Initial Comment: More specifically, I get this sequence of error messages File "/Users/woolford/EMAN2/lib/emimage2d.py", line 721, in render GL.glBlendEquation(GL.GL_FUNC_SUBTRACT); File "/Library/Python/2.5/site-packages/PyOpenGL-3.0.0b5-py2.5.egg/OpenGL/platform/baseplatform.py", line 296, in __call__ if self.extension and self.load(): File "/Library/Python/2.5/site-packages/PyOpenGL-3.0.0b5-py2.5.egg/OpenGL/platform/baseplatform.py", line 275, in load pointer = platform.PLATFORM.getExtensionProcedure( AttributeError: 'DarwinPlatform' object has no attribute 'getExtensionProcedure' ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 22:32 Message: bzr head seems to have been fixed to not call getExtensionProcedure on Mac. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2079402&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 02:44:11
|
Bugs item #1737282, was opened at 2007-06-14 11:38 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1737282&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Seg fault on Ubuntu Fiesty x86-64 - 3.0.0a6 Initial Comment: With Python 2.5,Python-2.5.tar.bz2 numpy, numpy-1.0.tar.gz PyOpenGL, PyOpenGL-3.0.0a6.tar.gz OpenGL-ctypes/OpenGL/tests$ python test_glutwindow.py newArguments ['test_glutwindow.py'] Segmentation fault (core dumped) This occurs on line 78 glutInitDisplayMode( GLUT_DOUBLE | GLUT_RGB ) ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 22:44 Message: Error checking on GLUT functions was causing these issues, glut error checking is disabled for the 3.0.1 (upcoming) release. See the LaunchPad bug for more discussions. ---------------------------------------------------------------------- Comment By: David O'Gwynn (dogwynn) Date: 2009-01-15 17:03 Message: ACK! Forgot to include stack dump of PyOpenGL crapping out.... (PyOpenGL 3.0.0b6) Backtrace from gdb: >>] gdb python GNU gdb Red Hat Linux (6.5-37.el5_2.2rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/libthread_db.so.1". (gdb) run Starting program: /.../dogwynn/bin/python [Thread debugging using libthread_db enabled] Python 2.6 (r26:66714, Nov 21 2008, 10:53:09) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2 Type "help", "copyright", "credits" or "license" for more information. [New Thread 47200948283808 (LWP 29788)] >>> from OpenGL.GLUT import * [Detaching after fork from child process 29791. (Try `set detach-on-fork off'.)] [Detaching after fork from child process 29793.] [Detaching after fork from child process 29795.] [Detaching after fork from child process 29797.] [Detaching after fork from child process 29799.] [Detaching after fork from child process 29801.] [Detaching after fork from child process 29808.] [Detaching after fork from child process 29813.] [Detaching after fork from child process 29815.] [Detaching after fork from child process 29824.] >>> glutInitDisplayMode(GLUT_SINGLE | GLUT_RGB) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47200948283808 (LWP 29788)] 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00002aedd7548ce8 in ffi_call_unix64 () at /.../dogwynn/sources/Python-2.6/Modules/_ctypes/libffi/src/x86/unix64.S:75 #2 0x00002aedd7548b34 in ffi_call (cif=0x7fffd6eac6f0, fn=0x2aedd8e3daf0 <glGetError>, rvalue=0x7fffd6eac660, avalue=0x7fffd6eac650) at /.../dogwynn/sources/Python-2.6/Modules/_ctypes/libffi/src/x86/ffi64.c:430 #3 0x00002aedd7543364 in _CallProc (pProc=0x2aedd8e3daf0 <glGetError>, argtuple=<value optimized out>, flags=<value optimized out>, argtypes=0x0, restype=0x712a740, checker=0x0) at /.../dogwynn/sources/Python-2.6/Modules/_ctypes/callproc.c:814 #4 0x00002aedd753b118 in CFuncPtr_call (self=0x71a6120, inargs=0x2aedd3c19050, kwds=0x0) at /.../dogwynn/sources/Python-2.6/Modules/_ctypes/_ctypes.c:3855 #5 0x0000000000417bbd in PyObject_Call (func=0x71a6120, arg=0x2aedd3c19050, kw=0x0) at Objects/abstract.c:2487 #6 0x0000000000490ae6 in PyEval_EvalFrameEx (f=0x729e770, throwflag=<value optimized out>) at Python/ceval.c:3890 #7 0x00000000004945e5 in PyEval_EvalCodeEx (co=0x71ba468, globals=<value optimized out>, locals=<value optimized out>, args=0x2aedd3c537a0, argcount=4, kws=0x0, kwcount=0, defs=0x71b4c80, defcount=2, closure=0x0) at Python/ceval.c:2942 #8 0x00000000004ea41d in function_call (func=0x71bab90, arg=0x2aedd3c53788, kw=0x0) at Objects/funcobject.c:524 #9 0x0000000000417bbd in PyObject_Call (func=0x71bab90, arg=0x2aedd3c53788, kw=0x0) at Objects/abstract.c:2487 #10 0x000000000041ef4f in instancemethod_call (func=<value optimized out>, arg=0x2aedd3c53788, kw=0x0) at Objects/classobject.c:2579 #11 0x0000000000417bbd in PyObject_Call (func=0x2aedd8391730, arg=0x2aedd3cebaf0, kw=0x0) at Objects/abstract.c:2487 #12 0x000000000041a96f in PyObject_CallFunctionObjArgs ( callable=0x2aedd8391730) at Objects/abstract.c:2718 #13 0x00002aedd753b148 in CFuncPtr_call (self=0x7225390, inargs=0x1, kwds=0x0) at /.../dogwynn/sources/Python-2.6/Modules/_ctypes/_ctypes.c:3871 #14 0x0000000000417bbd in PyObject_Call (func=0x7225390, arg=0x2aedd3c4bc50, kw=0x0) at Objects/abstract.c:2487 ---Type <return> to continue, or q <return> to quit--- #15 0x0000000000490ae6 in PyEval_EvalFrameEx (f=0x7293e60, throwflag=<value optimized out>) at Python/ceval.c:3890 #16 0x00000000004945e5 in PyEval_EvalCodeEx (co=0x2aedd3ce1af8, globals=<value optimized out>, locals=<value optimized out>, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2942 #17 0x0000000000494622 in PyEval_EvalCode (co=0x0, globals=0x2aedd3c16a70, locals=0x3b30015280) at Python/ceval.c:515 #18 0x00000000004b629d in PyRun_InteractiveOneFlags (fp=<value optimized out>, filename=0x5029b7 "<stdin>", flags=0x7fffd6ead420) at Python/pythonrun.c:1330 #19 0x00000000004b64c4 in PyRun_InteractiveLoopFlags (fp=0x3b2f54d680, filename=0x5029b7 "<stdin>", flags=0x7fffd6ead420) at Python/pythonrun.c:756 #20 0x00000000004b65ca in PyRun_AnyFileExFlags (fp=0x3b2f54d680, filename=0x5029b7 "<stdin>", closeit=0, flags=0x7fffd6ead420) at Python/pythonrun.c:725 #21 0x0000000000413d2f in Py_Main (argc=<value optimized out>, argv=0x7fffd6ead548) at Modules/main.c:597 #22 0x0000003b2f21d8b4 in __libc_start_main () from /lib64/libc.so.6 #23 0x0000000000412f99 in _start () (gdb) ---------------------------------------------------------------------- Comment By: David O'Gwynn (dogwynn) Date: 2009-01-15 17:01 Message: Confirm that this causing problem on CentOS as well. -------------------------------- Background -------------------------------- >>] uname -a Linux ... 2.6.18-92.el5 #1 SMP Tue Jun 10 18:51:06 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux >>] /sbin/lspci | grep VGA 01:00.0 VGA compatible controller: nVidia Corporation NV41GL [Quadro FX 1400] (rev a2) >>] lsb_release -rd Description: CentOS release 5.2 (Final) Release: 5.2 -------------------------------- This is a problem with PyOpenGL's wrapping of glut/freeglut somehow. The functions can be called directly via ctypes with no errors on my system. >>] python Python 2.6 (r26:66714, Nov 21 2008, 10:53:09) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import * >>> glut = cdll.LoadLibrary('libglut.so') >>> glut.glutInit(pointer(c_int(0)),pointer(c_char_p(''))) 234 >>> glut.glutInitDisplayMode(c_int(2)) # GLUT_DOUBLE | GLUT_RGB 344264064 >>> wID = glut.glutCreateWindow(c_char_p('test window')) freeglut Unable to create direct context rendering for window 'test window' This may hurt performance. >>> print wID 1 >>> This correctly initializes a rendering context and pops up a window. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-01-06 19:15 Message: this also happened to me on Ubuntu 32bit. The problem was calling "glutInitDisplayMode" before "glutCreateWindow". If you call it the other way round it works. For more info look at launchpad: https://bugs.edge.launchpad.net/debian/+source/pyopengl/+bug/289925 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-07-09 00:54 Message: Logged In: NO I receive the segmentation fault on my 64 bit Hardy Heron on an AMD64-2x, but it happens at the import OpenGL.GL statement, and it goes away if I run as root: 'sudo python test_glutwindow.py'. I have tried to reinstall all opengl components but it still segfaults on import OpenGL.GL. ---------------------------------------------------------------------- Comment By: hippodriver (hippodriver) Date: 2008-05-03 06:34 Message: Logged In: YES user_id=1981020 Originator: NO I get the same error on Fedora 9 AMD64 and Arch Linux ia32. Here are the library versions: a) Fedora 9 - PyOpenGL-3.0.0-0.5.b1.fc9.noarch - freeglut-2.4.0-14.fc9.x86_64 - python-2.5.1-25.fc9.x86_64 b) Arch Linux 03052008 - python 2.5.2-2 - python-opengl 3.0.0b1-1 - freeglut 2.4.0-3 ---------------------------------------------------------------------- Comment By: hippodriver (hippodriver) Date: 2008-05-03 05:16 Message: Logged In: YES user_id=1981020 Originator: NO I get the same error on Fedora 9 AMD64 and Arch Linux ia32. Here are the library versions: a) Fedora 9 - PyOpenGL-3.0.0-0.5.b1.fc9.noarch - freeglut-2.4.0-14.fc9.x86_64 - python-2.5.1-25.fc9.x86_64 b) Arch Linux 03052008 - python 2.5.2-2 - python-opengl 3.0.0b1-1 - freeglut 2.4.0-3 ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-04-06 20:45 Message: Logged In: YES user_id=34901 Originator: NO I can't reproduce the bug on a 64-bit Gentoo AMD64 machine running Python 2.5.1 and current CVS head against media-libs/freeglut-2.4.0-r1 . That is, the script runs here (I develop on this amd64 Gentoo box normally). Can you give more details about your library versions? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-10-25 06:58 Message: Logged In: NO What's going on this bug is still present in Ubuntu Gutsy (64 bits version), are pyopengl abandoned? or is there a secret bugfix? Nothing has happened with this bug for 4 month. A segfault on 64-bits Linux has to be considered a quite severe bug. I'm very new to Python but I need it for a course in 3d rendering at school so if there is some debugging I can do please let me know, but I think it's quite easy to reproduce. /Björn ---------------------------------------------------------------------- Comment By: Gary Orser (orser) Date: 2007-06-14 13:53 Message: Logged In: YES user_id=82696 Originator: NO Forgot to add: The script I used to build this python, generates a python that doesn't seg fault on Fiesty 32bit. It also seg faults, on SuSE 10.1 64 bit. This must be some sort of 64 bit issue. ---------------------------------------------------------------------- Comment By: Gary Orser (orser) Date: 2007-06-14 11:48 Message: Logged In: YES user_id=82696 Originator: NO Forgot to add: The script I used to build this python, generates a python that doesn't seg fault on Fiesty 32bit. It also seg faults, on SuSE 10.1 64 bit. This must be some sort of 64 bit issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1737282&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 02:42:38
|
Bugs item #1827190, was opened at 2007-11-06 17:35 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1827190&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Chris Waters (crwaters) Assigned to: Mike C. Fletcher (mcfletch) Summary: Default (Numpy) array return values not accepted Initial Comment: The values returned by the default array type, numpy, are not accepted by OpenGL; more importantly, they are not accepted by the respective set/bind functions. This output is from the attached test file, run with the latest CVS revision: glGenTextures(1) -> 1 (<type 'long'>) glGenTextures(2) -> [2 3] (list: <type 'numpy.ndarray'>, elements: <type 'numpy.uint32'>) Calling: glBindTexture(GL_TEXTURE_2D, 1) (created from glGenTextures(1)) No Exceptions Calling: glBindTexture(GL_TEXTURE_2D, 2) (created from glGenTextures(2), element 0) Exception Caught: argument 2: <type 'exceptions.TypeError'>: wrong type The returned type of the array is numpy.ndarray, with each element having the type numpy.uint32. This element type is also not immediately convertable to a function argument type such as GLuint. The return type of glGenTextures(1), however, is of the type long due to the special-case functionality. This is not the case for functions that do not handle special cases similar to this, such as OpenGL.GL.EXT.framebuffer_object.glGenFramebuffersEXT A quick global work-around is to change the array type to ctypes after importing OpenGL: from OpenGL.arrays import formathandler formathandler.FormatHandler.chooseOutput( 'ctypesarrays' ) ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 22:42 Message: Since 2.5.2 and 2.6 are fixed, I'm going to call this closed. ---------------------------------------------------------------------- Comment By: Giovanni Bajo (giovannibajo) Date: 2008-02-24 19:59 Message: Logged In: YES user_id=727687 Originator: NO Right, I saw this in Python 2.5.2 changelog: - The ctypes int types did not accept objects implementing __int__() in the constructor. Nice to see this bug squashed then (it was really annoying to debug because numpy array/integers look like python basic types in repr!). ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-02-24 18:46 Message: Logged In: YES user_id=34901 Originator: NO AFAIK the default was *never* ctypes arrays. ctypes arrays aren't generally compatible with Numpy/Numeric-assuming code, so they are far more likely to cause coding problems than Numpy scalars. Thomas has fixed the bug in ctypes (which wasn't calling __int__ on the values), so with the next point release of Python we should see the problem fix itself. ---------------------------------------------------------------------- Comment By: Giovanni Bajo (giovannibajo) Date: 2008-02-24 18:12 Message: Logged In: YES user_id=727687 Originator: NO Thus, can't we switch the default back to ctypesarrays until this is resolved (if ever)? ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-01-07 19:50 Message: Logged In: YES user_id=34901 Originator: NO Seems "pending" is considered "closed" for some reason. Reopening so it's not lost. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-01-07 19:49 Message: Logged In: YES user_id=34901 Originator: NO Hmm, maybe I'm just having a bad ctypes day, but I don't see how to take the buffer object (the proposed work-around) and convert its contents to a ctypes.c_* type. The buffer must have knowledge of its internal address, but I don't see a member that gives me access to it. Even if it did work, we'd be in the same boat with an extra Python function call introduced as overhead for every single simple data-type parameter. This needs to happen down in the C code in ctypes to have any hope of being fast enough IMO. ---------------------------------------------------------------------- Comment By: Andrew Straw (astraw) Date: 2008-01-07 16:54 Message: Logged In: YES user_id=210276 Originator: NO I forwarded this bug report to the numpy-discussion list, where a bugfix was implemented and workaround was discussed: http://projects.scipy.org/pipermail/numpy-discussion/2008-January/030670.html ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-01-07 13:32 Message: Logged In: YES user_id=34901 Originator: NO I've added an optional flag to the top-level module which allows for using numpy scalars. ALLOW_NUMPY_SCALARS which when true allows your test case to succeed. Coded in Python, however, it's rather slow (and rather poorly implemented). I looked into implementing this using the __array_interface__ on scalars, but the data-pointer there appears to be randomly generated. Without that, a conversion at the Python level and then passing onto the original function seems the only solution. I doubt we'll get a *good* solution to this in the near term. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1827190&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 02:41:35
|
Bugs item #1887247, was opened at 2008-02-05 15:27 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1887247&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: install Group: v2.0.1 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Neppord (neppord) Assigned to: Nobody/Anonymous (nobody) Summary: Install error on Mac OS X Initial Comment: There is an error in the newest darwin.py file there is a "GLUT" that should be "glut". ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 22:41 Message: Branch was merged. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-02-02 20:41 Message: This is fixed in my branch: bzr co https://code.launchpad.net/~illume/pyopengl/pyopengl.illume cheers, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1887247&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 02:41:00
|
Bugs item #1854632, was opened at 2007-12-20 00:07 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1854632&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: GLU Group: v3.0.0 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: gluTessVertex function take wrong data Initial Comment: Windows XP 32bit, Python2.5.1 When running tests.py in PyOpenGL3.0.0b1 from cvs, I got the flowing output: .........error 12590456 E. ====================================================================== ERROR: Test that tessellation works ---------------------------------------------------------------------- Traceback (most recent call last): File "E:\home\tests.py", line 225, in test_tess gluTessEndPolygon(tobj); WindowsError: exception code 0xc01d78 ---------------------------------------------------------------------- Ran 11 tests in 3.469s FAILED (errors=1) I'm sure that it's caused by a bug in gluTessVertex function. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 22:40 Message: We've got working tess operations in a number of codebases, so I'm guessing we're out-of-date here. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-01-07 10:32 Message: Logged In: YES user_id=34901 Originator: NO There was at least one major bug in the gluTess* functions (wrong ctypes-level function type) which would cause win32 failures, which is fixed in the first beta. We're still seeing occasional failures on win32 tessellation, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1854632&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 02:39:49
|
Bugs item #1869877, was opened at 2008-01-12 05:40 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1869877&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: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Mike C. Fletcher (mcfletch) Summary: glColorPointer/ glVertexPointer broken Initial Comment: This might be related to bug 1067130, but I'm not sure, mark duplicate if needed. In the attached script, the polygon is often miscoloured, or lacks vertexes. If I disable GL_COLOR_ARRAY, vertexes draw fine. >From what I get it seems that calling glColorPointer overwrites some data in vertex pointer and/or vice versa. I get distorted views like http://img292.imageshack.us/img292/5295/bugwd1.jpg, while I should get the full polygon. If I change the order of functions artifacts change too and sometimes disappear, but nothing predictable. The similar program in C runs fine, so it is unlikely to be a driver issue. System used: Ubuntu Linux, kernel 2.6.22 pyopengl 3.0.0 Python 2.5.1 ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 22:39 Message: This does appear to have been the problem, closing. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-01-19 11:46 Message: Logged In: YES user_id=34901 Originator: NO With current CVS I can't reproduce the problem. I'm guessing this was the same bug as fixed a while ago where the two arrays were both getting stored as floats and the caching code was storing them using their type rather than their role. ---------------------------------------------------------------------- Comment By: Vytas (vytaslt) Date: 2008-01-12 05:44 Message: Logged In: YES user_id=1979684 Originator: NO I am the submitter just forgot to login ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1869877&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 02:38:44
|
Bugs item #1878648, was opened at 2008-01-23 22:05 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1878648&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: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: tkerwin (tkerwin) Assigned to: Nobody/Anonymous (nobody) Summary: glShaderSource wrapper not loaded properly Initial Comment: When I try to use glShaderSource, I get this error message: File "C:\Python25\Lib\site-packages\OpenGL\platform\baseplatform.py", line 253, in __call__ return self( *args, **named ) TypeError: this function takes 4 arguments (2 given) I was expecting it to require two arguments from the documentation. From glancing at the code, it seems like the wrapper is in there, but perhaps not loading properly. Is there any workaround for this to get shaders working? ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 22:38 Message: We've got many examples of working code on both Win32 and Linux, so we'll assume the fix worked. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-04-06 20:58 Message: Logged In: YES user_id=34901 Originator: NO This would be easier to debug with a test case. I'm guessing what's happening is that you are on Win32, and that at the point where you import the module, there's no glShaderSource function. As a result the wrappers were not being created. Later, when you tried to call them, the null-function wrapper was able to resolve the function and tried to call it directly. See OpenGLContext/tests/shaderobjects.py for an example that should work in this mode. Also note that I've altered the wrappers to no longer do the load-time checks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1878648&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 02:37:36
|
Bugs item #2333002, was opened at 2008-11-23 08:59 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2333002&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: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Evgeni Golov (sargentd) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault with Mesa 7.2 Initial Comment: Hi, I'm running Debian Sid with Mesa 7.2 from experimental (needed for Direct Rendering to work with my card [ATI Radeon X1400]). The following snippet produces a segfault: from OpenGL.GLUT import * glutInit(["test"]) glutInitDisplayMode(GLUT_RGB) When I downgrade Mesa to 7.0.3, I have no DRI anymore, but also the segfault goes away. I attach a backtrace from gdb, in the hope that helps somehow -- if you need more info, please ask :) Regards Evgeni ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 22:37 Message: GLUT Error checking has been disabled for PyOpenGL 3.0.1 (upcoming). ---------------------------------------------------------------------- Comment By: Evgeni Golov (sargentd) Date: 2008-11-24 15:36 Message: \o/ That works! Btw, you can find the Debian Bugreport here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483043 ---------------------------------------------------------------------- Comment By: lman (l_man) Date: 2008-11-24 15:10 Message: Here is sthing I found on the net. Hope it helps: http://asleepfromday.wordpress.com/2008/08/20/bug-in-python-opengl-mesa/ It basically suggests to turn off opengl error checking. It solves the issue ---------------------------------------------------------------------- Comment By: lman (l_man) Date: 2008-11-23 11:19 Message: I downgraded to mesa 7.0.3 and still get segmentation fault. tried it with b6 and b5 too. If i downgrade the pyopengl package to 2.0.1 everything works fine. ---------------------------------------------------------------------- Comment By: Evgeni Golov (sargentd) Date: 2008-11-23 09:08 Message: Forgot to mention, this is with pyopengl 3.0.0b6 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2333002&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 02:36:17
|
Bugs item #1892167, was opened at 2008-02-12 14:36 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1892167&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Shader related error reporting is broken Initial Comment: In pyopengl-ctypes CVS: When trying to compile an erroneous shader pyopengl returns the following error: File "/usr/lib/python2.5/site-packages/OpenGL/GL/VERSION/GL_2_0.py", line 85, in GLSLCheckError description= glGetInfoLog( cArguments[0] ) NameError: global name 'glGetInfoLog' is not defined After adding "from OpenGL.GL.ARB.shader_objects import glGetInfoLogARB as glGetInfoLog" to GL_2.0.py the following error appears: File "/usr/lib/python2.5/site-packages/OpenGL/GL/ARB/shader_objects.py", line 120, in glGetInfoLogARB log = ctypes.create_string_buffer(length) File "/usr/lib/python2.5/ctypes/__init__.py", line 73, in create_string_buffer raise TypeError, init TypeError: 220 The preceding call to glGetObjectParameterivARB returns a "length" that is of type numpy.int32 while ctypes expects long or int. After casting "length" to int, the program now throws the proper GLError. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 22:36 Message: Shader info logs are working on shader capable machines. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-04-18 16:49 Message: Logged In: YES user_id=34901 Originator: NO Don't have a shader-capable system at the moment, I've integrated the changes into CVS, guess we'll see whether they work when I get to a shader-capable machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1892167&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 02:34:16
|
Bugs item #2029134, was opened at 2008-07-27 00:14 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2029134&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: install Group: v3.0.0 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: irobot (irbotto) Assigned to: Nobody/Anonymous (nobody) Summary: error in vbo_junk.py Initial Comment: I try to install PyOpenGL-3.0.0b4 by typing "python setup.py install" it's running and display its processing status. But when it display 'Extracting PyOpenGL-3.0.0b4-py2.5.egg to g:\python25\lib\site-packages", it said one file in the sub-directory \OpenGL\arrays\vbo-junk.py" has error at line 2. And display <<<<<<< vbo.py ^ SyntaxError: invalid syntax And then it ends up. I found that I can't use PyOpenGL. I try to look at the vbo_junk.py and found that there are many unknown command like "<<<<<<< vbo" and ">>>>>>> 1.5" at various part inside the file. I don't know what is the problem here. I have install python2.5 and the latest version of ez_setup. I fail with both the command "easy_install PyOpenGL" and "python setup.py install", end up with the same screen. I have try in the WinXp and Win98 platform and end up with the same result. I am not sure whether it is it a bug or not. Just for reference. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 22:33 Message: Was fixed a while ago by removing the junk file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2029134&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 01:57:19
|
Bugs item #2130003, was opened at 2008-09-26 07:19 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2130003&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Loading GLUT on DarwinPlatform failes Initial Comment: If the file system was formatted as case sensitive (Leopard offers this option at install time), the following code will fail: from OpenGL.GLU import * with >>> from OpenGL.GLU import * Traceback (most recent call last): File "<stdin>", line 1, in <module> File "OpenGL/GLU/__init__.py", line 2, in <module> from OpenGL import platform File "OpenGL/platform/__init__.py", line 36, in <module> _load() File "OpenGL/platform/__init__.py", line 27, in _load plugin_class = plugin.load() File "OpenGL/plugins.py", line 14, in load return importByName( self.import_path ) File "OpenGL/plugins.py", line 28, in importByName module = __import__( ".".join(moduleName), {}, {}, moduleName) File "OpenGL/platform/darwin.py", line 27, in <module> class DarwinPlatform( baseplatform.BasePlatform ): File "OpenGL/platform/darwin.py", line 47, in DarwinPlatform mode=ctypes.RTLD_GLOBAL File "OpenGL/platform/ctypesloader.py", line 42, in loadLibrary return dllType( name, mode ) File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ctypes/__init__.py", line 325, in __init__ self._handle = _dlopen(self._name, mode) OSError: ('dlopen(glut, 10): image not found', 'glut', None) >>> Proposed fix: in OpenGL/platform/darwin.py change line 46 from: 'glut', to 'GLUT', this will solve the problem. ikokai <at> gmail <dot> com ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 21:57 Message: bzr head appears to have been fixed at some point. ---------------------------------------------------------------------- Comment By: Arve Knudsen (arve_knudsen) Date: 2008-11-27 05:30 Message: Regarding why it should be uppercase, I'm guessing it has to do with Mac conventions, i.e., that frameworks should be capitalized. ---------------------------------------------------------------------- Comment By: Arve Knudsen (arve_knudsen) Date: 2008-11-27 05:29 Message: I just ran into this bug too :/ Luckily it is easy to fix (hint hint). ---------------------------------------------------------------------- Comment By: Jonathan Toomim (jtoomim) Date: 2008-11-07 04:30 Message: Hmmm... See also bug 1887247. I don't know why neppord thinks it should be lowercase. Heck, I don't know why it should be uppercase except that that's what works. ---------------------------------------------------------------------- Comment By: Jonathan Toomim (jtoomim) Date: 2008-11-07 04:23 Message: I confirm that this problem exists, and the fix described works. I'm using OS X Leopard with a case sensitive file system. Building and installing PyOpenGL-3.0.0b6 stock will let me do >>> import OpenGL but not >>> import OpenGL.GLUT which produces the "OSError: ('dlopen(glut, 10): image not found', 'glut', None)" message described above at the end of the traceback. Making the change described above and rebuilding solved the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2130003&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 01:55:47
|
Bugs item #2143888, was opened at 2008-10-03 04:24 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2143888&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: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: glut32.dll required on vista? Initial Comment: This is strange ... I had a friend of mine test my codebase which I ship the entire OpenGL dir with so it's not required to be installed manually ... He didn't install anything special, he ran it, and it worked. Now, I have my _other_ friend test the same codebase ... and he gets this error: C:\SIL>__init__.py <<< SILr470 <<< psyco not initialized Traceback (most recent call last): File "C:\SIL\__init__.py", line 336, in <module> Singleton = Engine() File "C:\SIL\__init__.py", line 85, in __init__ OpenGL.GLUT.glutInit() File "C:\SIL\OpenGL\GLUT\special.py", line 316, in glutInit _base_glutInit( ctypes.byref(count), holder ) File "C:\SIL\OpenGL\GLUT\special.py", line 57, in _base_glutInit return __glutInitWithExit(pargc, argv, _exitfunc) File "C:\SIL\OpenGL\platform\baseplatform.py", line 280, in __call__ self.__name__, self.__name__, OpenGL.error.NullFunctionError: Attempt to call an undefined function __glutInit WithExit, check for bool(__glutInitWithExit) before calling C:\SIL> Apparently he needs the glut32.dll or something ? Why didn't my other friend also on vista lack glut32.dll ? Is it possible to have freeglut work purely in python code cross-platform without depending on a GLUT-specific binary at all? Freeglut seems to be going stagnant and it appears the thing people suggest most often is 'use a different windowing library', like SDL or something.. ? Here's a relevant GLUT bug report I submitted which I think is pretty crucial.. http://sourceforge.net/tracker/index.php?func=detail&aid=2137721&group_id=1032&atid=101032 Also, if PyOpenGL developers have to rely on the fact that their end-users will have glut32.dll in order to get anything working (or ship it themselves) .. then why even use PyOpenGL over say.. pygame or SDL-ctypes (which pygame-ctypes uses) .. because that also depends on the end-user having a binary (SDL in the case of SDL-ctypes, or pygame+SDL in the game of pygame) I guess what I'm asking for would basically be a rewrite of [Free]GLUT in python using winapi/xlib/cocoa calls while adding said fixes / enhancements, eh? Also.. one final thing I _CAN_ think of a difference in the two vista test cases.. the one that passed had python 2.4 + ctypes .. the one that failed had 2.6 https://svn.enthought.com/epd/ticket/148 ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 21:55 Message: Later PyOpenGL releases include a binary release of GLUT for Win32 platforms. Regarding why you would use PyOpenGL instead of Pygame, the GLUT library isn't really being maintained actively AFAIK. The successor to Pygame-ctypes (Pyglet) sounds about like what you were describing. HTH. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-10-05 18:21 Message: Putting 'glut32.dll' in the same directory as the executing script allows it to function.. I tried using the DLL from the following source: http://slickr-dotnet.googlecode.com/svn/trunk/Lib/freeglut.dll (obviously renaming it to glut32.dll first) but it failed. The following one works and is the one I'm currently using: http://bullet.googlecode.com/svn/trunk/GLUT32.DLL ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2143888&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 01:52:31
|
Bugs item #2152623, was opened at 2008-10-08 01:05 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2152623&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Karl Ostmo (kostmo) Assigned to: Nobody/Anonymous (nobody) Summary: KeyError: GL_BITMAP with glDrawPixels Initial Comment: Error trace: glDrawPixels(len(pixels[0])*8, len(pixels), GL_STENCIL_INDEX, GL_BITMAP, pixels) File "/usr/lib/python2.5/site-packages/OpenGL/wrapper.py", line 915, in wrapperCall pyArgs.append( converter(arg, self, args) ) File "/usr/lib/python2.5/site-packages/OpenGL/GL/images.py", line 404, in __call__ arrayType = arrays.GL_CONSTANT_TO_ARRAY_TYPE[ images.TYPE_TO_ARRAYTYPE[ type ] ] KeyError: GL_BITMAP It looks like the capability to draw bitmaps (1 byte = 8 pixels) is not implemented. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 21:52 Message: I realize it's far too late, but I did finally see this bug report. Thanks for the patch. I have added a test case to the test_core.py file and added a BITMAP type to the registered image types. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2152623&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 01:26:27
|
Bugs item #2300218, was opened at 2008-11-16 14:02 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2300218&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: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Andre Klapper (riot69) Assigned to: Nobody/Anonymous (nobody) Summary: crash inside glGetBoolean(GL_TEXTURE_2D) Initial Comment: http://bugzilla.gnome.org/show_bug.cgi?id=552981 is receiving lots of duplicates, and it seems to be a PyOpenGL issue. Kindly asking for investigating here: ----------- .xsession-errors --------------------- self.chessSet.drawPiece(self.name, state, self.scene) File "/var/lib/python-support/python2.5/glchess/scene/opengl/new_models.py", line 110, in drawPiece if glGetBoolean(GL_TEXTURE_2D): File "/usr/lib/python2.5/site-packages/PyOpenGL-3.0.0b6-py2.5.egg/OpenGL/wrapper.py", line 1631, in __call__ return self.finalise()( *args, **named ) File "/usr/lib/python2.5/site-packages/PyOpenGL-3.0.0b6-py2.5.egg/OpenGL/wrapper.py", line 683, in wrapperCall converter( pyArgs, index, self ) File "/usr/lib/python2.5/site-packages/PyOpenGL-3.0.0b6-py2.5.egg/OpenGL/converters.py", line 195, in __call__ return self.arrayType.zeros( self.getSize(pyArgs) ) File "/usr/lib/python2.5/site-packages/PyOpenGL-3.0.0b6-py2.5.egg/OpenGL/arrays/arraydatatype.py", line 98, in zeros return cls.returnHandler().zeros( dims, typeCode or cls.typeConstant ) File "/usr/lib/python2.5/site-packages/PyOpenGL-3.0.0b6-py2.5.egg/OpenGL/arrays/nones.py", line 32, in zeros raise TypeError( """Can't create NULL pointer filled with values""" ) TypeError: ("Can't create NULL pointer filled with values", 'Failure in cConverter <OpenGL.converters.SizedOutput object at 0x84904fc>', [GL_TEXTURE_2D], 1, <OpenGL.wrapper.glGetIntegerv object at 0x8 -------------------------------------------------- Traceback (most recent call last): File "/var/lib/python-support/python2.5/glchess/gtkui/chessview.py", line 166, in __expose self.view.feedback.renderGL() File "/var/lib/python-support/python2.5/glchess/display.py", line 467, in renderGL self.scene.controller.render() File "/var/lib/python-support/python2.5/glchess/scene/opengl/opengl.py", line 326, in render self.drawPieces() File "/var/lib/python-support/python2.5/glchess/scene/opengl/opengl.py", line 728, in drawPieces piece.draw() File "/var/lib/python-support/python2.5/glchess/scene/opengl/opengl.py", line 104, in draw self.chessSet.drawPiece(self.name, state, self.scene) File "/var/lib/python-support/python2.5/glchess/scene/opengl/new_models.py", line 110, in drawPiece if glGetBoolean(GL_TEXTURE_2D): File "/usr/lib/python2.5/site-packages/PyOpenGL-3.0.0b6-py2.5.egg/OpenGL/wrapper.py", line 1631, in __call__ return self.finalise()( *args, **named ) File "/usr/lib/python2.5/site-packages/PyOpenGL-3.0.0b6-py2.5.egg/OpenGL/wrapper.py", line 683, in wrapperCall converter( pyArgs, index, self ) File "/usr/lib/python2.5/site-packages/PyOpenGL-3.0.0b6-py2.5.egg/OpenGL/converters.py", line 195, in __call__ return self.arrayType.zeros( self.getSize(pyArgs) ) File "/usr/lib/python2.5/site-packages/PyOpenGL-3.0.0b6-py2.5.egg/OpenGL/arrays/arraydatatype.py", line 98, in zeros return cls.returnHandler().zeros( dims, typeCode or cls.typeConstant ) File "/usr/lib/python2.5/site-packages/PyOpenGL-3.0.0b6-py2.5.egg/OpenGL/arrays/nones.py", line 32, in zeros raise TypeError( """Can't create NULL pointer filled with values""" ) TypeError: ("Can't create NULL pointer filled with values", 'Failure in cConverter <OpenGL.converters.SizedOutput object at 0x84904fc>', [GL_TEXTURE_2D], 1, <OpenGL.wrapper.glGetIntegerv object at 0x849f28c>) ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 21:26 Message: Sorry this bug didn't get addressed last year. I can't reproduce the behaviour on Ubuntu amd64, the traceback suggests that the NonesHandler was registered as being a return-type handler, which should not be possible on current bzr head (at least, I don't see how it could happen). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-05-04 21:17 Message: thanks for the work around ---------------------------------------------------------------------- Comment By: Lino Mastrodomenico (mastrodomenico) Date: 2009-04-30 17:28 Message: A workaround is to install python-numpy (tested on Ubuntu 9.04). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-26 17:39 Message: Same for me with glGetDoublev(GL_VIEWPORT) OpenGL.__version__ = '3.0.0b6' This is on Ubuntu 9.04 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-01-02 08:09 Message: Same for me on debian lenny with 3.0.0~b6-3, going back to b3-1 resolves the problem. ---------------------------------------------------------------------- Comment By: Ignazio Di Napoli (neclepsio) Date: 2008-11-21 18:37 Message: I have the very same problem, but with glGetInteger(GL_DEPTH_BITS). This only happens with b6, going back to b5 makes the error disappear. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2300218&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 01:01:01
|
Bugs item #2798902, was opened at 2009-05-30 14:06 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2798902&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stephan Houben (stephanhouben) Assigned to: Nobody/Anonymous (nobody) Summary: crash glGetError Initial Comment: With PyOpenGL 3.0.0 and Python 2.6.2 (on x86), the following simple file causes a crash: ======================= from OpenGL.GLUT import * glutInit() glutInitDisplayMode(GLUT_RGB) ======================= (gdb) run gltest.py Starting program: /usr/local/bin/python gltest.py [Thread debugging using libthread_db enabled] [New Thread 0xb7da28d0 (LWP 1302)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7da28d0 (LWP 1302)] 0xb7c1b196 in glGetError () from /usr/lib/libGL.so.1 (gdb) where #0 0xb7c1b196 in glGetError () from /usr/lib/libGL.so.1 #1 0xb7c91f67 in ffi_call_SYSV () at /home/stephanh/DOWNLOAD/Python-2.6.2/Modules/_ctypes/libffi/src/x86/sysv.S:61 #2 0xb7c91da6 in ffi_call (cif=0xbf87d9a8, fn=0xb7c1b190 <glGetError>, rvalue=0x0, avalue=0xbf87da20) at /home/stephanh/DOWNLOAD/Python-2.6.2/Modules/_ctypes/libffi/src/x86/ffi.c:213 #3 0xb7c8c4aa in _CallProc (pProc=0xb7c1b190 <glGetError>, argtuple=0xb7d6202c, flags=<value optimized out>, argtypes=0x0, restype=0x86b85fc, checker=0x0) at /home/stephanh/DOWNLOAD/Python-2.6.2/Modules/_ctypes/callproc.c:815 #4 0xb7c83da9 in CFuncPtr_call (self=0x8700304, inargs=0xb7d6202c, kwds=0x0) at /home/stephanh/DOWNLOAD/Python-2.6.2/Modules/_ctypes/_ctypes.c:3857 #5 0x0805f6ca in PyObject_Call (func=0x8700304, arg=0xb7d6202c, kw=0x0) at Objects/abstract.c:2492 #6 0x080dacfa in PyEval_EvalFrameEx (f=0x87a6444, throwflag=0) at Python/ceval.c:3917 #7 0x080dddc8 in PyEval_EvalCodeEx (co=0x871d068, globals=0x870cdfc, locals=0x0, args=0xb7d507e0, argcount=4, kws=0x0, kwcount=0, defs=0x871c6d8, defcount=2, closure=0x0) at Python/ceval.c:2968 #8 0x08131fef in function_call (func=0x8713df4, arg=0xb7d507d4, kw=0x0) at Objects/funcobject.c:524 #9 0x0805f6ca in PyObject_Call (func=0x8713df4, arg=0xb7d507d4, kw=0x0) at Objects/abstract.c:2492 #10 0x080665ca in instancemethod_call (func=0x8713df4, arg=0xb7d507d4, kw=0x0) at Objects/classobject.c:2579 #11 0x080640d1 in PyObject_CallFunctionObjArgs (callable=0xb7cd2dec) at Objects/abstract.c:2492 #12 0xb7c83de3 in CFuncPtr_call (self=0x876043c, inargs=0xb7d5232c, kwds=0x0) at /home/stephanh/DOWNLOAD/Python-2.6.2/Modules/_ctypes/_ctypes.c:3873 #13 0x0805f6ca in PyObject_Call (func=0x876043c, arg=0xb7d5232c, kw=0x0) at Objects/abstract.c:2492 #14 0x080dacfa in PyEval_EvalFrameEx (f=0x86a0f8c, throwflag=0) at Python/ceval.c:3917 #15 0x080dddc8 in PyEval_EvalCodeEx (co=0xb7d8f6e0, globals=0xb7d850b4, locals=0xb7d850b4, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2968 #16 0x080ddf27 in PyEval_EvalCode (co=0xb7d8f6e0, globals=0xb7d850b4, locals=0xb7d850b4) at Python/ceval.c:522 #17 0x080fbb01 in PyRun_FileExFlags (fp=0x8653cf8, filename=0xbf87f8f8 "gltest.py", start=257, globals=0xb7d850b4, locals=0xb7d850b4, closeit=1, flags=0xbf87e718) at Python/pythonrun.c:1335 #18 0x080fbe5a in PyRun_SimpleFileExFlags (fp=0x8653cf8, filename=0xbf87f8f8 "gltest.py", closeit=1, flags=0xbf87e718) at Python/pythonrun.c:931 #19 0x0805ae42 in Py_Main (argc=1, argv=0xbf87e7e4) at Modules/main.c:599 #20 0x08059f32 in main (argc=-1081615896, argv=0xb7c91da6) at ./Modules/python.c:23 ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 18:53 Message: Thanks for the bug report, PyOpenGL 3.0.1 (current head) has fixed the problem with the implicit calling of glGetError, which is no longer safe on Linux platforms. ---------------------------------------------------------------------- Comment By: Stephan Houben (stephanhouben) Date: 2009-05-31 09:33 Message: Hi all, Turns out the problem is caused by the implicit call to glGetError() caused by glutInitDisplayMode() which is done before a window is created. Presumably, this means no OpenGL context is created either at this point. If I do a glutCreateWindow() before glutInitDisplayMode() everything is fine. I am not sure if doing a glGetError before a GL context is created is supposed to be legal. If it is, the blame rests on the GL implementation (mesa) but otherwise it is bug in PyOpenGL. I think calling glutInitDisplayMode() before glutCreateWindow() is ordinarily an expected order. Stephan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2798902&group_id=5988 |
32 messages has been excluded from this view by a project administrator.
