Hi Thorsten,
> 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.
yeah, but it is much more interesting to write code;-)
> indeed, this would be just a simple elisp function or even a
> keyboard-macro.
Yes, this is staightforward for C but not for 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.
I think it's too much work for too little benefit. The result would be
fragile. C++ is too complex.
>> IIRC I used minipicolisp for it, which didn't support dlopen etc. so I
>> compiled the glue code directly into the picolisp executable.
I think the main reason for using minipicolisp was that I had a 64 bit
OS and didn't want to polute it with so many 32 bit libraries and their
dependencies just for testing the FFI.
>> 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.
At the moment, people need to decide whether to use 32 bit or 64 bit
picolisp. This decision impacts how to do FFI, which is a shame. The
point here is that there could be unified FFI interface across all types
of picolisp. (Well, except the java version, I suppose.)
> 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.
Yes, the function 'native'.
> 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.
One solution even though not so general, could be to write some kind of
simple interpreter (repl) on top of the library and communicate/control
it from picolisp via a text protocol/language. Many sophisticated
scientific libraries often have such a repl already.
> 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++.
Yes, that seems like a good plan to attack the problem. I imagine
though that the generated C will be pretty bloated mess.
Cheers,
Tomas
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
