On 15.02.2006, at 16:10, Luís Oliveira wrote:
I have added macroexpansion-time translators to CFFI and this is quite relevant to cl-opengl. Here's an example: [...] I propose that we use this in cl-opengl and volunteer to do that. :-)
Neat! This would cut out a lot of the annoying (float ...) throughout the wrappers. It seems to me like a lot of things that I used to do by hand are made obsolete by CFFI advancements. Maybe we won't need any wrappers at all soon? :)
BTW, can I request a FOREIGN-ENUM-P? I have been working on the state queries lately (so much typing.. argh), and this would come in handy. My current definition looks like this:
(defun foreign-enum-p (enum) (typep (cffi::find-type enum) 'cffi::foreign-enum))
(foreign-enum-p 'begin-mode) => t (foreign-enum-p 'float) => nil
That would mean passing some of the DEFCFUNs in funcs.lisp over to the respective <spec-section>.lisp right? Though I see some functions that are just (defun foo (...) (%foo ...)) what's up with that?
The reason for keeping the wrapper functions separate from the FFI definitions is that I thought it might be possible to also support FFI-less GLX without having to change any of the wrappers. Suppose there are two backends, one for the C-based library and one for GLX through CLX, then a call to %glFoo could be either a foreign call or some Lisp function which sends out the appropriate GLX request to the server, depending on which backend is loaded.
Note that I never intended to write a GLX backend, but I wanted to keep the possibility open and tried not to conflate the wrappers with the FFI definitions to make it easier if somebody wants to work on such a thing. The functions you mention are just there for consistency with this separation.
I'm not sure if anybody actually needs such a thing and if there's any real value in keeping the definitions separate though.