[cffi-devel] offer of code contribution - with-array-as-foreign-pointer

[Gustavo]

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 at 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/shareable-vectors.txt
>
> 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-cffi
>
> JK
>
>
>
>
>
>
> <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 at 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 at 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 at common-lisp.net
>>> http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20100912/d06cbf04/attachment.html>