[cffi-devel] Re: WG: first clisp-specific patch

[Luís Oliveira]

On 2005-dec-21, at 18:48, Hoehle, Joerg-Cyril wrote:
> Luis, here's the patch for you.
> How do people submit shorter patches? Most of the 40KB is the  
> "context" that darcs appends.

darcs diff will produce a short patch. Alternatively, puting your  
darcs tree somewhere where anyone can pull patches from is quite  
convenient.


> ---------------
> Your mail to 'cffi-devel' with the subject
>
>     first clisp-specific patch
>
> Is being held until the list moderator can review it for approval.

It'd be nice if cffi-devel wasn't moderated at all (namely, this  
would allow anyone to post via gmane.lisp.cffi.devel), but I suppose  
it would get a lot of spam?


> -----Ursprüngliche Nachricht-----
> Von: Höhle, Jörg-Cyril
> Gesendet: Mittwoch, 21. Dezember 2005 17:58
> An: cffi-devel at common-lisp.net
> Betreff: first clisp-specific patch
>
>
> Hi,
>
> I used darcs pull /home/src/cffi-luis to create a local copy,  
> experiment a little with record and revert. darcs unrecord seems to  
> be good enough to cancel my patch that conflicted with the recent  
> changes to types.lisp.
>
> The current patch set is appended. I'd like to add more. The 96  
> tests pass.
> The patches are:
> ffi:memory-as is a perfect match for %mem-ref

Sure, sure. We would have used it if it were documented. ;-)


> use ffi:foreign-variable in foreign-symbol-pointer
> foreign-slot-value|set compiler-macro update
> cffi-clisp:%defcallback: simplify it
> Add background info on free'ing callbacks

Regarding this comment:

         ;; The created callback function is not stack-allocated.
+       ;; It is valid until  (ffi:foreign-free #<FOREIGN-FUNCTION>),
+       ;;  but you can't use (ffi:foreign-free (callback name)),
+       ;;  because that would invoke free() on the opaque c-pointer!
+       ;; Maybe cffi should make an exception and use the
+       ;;  foreign-function object, not its address?

I think the question whether (ffi:foreign-free (callback name)) works  
is pretty irrelevant since if people used that, the bindings wouldn't  
be portable anymore.

However I suppose cffi-clisp's %defcallback should free the previous  
callback with the same name (maybe this is what you're thinking  
about). 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)
         (setf (get ',name 'callback-ptr)
               (ffi:foreign-address ,cb-var)))))


> BTW, cffi-gcl does not reflect the recent renaming fiesta (null-ptr- 
> p etc.).

The GCL port has never been complete. I guess it'll have to wait  
either for someone who actually uses GCL to pick it up or for more  
important stuff to get finished first.


> Further simple patches could cover possible performance  
> optimizations, or whatever.
>
> Regards & happy new year,
> 	Jörg Höhle.
>
> <Joerg.patch>


Btw, I have a question about CLISP's licensing. Quoting from CLISP's  
COPYRIGHT file:

  "This copyright does *not* cover user programs that run in CLISP and
   third-party packages not part of CLISP, if
     a) They only reference external symbols in CLISP's public packages
        (namely the packages COMMON-LISP, COMMON-LISP-USER, KEYWORD,  
CLOS,
        GRAY, EXT), i.e. if they don't rely on CLISP internals and  
would as
        well run in any other Common Lisp implementation. Or
     b) They only reference external symbols in CLISP's public packages
        (namely the packages COMMON-LISP, COMMON-LISP-USER, KEYWORD,  
CLOS,
        GRAY, EXT) and some external, not CLISP specific, symbols in
        third-party packages that are released with source code under a
        GPL compatible license and that run in a great number of  
Common Lisp
        implementations, i.e. if they rely on CLISP internals only to  
the
        extent needed for gaining some functionality also available in a
        great number of Common Lisp implementations."

Since my legalese skills are weak specially in English I'm not even  
sure which of these two exceptions apply to CFFI. However, both talk  
about referencing external symbols only and cffi-clisp.lisp  
references a few internal symbols.

My question is: does this mean CFFI (the whole CFFI?) would have to  
be licensed under the GPL? If so, could these symbols CFFI uses be  
exported? I'm certain relicensing CFFI under GPL would not be an option.

Anyway, thanks for your patch and merry christmas!

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt