Re: Possible bug in PyOpenGL wrapper of glGenTextures?

"Mike C. Fletcher" <[email protected]> Tue, 09 Sep 2014 09:05:42 -0400
Newsgroups gmane.comp.python.opengl.devel
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--===============3501277096610167356==
Content-Type: multipart/alternative;
	boundary="------------050006020702070603060906"

This is a multi-part message in MIME format.
--------------050006020702070603060906
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

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 
> <[email protected] <mailto:[email protected]>> 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
>     [email protected]
>     <mailto:[email protected]>
>     https://lists.sourceforge.net/lists/listinfo/pyopengl-devel
>
>


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


--------------050006020702070603060906
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">On 09/08/2014 06:31 PM, Karl Koscher
      wrote:<br>
    </div>
    <blockquote
cite=3D"mid:[email protected]=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">Thanks for the quick response. Attached is a simpl=
e
        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:</div>
    </blockquote>
    <br>
    Oh, that's *weird*, apparently the ulong type doesn't work the same
    way on win32?<br>
    <br>
    I'll have to get some time to boot into windows and look into that.<b=
r>
    <br>
    Thanks,<br>
    Mike<br>
    <br>
    <blockquote
cite=3D"mid:[email protected]=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>TypeError: ("No array-type handler for type &lt;class
            'ctypes.c_ulong'&gt; (value: c_ulong(0L)) registered",
            &lt;OpenGL.converters.CallFuncPyConverter object at
            0x041F6930&gt;)</div>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>I've also attached a patch which seems to fix the problem.</=
div>
        <div><br>
        </div>
        <div><br>
        </div>
      </div>
      <div class=3D"gmail_extra"><br>
        <div class=3D"gmail_quote">On Mon, Sep 8, 2014 at 6:34 AM, Mike C=
.
          Fletcher <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
              href=3D"mailto:[email protected]" target=3D"_blank">mc=
[email protected]</a>&gt;</span>
          wrote:<br>
          <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div text=3D"#000000" bgcolor=3D"#FFFFFF">
              <div>
                <div class=3D"h5">
                  <div>On 09/08/2014 03:48 AM, Karl Koscher wrote:<br>
                  </div>
                  <blockquote type=3D"cite">
                    <div dir=3D"ltr">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.
                      <div><br>
                      </div>
                      <div>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).=A0</div>
                      <div><br>
                      </div>
                      <div>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.<br>
                      </div>
                    </div>
                  </blockquote>
                  <br>
                </div>
              </div>
              In ctypes, passing in a &lt;ulong&gt; 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.=A0
              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.<br>
              <br>
              What would help is:<br>
              <ul>
                <li>report your (gnuradio and) PyOpenGL version</li>
                <li>include a traceback</li>
                <li>include the patch for what you changed to make it
                  work<br>
                </li>
              </ul>
              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.=A0 From what I can see
              gnuradio is only ever calling glGenTextures(1) in a very
              standard/simple way.<br>
              <br>
              Take care,<br>
              Mike<span class=3D"HOEnZb"><font color=3D"#888888"><br>
                  <br>
                  <pre cols=3D"72">--=20
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  <a moz-do-not-send=3D"true" href=3D"http://www.vrplumber.com" target=3D=
"_blank">http://www.vrplumber.com</a>
  <a moz-do-not-send=3D"true" href=3D"http://blog.vrplumber.com" target=3D=
"_blank">http://blog.vrplumber.com</a>
</pre>
                </font></span></div>
            <br>
-------------------------------------------------------------------------=
-----<br>
            Want excitement?<br>
            Manually upgrade your production database.<br>
            When you want reliability, choose Perforce<br>
            Perforce version control. Predictably reliable.<br>
            <a moz-do-not-send=3D"true"
href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D157508191&amp;iu=3D=
/4140/ostg.clktrk"
              target=3D"_blank">http://pubads.g.doubleclick.net/gampad/cl=
k?id=3D157508191&amp;iu=3D/4140/ostg.clktrk</a><br>
            _______________________________________________<br>
            PyOpenGL Homepage<br>
            <a moz-do-not-send=3D"true"
              href=3D"http://pyopengl.sourceforge.net" target=3D"_blank">=
http://pyopengl.sourceforge.net</a><br>
            _______________________________________________<br>
            PyOpenGL-Devel mailing list<br>
            <a moz-do-not-send=3D"true"
              href=3D"mailto:[email protected]">PyOpen=
[email protected]</a><br>
            <a moz-do-not-send=3D"true"
              href=3D"https://lists.sourceforge.net/lists/listinfo/pyopen=
gl-devel"
              target=3D"_blank">https://lists.sourceforge.net/lists/listi=
nfo/pyopengl-devel</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <br>
    <pre class=3D"moz-signature" cols=3D"72">--=20
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  <a class=3D"moz-txt-link-freetext" href=3D"http://www.vrplumber.com">ht=
tp://www.vrplumber.com</a>
  <a class=3D"moz-txt-link-freetext" href=3D"http://blog.vrplumber.com">h=
ttp://blog.vrplumber.com</a>
</pre>
  </body>
</html>

--------------050006020702070603060906--


--===============3501277096610167356==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
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
--===============3501277096610167356==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net
_______________________________________________
PyOpenGL-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyopengl-devel

--===============3501277096610167356==--