Fwd: Future of OpenGLRaw, OpenGL, GLUT, and GLUTRaw
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. ...
The issues fit into a few categories: a) Support for specific versions of the OpenGL spec b) Refinement of the types (better modeling of C while easy to use in Haskell) c) Performance (MArray instances, if possible and fast floating point conversions) d) OpenGL doesn't expose everything that OpenGLRaw already supports/exposes
Before Alexander disappeared he showed me that someone has started a tool (available on github) for parsing the Khronos xml spec for OpenGL. We could use that code to auto generate much of the code in OpenGLRaw. I think that could be a fun and reasonable project for someone. How do others feel about using that to address (a) and (b)? Of course, some work would need to be done first to prototype how it should look/work and then the automated conversion could be developed.
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. As OpenGLRaw doesn't need that information it can be created from the files. I've created code that does that, though it's missing some essential things. 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. 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). 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.
...
I'd like to focus my attention on (a) and (b) first. I also want to make a bug fix release of all four packages that update the cabal files and just do a minor version number bump. Any objects to that?
... Sounds good.
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
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
participants (2)
-
Jason Dagit -
L Corbijn