[cffi-devel] Re: first clisp-specific patch: copyright, callbacks & spam

[Hoehle, Joerg-Cyril]

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.