Re: [PyOpenGL-Devel] Possible bug in PyOpenGL wrapper of glGenTextures?

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

On 09/08/2014 06:31 PM, Karl Koscher wrote:
> Thanks for the quick response. Attached is a simple Python script 
> which will reproduce the bug without any special hardware. I'm running 
> gnuradio 3.7.2.2 and PyOpenGL 3.1.0a3 for Python 2.7. AFAIK this is 
> only a problem on Windows. Here's the traceback:

Oh, that's *weird*, apparently the ulong type doesn't work the same way 
on win32?

I'll have to get some time to boot into windows and look into that.

Thanks,
Mike

> TypeError: ("No array-type handler for type <class 'ctypes.c_ulong'> 
> (value: c_ulong(0L)) registered", 
> <OpenGL.converters.CallFuncPyConverter object at 0x041F6930>)
>
>
> I've also attached a patch which seems to fix the problem.
>
>
>
> On Mon, Sep 8, 2014 at 6:34 AM, Mike C. Fletcher 
> <mcf...@vr... <mailto:mcf...@vr...>> wrote:
>
>     On 09/08/2014 03:48 AM, Karl Koscher wrote:
>>     I'm running GNU Radio on Windows and was trying to figure out why
>>     the WX FFT display wasn't working. It looks like glGenTextures(1)
>>     is the culprit. An argument of 1 is special-cased for
>>     backwards-compatibility, but this seems to break. Commenting this
>>     special case out fixes the FFT display.
>>
>>     I think the problem is that a single ulong is passed in to the
>>     underlying function, but it always expects an array of ulongs. I
>>     think an array should still be passed in, with the first element
>>     of the array returned in the special case (instead of the array
>>     itself).
>>
>>     Of course, this is all voodoo magic to me, so perhaps there's a
>>     good reason for the code the way it is. It would be nice for it
>>     to work on Windows without hacking the code, though.
>
>     In ctypes, passing in a <ulong> variable acts as a single-element
>     *ulong, so that *shouldn't* be the issue. However, it is always
>     possible that we've got a bug in the handling. Thing is, I can't
>     see anything wrong with the gnuradio code, and without a traceback
>     or other error to tell me *what* went wrong, I can't investigate
>     further. I'm assuming that gnuradio would require a piece of
>     hardware to run, which suggests I wouldn't be able to reproduce
>     the error easily here.
>
>     What would help is:
>
>       * report your (gnuradio and) PyOpenGL version
>       * include a traceback
>       * include the patch for what you changed to make it work
>
>     It *looks* like the wrapper is actually entirely unneeded these
>     days (it basically duplicates the code in the automated wrapping),
>     but without knowing *how* the code is failing I can't actually be
>     sure eliminating the wrapper entirely would fix your problem. 
>     From what I can see gnuradio is only ever calling glGenTextures(1)
>     in a very standard/simple way.
>
>     Take care,
>     Mike
>
>     -- 
>     ________________________________________________
>        Mike C. Fletcher
>        Designer, VR Plumber, Coder
>        http://www.vrplumber.com
>        http://blog.vrplumber.com
>
>
>     ------------------------------------------------------------------------------
>     Want excitement?
>     Manually upgrade your production database.
>     When you want reliability, choose Perforce
>     Perforce version control. Predictably reliable.
>     http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>     _______________________________________________
>     PyOpenGL Homepage
>     http://pyopengl.sourceforge.net
>     _______________________________________________
>     PyOpenGL-Devel mailing list
>     PyO...@li...
>     <mailto:PyO...@li...>
>     https://lists.sourceforge.net/lists/listinfo/pyopengl-devel
>
>


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