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

[Gustavo]

Em 13 de setembro de 2010 02:05, JTK <jetmonk at gmail.com> escreveu:

>
>
> 2010/9/12 Gustavo <gugamilare at 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.
>

I meant to avoid copying.

>
>
>> 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.
>

It looks like some implementations need you to say that the array should be
created in static memory so it doesn't get relocated. In your library, SBCL
is somehow privileged, which is not bad but neither ideal. CFFI seems to
have code for using pointers to native Lisp arrays in various
implementations. I think the right answer would be to extend the
specification of the proposal. CFFI should detect the cases where the
implementation can't provide a pointer to the array so it copies the array
instead.

Just a though.

>
>
>
>> 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.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20100913/c65d6e49/attachment.html>