Re: Back again
Balazs Komuves <[email protected]> Mon, 22 Jul 2013 17:05:48 +0200
| Newsgroups | gmane.comp.lang.haskell.hopengl |
|---|---|
| Message-ID | <CAHZd2p=LPDbuXCYcOR6Nk+dUO0pBLpAzrbAjGEbnf=062b71tw@mail.gmail.com> |
--===============6312313177344043116== Content-Type: multipart/alternative; boundary=089e0158caf2f1190304e21b0213 --089e0158caf2f1190304e21b0213 Content-Type: text/plain; charset=UTF-8 Sven, first of all it's very nice to see you back again! HOpenGL was one of my early, and influential Haskell experiences. I prefer one big package opposed to separate StateVar etc, but that's just a subjective opinion. The newtypes (GLDouble etc) are both inconvenient and very slow because GHC sees fromRational/toRational which it cannot optimize away. In my personal projects I actually used unsafeCoerce, which kind of illustrates the seriousness of this issue... I fully agree with supporting old-school OpenGL, it's much much easier to start with than modern OpenGL. I'm not up to date with the latest versions, both because I don't really have modern hardware, and because I use what is basically a fork of the old version (with render-to-texture and other stuff added). It's probably horribly outdated, but in any case, I think the patches are here: http://code.haskell.org/~bkomuves/hopengl_2009-03-13.patch Offtopic, but examples of "real-world" Haskell OpenGL stuff can be seen here: http://moire.be/misszio/ (almost all of that is Haskell, sometimes with minor C code) Balazs On Mon, Jul 22, 2013 at 11:23 AM, Sven Panne <[email protected]> wrote: > After a few HOpenGL-free years caused by personal and job-related > circumstances, I'd like to work on this again. First of thanks to all > the people involved in keeping the binding alive, especially Jason! > Having the packages in the Haskell platform is simply great, because > it improves the visibility of the binding a lot and will keep new > users (and new bug reports ;-) coming. > > I've browsed through the mailing list archives, so here are a few > miscellaneous remarks: > > * The StateVar/Tensor/ObjectName packages are now in the OpenGL > package itself (in a different namespace), and the previous standalone > packages are still available, too. Although I don't think it is a > perfect solution, it was probably done to get the OpenGL packages into > the Haskell platform, right? If this was the motivation, I think the > price to pay was well worth it. The OpenAL/ALUT packages use the > assimilated packages, too, so I should probably update the former ones > to use the latter ones. This will introduce a dependency of > OpenAL/ALUT on OpenGL, something I wanted to avoid. But I think there > are very few programs using OpenAL without OpenGL, and the latter is > now universally available via the Haskell platformm, so this should be > the right way to proceed. > > * What was the exact motivation for using type synonyms instead of > the former renamings (newtypes) for the OpenGL types? Were there any > *real* problems or only potential/hypothetical ones? I am a bit torn > between those alternatives, so I'd like to learn the experience of > other people, including their opinions. > > * The examples have bit-rotted, e.g. SmoothOpenGL3.hs yields an > InvalidOperation in triangle's vertexAttribPointer calls, 'catch' > should probably be replaced by Control.Exception.{catch,IOException}, > etc. Apart from fixing them, having GLUT versions of nehe-tuts in the > GLUT package would be great. I really like the idea of GLUT being a > one-stop-shop for tons of examples regarding the usage of the > OpenGL/OpenGLRaw packages. > > * Currently the binding doesn't work out-of-the box with ghci on > Ubuntu 12.04 if you have NVIDIA drivers installed in addition to the > Mesa ones. I have an ugly fix (adding /usr/lib/nvidia/current to > OpenGLRaw's library-dirs), but I'd like to solve this more cleanly. > More about this in a separate mail. > > * Finally Khronos has released the OpenGL registry in a less > braindead format > ( > http://www.opengl.org/discussion_boards/showthread.php/181927-New-XML-based-API-Registry-released?p=1251759 > ), > so there is a good chance now that the OpenGLRaw package can be > completely autogenerated, something I wanted to do for ages. Judging > from the HOpenGL mailing list, Lars is already looking into it, so > let's coordinate our efforts here, preferably in a separate mail > thread. My main concerns here are: Include the generator (plus > pre-generated bindings) in the OpenGLRaw package, it really belongs > there. Don't put anything clever into OpenGLRaw, it should really, > really be a plain, straightforward 1:1 mapping of the registry. No > name mangling, structural modifications etc. apart from things > automatically derivable from the XML registry. A big question remains: > Can we generate the (un-)marshaling functions already in OpenGLRaw? > The XML registry has <groups>/<group> tags, but I fear that they are > still too incomplete/incorrect to be of any use for the Haskell > binding. On the positive side, I think that it should be possible to > upstream changes to the registry to make it more useful in general. I > had contact with Jon Leech in the past, and he has always been very > open and helpful. > > * Given the fact that OpenGL 4.3 is quite different from OpenGL in > the "old days", there are quite a few design decisions in the OpenGL > (convenience) package that I would do differently nowadays. But I > think with the feedback from the community we can gradually tweak this > layer to something more useful and up-to-date. Perhaps we can somehow > re-arrange things to be more in line with OpenGL versions/profiles, > but whatever we do, we should not drop support for "old skool" OpenGL, > there are *tons* of tutorials, books and courses relying on it, and > even NVIDIA has effectively promised to support this forever. > > Cheers, > S. > > _______________________________________________ > HOpenGL mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/hopengl > --089e0158caf2f1190304e21b0213 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div><div><div><br>Sven, first of all it's very n= ice to see you back again! HOpenGL was one of my early, and influential Has= kell experiences.<br><br></div><div>I prefer one big package opposed to sep= arate StateVar etc, but that's just a subjective opinion.<br> </div><div><br></div>The newtypes (GLDouble etc) are both inconvenient and = very slow because GHC sees fromRational/toRational which it cannot optimize= away. In my personal projects I actually used unsafeCoerce, which kind of = illustrates the seriousness of this issue... <br> <br></div><div>I fully agree with supporting old-school OpenGL, it's mu= ch much easier to start with than modern OpenGL.<br><br></div>I'm not u= p to date with the latest versions, both because I don't really have mo= dern hardware, and because I use what is basically a fork of the old versio= n (with render-to-texture and other stuff added). It's probably horribl= y outdated, but in any case, I think the patches are here: <a href=3D"http:= //code.haskell.org/~bkomuves/hopengl_2009-03-13.patch">http://code.haskell.= org/~bkomuves/hopengl_2009-03-13.patch</a><br> <br></div>Offtopic, but examples of "real-world" Haskell OpenGL s= tuff can be seen here: <a href=3D"http://moire.be/misszio/">http://moire.be= /misszio/</a> (almost all of that is Haskell, sometimes with minor C code)<= br> <br></div>Balazs<br><br></div><div class=3D"gmail_extra"><br><br><div class= =3D"gmail_quote">On Mon, Jul 22, 2013 at 11:23 AM, Sven Panne <span dir=3D"= ltr"><<a href=3D"mailto:[email protected]" target=3D"_blank">svenpanne= @gmail.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">After a few HOpenGL-free years caused by per= sonal and job-related<br> circumstances, I'd like to work on this again. First of thanks to all<b= r> the people involved in keeping the binding alive, especially Jason!<br> Having the packages in the Haskell platform is simply great, because<br> it improves the visibility of the binding a lot and will keep new<br> users (and new bug reports ;-) coming.<br> <br> I've browsed through the mailing list archives, so here are a few<br> miscellaneous remarks:<br> <br> =C2=A0* =C2=A0The StateVar/Tensor/ObjectName packages are now in the OpenGL= <br> package itself (in a different namespace), and the previous standalone<br> packages are still available, too. Although I don't think it is a<br> perfect solution, it was probably done to get the OpenGL packages into<br> the Haskell platform, right? If this was the motivation, I think the<br> price to pay was well worth it. The OpenAL/ALUT packages use the<br> assimilated packages, too, so I should probably update the former ones<br> to use the latter ones. This will introduce a dependency of<br> OpenAL/ALUT on OpenGL, something I wanted to avoid. But I think there<br> are very few programs using OpenAL without OpenGL, and the latter is<br> now universally available via the Haskell platformm, so this should be<br> the right way to proceed.<br> <br> =C2=A0* What was the exact motivation for using type synonyms instead of<br= > the former renamings (newtypes) for the OpenGL types? Were there any<br> *real* problems or only potential/hypothetical ones? I am a bit torn<br> between those alternatives, so I'd like to learn the experience of<br> other people, including their opinions.<br> <br> =C2=A0* The examples have bit-rotted, e.g. SmoothOpenGL3.hs yields an<br> InvalidOperation in triangle's vertexAttribPointer calls, 'catch= 9;<br> should probably be replaced by Control.Exception.{catch,IOException},<br> etc. Apart from fixing them, having GLUT versions of nehe-tuts in the<br> GLUT package would be great. I really like the idea of GLUT being a<br> one-stop-shop for tons of examples regarding the usage of the<br> OpenGL/OpenGLRaw packages.<br> <br> =C2=A0* Currently the binding doesn't work out-of-the box with ghci on<= br> Ubuntu 12.04 if you have NVIDIA drivers installed in addition to the<br> Mesa ones. I have an ugly fix (adding /usr/lib/nvidia/current to<br> OpenGLRaw's library-dirs), but I'd like to solve this more cleanly.= <br> More about this in a separate mail.<br> <br> =C2=A0* Finally Khronos has released the OpenGL registry in a less<br> braindead format<br> (<a href=3D"http://www.opengl.org/discussion_boards/showthread.php/181927-N= ew-XML-based-API-Registry-released?p=3D1251759" target=3D"_blank">http://ww= w.opengl.org/discussion_boards/showthread.php/181927-New-XML-based-API-Regi= stry-released?p=3D1251759</a>),<br> so there is a good chance now that the OpenGLRaw package can be<br> completely autogenerated, something I wanted to do for ages. Judging<br> from the HOpenGL mailing list, Lars is already looking into it, so<br> let's coordinate our efforts here, preferably in a separate mail<br> thread. My main concerns here are: Include the generator (plus<br> pre-generated bindings) in the OpenGLRaw package, it really belongs<br> there. Don't put anything clever into OpenGLRaw, it should really,<br> really be a plain, straightforward 1:1 mapping of the registry. No<br> name mangling, structural modifications etc. apart from things<br> automatically derivable from the XML registry. A big question remains:<br> Can we generate the (un-)marshaling functions already in OpenGLRaw?<br> The XML registry has <groups>/<group> tags, but I fear that the= y are<br> still too incomplete/incorrect to be of any use for the Haskell<br> binding. On the positive side, I think that it should be possible to<br> upstream changes to the registry to make it more useful in general. I<br> had contact with Jon Leech in the past, and he has always been very<br> open and helpful.<br> <br> =C2=A0* Given the fact that OpenGL 4.3 is quite different from OpenGL in<br= > the "old days", there are quite a few design decisions in the Ope= nGL<br> (convenience) package that I would do differently nowadays. But I<br> think with the feedback from the community we can gradually tweak this<br> layer to something more useful and up-to-date. Perhaps we can somehow<br> re-arrange things to be more in line with OpenGL versions/profiles,<br> but whatever we do, we should not drop support for "old skool" Op= enGL,<br> there are *tons* of tutorials, books and courses relying on it, and<br> even NVIDIA has effectively promised to support this forever.<br> <br> Cheers,<br> =C2=A0 =C2=A0S.<br> <br> _______________________________________________<br> HOpenGL mailing list<br> <a href=3D"mailto:[email protected]">[email protected]</a><br> <a href=3D"http://www.haskell.org/mailman/listinfo/hopengl" target=3D"_blan= k">http://www.haskell.org/mailman/listinfo/hopengl</a><br> </blockquote></div><br></div> --089e0158caf2f1190304e21b0213-- --===============6312313177344043116== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ HOpenGL mailing list [email protected] http://www.haskell.org/mailman/listinfo/hopengl --===============6312313177344043116==--