[cl-opengl-devel] New CFFI features relevant to cl-opengl

[Oliver Markovic]

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