[HOpenGL] Fwd: Future of OpenGLRaw, OpenGL, GLUT, and GLUTRaw

[L Corbijn]

>>
>>> OpenGL has these issues:
>>> https://github.com/haskell-opengl/OpenGL/issues
>>
>> Most of the issues regarding regarding GL3.0 have been implemented
>> though not yet merged, partially because I'm not yet confident that
>> everything is there and for some parts I'm not yet happy about what
>> I've written.
>
> What can we do to increase your confidence?  Do we need some form of
> continuous integration testing (eg., a build farm) and some test
> cases?  Do you want me to look at what you have?

The first problem is whether or not everything of the GL3.0 spec is in
there, and exposed in the right way. Especially for the 3.0 version
this is quite a difficult one, as the spec is about 500 pages long
(and quite dull). While it's not a big issue to add a missing
function/enum/feature, but this addition might also lead to points
where the future proof and usable implementation would lead to
breaking changes (e.g. the current Texture part and rectangular
textures).

The second type of problem is of the sort "Is this the best way to do
it?". While most of the work is reading the spec and copying the work
already done there are some points where there are some more difficult
problems. It should be noted that my history with Haskell/FP is quite
short, and that on average more complex things tend to be rewritten at
least once before I'm happy with the result. So in short my
knowledge/experience is sometimes lacking for some problems (though
it's getting better :D).

About testing, I'm confident that OpenGL builds as it doesn't require
anything special, OpenGLRaw isn't much of a problem either as it's
straight forward for the things I could add. The problem with test
cases is that they costs are relatively high to the cost of writing
the functions, and most of the time you have to check by eye.
A look at the code would of course be nice, though most of the stuff
is (as said) straight forward. The more difficult problems are with
the FramebufferObjects, Textures and maybe more, but I would happily
generate a list of points where things are likely missing or wrongly
implemented.

>
>> ... (part about the inconsistencies in the .spec files)
>
> Ah, interesting.  So we would probably want to massage the files from
> Khronos before processing them.  Thanks for pointing that out.  It's
> details like that that can really come back to bite you.

For generating Raw, the massaging I had to do to compile it was almost
trivial (e.g. fixing a few exports/imports). Though the format has
some nasty indirections that I haven't resolved yet.

>> For generating OpenGL marshalling there is some need for extra
>> information before it can be generated. I'm currently experimenting
>> with an xml format I've made. Though the code generator is still
>> absent, I'm trying to make one that is sturdy enough to be able to
>> handle the things OpenGL throws at it.
>
> Is that code in a state where you'd want to share it?

I'm not really started with the code generator. The problem with code
generation from my point of view is that while there is a good
representation of haskell source in haskell (see the haskell-src-exts
package), there seems to be missing higher representation of
functions, datatypes, etc. . So I'm trying to come up with something
that would represent those things to my wish. Only problem is that
there are so much directions, interesting ideas, etc. that I don't
know which idea I should chose (due to some inexperience, and coming
up with new ideas regularly). So maybe I should implement some ideas
and ask, as I cannot decide (yet).

On the format, if people would like I could upload or in some other
way share the current xml file, which currently describes a part of
the Bufferobjects syntax.

>> One major question about any code generation is how it should affect
>> the current implementation, should it replace, augment the current
>> library or should it be only a tool for the developers speeding up the
>> code process. My personal preference goes to augment and replace (in
>> the future).
>
> I wouldn't want to edit the generated code (I'd rather fix the
> generator), but I would like to commit the generated code
> periodically, say at release time, so that there is 1 canonical
> generated version per release.  Also, that way people using the opengl
> binding wouldn't need to build/run the generator.
>

Certainly, but I was also wondering what we should do with the current
code. Some parts I wouldn't want to recreate/generate others could be
easily. And if we would switch to a generator, that probably would
mean some API changes in subtle ways. So how would such generator
interact with the current code base.It could for example end up
between the extra helper functions that are mostly handwritten, and
OpenGLRaw replacing part/most of the marshalling.

Lars