On Mon, Aug 18, 2008 at 1:29 PM, Luís Oliveira luismbo@gmail.com wrote:
Actually, I wouldn't mind seeing the per-function enums come back. Having compile-time warnings when we passed a bogus keyword was nice. Can anyone remind me why were they collapsed into one enum?
Sounds like a reasonable thing to have, if we can generate it easily (which we can't for GL3 at the moment, since there are not complete .spec files available yet).
Only thing i could find in the list archives is that it is harder to deal with returning enums, though seems like at worst we could just have a combined set used for doing the reverse translations in that case.
Also, looking at the glGet*, is there any reason we don't just map all of those to gl:get and add a compiler macro (or whatever) to pick the correct low level version? looks like the enum.spec files might even have enough info to map most of the enums to types, though probably have to pick out the ones that should be interpreted as enums by hand.
-b-
On Mon, Aug 18, 2008 at 3:05 PM, Bart Botta 00003b@gmail.com wrote:
On Mon, Aug 18, 2008 at 1:29 PM, Luís Oliveira luismbo@gmail.com wrote:
Actually, I wouldn't mind seeing the per-function enums come back. Having compile-time warnings when we passed a bogus keyword was nice.
Sounds like a reasonable thing to have, if we can generate it easily (which we can't for GL3 at the moment, since there are not complete .spec files available yet).
OK, after looking at the full gl3 .spec files, it looks like we can't generate all of the function specific enums automatically. It looks like it has some of the older enums split out, but not sure if they include all the newer extensions or not.
Probably could build up a full set of enums, if we don't mind giving up on being able to completely regenerate the enums automatically.
I've been thinking that might be a good idea in general though (the not fully automatic bindings part), since GL naming isn't consistent enough to rely on the automatic stuff for new function names anyway, so currently adding new extensions requires a few passes of proofreading the generated bindings and editing the generator.
Does it sound reasonable to split the binding generation into 3 steps, only 2 automatic: First would parse the .spec files, tracking any enum groups defined in the file, approximately splitting up function names, etc. and write the results to some lispy format (reusing output of step 2 if available). Second step would be editing the generated data by hand, adding missing enum groups, fixing word breaks that the automatic code got wrong, etc. Third would be parsing the hand edited code to generate the actual bindings.
-b-
2008/8/30 Bart Botta 00003b@gmail.com:
Does it sound reasonable to split the binding generation into 3 steps, only 2 automatic: First would parse the .spec files, tracking any enum groups defined in the file, approximately splitting up function names, etc. and write the results to some lispy format (reusing output of step 2 if available). Second step would be editing the generated data by hand, adding missing enum groups, fixing word breaks that the automatic code got wrong, etc. Third would be parsing the hand edited code to generate the actual bindings.
Sounds good to me. It'd be great if this process could somehow highlight changes in the spec so that step 2 can be focused on what changed instead of having to review everything.
On Sat, Aug 30, 2008 at 5:27 PM, Luís Oliveira luismbo@gmail.com wrote:
Sounds good to me. It'd be great if this process could somehow highlight changes in the spec so that step 2 can be focused on what changed instead of having to review everything.
Yeah, that was the idea, though I'm leaning towards just letting the version control deal with highlighting the changes.
-b-
After looking at it a bit more, I think trying to split out the enums is going to be too much work to block gl3 support for (and possibly too much work in general). The .spec files have lots of parameters mapped to enum directly, many of the enums that do exist are incomplete or need split into multiple enums, etc. so it would pretty much require just going through the spec/extensions and building the list by hand anyway.
So for the problem of clashes with the aliases for enums with -BIT names, I'll try splitting those out by hand, and the rest can stay in the big enum for now.
Any objection to removing the aliases that were auto-generated for the names that end with _BITS but aren't bitfields? (usually queries for # of bits in something)
-b-
On Tue, Sep 2, 2008 at 12:05 PM, Bart Botta 00003b@gmail.com wrote:
Any objection to removing the aliases that were auto-generated for the names that end with _BITS but aren't bitfields? (usually queries for # of bits in something)
Not really. Thanks for keeping us updated!
cl-opengl-devel@common-lisp.net
-
Bart Botta -
Luís Oliveira