Tomas Hlavaty <t...@logand.com> writes: Hi Tomas,
> I'm Cc-ing picolisp mailing list too just in case others find it > interesting. thats OK, I think this could generally be very useful. And thanks for your informative answer! > 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. Maybe you should do a bit more publicity and marketing for your libraries? You have some quite interesting stuff in your 'backcatalog' that is not at all linked to or documented in the PicoLisp Wiki. > 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: SWIG is a monster compared to your ffi.l, it would be so much nicer to have something small and understandable. > 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. indeed, this would be just a simple elisp function or even a keyboard-macro. > 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>. One of the major problems for me is that most interesting libraries are actually object-oriented C++ class libraries, so the direct correspondence between C function signature and PicoLisp list is lost. So the (giant) first task is to port C++ classes to C function calls. SWIG is able to do this by exposing the internal of the user defined object in a lot of C function, e.g. a getter and a setter function for each instance variable and one C function of each (overloaded) constructor and one C function for each method etc. Probably no magic at work, but one should probably understand the inner working of C++ to write such transformation 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. I'm not sure which 'dynamic FFI capabilities' you mean, but 64bit picolisp has the (native) function that seems to me like a 'one function ffi' to C code. When its only about C functions with primitive args and return values, they can be translated directly into native calls. Unfortunately whenever I search for interesting C libraries, e.g. for data mining or whatever, I find C++ class hierarchies, sometimes with dozens or hundreds of classes and hundreds of thousands of methods. So as I see it, I still have to use SWIG to turn these class hierarchies in plain functions calls, and then I can use PicoLisp 'native' calls as wrappers. Would be great though to have a ffi.l that knows how to deal with C++. -- cheers, Thorsten -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
