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.