[Ecls-list] Fwd: ECL specific changes for CFFI

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Sun Apr 25 12:50:18 UTC 2010


FYI, a forward of a few patches I sent to the cffi-devel maling list. I feel
there is a lot of room for improvement using compiler macros: the result
might be a much leaner version of the code, with almost everything inlined
when using the C compiler.

The only problem is that the code generated by CFFI still relies on its own
runtime, methods, classes and other stuff that it does not resolve at
compilation time. I find this is unfortunate, but I do not have the time to
dig deeper into the library: my investigations are just focused around
cffi-ecl.lisp

Juanjo

---------- Forwarded message ----------
From: Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com>
Date: Sun, Apr 25, 2010 at 2:47 PM
Subject: ECL specific changes for CFFI
To: cffi-devel at common-lisp.net


* The former definition for :long-long types in cffi-ecl.lisp was broken. I
have agumented ECL with a feature that signals the existence of such a type
in ECL and include a patch here for CFFI to take that into account. (Patch
attached)

* Instead of defining NULL-POINTER-P, it would be better to simply reexport
the symbol living in the "EXT" package. Patch attached.

* Upon reading the CFFI specification it seems that FOREIGN-FREE can only
free memory that has been allocated by CFFI. However the test cases in
misc-types.lsp do something else, deallocating the output of my_strdup()
explicitely.

* At the low level ECL has two different foreign function interfaces: one
used in the interpreter and relying on an external library (libffi) and
another one, much simpler, using the C compiler. Right now CFFI was only
using the former unless it was not available. I provide a patch that chooses
the interface depending on the use of the code: interpreter or compiled.
(patch attached).

* Is there the equivalent of launchpad for CFFI? Should I always submit the
patches to the mailing list? I say this because there are other improvements
I could forward when I find time.

Cheers

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com



-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100425/17b3f2e4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Proper-support-of-the-long-long-type.patch
Type: application/octet-stream
Size: 1095 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100425/17b3f2e4/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Do-not-dealloc-with-FOREIGN-FREE-the-strings-returne.patch
Type: application/octet-stream
Size: 1686 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100425/17b3f2e4/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Instead-of-defining-a-new-null-pointer-p-just-reexpo.patch
Type: application/octet-stream
Size: 1112 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100425/17b3f2e4/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Teach-CFFI-to-use-C-INLINE-when-producing-compiled-c.patch
Type: application/octet-stream
Size: 3762 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100425/17b3f2e4/attachment-0003.obj>


More information about the ecl-devel mailing list