[HOpenGL] Back again

[L Corbijn]

On Mon, Jul 22, 2013 at 11:23 AM, Sven Panne <svenpanne at gmail.com> 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
> HOpenGL at haskell.org
> http://www.haskell.org/mailman/listinfo/hopengl


A bit overtime (I've been incredibly busy with some other things) but
welcome back!

Some notes on generating. For OpenGLRaw I had build a generator which
works with the old spec format. Discussion on starting to use it  was
at https://github.com/haskell-opengl/OpenGLRaw/issues/3 .

Though with the new spec files the generator requires major overhaul.
The starting point for this would be to parse the new format. For this
I did start on a project https://github.com/Laar/opengl-xmlspec , but
I've not had the time to work on it nor could I choose an xml library
(it seems that there are too many of them out there, suggestions are
welcome).

Generating (un)marshalling code is quite a bit harder, but I think
doable for quite some functions. From my experience on extending
OpenGL to include version 3.0 I think that even more is possible.
Though the question is then how much information the user would need
to supply to a helper tool and how complex it should be. But before
starting such project the OpenGLRaw generator should probably be
finished and in use.

Lars