On 2/12/11, Gerd Kortemeyer <korte at lite.msu.edu> wrote:
> Well, yes, I have a wish list, but I feel bad presenting it, as we have no
> time or resources to work on it.
Well, for my part, it is valuable to the project to get the
opinions of well-informed outsiders, even if those people
don't have the time to work on stuff.
> Essentially, we would love to have MAXIMA as a true kernel that we can talk to.
There has been some work in that direction; see below.
I would be interested to know what more could be done.
> * MAXIMA itself managing a number of running child process (like Apache,
> etc)
>
> * Providing a port to send requests to these child processes (like Apache,
> etc)
There is share/contrib/maxima-server.lisp which implements
a simple-minded Unixish server:
server listens on a port, accepts connections from clients,
and forks a new instance for each client.
Forking the server is, I hope, more efficient than launching
a new instance. Anything loaded into the server is present
in the forked processes.
The connected socket just transmits all the stuff that would
otherwise go to a terminal. Note that there are command line
options to make Maxima quieter (suppressing the banner
and input/output labels).
maxima-server.lisp only works w/ SBCL, but I guess you are
using SBCL already so that's good news.
> * A highly predictable command-reply sequence. We really struggle with
> MAXIMA having questions back for LON-CAPA (like "Is x positive?"), which of
> course are unanswerable. If an expression given by a student is not
> completely defined, we just need an error message back, and MAXIMA should
> not wait for an answer. Ideally: one line in, one line out, always.
Yes, this is quite a problem. There is an experimental add-on package
named noninteractive which attempts to intercept such questions
and throw the expression being considered instead of waiting for input.
Unfortunately noninteractive is rather fragile; it is not too hard to
come up with examples which trigger bugs. But with some
prodding, I could be inspired to work on it some more (or anyone
else can, of course).
There are some examples (working or buggy) in the comment
header for share/contrib/noninteractive/noninteractive.mac.
> * A way to run MAXIMA safely, i.e., without any file or operating system
> access
My advice is to use chroot to change the file system visible to Maxima.
Trying to plug all the holes by disallowing a certain set of functions
is probably defeatable.
Beyond chroot, you might consider using some virtualization
software so Maxima runs in its own instance of the OS.
> * A way to cleanly and quickly reset MAXIMA between requests: all variables,
> definitions, assumptions, etc.
As you know, reset and kill don't clean up everything,
and trying to fix those is probably not worth the trouble.
I think your best bet is to use maxima-server and just create
a new instance when you want a clean slate.
Hope this helps in some way. It appears that you're using an old
version of Maxima. We have been making a lot of progress in the
past several years, so I'll encourage you to use a newer version.
The stuff I've mentioned might or might not exist in old versions.
best
Robert Dodier