Re: Fwd: Future of OpenGLRaw, OpenGL, GLUT, and GLUTRaw

On Sat, Oct 1, 2011 at 10:41 AM, L Corbijn <[email protected]> wrote:
> Oops forgot to send it also to the list.
> Lars
>
> ....
>
>> 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?

> I believe that something has been done by Sven in the past (see the
> files in the OpenGL repo under specs).
> I've been working on some things (from scratch) for about a month
> (though not very active, due to lack of time).
>
> There are some difficult points about generating the binding from the
> spec files.  Their are some inconsistencies in the enum spec file
> (which Khronos hasn't fixed, and probably isn't gone fix soon), but
> they can be fixed by hand. A different problem is that information
> needed for creating a type safe haskell binding is missing. For
> example enumerations aren't grouped and 'ObjectName'-s aren't
> identified.

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 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?

> 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.

> A generator that can fully replace/rewrite the code could have some
> extra (partial) back-ends that could for example generate memory
> managed code or code that reduces needles GLfunction calls.

Yes, that does seem like an interesting future direction.

Thanks for you input,
Jason