Luís Oliveira wrote:
>> ffi:memory-as is a perfect match for %mem-ref
>Sure, sure. We would have used it if it were documented. ;-)
You didn't read the documentation recently, did you?
>darcs diff will produce a short patch.
Ah, I used darcs send -uo file.patch instead
>It'd be nice if cffi-devel wasn't moderated at all, but I suppose
>it would get a lot of spam?
I have no experience here, but IIRC Kevin Rosenberg or Marco Baringer have very
strong opinions on the "subscribe first". I'd just appreciate if the
mailing-list descriptions on common-lisp.net would mention that requirement.
>However I suppose cffi-clisp's %defcallback should free the previous
>callback with the same name (maybe this is what you're thinking
>about).
No, I did not mean that.
> Something like this?
>+ (let ((cb-fun (get ',name 'clisp-callback-function)))
>+ (when cb-fun (ffi:foreign-free cb-fun)))
>+ (setf (get ',name 'clisp-callback-function) ,cb-var)
The comments specifically meant that this would not work, because
(foreign-free #.#<FOREIGN-ADDRESS>) -> free(), which is not appropriate,
while
(foreign-free #.#<FOREIGN-FUNCTION>) lets clisp recognize and free the function.
Cffi currently stores (foreign-address #<foreign-function>) in the plist, thus
it cannot free the thing anymore.
I haven't investigated what implications storing the #<FOREIGN-FUNCTION> object
instead of its address would have on cffi invariants.
Another possibility would be to attach a finalizer. But given that cffi
callbacks are static only (and thus probably not numerous), I wouldn't bother
the GC. There are other situations which create callbacks on the fly, without
easy means to free them. For example, each time you pass a Lisp function to a
foreign one with type (c-function ...): the Lisp side typically does not see
pointer to the callback that gets created.
>Btw, I have a question about CLISP's licensing.
>My question is: does this mean CFFI (the whole CFFI?) would have to
>be licensed under the GPL?
I'm no lawyer either. the question arises from time to time and was even
discussed not too long ago for UFFI (in clisp-list or clisp-devel).
My understanding was that there's no problem, as the goal is to provide
functionality also available in a great number of Common Lisp implementations.
>If so, could these symbols CFFI uses be exported?
I'm looking into that.
Regards,
Jörg Höhle.
_______________________________________________
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
