On Sat, Oct 1, 2011 at 10:41 AM, L Corbijn
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