Hi Thorsten,

I'm Cc-ing picolisp mailing list too just in case others find it

Thorsten Jolitz <tjol...@googlemail.com> writes:

> Hi Tomas, 
> hast du mal was mit PicoLisp und SWIG gemacht?
> zB hier bei der Erzeugung des FFI:
> ,------------------------------------------------------------------
> | mplisp (tar.gz): miniPicoLisp with FFI. Modules include Buddy BDD
> | library, OpenGL, Gtk and GMP.
> `------------------------------------------------------------------

I created a convenient FFI for picolisp.  In those days (2008, ah the
time flies), one had to write glue C code manually.  I didn't use SWIG,
because it was much simpler to do it using picolisp (although SWIG is a
nice idea, it doesn't work that well in practice).  The idea was:

1. The user writes bindings in sexp format (see the *.ffi files in
   <http://logand.com/mplisp/src/mod/>).  It is quite straightforward to
   create the *.ffi files from *.h files by simple text manipulation in
   emacs.  The .ffi files are syntactically as close to C as possible
   while being valid picolisp at the same time.

2. Then the .ffi file gets converted to .h, .c, and .fn files by loading
   the code in <http://logand.com/mplisp/src/mod/ffi.l> and then loading
   the .ffi file.

3. Next the generated glue C code needs to be "plugged" into picolisp
   sources by adding stuff to src/mod.h and src/mod.fn files.  I had to
   slightly modify picolisp for this (to include those files in the
   right places), but very litle.

4. Compile picolisp.

5. Finally, the foreign functions are normally callable from picolisp

The FFI is quite powerful and can deal conveniently with most cases.  It
is not complete, however.  For example, Jon's OpenGL bindings can almost
completely be generated systematically, except a few functions which are
defined separatelly in the traditional way in the C code

IIRC I used minipicolisp for it, which didn't support dlopen etc.  so I
compiled the glue code directly into the picolisp executable.

The official 32 bit picolisp supports runtime loading of dynamic
libraries so those glue modules could be compiled and loaded separately
without the need for being up-front included in the picolisp executable.

I think this FFI code could still be useful to people that want to
easily interface picolisp with C.  For the 64 picolisp, which came later
and used completely dynamic FFI, it should be reasonably easy to make
another ("64bit") version of ffi.l which would preserve the FFI
interface (use the .ffi files) but instead of going the C route, it
could directly use the dynamic FFI capabilities of 64 bit picolisp.


UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to