Hello,
I have added macroexpansion-time translators to CFFI and this is quite relevant to cl-opengl. Here's an example:
CFFI> (defctype ensure-float :float) ENSURE-FLOAT CFFI> (defmethod expand-to-foreign (value (type (eql 'ensure-float))) (if (constantp value) (float (eval value)) `(float ,value))) ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. VALUE TYPE): ; Compiling Top-Level Form: #<STANDARD-METHOD EXPAND-TO-FOREIGN (T (EQL ENSURE-FLOAT)) {4053169D}> CFFI> (macroexpand-1 '(defcfun "sqrtf" :float (x ensure-float))) (PROGN NIL (DEFUN SQRTF (X) (LET ((#:G2792 (FLOAT X))) (VALUES (%FOREIGN-FUNCALL "sqrtf" :FLOAT #:G2792 :FLOAT))))) T CFFI>
I propose that we use this in cl-opengl and volunteer to do that. :-)
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?
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.
Oliver Markovic entrox@entrox.org writes:
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? :)
The less wrappers the better. :-)
BTW, can I request a FOREIGN-ENUM-P?
Sure. That sounds useful. I'll try to come up with some sort of more generic foreign-typep first and if I fail, I'll add foreign-enum-p.
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.
What about something like this:
(defmacro defglfun (name rettype &body args) `(defcfun ,name ,rettype ,@args))
Then a CLX backend would implement this macro (which would probably be slightly more complicated, I'm sure). I have no idea if this makes sense as I've never touched CLX.
Again, if it does make sense, I volunteer to do the gruntwork. :-)
On 22.02.2006, at 00:06, Luís Oliveira wrote:
What about something like this:
(defmacro defglfun (name rettype &body args) `(defcfun ,name ,rettype ,@args))
Then a CLX backend would implement this macro (which would probably be slightly more complicated, I'm sure). I have no idea if this makes sense as I've never touched CLX.
Again, if it does make sense, I volunteer to do the gruntwork. :-)
Yes, this is pretty much what I had in mind, but I'm not sure if this is so important to change right now. I'd try to focus on getting a releasable binding for OpenGL and GLU(T) with sane semantics for CFFI first before making too many accommodations for hypothetical features which may never get implemented anyway. But feel free to do it if you're bored. :)
cl-opengl-devel@common-lisp.net
-
Luís Oliveira -
Oliver Markovic