pyopengl-devel Mailing List for PyOpenGL (Page 4)
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: SourceForge.net <no...@so...> - 2012-08-29 12:30:43
|
Patches item #985059, was opened at 2004-07-04 14:25 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=985059&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: Demo Group: v2.0 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Brian Leair (bleair2) Assigned to: Nobody/Anonymous (nobody) Summary: Port of NeHe tutorial 43 Initial Comment: Port of the NeHe.gamedev.net tutorial 43. Uses glut. Requires PIL. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-08-29 05:30 Message: BTDWlN <a href="http://lhmibnpewxud.com/">lhmibnpewxud</a>, [url=http://xrqgwajanhky.com/]xrqgwajanhky[/url], [link=http://wtnzvwogipte.com/]wtnzvwogipte[/link], http://qlxaolhipzdo.com/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-07-22 15:35 Message: 7T9Ot2 <a href="http://usllaqlpyuwe.com/">usllaqlpyuwe</a>, [url=http://vlcsjlkinczc.com/]vlcsjlkinczc[/url], [link=http://mtizsnkruloi.com/]mtizsnkruloi[/link], http://yjcnmehamink.com/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=985059&group_id=5988 |
|
From: Mike C. F. <mcf...@vr...> - 2012-08-22 17:34:07
|
On 12-08-22 06:03 AM, Almar Klein wrote: > Hi Mike, > > I'm about to release a new version of Visvis, which now has Py3k > support. Since it relies on PyOpenGl I was wondering whether its > latest release has the fixes that we helped with last April. > > Looking at Pypi and Christoph Gohlke's site I was a bit confused: On > the first the latest release seems to be 3.0.2a5 from Februari 2012, > and on the latter I see a version 3.0.2.a6 from Juli. I haven't yet finished releasing 3.0.2b2, which has the fixes. That is, I've put a source release up on PyPI, but PyPI keeps crashing, so I'll likely delay the full roll out (e.g. packaging and building for Windows etc). It normally requires ~ a full day to package, test and release, but I need to get back to paying work this week. Take care, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: Almar K. <a....@sc...> - 2012-08-22 10:30:17
|
Hi Mike, I'm about to release a new version of Visvis, which now has Py3k support. Since it relies on PyOpenGl I was wondering whether its latest release has the fixes that we helped with last April. Looking at Pypi and Christoph Gohlke's site I was a bit confused: On the first the latest release seems to be 3.0.2a5 from Februari 2012, and on the latter I see a version 3.0.2.a6 from Juli. Thanks, Almar -- Almar Klein, PhD Science Applied phone: +31 6 19268652 e-mail: a....@sc... |
|
From: SourceForge.net <no...@so...> - 2012-07-22 22:35:59
|
Patches item #985059, was opened at 2004-07-04 14:25 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=985059&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: Demo Group: v2.0 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Brian Leair (bleair2) Assigned to: Nobody/Anonymous (nobody) Summary: Port of NeHe tutorial 43 Initial Comment: Port of the NeHe.gamedev.net tutorial 43. Uses glut. Requires PIL. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-07-22 15:35 Message: 7T9Ot2 <a href="http://usllaqlpyuwe.com/">usllaqlpyuwe</a>, [url=http://vlcsjlkinczc.com/]vlcsjlkinczc[/url], [link=http://mtizsnkruloi.com/]mtizsnkruloi[/link], http://yjcnmehamink.com/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=985059&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2012-07-22 08:00:55
|
Patches item #3547172, was opened at 2012-07-22 01:00 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=3547172&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: build Group: v2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: rD6SFk <a href="http://iflbejozyvwo.com/">iflbejozyvwo</a>, Initial Comment: rD6SFk <a href="http://iflbejozyvwo.com/">iflbejozyvwo</a>, [url=http://jqfhnhvfpnln.com/]jqfhnhvfpnln[/url], [link=http://hztytenzyaor.com/]hztytenzyaor[/link], http://umxqeqbqpdis.com/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=3547172&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2012-07-21 23:07:04
|
Patches item #985060, was opened at 2004-07-04 14:26 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=985060&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: Demo Group: v2.0 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Brian Leair (bleair2) Assigned to: Nobody/Anonymous (nobody) Summary: Port of NeHe tutorial 42 Initial Comment: Port of the NeHe.gamedev.net tutorial 42. Uses glut. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-07-21 16:07 Message: yZ9VfO <a href="http://eqshvrlzwwbk.com/">eqshvrlzwwbk</a>, [url=http://ezwffhnltmgb.com/]ezwffhnltmgb[/url], [link=http://fqmmrppjuxji.com/]fqmmrppjuxji[/link], http://qsqwccwqmhgi.com/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=985060&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2012-07-21 21:20:41
|
Patches item #991370, was opened at 2004-07-14 22:58 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=991370&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: Demo Group: v2.0 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Brian Leair (bleair2) Assigned to: Nobody/Anonymous (nobody) Summary: Port of NeHe tutorial 48 Initial Comment: Zip file with python code for tutorial 48 ArcBall rotation. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-07-21 14:20 Message: Eelrpm <a href="http://ctfftdwmzymj.com/">ctfftdwmzymj</a>, [url=http://dnjhzasxuerx.com/]dnjhzasxuerx[/url], [link=http://hftkbjpswnkh.com/]hftkbjpswnkh[/link], http://hqzbcealoltm.com/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=991370&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2012-07-18 03:06:19
|
Bugs item #3540740, was opened at 2012-07-05 23:29 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3540740&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: Demo Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Yann Golanski (kierun) Assigned to: Mike C. Fletcher (mcfletch) Summary: tests/shader_1.py error C7533 deprecated call to gl_Model Initial Comment: When attempting to run tests/shader_1.py, I get the following error: RuntimeError: ('Shader compile failure (0): 0(3) : error C7533: global variable gl_ModelViewProjectionMatrix is deprecated after version 120\n0(3) : error C7533: global variable gl_Vertex is deprecated after version 120\n', ['#version 330\n void main() {\n gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;\n }'], GL_VERTEX_SHADER) If I change the #version to 120, I get this: NameError: name 'GL_UNIFORM_BUFFER' is not defined ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2012-07-17 20:06 Message: The GL_UNIFORM_BUFFER not defined error is because it's only available in current bzr head PyOpenGL. The version was changed because of reports that certain machines were unable to compile without a 330 declaration; 120 is apparently the last version that "supports" the fixed pipeline. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3540740&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2012-07-06 06:29:35
|
Bugs item #3540740, was opened at 2012-07-05 23:29 Message generated for change (Tracker Item Submitted) made by kierun You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3540740&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: Demo Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Yann Golanski (kierun) Assigned to: Mike C. Fletcher (mcfletch) Summary: tests/shader_1.py error C7533 deprecated call to gl_Model Initial Comment: When attempting to run tests/shader_1.py, I get the following error: RuntimeError: ('Shader compile failure (0): 0(3) : error C7533: global variable gl_ModelViewProjectionMatrix is deprecated after version 120\n0(3) : error C7533: global variable gl_Vertex is deprecated after version 120\n', ['#version 330\n void main() {\n gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;\n }'], GL_VERTEX_SHADER) If I change the #version to 120, I get this: NameError: name 'GL_UNIFORM_BUFFER' is not defined ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3540740&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2012-06-21 17:40:58
|
Bugs item #3536957, was opened at 2012-06-21 10:40 Message generated for change (Tracker Item Submitted) made by tomobag You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3536957&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: Tom Palmer (tomobag) Assigned to: Mike C. Fletcher (mcfletch) Summary: glutInit broken on python3 for no args Initial Comment: The following code passes a unicode str for no args for python3: args = [as_8_bit(x) for x in args] if not count: count, args = 1, ['foo'] It might ought to say the following: if not count: count, args = 1, ['foo'] args = [as_8_bit(x) for x in args] Just try calling glutInit() on python3 to cause the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3536957&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2012-06-11 15:25:46
|
Bugs item #3534110, was opened at 2012-06-10 03:02 Message generated for change (Comment added) made by lxnt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3534110&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: Fixed Priority: 5 Private: No Submitted By: Alexander Sabourenkov (lxnt) Assigned to: Mike C. Fletcher (mcfletch) Summary: hasGLExtension fail wrt circular import Initial Comment: Given a 3.0+ forward-compatible context, that is, with glGetString barking at GL_EXTENSIONS, "from OpenGL.GL import *" may fail if one of OpenGL.GL.VERSION.GL_* submodules with version below 3.0 calls hasGLExtension() due to the fact that until "from OpenGL.GL.VERSION.GL_3_0 import *" line is executed in OpenGL/GL/__init__.py, the line "from OpenGL.GL import GL_NUM_EXTENSIONS, glGetStringi, glGetIntegerv" is guaranteed to throw an ImportError. Suggested solution: replace the aforementioned import statement in the hasExtension() function with the following two lines: from OpenGL.GL.VERSION.GL_3_0 import GL_NUM_EXTENSIONS, glGetStringi from OpenGL.GL import glGetIntegerv Works for me. Attached patch: the above fix plus a couple of nits to make it all work under Python 3.2 ---------------------------------------------------------------------- >Comment By: Alexander Sabourenkov (lxnt) Date: 2012-06-11 08:25 Message: I withdraw that comment about except and stuff, that was indeed a local distutils breakage on my system. Thank you. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2012-06-11 08:16 Message: Oh, missed that there was a patch... okay, will apply it tonight. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2012-06-11 08:15 Message: You mean 2to3 *isnt'* converting the source code properly? It was supposed to convert references to unicode to str and exception syntax over to the 3.x syntax. Hrm. Circular import I'll have to look at again when I get a chance. ---------------------------------------------------------------------- Comment By: Alexander Sabourenkov (lxnt) Date: 2012-06-11 07:40 Message: On the ' except ... as ' issue: Since the old syntax prevents it working on Python 3.x, and since the err variable isn't used anyway, I propose the line to be changed to just "except error.NullFunctionError:". On the "isinstance( name, ( str, unicode)):" "unicode" builtin was removed in Python 3.0. Thus it also breaks stuff under 3.0 and newer. I didn't dig to understand why it's there. To make it work though I suggest doing something like: try: nametypes = ( str, unicode) except NameError: nametypes = ( bytes, str) if not isinstance(name, nametypes): ... ---------------------------------------------------------------------- Comment By: Alexander Sabourenkov (lxnt) Date: 2012-06-11 07:19 Message: Thanks for quick reaction. There is another major problem. Now hasGLExtension() is called recursively on the first call. That is, at the first call we get to "from OpenGL.GL.VERSION.GL_3_0 import ...", which does "from OpenGL.GL.ARB.vertex_array_object import *", which in turn ends up calling hasGLExtension(). The problem is that at the time of that second call glGetStringi()'s restype is not yet set. Thus it returns GLubytearrays or something, which leads to ARB_vertex_array_object extension be declared unavailable. The attached patch fixes the issue, moving restype assignment to above the extension imports. Those two calls to hasGlExtension() end up doing the work twice. This isn't so much a problem in itself, just not quite elegant. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2012-06-10 19:33 Message: I've merged approximately this patch in. I reverted the "as" changes, as I don't believe I've ever officially announced dropping support for Python 2.5 (though I likely should some day soon). The change that would break unicode string checking on Python 2.x was also not included (AFAIK that code would work perfectly well on Python 3.x); there was a real reason to say "string or unicode" there. I had to add an alias for the __bool__ as well so that earlier Python's would still be able to do boolean checking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3534110&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2012-06-11 15:16:31
|
Bugs item #3534110, was opened at 2012-06-10 03:02 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3534110&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: Fixed Priority: 5 Private: No Submitted By: Alexander Sabourenkov (lxnt) Assigned to: Mike C. Fletcher (mcfletch) Summary: hasGLExtension fail wrt circular import Initial Comment: Given a 3.0+ forward-compatible context, that is, with glGetString barking at GL_EXTENSIONS, "from OpenGL.GL import *" may fail if one of OpenGL.GL.VERSION.GL_* submodules with version below 3.0 calls hasGLExtension() due to the fact that until "from OpenGL.GL.VERSION.GL_3_0 import *" line is executed in OpenGL/GL/__init__.py, the line "from OpenGL.GL import GL_NUM_EXTENSIONS, glGetStringi, glGetIntegerv" is guaranteed to throw an ImportError. Suggested solution: replace the aforementioned import statement in the hasExtension() function with the following two lines: from OpenGL.GL.VERSION.GL_3_0 import GL_NUM_EXTENSIONS, glGetStringi from OpenGL.GL import glGetIntegerv Works for me. Attached patch: the above fix plus a couple of nits to make it all work under Python 3.2 ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2012-06-11 08:16 Message: Oh, missed that there was a patch... okay, will apply it tonight. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2012-06-11 08:15 Message: You mean 2to3 *isnt'* converting the source code properly? It was supposed to convert references to unicode to str and exception syntax over to the 3.x syntax. Hrm. Circular import I'll have to look at again when I get a chance. ---------------------------------------------------------------------- Comment By: Alexander Sabourenkov (lxnt) Date: 2012-06-11 07:40 Message: On the ' except ... as ' issue: Since the old syntax prevents it working on Python 3.x, and since the err variable isn't used anyway, I propose the line to be changed to just "except error.NullFunctionError:". On the "isinstance( name, ( str, unicode)):" "unicode" builtin was removed in Python 3.0. Thus it also breaks stuff under 3.0 and newer. I didn't dig to understand why it's there. To make it work though I suggest doing something like: try: nametypes = ( str, unicode) except NameError: nametypes = ( bytes, str) if not isinstance(name, nametypes): ... ---------------------------------------------------------------------- Comment By: Alexander Sabourenkov (lxnt) Date: 2012-06-11 07:19 Message: Thanks for quick reaction. There is another major problem. Now hasGLExtension() is called recursively on the first call. That is, at the first call we get to "from OpenGL.GL.VERSION.GL_3_0 import ...", which does "from OpenGL.GL.ARB.vertex_array_object import *", which in turn ends up calling hasGLExtension(). The problem is that at the time of that second call glGetStringi()'s restype is not yet set. Thus it returns GLubytearrays or something, which leads to ARB_vertex_array_object extension be declared unavailable. The attached patch fixes the issue, moving restype assignment to above the extension imports. Those two calls to hasGlExtension() end up doing the work twice. This isn't so much a problem in itself, just not quite elegant. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2012-06-10 19:33 Message: I've merged approximately this patch in. I reverted the "as" changes, as I don't believe I've ever officially announced dropping support for Python 2.5 (though I likely should some day soon). The change that would break unicode string checking on Python 2.x was also not included (AFAIK that code would work perfectly well on Python 3.x); there was a real reason to say "string or unicode" there. I had to add an alias for the __bool__ as well so that earlier Python's would still be able to do boolean checking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3534110&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2012-06-11 15:15:40
|
Bugs item #3534110, was opened at 2012-06-10 03:02 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3534110&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: Fixed Priority: 5 Private: No Submitted By: Alexander Sabourenkov (lxnt) Assigned to: Mike C. Fletcher (mcfletch) Summary: hasGLExtension fail wrt circular import Initial Comment: Given a 3.0+ forward-compatible context, that is, with glGetString barking at GL_EXTENSIONS, "from OpenGL.GL import *" may fail if one of OpenGL.GL.VERSION.GL_* submodules with version below 3.0 calls hasGLExtension() due to the fact that until "from OpenGL.GL.VERSION.GL_3_0 import *" line is executed in OpenGL/GL/__init__.py, the line "from OpenGL.GL import GL_NUM_EXTENSIONS, glGetStringi, glGetIntegerv" is guaranteed to throw an ImportError. Suggested solution: replace the aforementioned import statement in the hasExtension() function with the following two lines: from OpenGL.GL.VERSION.GL_3_0 import GL_NUM_EXTENSIONS, glGetStringi from OpenGL.GL import glGetIntegerv Works for me. Attached patch: the above fix plus a couple of nits to make it all work under Python 3.2 ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2012-06-11 08:15 Message: You mean 2to3 *isnt'* converting the source code properly? It was supposed to convert references to unicode to str and exception syntax over to the 3.x syntax. Hrm. Circular import I'll have to look at again when I get a chance. ---------------------------------------------------------------------- Comment By: Alexander Sabourenkov (lxnt) Date: 2012-06-11 07:40 Message: On the ' except ... as ' issue: Since the old syntax prevents it working on Python 3.x, and since the err variable isn't used anyway, I propose the line to be changed to just "except error.NullFunctionError:". On the "isinstance( name, ( str, unicode)):" "unicode" builtin was removed in Python 3.0. Thus it also breaks stuff under 3.0 and newer. I didn't dig to understand why it's there. To make it work though I suggest doing something like: try: nametypes = ( str, unicode) except NameError: nametypes = ( bytes, str) if not isinstance(name, nametypes): ... ---------------------------------------------------------------------- Comment By: Alexander Sabourenkov (lxnt) Date: 2012-06-11 07:19 Message: Thanks for quick reaction. There is another major problem. Now hasGLExtension() is called recursively on the first call. That is, at the first call we get to "from OpenGL.GL.VERSION.GL_3_0 import ...", which does "from OpenGL.GL.ARB.vertex_array_object import *", which in turn ends up calling hasGLExtension(). The problem is that at the time of that second call glGetStringi()'s restype is not yet set. Thus it returns GLubytearrays or something, which leads to ARB_vertex_array_object extension be declared unavailable. The attached patch fixes the issue, moving restype assignment to above the extension imports. Those two calls to hasGlExtension() end up doing the work twice. This isn't so much a problem in itself, just not quite elegant. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2012-06-10 19:33 Message: I've merged approximately this patch in. I reverted the "as" changes, as I don't believe I've ever officially announced dropping support for Python 2.5 (though I likely should some day soon). The change that would break unicode string checking on Python 2.x was also not included (AFAIK that code would work perfectly well on Python 3.x); there was a real reason to say "string or unicode" there. I had to add an alias for the __bool__ as well so that earlier Python's would still be able to do boolean checking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3534110&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2012-06-11 14:40:13
|
Bugs item #3534110, was opened at 2012-06-10 03:02 Message generated for change (Comment added) made by lxnt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3534110&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: Fixed Priority: 5 Private: No Submitted By: Alexander Sabourenkov (lxnt) Assigned to: Mike C. Fletcher (mcfletch) Summary: hasGLExtension fail wrt circular import Initial Comment: Given a 3.0+ forward-compatible context, that is, with glGetString barking at GL_EXTENSIONS, "from OpenGL.GL import *" may fail if one of OpenGL.GL.VERSION.GL_* submodules with version below 3.0 calls hasGLExtension() due to the fact that until "from OpenGL.GL.VERSION.GL_3_0 import *" line is executed in OpenGL/GL/__init__.py, the line "from OpenGL.GL import GL_NUM_EXTENSIONS, glGetStringi, glGetIntegerv" is guaranteed to throw an ImportError. Suggested solution: replace the aforementioned import statement in the hasExtension() function with the following two lines: from OpenGL.GL.VERSION.GL_3_0 import GL_NUM_EXTENSIONS, glGetStringi from OpenGL.GL import glGetIntegerv Works for me. Attached patch: the above fix plus a couple of nits to make it all work under Python 3.2 ---------------------------------------------------------------------- >Comment By: Alexander Sabourenkov (lxnt) Date: 2012-06-11 07:40 Message: On the ' except ... as ' issue: Since the old syntax prevents it working on Python 3.x, and since the err variable isn't used anyway, I propose the line to be changed to just "except error.NullFunctionError:". On the "isinstance( name, ( str, unicode)):" "unicode" builtin was removed in Python 3.0. Thus it also breaks stuff under 3.0 and newer. I didn't dig to understand why it's there. To make it work though I suggest doing something like: try: nametypes = ( str, unicode) except NameError: nametypes = ( bytes, str) if not isinstance(name, nametypes): ... ---------------------------------------------------------------------- Comment By: Alexander Sabourenkov (lxnt) Date: 2012-06-11 07:19 Message: Thanks for quick reaction. There is another major problem. Now hasGLExtension() is called recursively on the first call. That is, at the first call we get to "from OpenGL.GL.VERSION.GL_3_0 import ...", which does "from OpenGL.GL.ARB.vertex_array_object import *", which in turn ends up calling hasGLExtension(). The problem is that at the time of that second call glGetStringi()'s restype is not yet set. Thus it returns GLubytearrays or something, which leads to ARB_vertex_array_object extension be declared unavailable. The attached patch fixes the issue, moving restype assignment to above the extension imports. Those two calls to hasGlExtension() end up doing the work twice. This isn't so much a problem in itself, just not quite elegant. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2012-06-10 19:33 Message: I've merged approximately this patch in. I reverted the "as" changes, as I don't believe I've ever officially announced dropping support for Python 2.5 (though I likely should some day soon). The change that would break unicode string checking on Python 2.x was also not included (AFAIK that code would work perfectly well on Python 3.x); there was a real reason to say "string or unicode" there. I had to add an alias for the __bool__ as well so that earlier Python's would still be able to do boolean checking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3534110&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2012-06-11 14:19:23
|
Bugs item #3534110, was opened at 2012-06-10 03:02 Message generated for change (Comment added) made by lxnt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3534110&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: Fixed Priority: 5 Private: No Submitted By: Alexander Sabourenkov (lxnt) Assigned to: Mike C. Fletcher (mcfletch) Summary: hasGLExtension fail wrt circular import Initial Comment: Given a 3.0+ forward-compatible context, that is, with glGetString barking at GL_EXTENSIONS, "from OpenGL.GL import *" may fail if one of OpenGL.GL.VERSION.GL_* submodules with version below 3.0 calls hasGLExtension() due to the fact that until "from OpenGL.GL.VERSION.GL_3_0 import *" line is executed in OpenGL/GL/__init__.py, the line "from OpenGL.GL import GL_NUM_EXTENSIONS, glGetStringi, glGetIntegerv" is guaranteed to throw an ImportError. Suggested solution: replace the aforementioned import statement in the hasExtension() function with the following two lines: from OpenGL.GL.VERSION.GL_3_0 import GL_NUM_EXTENSIONS, glGetStringi from OpenGL.GL import glGetIntegerv Works for me. Attached patch: the above fix plus a couple of nits to make it all work under Python 3.2 ---------------------------------------------------------------------- >Comment By: Alexander Sabourenkov (lxnt) Date: 2012-06-11 07:19 Message: Thanks for quick reaction. There is another major problem. Now hasGLExtension() is called recursively on the first call. That is, at the first call we get to "from OpenGL.GL.VERSION.GL_3_0 import ...", which does "from OpenGL.GL.ARB.vertex_array_object import *", which in turn ends up calling hasGLExtension(). The problem is that at the time of that second call glGetStringi()'s restype is not yet set. Thus it returns GLubytearrays or something, which leads to ARB_vertex_array_object extension be declared unavailable. The attached patch fixes the issue, moving restype assignment to above the extension imports. Those two calls to hasGlExtension() end up doing the work twice. This isn't so much a problem in itself, just not quite elegant. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2012-06-10 19:33 Message: I've merged approximately this patch in. I reverted the "as" changes, as I don't believe I've ever officially announced dropping support for Python 2.5 (though I likely should some day soon). The change that would break unicode string checking on Python 2.x was also not included (AFAIK that code would work perfectly well on Python 3.x); there was a real reason to say "string or unicode" there. I had to add an alias for the __bool__ as well so that earlier Python's would still be able to do boolean checking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3534110&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2012-06-11 02:33:24
|
Bugs item #3534110, was opened at 2012-06-10 03:02 Message generated for change (Settings changed) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3534110&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: Fixed Priority: 5 Private: No Submitted By: Alexander Sabourenkov (lxnt) Assigned to: Mike C. Fletcher (mcfletch) Summary: hasGLExtension fail wrt circular import Initial Comment: Given a 3.0+ forward-compatible context, that is, with glGetString barking at GL_EXTENSIONS, "from OpenGL.GL import *" may fail if one of OpenGL.GL.VERSION.GL_* submodules with version below 3.0 calls hasGLExtension() due to the fact that until "from OpenGL.GL.VERSION.GL_3_0 import *" line is executed in OpenGL/GL/__init__.py, the line "from OpenGL.GL import GL_NUM_EXTENSIONS, glGetStringi, glGetIntegerv" is guaranteed to throw an ImportError. Suggested solution: replace the aforementioned import statement in the hasExtension() function with the following two lines: from OpenGL.GL.VERSION.GL_3_0 import GL_NUM_EXTENSIONS, glGetStringi from OpenGL.GL import glGetIntegerv Works for me. Attached patch: the above fix plus a couple of nits to make it all work under Python 3.2 ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2012-06-10 19:33 Message: I've merged approximately this patch in. I reverted the "as" changes, as I don't believe I've ever officially announced dropping support for Python 2.5 (though I likely should some day soon). The change that would break unicode string checking on Python 2.x was also not included (AFAIK that code would work perfectly well on Python 3.x); there was a real reason to say "string or unicode" there. I had to add an alias for the __bool__ as well so that earlier Python's would still be able to do boolean checking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3534110&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2012-06-10 10:02:21
|
Bugs item #3534110, was opened at 2012-06-10 03:02 Message generated for change (Tracker Item Submitted) made by lxnt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3534110&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: Alexander Sabourenkov (lxnt) Assigned to: Mike C. Fletcher (mcfletch) Summary: hasGLExtension fail wrt circular import Initial Comment: Given a 3.0+ forward-compatible context, that is, with glGetString barking at GL_EXTENSIONS, "from OpenGL.GL import *" may fail if one of OpenGL.GL.VERSION.GL_* submodules with version below 3.0 calls hasGLExtension() due to the fact that until "from OpenGL.GL.VERSION.GL_3_0 import *" line is executed in OpenGL/GL/__init__.py, the line "from OpenGL.GL import GL_NUM_EXTENSIONS, glGetStringi, glGetIntegerv" is guaranteed to throw an ImportError. Suggested solution: replace the aforementioned import statement in the hasExtension() function with the following two lines: from OpenGL.GL.VERSION.GL_3_0 import GL_NUM_EXTENSIONS, glGetStringi from OpenGL.GL import glGetIntegerv Works for me. Attached patch: the above fix plus a couple of nits to make it all work under Python 3.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3534110&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2012-05-13 18:38:02
|
Bugs item #3526361, was opened at 2012-05-13 11:38 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3526361&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: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: GL.glGenLists not returning int on OSX 64 bit Initial Comment: I'm using py27-opengl 3.0.1_0 and py27-opengl-accelerate 3.0.1_0 on MacOS 10.7.3 64 bit via macports. I'm also using wxWidgets-devel 2.9.3_0+sdl if that's relevant. I've installed the wxgui component of gnuradio and am getting the following error when I try and use an openGL widget: Traceback (most recent call last): File "/opt/local/lib/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py", line 187, in _on_paint for fcn in self._draw_fcns: fcn[1]() File "/opt/local/lib/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py", line 58, in draw GL.glNewList(self._grid_compiled_list_id, GL.GL_COMPILE) ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: wrong type The code is at http://pastebin.com/ezLmgYv2 Please make sure GL.glGenLists is returning what you expect it to return (namely an unsigned int). On some platforms I've seen PyOpenGL bindings not returning the generated value but rather expecting to assign it to the second parameter in a similar fashion than that of the C API. Hope this helps! Alejandro.- Hi Alejandro, self._grid_compiled_list_id = GL.glGenLists(1) print self._grid_compiled_list_id returns 'None' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3526361&group_id=5988 |
|
From: Almar K. <a....@sc...> - 2012-05-10 21:09:31
|
Hi, Just wanted to say that I've got our visualization toolkit (visvis) running in Python 3, based on the current Bazaar head of pyopengl. I've got all our examples working on both Linux and Windows. The only thing that doesn't feel right yet is that I have to pass the shading code as a str and names for uniforms as bytes. But I understood from Rob that this is on your todo list. Thanks for your support so far. Regards, Almar On 27 April 2012 15:43, Rob Reilink <r.r...@sc...> wrote: > Hi Anthony, > > We (Science Applied) are using Py3 with bzr head. I am on Mac OS X, Almar > Klein is on Win32. It seems that the result of this bug was that only > functions that are provided by extensions (or something the like) were > influenced. > > Almar is going to work on his visualization toolkit (visvis) to get that > to work on Python3 (he just started and this bug was the first issue in > PyOpenGL that he encountered). We do now have some of our test cases > working, while others are not yet. The problem(s) may be either in visvis > or in PyOpenGL, that is to be seen in the coming weeks (he's on holidays > next week but he'll probably do some more testing/Py3 porting after next > week) > > Anyway, for now, I'll create a fork and a pull request. > > Rob > > > --------------------------------------------- > Rob Reilink, M.Sc > Science Applied > > phone: +31 6 187 26562 > e-mail: r.r...@sc... > --------------------------------------------- > > > > > Op 27 apr 2012, om 15:04 heeft Mike C. Fletcher het volgende geschreven: > > > BTW, is anyone actively using a Python3 version with bzr head? This bug > seems like it would make the whole thing a non-starter (if no function > will load, it doesn't seem anyone would get anywhere useful). If we're > close, I'd prefer to get the major Python3 compatibility changes into at > least one beta release of 3.0.2 before we roll out a final. I've got a > TODO sitting in my inbox for allowing unicode in GLchar*, but AFAIK > that's our only pending 3.x enhancement. If we're a long way from > compatibility I may as well push a 3.0.2 beta and plan for 3.0.3 to have > Python3 compatibility. > > Have fun, > Mike > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Devel mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-devel > > -- Almar Klein, PhD Science Applied phone: +31 6 19268652 e-mail: a....@sc... |
|
From: Almar K. <a....@sc...> - 2012-04-27 21:45:06
|
> We noted that extension functions do not work properly in Py3 on Win32. For the record, I encountered the same bug on Linux (Mint). Almar |
|
From: Rob R. <r.r...@sc...> - 2012-04-27 13:44:03
|
Hi Anthony, We (Science Applied) are using Py3 with bzr head. I am on Mac OS X, Almar Klein is on Win32. It seems that the result of this bug was that only functions that are provided by extensions (or something the like) were influenced. Almar is going to work on his visualization toolkit (visvis) to get that to work on Python3 (he just started and this bug was the first issue in PyOpenGL that he encountered). We do now have some of our test cases working, while others are not yet. The problem(s) may be either in visvis or in PyOpenGL, that is to be seen in the coming weeks (he's on holidays next week but he'll probably do some more testing/Py3 porting after next week) Anyway, for now, I'll create a fork and a pull request. Rob --------------------------------------------- Rob Reilink, M.Sc Science Applied phone: +31 6 187 26562 e-mail: r.r...@sc... --------------------------------------------- Op 27 apr 2012, om 15:04 heeft Mike C. Fletcher het volgende geschreven: > > BTW, is anyone actively using a Python3 version with bzr head? This bug > seems like it would make the whole thing a non-starter (if no function > will load, it doesn't seem anyone would get anywhere useful). If we're > close, I'd prefer to get the major Python3 compatibility changes into at > least one beta release of 3.0.2 before we roll out a final. I've got a > TODO sitting in my inbox for allowing unicode in GLchar*, but AFAIK > that's our only pending 3.x enhancement. If we're a long way from > compatibility I may as well push a 3.0.2 beta and plan for 3.0.3 to have > Python3 compatibility. > > Have fun, > Mike > |
|
From: Mike C. F. <mcf...@vr...> - 2012-04-27 13:04:41
|
On 12-04-27 07:06 AM, Rob Reilink wrote: > Hi, > > We noted that extension functions do not work properly in Py3 on > Win32. The problem is that the function name is passed as a (unicode) > str to Win32Platform.getExtensionProcedure (which is a static method > referring to OpenGL.wglGetProcAddress), which is called from > BasePlatform.constructFunction > > The solution is of course to encode the the name, the question is > where to do this? > > I expect that all platforms that use getExtensionProcedure (those that > have self.EXTENSIONS_USE_BASE_FUNCTIONS==False, i.e. Win32, GLX, > OSMESA) have a function that expects bytes, not str. So I would > propose to put > pointer = self.getExtensionProcedure( as_8_bit(functionName) ) > in BasePlatform.constructFunction. > > Should I go ahead and implement this and create a pull request, or > should this be implemented somewhere else? Ah, apparently function.__name__ has become unicode too, did not realize that. Yeah, that looks like a reasonable place to put the change. Feel free to create a pull request. BTW, is anyone actively using a Python3 version with bzr head? This bug seems like it would make the whole thing a non-starter (if no function will load, it doesn't seem anyone would get anywhere useful). If we're close, I'd prefer to get the major Python3 compatibility changes into at least one beta release of 3.0.2 before we roll out a final. I've got a TODO sitting in my inbox for allowing unicode in GLchar*, but AFAIK that's our only pending 3.x enhancement. If we're a long way from compatibility I may as well push a 3.0.2 beta and plan for 3.0.3 to have Python3 compatibility. Have fun, Mike |
|
From: Rob R. <r.r...@sc...> - 2012-04-27 11:07:04
|
Hi, We noted that extension functions do not work properly in Py3 on Win32. The problem is that the function name is passed as a (unicode) str to Win32Platform.getExtensionProcedure (which is a static method referring to OpenGL.wglGetProcAddress), which is called from BasePlatform.constructFunction The solution is of course to encode the the name, the question is where to do this? I expect that all platforms that use getExtensionProcedure (those that have self.EXTENSIONS_USE_BASE_FUNCTIONS==False, i.e. Win32, GLX, OSMESA) have a function that expects bytes, not str. So I would propose to put pointer = self.getExtensionProcedure( as_8_bit(functionName) ) in BasePlatform.constructFunction. Should I go ahead and implement this and create a pull request, or should this be implemented somewhere else? Rob --------------------------------------------- Rob Reilink, M.Sc Science Applied phone: +31 6 187 26562 e-mail: r.r...@sc... --------------------------------------------- |
|
From: Almar K. <a....@sc...> - 2012-04-25 20:42:30
|
> As far as I know (but my OpenGL knowledge is limited) glGetString is > the only function that actually returns a string. There is also glGetInfoLog() -- Almar Klein, PhD Science Applied phone: +31 6 19268652 e-mail: a....@sc... |
|
From: SourceForge.net <no...@so...> - 2012-04-14 04:40:08
|
Bugs item #3517651, was opened at 2012-04-13 21:40 Message generated for change (Tracker Item Submitted) made by cjgohlke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3517651&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christoph Gohlke (cjgohlke) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for OpenGL_accelerate on win-amd64 Initial Comment: Currently OpenGL_accelerate tests fails on win-amd64. A patch is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3517651&group_id=5988 |
32 messages has been excluded from this view by a project administrator.
