pyopengl-devel Mailing List for PyOpenGL (Page 12)
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...> - 2009-07-19 00:20:54
|
Bugs item #2354582, was opened at 2008-11-27 21:17 Message generated for change (Settings changed) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2354582&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: Duplicate Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for tessellation combine callback Initial Comment: PyOpenGL 3.0.0b6 on WindowsXP x86 and Ubuntu 8.04 x86_64. Data generated in a GLU_TESS_COMBINE callback is lost. ---------------------------------------------------------------------- Comment By: Jonathan Harris (marginal42) Date: 2008-11-27 21:35 Message: Please delete - duplicate of 2354596 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2354582&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 00:20:14
|
Bugs item #2347624, was opened at 2008-11-25 20:28 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2347624&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: doc Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: project web page bad link Initial Comment: The link to the py2exe page is broken. On the web page: http://pyopengl.sourceforge.net/documentation/index.html The underlying HTML reads: <li><a href="file:///S:/PyOpenGLWebSite/documentation/py2exe.html">Using py2exe</a> with PyOpenGL and OpenGLContext -- building stand-alone executables for Win32 systems (note, not currently working with 3.x!)</li> The link should be: http://pyopengl.sourceforge.net/documentation/py2exe.html ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 20:20 Message: Appears to have been fixed at some point. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2347624&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 00:17:16
|
Bugs item #2354596, was opened at 2008-11-27 21:27 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2354596&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: Fixed Priority: 5 Private: No Submitted By: Jonathan Harris (marginal42) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for tessellation combine callback Initial Comment: PyOpenGL 3.0.0b6 on WindowsXP x86 and Ubuntu 8.04 x86_64. Data generated in a GLU_TESS_COMBINE callback is lost. Patch attached. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 20:17 Message: Sorry about the delay, I'm apparently not on the SF bug email list any more. Fixed in bzr head. Test integrated into test suite. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-17 02:01 Message: Why hasn't this patch been integrated? I wasted a few hours on this, until I found this patch and applied it to my PyOpenGL. ---------------------------------------------------------------------- Comment By: Jonathan Harris (marginal42) Date: 2008-11-27 21:34 Message: File Added: fixed.log ---------------------------------------------------------------------- Comment By: Jonathan Harris (marginal42) Date: 2008-11-27 21:33 Message: File Added: 3.0.0b6.log ---------------------------------------------------------------------- Comment By: Jonathan Harris (marginal42) Date: 2008-11-27 21:32 Message: File Added: fixed.log ---------------------------------------------------------------------- Comment By: Jonathan Harris (marginal42) Date: 2008-11-27 21:31 Message: File Added: 3.0.0b6.log ---------------------------------------------------------------------- Comment By: Jonathan Harris (marginal42) Date: 2008-11-27 21:30 Message: File Added: 2.0.2.01.log ---------------------------------------------------------------------- Comment By: Jonathan Harris (marginal42) Date: 2008-11-27 21:28 Message: File Added: tesstest.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2354596&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 00:08:17
|
Bugs item #2561765, was opened at 2009-02-03 14:26 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2561765&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: Andrew Straw (astraw) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong image size for glReadPixels() Initial Comment: I've been tracking down an error with the Vision Egg and PyOpenGL 3. (This code works fine with PyOpenGL 2.) The code that led me to this issue is line 476 of VisionEgg/Core.py [1], which is a call to glReadPixels(). Basically, doing glReadPixels with a format of GL_BGRA and type of GL_UNSIGNED_INT_8_8_8_8_REV returns an NxMx4 array of type uint32. I think this should either be an NxM(x1) array of type uint32 or an NxMx4 array of type uint8. The code at issue seems to be in OpenGL.images.createTargetArray(). It is responsible for creating the mis-sized array. I hesitate to suggest a patch, since I'm not sure what the optimal solution is, but this is at least a change of behavior since PyOpenGL 2. I am including a test which hopefully clarifies my thinking about the proper size of the array. [1] http://visionegg.org/trac/browser/tags/release_1.1.2/VisionEgg/Core.py#L476 ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 20:08 Message: Hi Andrew, thanks for the bug report, and particularly for the test case. I've added a table to the OpenGL.images module which enumerates the packed image types and overrides the calculation for their case, as well as checking that the format can hold the number of components specified (at least). bzr head has the fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2561765&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 00:05:56
|
Bugs item #2805305, was opened at 2009-06-12 04:37 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2805305&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: Nathan Dunfield (dunfield) Assigned to: Nobody/Anonymous (nobody) Summary: easy_install grabs dated version Initial Comment: easy_install installs 3.0.0c1 instead of 3.0.0 (final). I have duplicated this on a number of systems (OS X.5, Fedora 8, Ubuntu 9.04) with Python 2.5 and 2.6 and setuptools 0.6c9. Here's what easy_install is searching through (md5 numbers cutoff for readability): python2.5 -m easy_install -v PyOpenGL Searching for PyOpenGL Reading http://pypi.python.org/simple/PyOpenGL/ Reading http://pyopengl.sourceforge.net Reading https://sourceforge.net/project/showfiles.php?group_id=5988&package_id=6035 Reading http://pyopengl.sourceforge.net/ctypes/ Reading http://sourceforge.net/project/showfiles.php?group_id=5988 Found link: http://pypi.python.org/packages/source/P/PyOpenGL/PyOpenGL-3.0.0c1.zip#md5= Found link: http://pypi.python.org/packages/2.4/P/PyOpenGL/PyOpenGL-3.0.0a5-py2.4.egg# Found link: http://pypi.python.org/packages/source/P/PyOpenGL/PyOpenGL-3.0.0b6.zip# Found link: http://pypi.python.org/packages/source/P/PyOpenGL/PyOpenGL-3.0.0c1.tar.gz# Found link: http://pypi.python.org/packages/source/P/PyOpenGL/PyOpenGL-3.0.0a5.tar.gz# Found link: http://pypi.python.org/packages/2.5/P/PyOpenGL/PyOpenGL-3.0.0a5-py2.5.egg#md5= Found link: http://pypi.python.org/packages/source/P/PyOpenGL/PyOpenGL-3.0.0b6.tar.gz#md5= Found link: http://pypi.python.org/packages/source/P/PyOpenGL/PyOpenGL-3.0.0a5.zip#md5= Best match: PyOpenGL 3.0.0c1 Downloading http://pypi.python.org/packages/source/P/PyOpenGL/PyOpenGL-3.0.0c1.zip#md5= etc. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 18:49 Message: Looks like easy_install is preferring PyPI uploads to SF downloads? SF is the official source for the package, apparently uploading a few versions of PyPI was an anti-robustness measure :( . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2805305&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 00:04:45
|
Bugs item #2624787, was opened at 2009-02-21 13:12 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2624787&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 'posix ' should be 'posix' Initial Comment: in OpenGL/__init__.py, the line below has an extra space after posix, meaning it doesn't match. PlatformPlugin( 'posix ', 'OpenGL.platform.glx.GLXPlatform' ) ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 18:58 Message: Thanks, fixed in bzr head. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2624787&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 00:03:59
|
Bugs item #2795863, was opened at 2009-05-23 12:49 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2795863&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: Open Resolution: None Priority: 5 Private: No Submitted By: Graham Cummins (gic888) Assigned to: Nobody/Anonymous (nobody) Summary: gluNewQuadric fails with seg violation on recent Linux x86 Initial Comment: Any call to gluNewQuadric now seems to cause a segmentation violation immediately on recent versions of 32 bit x86 Linux. I have tested this on Ubuntu Jaunty, and Arch Linux with pacman updates more recent than ~4/1/09. Identical code runs normally on Ubuntu 8.04, Arch versions from 2008, and any version of Mac OS X. I thus assume this is a compatibility issue with recent changes in xorg or OpenGL. My app uses PyOpenGL 3.0.0 with the glcanvas context provided by wxWidgets 2.8.9.2. Based on my testing, however, I don't think wx is involved in the crash. I can duplicate the segv with 100% reliability in highly reduced scripts that call gluNewQuadric. I can also run the full program simply by commenting out the call to gluNewQuadric, and subsequently drawing points and lines instead of spheres and cylinders. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 18:08 Message: I've added an optional flag CHECK_CONTEXT, which will do explicit checks for context before running any function. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 17:39 Message: Ah, sorry, missed the comment. Recent X11 mesas are *very* picky about GL calls before context initialization, probably 3/4 of the OpenGL API will cause seg-faults if called before context init. Guess I need to be helping people with this somehow... ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 17:37 Message: Don't see the bug on 64-bit Ubuntu Jaunty with bzr head (Demo/NeHe/lesson18.py works), will have to get a 32-bit version to test with. ---------------------------------------------------------------------- Comment By: Graham Cummins (gic888) Date: 2009-07-02 19:56 Message: Workaround found: This failure does not occur if there is a currently active GL context with a defined size. My app uses a class that creates a Quadric on class initialization, which may occur before creating the GLCanvas the class will eventually draw in. My test scripts don't use a drawing context at all - just import GLU and call gluNewQuadric. If I postpone creation of the Quadric until after the GLCanvas is created, sized, and SetCurrent, then there is no problem. I am testing with the wxPython GLCanvas context. I guess the same behavior would apply to OpenGLContext, but I haven't tested that. I still consider this a minor bug, or at least a documentation failure. Creating a Quadric object (without using it to draw anything) shouldn't really require an active drawing context. It doesn't on Windows, Mac, and earlier versions of X11. If it is a new design decision to prevent this on X11 it should A) be documented somewhere, and B) fail with a Python exception, rather than a seg fault if possible. However, now that I know about this, it is a pretty easy workaround to simply create the Quadric only when it is needed to draw something immediately, so the segv doesn't pose any serious problems for me anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2795863&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 00:01:38
|
Bugs item #2646943, was opened at 2009-02-27 18:28 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2646943&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: missing "raise" in baseplatform.py Initial Comment: baseplatform.py line 94: "raise" missing in front of: AttributeError( """Extension %r available, but no pointer for function %r"""%(extension,functionName)) (found while trying to use pyglet and PyOpenGL at the same time) etm_at_blastnet.ee ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 18:56 Message: Thanks, fixed in PyOpenGL 3.0.1 (head) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2646943&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-18 23:31:12
|
Bugs item #2481594, was opened at 2009-01-01 19:03 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2481594&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: Nikolay (turki_bg) Assigned to: Nobody/Anonymous (nobody) Summary: Please distribute license.txt with the tarball Initial Comment: Part of the fedora guideline for packaging is that every package must provide some file with it's license. Up until b8 there was a license.txt in the root of the tarball. Please provide it again. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 19:31 Message: I've added the license.txt explicitly to the set of files included in the archive (MANIFEST.in). 3.0.1 will include it. ---------------------------------------------------------------------- Comment By: Nikolay (turki_bg) Date: 2009-06-09 15:43 Message: Any update? PyOpenGL has been packaged as an RPM for the Fedora Project. However, the distribution archive does not seem to include a copy of the full text(s) of the license(s) under which it is distributed. In general we like to include a copy of the license for programs we package, for the following reasons: * it is useful to other users who might download a tarball of your package to * be able to have a copy of the license at hand. * it ensures that the license is available offline * it ensures that there is no ambiguity about the license Although we could retrieve the source text from an alternate location and include that, this makes it more difficult to track changes you may make to the licensing in future and creates the possibility that we may inadvertently include an incorrect license. We very much want to avoid this. Therefore we would be grateful if you would consider including the full license text of all licenses that are applicable to the software with future versions. ---------------------------------------------------------------------- Comment By: Nikolay (turki_bg) Date: 2009-01-01 19:08 Message: To clarify the full legal text of the license must be provided by the package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2481594&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-18 23:26:18
|
Bugs item #2618251, was opened at 2009-02-19 20:22 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2618251&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: GLUT font error 'NoneType' object has no attribute '_handle' Initial Comment: >>> import OpenGL.GLUT GLUT font error 'NoneType' object has no attribute '_handle' GLUT font error 'NoneType' object has no attribute '_handle' GLUT font error 'NoneType' object has no attribute '_handle' GLUT font error 'NoneType' object has no attribute '_handle' GLUT font error 'NoneType' object has no attribute '_handle' GLUT font error 'NoneType' object has no attribute '_handle' GLUT font error 'NoneType' object has no attribute '_handle' GLUT font error 'NoneType' object has no attribute '_handle' GLUT font error 'NoneType' object has no attribute '_handle' on Debian "Lenny" Stable v5.0 ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 19:26 Message: Using log instead of print now so that the warning can be suppressed, also only logging warning if GLUT loaded in the first place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2618251&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-18 23:19:03
|
Bugs item #2727274, was opened at 2009-04-02 15:46 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2727274&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Francois Lagunas (flagunas) Assigned to: Nobody/Anonymous (nobody) Summary: glDeleteFramebuffersEXT Bug Initial Comment: The glDeleteFramebuffersEXT does not seem to work. The bug lead to an opengl "out of memory" error when allocating and disallocating a large number of fbos (~ 200 ). In the attachement, a C++ version is included for comparison : the fbo id is recycled and then reused after glDeleteFramebuffersEXT is called, but not in the python version. This is true for at least the 3.0.0 version . ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 19:18 Message: Running your original code on Linux AMD64 with the PyOpenGL bzr head, the code works and the IDs are recycled (that is, no silent failure observed). Wrappers have also been added so you can pass any of the raw uint, an array or the list as a single value to the delete operations. ARB version has been similarly wrapped. ---------------------------------------------------------------------- Comment By: Francois Lagunas (flagunas) Date: 2009-04-02 16:48 Message: My bad but ... You have to call the glDeleteFramebuffersEXT this way : fbo_id0, fbo_id1 = EXT.glGenFramebuffersEXT(1) glDeleteRenderbuffersEXT (1, numpy.array(fbo_id0)) or glDeleteRenderbuffersEXT (2, numpy.array([fbo_id0, fbo_id1])) and not glDeleteRenderbuffersEXT (1, [int(fbo_id)]) which fails silently ... The doc is very sparse on the subject, and the fact that it fails silently is not very cool ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2727274&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-18 22:47:05
|
Bugs item #2813722, was opened at 2009-06-28 22:11 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2813722&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: FreeGLUT integration issues Initial Comment: Working with with FreeGLUT 2.6.0 rc1 and having this issues: * Missing entries for OpenGL 3.x context in OpenGL.GLUT.freeglut.py GLUT_INIT_MAJOR_VERSION, GLUT_INIT_MINOR_VERSION, GLUT_INIT_FLAGS, GLUT_DEBUG, GLUT_FORWARD_COMPATIBLE glutInitContextVersion( int(majorVersion), int(minorVersion) ), glutInitContextFlags( int(flags) ) I know it's a release candidate, but it's not like it will change that much. * Inverted assignment for HAVE_FREEGLUT variable in OpenGL.GLUT.__init__.py Why "HAVE_FREEGLUT = False" when freeglut was successfully imported? * FreeGLUT does not have __glutCreateWindowWithExit entry used in OpenGL.GLUT.special.py This could use the HAVE_FREEGLUT var above to avoid the call delegation and error. * The OpenGL module only checks for glut32[.dll] (windows) and not freeglut[.dll] (or freeglut32). I have compiled freeglut and renamed to glut32 to use it without changing much code. It would be nice to have both in the system and selectable.... ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 18:46 Message: Have begun work on this. The constants are added, though they do not appear in my version of FreeGLUT. I've added the freeglut and freeglut32 dll names, but at the moment I don't have them selectable. The HAVE_FREEGLUT flag should be properly set now, and the wrapper operations should only occur if __glutCreateWindowWithExit exists (so should not occur for freeglut). Will need to test the changes on Win32, of course. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2813722&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-18 21:39:48
|
Bugs item #2795863, was opened at 2009-05-23 12:49 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2795863&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: Open Resolution: None Priority: 5 Private: No Submitted By: Graham Cummins (gic888) Assigned to: Nobody/Anonymous (nobody) Summary: gluNewQuadric fails with seg violation on recent Linux x86 Initial Comment: Any call to gluNewQuadric now seems to cause a segmentation violation immediately on recent versions of 32 bit x86 Linux. I have tested this on Ubuntu Jaunty, and Arch Linux with pacman updates more recent than ~4/1/09. Identical code runs normally on Ubuntu 8.04, Arch versions from 2008, and any version of Mac OS X. I thus assume this is a compatibility issue with recent changes in xorg or OpenGL. My app uses PyOpenGL 3.0.0 with the glcanvas context provided by wxWidgets 2.8.9.2. Based on my testing, however, I don't think wx is involved in the crash. I can duplicate the segv with 100% reliability in highly reduced scripts that call gluNewQuadric. I can also run the full program simply by commenting out the call to gluNewQuadric, and subsequently drawing points and lines instead of spheres and cylinders. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 17:39 Message: Ah, sorry, missed the comment. Recent X11 mesas are *very* picky about GL calls before context initialization, probably 3/4 of the OpenGL API will cause seg-faults if called before context init. Guess I need to be helping people with this somehow... ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 17:37 Message: Don't see the bug on 64-bit Ubuntu Jaunty with bzr head (Demo/NeHe/lesson18.py works), will have to get a 32-bit version to test with. ---------------------------------------------------------------------- Comment By: Graham Cummins (gic888) Date: 2009-07-02 19:56 Message: Workaround found: This failure does not occur if there is a currently active GL context with a defined size. My app uses a class that creates a Quadric on class initialization, which may occur before creating the GLCanvas the class will eventually draw in. My test scripts don't use a drawing context at all - just import GLU and call gluNewQuadric. If I postpone creation of the Quadric until after the GLCanvas is created, sized, and SetCurrent, then there is no problem. I am testing with the wxPython GLCanvas context. I guess the same behavior would apply to OpenGLContext, but I haven't tested that. I still consider this a minor bug, or at least a documentation failure. Creating a Quadric object (without using it to draw anything) shouldn't really require an active drawing context. It doesn't on Windows, Mac, and earlier versions of X11. If it is a new design decision to prevent this on X11 it should A) be documented somewhere, and B) fail with a Python exception, rather than a seg fault if possible. However, now that I know about this, it is a pretty easy workaround to simply create the Quadric only when it is needed to draw something immediately, so the segv doesn't pose any serious problems for me anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2795863&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-18 21:37:51
|
Bugs item #2795863, was opened at 2009-05-23 12:49 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2795863&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: Open Resolution: None Priority: 5 Private: No Submitted By: Graham Cummins (gic888) Assigned to: Nobody/Anonymous (nobody) Summary: gluNewQuadric fails with seg violation on recent Linux x86 Initial Comment: Any call to gluNewQuadric now seems to cause a segmentation violation immediately on recent versions of 32 bit x86 Linux. I have tested this on Ubuntu Jaunty, and Arch Linux with pacman updates more recent than ~4/1/09. Identical code runs normally on Ubuntu 8.04, Arch versions from 2008, and any version of Mac OS X. I thus assume this is a compatibility issue with recent changes in xorg or OpenGL. My app uses PyOpenGL 3.0.0 with the glcanvas context provided by wxWidgets 2.8.9.2. Based on my testing, however, I don't think wx is involved in the crash. I can duplicate the segv with 100% reliability in highly reduced scripts that call gluNewQuadric. I can also run the full program simply by commenting out the call to gluNewQuadric, and subsequently drawing points and lines instead of spheres and cylinders. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-18 17:37 Message: Don't see the bug on 64-bit Ubuntu Jaunty with bzr head (Demo/NeHe/lesson18.py works), will have to get a 32-bit version to test with. ---------------------------------------------------------------------- Comment By: Graham Cummins (gic888) Date: 2009-07-02 19:56 Message: Workaround found: This failure does not occur if there is a currently active GL context with a defined size. My app uses a class that creates a Quadric on class initialization, which may occur before creating the GLCanvas the class will eventually draw in. My test scripts don't use a drawing context at all - just import GLU and call gluNewQuadric. If I postpone creation of the Quadric until after the GLCanvas is created, sized, and SetCurrent, then there is no problem. I am testing with the wxPython GLCanvas context. I guess the same behavior would apply to OpenGLContext, but I haven't tested that. I still consider this a minor bug, or at least a documentation failure. Creating a Quadric object (without using it to draw anything) shouldn't really require an active drawing context. It doesn't on Windows, Mac, and earlier versions of X11. If it is a new design decision to prevent this on X11 it should A) be documented somewhere, and B) fail with a Python exception, rather than a seg fault if possible. However, now that I know about this, it is a pretty easy workaround to simply create the Quadric only when it is needed to draw something immediately, so the segv doesn't pose any serious problems for me anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2795863&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-05 23:46:53
|
Bugs item #2817196, was opened at 2009-07-05 23:46 Message generated for change (Tracker Item Submitted) made by astraw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2817196&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GL Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrew Straw (astraw) Assigned to: Nobody/Anonymous (nobody) Summary: regression: multitexturing broken in 3.0.0 Initial Comment: I've been trying to track down a regression in multitexturing that happens on Windows with PyOpenGL3. I get the same issue with Python2.5 and Python2.6, and it goes away when I test on Python2.5 with PyOpenGL 2.0.2.01. I don't get this error on Linux. Running the old NeHe demo "lesson6-multi.py" I found in a local copy of PyOpenGL-2.0.1.09 (in PyOpenGL-2.0.1.09/OpenGL/Demo/NeHe/), I get this traceback: Z:\test>c:\python25\python lesson6-multi.py Hit ESC key to quit. Traceback (most recent call last): File "c:\python25\lib\site-packages\OpenGL\GLUT\special.py", line 113, in safe Call return function( *args, **named ) File "lesson6-multi.py", line 189, in DrawGLScene glEnd(); # Done Drawing The Cube File "c:\python25\lib\site-packages\OpenGL\lazywrapper.py", line 9, in __call_ _ return wrapper( baseFunction, *args, **named ) File "c:\python25\lib\site-packages\OpenGL\GL\exceptional.py", line 57, in glE nd return baseFunction( ) File "c:\python25\lib\site-packages\OpenGL\error.py", line 194, in glCheckErro r baseOperation = baseOperation, GLError: GLError( err = 1282, description = 'invalid operation', baseOperation = glEnd, cArguments = () ) GLUT Idle callback <function DrawGLScene at 0x00D47830> with (),{} failed: retur ning None GLError( err = 1282, description = 'invalid operation', baseOperation = glEnd, cArguments = () ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2817196&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-02 23:56:42
|
Bugs item #2795863, was opened at 2009-05-23 10:49 Message generated for change (Comment added) made by gic888 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2795863&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: Open Resolution: None Priority: 5 Private: No Submitted By: Graham Cummins (gic888) Assigned to: Nobody/Anonymous (nobody) Summary: gluNewQuadric fails with seg violation on recent Linux x86 Initial Comment: Any call to gluNewQuadric now seems to cause a segmentation violation immediately on recent versions of 32 bit x86 Linux. I have tested this on Ubuntu Jaunty, and Arch Linux with pacman updates more recent than ~4/1/09. Identical code runs normally on Ubuntu 8.04, Arch versions from 2008, and any version of Mac OS X. I thus assume this is a compatibility issue with recent changes in xorg or OpenGL. My app uses PyOpenGL 3.0.0 with the glcanvas context provided by wxWidgets 2.8.9.2. Based on my testing, however, I don't think wx is involved in the crash. I can duplicate the segv with 100% reliability in highly reduced scripts that call gluNewQuadric. I can also run the full program simply by commenting out the call to gluNewQuadric, and subsequently drawing points and lines instead of spheres and cylinders. ---------------------------------------------------------------------- >Comment By: Graham Cummins (gic888) Date: 2009-07-02 17:56 Message: Workaround found: This failure does not occur if there is a currently active GL context with a defined size. My app uses a class that creates a Quadric on class initialization, which may occur before creating the GLCanvas the class will eventually draw in. My test scripts don't use a drawing context at all - just import GLU and call gluNewQuadric. If I postpone creation of the Quadric until after the GLCanvas is created, sized, and SetCurrent, then there is no problem. I am testing with the wxPython GLCanvas context. I guess the same behavior would apply to OpenGLContext, but I haven't tested that. I still consider this a minor bug, or at least a documentation failure. Creating a Quadric object (without using it to draw anything) shouldn't really require an active drawing context. It doesn't on Windows, Mac, and earlier versions of X11. If it is a new design decision to prevent this on X11 it should A) be documented somewhere, and B) fail with a Python exception, rather than a seg fault if possible. However, now that I know about this, it is a pretty easy workaround to simply create the Quadric only when it is needed to draw something immediately, so the segv doesn't pose any serious problems for me anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2795863&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-07-01 17:42:52
|
Bugs item #1227249, was opened at 2005-06-24 20:49 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1227249&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: doc Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Laxori666 (laxori666) Assigned to: Mike C. Fletcher (mcfletch) Summary: documentation is incorrect Initial Comment: The documentation for py2exe instructions says that you should stop py2exe from including OpenGL and then include it manually later. I tried this and had tons of hassle. Then I simply removed the --excludes=OpenGL line and my program worked perfectly. I think the documentation should be modified to reflect the fact that py2exe now indeed does work fine with OpenGL's import hooks. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-07-01 17:42 Message: For the record, I tested it and the generated executable works if PyOpenGL isn't installed. ---------------------------------------------------------------------- Comment By: BrammO (bgeron) Date: 2009-06-30 20:53 Message: I downloaded PyOpenGL and py2exe this week, used the PyOpenGL documentation[1] to get it working, but it failed. Also Laxori666's tip of not doing anything special didn't work. After a few hours of trying, I found out a workaround for the strange errors that appeared: - add the current directory to sys.path - copy the whole PyOpenGL package directory to the dist/ directory, and ship it with the binary I explained it on the py2exe wiki[2]. I'm not entirely sure if it works on machines where PyOpenGL wasn't installed, but I have good confidence. If not, I'll comment again. It would be cool if that page was linked to, or the information merged with the PyOpenGL documentation, to save others some clueless hours of trying to get anything working at all. :) If you want more information on the errors that appeared, I can give you them in a few days. [1]: http://pyopengl.sourceforge.net/documentation/py2exe.html [2]: http://www.py2exe.org/index.cgi/PyOpenGL ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2005-07-16 23:56 Message: Logged In: YES user_id=34901 Okay, have added a note to the py2exe page to this effect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1227249&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-06-30 20:53:28
|
Bugs item #1227249, was opened at 2005-06-24 22:49 Message generated for change (Comment added) made by bgeron You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1227249&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: doc Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Laxori666 (laxori666) Assigned to: Mike C. Fletcher (mcfletch) Summary: documentation is incorrect Initial Comment: The documentation for py2exe instructions says that you should stop py2exe from including OpenGL and then include it manually later. I tried this and had tons of hassle. Then I simply removed the --excludes=OpenGL line and my program worked perfectly. I think the documentation should be modified to reflect the fact that py2exe now indeed does work fine with OpenGL's import hooks. ---------------------------------------------------------------------- Comment By: BrammO (bgeron) Date: 2009-06-30 22:53 Message: I downloaded PyOpenGL and py2exe this week, used the PyOpenGL documentation[1] to get it working, but it failed. Also Laxori666's tip of not doing anything special didn't work. After a few hours of trying, I found out a workaround for the strange errors that appeared: - add the current directory to sys.path - copy the whole PyOpenGL package directory to the dist/ directory, and ship it with the binary I explained it on the py2exe wiki[2]. I'm not entirely sure if it works on machines where PyOpenGL wasn't installed, but I have good confidence. If not, I'll comment again. It would be cool if that page was linked to, or the information merged with the PyOpenGL documentation, to save others some clueless hours of trying to get anything working at all. :) If you want more information on the errors that appeared, I can give you them in a few days. [1]: http://pyopengl.sourceforge.net/documentation/py2exe.html [2]: http://www.py2exe.org/index.cgi/PyOpenGL ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2005-07-17 01:56 Message: Logged In: YES user_id=34901 Okay, have added a note to the py2exe page to this effect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1227249&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-06-29 02:11:38
|
Bugs item #2813722, was opened at 2009-06-29 02:11 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2813722&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: FreeGLUT integration issues Initial Comment: Working with with FreeGLUT 2.6.0 rc1 and having this issues: * Missing entries for OpenGL 3.x context in OpenGL.GLUT.freeglut.py GLUT_INIT_MAJOR_VERSION, GLUT_INIT_MINOR_VERSION, GLUT_INIT_FLAGS, GLUT_DEBUG, GLUT_FORWARD_COMPATIBLE glutInitContextVersion( int(majorVersion), int(minorVersion) ), glutInitContextFlags( int(flags) ) I know it's a release candidate, but it's not like it will change that much. * Inverted assignment for HAVE_FREEGLUT variable in OpenGL.GLUT.__init__.py Why "HAVE_FREEGLUT = False" when freeglut was successfully imported? * FreeGLUT does not have __glutCreateWindowWithExit entry used in OpenGL.GLUT.special.py This could use the HAVE_FREEGLUT var above to avoid the call delegation and error. * The OpenGL module only checks for glut32[.dll] (windows) and not freeglut[.dll] (or freeglut32). I have compiled freeglut and renamed to glut32 to use it without changing much code. It would be nice to have both in the system and selectable.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2813722&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-06-12 08:38:19
|
Bugs item #2805305, was opened at 2009-06-12 03:37 Message generated for change (Tracker Item Submitted) made by dunfield You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2805305&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: Nathan Dunfield (dunfield) Assigned to: Nobody/Anonymous (nobody) Summary: easy_install grabs dated version Initial Comment: easy_install installs 3.0.0c1 instead of 3.0.0 (final). I have duplicated this on a number of systems (OS X.5, Fedora 8, Ubuntu 9.04) with Python 2.5 and 2.6 and setuptools 0.6c9. Here's what easy_install is searching through (md5 numbers cutoff for readability): python2.5 -m easy_install -v PyOpenGL Searching for PyOpenGL Reading http://pypi.python.org/simple/PyOpenGL/ Reading http://pyopengl.sourceforge.net Reading https://sourceforge.net/project/showfiles.php?group_id=5988&package_id=6035 Reading http://pyopengl.sourceforge.net/ctypes/ Reading http://sourceforge.net/project/showfiles.php?group_id=5988 Found link: http://pypi.python.org/packages/source/P/PyOpenGL/PyOpenGL-3.0.0c1.zip#md5= Found link: http://pypi.python.org/packages/2.4/P/PyOpenGL/PyOpenGL-3.0.0a5-py2.4.egg# Found link: http://pypi.python.org/packages/source/P/PyOpenGL/PyOpenGL-3.0.0b6.zip# Found link: http://pypi.python.org/packages/source/P/PyOpenGL/PyOpenGL-3.0.0c1.tar.gz# Found link: http://pypi.python.org/packages/source/P/PyOpenGL/PyOpenGL-3.0.0a5.tar.gz# Found link: http://pypi.python.org/packages/2.5/P/PyOpenGL/PyOpenGL-3.0.0a5-py2.5.egg#md5= Found link: http://pypi.python.org/packages/source/P/PyOpenGL/PyOpenGL-3.0.0b6.tar.gz#md5= Found link: http://pypi.python.org/packages/source/P/PyOpenGL/PyOpenGL-3.0.0a5.zip#md5= Best match: PyOpenGL 3.0.0c1 Downloading http://pypi.python.org/packages/source/P/PyOpenGL/PyOpenGL-3.0.0c1.zip#md5= etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2805305&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-06-09 19:43:40
|
Bugs item #2481594, was opened at 2009-01-02 02:03 Message generated for change (Comment added) made by turki_bg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2481594&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: Nikolay (turki_bg) Assigned to: Nobody/Anonymous (nobody) Summary: Please distribute license.txt with the tarball Initial Comment: Part of the fedora guideline for packaging is that every package must provide some file with it's license. Up until b8 there was a license.txt in the root of the tarball. Please provide it again. ---------------------------------------------------------------------- >Comment By: Nikolay (turki_bg) Date: 2009-06-09 22:43 Message: Any update? PyOpenGL has been packaged as an RPM for the Fedora Project. However, the distribution archive does not seem to include a copy of the full text(s) of the license(s) under which it is distributed. In general we like to include a copy of the license for programs we package, for the following reasons: * it is useful to other users who might download a tarball of your package to * be able to have a copy of the license at hand. * it ensures that the license is available offline * it ensures that there is no ambiguity about the license Although we could retrieve the source text from an alternate location and include that, this makes it more difficult to track changes you may make to the licensing in future and creates the possibility that we may inadvertently include an incorrect license. We very much want to avoid this. Therefore we would be grateful if you would consider including the full license text of all licenses that are applicable to the software with future versions. ---------------------------------------------------------------------- Comment By: Nikolay (turki_bg) Date: 2009-01-02 02:08 Message: To clarify the full legal text of the license must be provided by the package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2481594&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-05-31 13:33:27
|
Bugs item #2798902, was opened at 2009-05-30 20:06 Message generated for change (Comment added) made by stephanhouben 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: Open Resolution: None 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: Stephan Houben (stephanhouben) Date: 2009-05-31 15: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 |
|
From: SourceForge.net <no...@so...> - 2009-05-30 18:06:35
|
Bugs item #2798902, was opened at 2009-05-30 20:06 Message generated for change (Tracker Item Submitted) made by stephanhouben 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: Open Resolution: None 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2798902&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-05-23 16:50:02
|
Bugs item #2795863, was opened at 2009-05-23 10:49 Message generated for change (Tracker Item Submitted) made by gic888 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2795863&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: Open Resolution: None Priority: 5 Private: No Submitted By: Graham Cummins (gic888) Assigned to: Nobody/Anonymous (nobody) Summary: gluNewQuadric fails with seg violation on recent Linux x86 Initial Comment: Any call to gluNewQuadric now seems to cause a segmentation violation immediately on recent versions of 32 bit x86 Linux. I have tested this on Ubuntu Jaunty, and Arch Linux with pacman updates more recent than ~4/1/09. Identical code runs normally on Ubuntu 8.04, Arch versions from 2008, and any version of Mac OS X. I thus assume this is a compatibility issue with recent changes in xorg or OpenGL. My app uses PyOpenGL 3.0.0 with the glcanvas context provided by wxWidgets 2.8.9.2. Based on my testing, however, I don't think wx is involved in the crash. I can duplicate the segv with 100% reliability in highly reduced scripts that call gluNewQuadric. I can also run the full program simply by commenting out the call to gluNewQuadric, and subsequently drawing points and lines instead of spheres and cylinders. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2795863&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2009-05-05 01:17:10
|
Bugs item #2300218, was opened at 2008-11-16 19:02 Message generated for change (Comment added) made by nobody 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: Open Resolution: None 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: Nobody/Anonymous (nobody) Date: 2009-05-05 01:17 Message: thanks for the work around ---------------------------------------------------------------------- Comment By: Lino Mastrodomenico (mastrodomenico) Date: 2009-04-30 21:28 Message: A workaround is to install python-numpy (tested on Ubuntu 9.04). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-26 21: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 13: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 23: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 |
32 messages has been excluded from this view by a project administrator.
