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. 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? You could create functions that transform between Lisp and C types (such as :int <-> '(signed-byte 32)).
Gustavo.
Em 12 de setembro de 2010 21:27, JTK jetmonk@gmail.com escreveu:
On Sep 12, 2010, at 1:57 PM, Gustavo wrote:
Actually, there is documentation, it's linked in CFFI's main page:
http://common-lisp.net/gitweb?p=projects/cffi/cffi.git;a=blob_plain;f=doc/sh...
You seem to need to use CFFI:MAKE-SHAREABLE-BYTE-VECTOR to create the array.
I saw this, but I assumed it was just a proposal, plus the use of shared vectors makes it hard to use with most lisp data, often leading the same copying overhead that would have arisen just malloc'ing.
I've been passing arrays to foreign libraries for a long time. I used to think that the right solution was to pass the Lisp data itself. Sometimes, for huge arrays on a 32 bit machine, it was actually necessary. Now, however, I've concluded that simply copying to malloc is good the vast majority of the time. There might be some truth to the adage that the perfect is the enemy of the good.
At any rate, I've put my WAAF copying package here:
http://www.cliki.net/WAAF-CFFI http://sites.google.com/site/lithpthtuff/home/waaf-cffiJK
http://common-lisp.net/gitweb?p=projects/cffi/cffi.git;a=blob_plain;f=doc/shareable-vectors.txt
Em 12 de setembro de 2010 20:39, Gustavo gugamilare@gmail.com escreveu:
Hello,
What about CFFI:WITH-POINTER-TO-VECTOR-DATA? Or did you just miss it? Documentation is missing, but it pines the array within its body (which means the array won't be moved, but garbage collector might still run) and grabs the foreign pointer of the array, at least on SBCL.
Regards, Gustavo.
2010/9/11 JTK jetmonk@gmail.com
Hello,
I'm using cffi, and I need to perform the common task of passing Lisp arrays to foreign code.
This task comes up a lot in scientific code, matrix math, image processing, etc.
Normally, it involves a lot of boilerplate to allocate a pointer, copy data Lisp to foreign memory, copy the data back, and deallocate the memory. Getting the copying to run fast can be tricky.
Hence I wrote a package to automate it. It maintains a set of specialized copying functions to copy from array of Lisp type X to foreign memory of type Y. On SBCL, copying doesn't cons and is reasonably fast (~200 MB a second, there and back)
I've put the package here:
http://www.megaupload.com/?d=CX1XFMU6
Sorry for the megaupload, and its imposed delay, but I didn't want to spam the list with a 100K file.
The package includes a MANUAL.txt and a test package.
I'd be happy to have this included in a user contrib section of CFFI, if the maintainers think it would be useful.
Here's an example the main macro does:
(LET ((U (MAKE-ARRAY 100 :ELEMENT-TYPE 'SINGLE-FLOAT :INITIAL-ELEMENT 1.0))) ;; (WITH-ARRAY-AS-FOREIGN-POINTER (U PU :FLOAT ;; LISP-VAR POINTER-VAR CFFI-FOREIGN-TYPE :LISP-TYPE SINGLE-FLOAT ;; promise U is a single-float array :START 2 ;; begin at index 2 of of Lisp array :END 7 ;; last index used is 6 :COPY-TO-FOREIGN T ;; put contents of Lisp into foreign memory :COPY-FROM-FOREIGN T) ;; copy back from FFI space to lisp array ;; ;; at this point, PU is a foreign pointer containing data copied ;; from the array starting at element 1 and ending at 6, of type :FLOAT.
(SOME-FOREIGN-FUNCTION PU)) ;; ;; at end, all foreign memory is deallocated, and U has been copied ;; back from foreign space, but the 0th element of U is untouched ;; because START was 1, not 0 )-John _______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel