Currently a number of functions in cl-opengl return %gl:enum, but cffi:defcenum only remembers 1 keyword for a particular enum value, so we can't reliably compare the return values with keywords. (see for example http://paste.lisp.org/display/86945 where one of the examples broke when I updated to the newest gl .spec version, which changed what symbol the enum mapped to).
Does anyone have objections (or better alternatives) to changing the return values to integers, and either adding a function to compare them (gl:enum= maybe?) to keywords, or adding a shortcut to look up an enum (probably gl:enum)?
so the code from the paste would look like
(let ((framebuffer-status (gl:check-framebuffer-status-ext :framebuffer-ext))) (unless (gl:enum= framebuffer-status :framebuffer-complete-ext) (error "Framebuffer not complete: ~A." framebuffer-status)))
or
(let ((framebuffer-status (gl:check-framebuffer-status-ext :framebuffer-ext))) (unless (= framebuffer-status (gl:enum :framebuffer-complete-ext)) (error "Framebuffer not complete: ~A." framebuffer-status)))
Alternately, cffi could be modified as suggested in the comment for cffi::make-foreign-enum to return a list of keywords when there are duplicates, but then we would have do modify the calling code anyway to use MEMBER or something, and that would be slower as well as less intuitive.
-b-
On Fri, Sep 11, 2009 at 9:27 PM, Bart Botta 00003b@gmail.com wrote:
Does anyone have objections (or better alternatives) to changing the return values to integers, and either adding a function to compare them (gl:enum= maybe?) to keywords, or adding a shortcut to look up an enum (probably gl:enum)?
What about splitting gl:enum back into multiple ones like it used to be? Perhaps keeping the big enum, since it makes sense for some of the functions, I suppose. Could we generate this automatically from the spec?
On Sat, Sep 12, 2009 at 4:46 PM, Luís Oliveiraluismbo@gmail.com wrote:
What about splitting gl:enum back into multiple ones like it used to be? Perhaps keeping the big enum, since it makes sense for some of the functions, I suppose. Could we generate this automatically from the spec?
Doesn't help, since there are cases where a particular value has multiple names, even when returned by the same function. For example when an extension adds a value, with -foo on the name, then it gets added to the core without the -foo, but the same value. So code using the extension should check for the -foo name, while code using the newer GL version should check for the name without -foo, even though both are actually looking for the same numerical value.
(and it would probably be hard to generate automatically from what I remember of trying to do so last time)
-b-
cl-opengl-devel@common-lisp.net
-
Bart Botta -
Luís Oliveira