Hi Thorsten, I'm Cc-ing picolisp mailing list too just in case others find it interesting.
Thorsten Jolitz <[email protected]> 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 code. 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 <http://logand.com/mplisp/src/mod/glut.c>. 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. Regards, Tomas -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
