2010/9/12 Gustavo <gugamilare@gmail.com>

Well, in this case you can use copy CFFI's code for that macro and that function to make your library work with more implementations.

Maybe I'm confused about what you mean, but WAAF already works with all implementations
that work with CFFI.  It's just that it uses foreign alloc and copying rather than tricks to make
pointers to native Lisp arrays.  

 

Or, wouldn't it be much better if you patch CFFI so that CFFI:MAKE-SHAREABLE-BYTE-VECTOR would be able to create arrays of different element types?

I guess one could do this, but  wouldn't this mean that only shareable arrays could be passed to foreign
code?  Not any lisp array?   In return, for some implementations, you would avoid copying
to and from malloc'ed memory. 

 

You could create functions that transform between Lisp and C types (such as :int <-> '(signed-byte 32)).

Yes, this is what my code does.  It constructs a library (a hash table, internally) of optimized lisp
functions to do the copying, one for each LISP<-->CFFI type pair, plus a generic set at a higher safety
level where the Lisp type is just T.  But doesn't inline or macroexpand the copying because I don't
think this  buys much because most of the cycles are likely spent iterating, not funcallling.

There are a various approaches to take when passing arrays.  What is important from my own
perspective, as a user, is to have them publicized and accessible, so I don't end up reinventing them.
Hence I put my solution on cliki's FFI page.    Very likely, at some point cffi will have functionality
that renders it redundant.