Maxima as a .dll/.dylib/.so in wxMaxima

[stylewarning]

It's my understanding that wxMaxima currently uses a socket-based interface to Maxima. This is, of course, a very robust choice, in the sense that the Maxima process can fail, be restarted, etc.

I would guess, however, that it can incur a lot of performance penalty in some cases, and in other cases, it makes communicating objects highly circuitous.

I wanted to let you know the existence of a functionality called SBCL-LIBRARIAN. It allows Common Lisp programs to expose a native C interface to any language that speaks C. There's an example in the directory. You specify the C API to your Lisp library (a mapping between what C function names invoke what Lisp function names), and it'll generate a header and a .dll file.

It only works with SBCL, but you get the performance benefits of SBCL.

I'm not sure if it would be a good idea, but it might be worth thinking about using this as an alternative to the socket-based interface. It would allow native Lisp/C data structures (e.g., strings) to be passed and manipulated directly by C++.

[gunterkoenigsmann]

Perhaps that would be a thing that is better discussed in the maxima-discuss mailing list: I personally dislike the socket communication for various reasons. I also would be happy if maxima would use a communication method that requires one to talk to one's firewall admin. But I don't want to create my own fork of maxima and don't want to be limited to a single maxima flavour, neither so if maxima would get a new interface I would prefer if the maxima team wrote it.

[gunterkoenigsmann]

ecl and gcl are lisp-to-c converters so they would make good dlls, too, perhaps.

[stylewarning]

ECL can be problematic because it computes all load-time stuff at DLL-load time. So an application like Maxima might have a really long start-up time.

For another application (a quantum simulator) it took an ECL-derived shared library over a minute (!!) to dlopen.

[gunterkoenigsmann]

That's a shame: Even if we want to keep maxima in a separate process (to protect the GUI from a potentially crashing or misbehaving maxima, but also in order to protect maxima from the GUI in case that the GUI overwrites a stack address or causes similar havoc) making a dll out of it would have potential:

• on lisps that don't support readline we could write a c program that does and that uses maxima.dll
• multiple maxima processes could run from a single dll
• maxima would gain a nice API for being embedded somewhere else.

As I have stated: I dislike our ipc that uses sockets. But the right place to change maxima is https://maxima.sourceforge.net.

[gunterkoenigsmann]

What I really like about running maxima as a separate process is that if maxima crashes or runs out of memory the worksheet with all the user did until now lives on.