[Maxima] Fork of maxima for make it more embeddable.
filonenko.mikhail at gmail.com
Sun Jan 8 02:03:49 CST 2012
2012/1/8 Robert Dodier <robert.dodier at gmail.com>:
> Hi Michael,
> About creating multiple concurrent Maxima sessions, take a look
> at share/contrib/maxima-server.lisp, which implements a conventional
> Unixish server. Server listens for clients, accepts a client, and forks
> a child process to handle the client. Since child processes are in
> separate virtual address spaces, changes to variables in one don't
> affect another. I suppose the server could be run with chroot to
> prevent access to the file system. maxima-server.lisp uses SBCL's
> POSIX interface.
Thanks, I will try it.
> About your project to create a Quicklisp-able Maxima, I think that
> is a valuable goal, and I'm 100% in favor of you (or anyone)
> creating their own projects based on Maxima. That said, since
> you have changed the build system a lot, I am hesitant to
> merge those changes into Maxima. I am no big fan of defsystem,
> but changing the build system could affect people who are
> building packages or installations.
Thanks. I would not want to look like a revolutionary, but for now
asdf is widespread and quicklisp supports only it. Quicklisp
repositories can make maxima developers free to solve some problems
like: filenames, socket, interprocess communication, etc.
Today state of my fork is:
- repository url: http://github.com/filonenko-mikhail/maxima
- all previous git history is saved, so, I only did "quicklisp"
branch, in which I repair existing maxima asdf system;
- merge changes from "master" to "quicklisp" is easy because git is
smart and can handle moving of files;
- merge changes from "quicklisp" to "master" is not so easy, because
I refactor following things:
- lapack, quadpack modules are compiled on-fly, now. I use asdf
system examples from f2cl/packages repository;
- setup of maxima paths depends on environment variables, and if it
does not exist, on asd file path;
- there are some external dependencies, which are available from
quicklisp repositaries. cl-fad, f2cl (embedded is removed now), getopt
(embedded is removed now), trivial-features (windows detection by
#+windows, instead of (string= "true" autoconf:**win32*));
- I remove archive/ directory, because lightweight packages are
better for quicklisp;
- I remove binary output path handling, because asdf and quicklisp
do it itself;
- I also move source files into directories in accordance with
maxima.asd, it is mostly cosmetic change;
There are all my changes:
> If you want to try (or not, that's OK too) to convince me & other
> developers to merge in your changes, perhaps you can describe
> how the build machinery will work. I can't guarantee that we'll accept it,
> but I am interested to hear about it.
There is quicklisp request for adding embedded maxima into
repositories. I am trying to find how many peoples are interested in
this project. Also, as I said, it is easy to merge mathematical parts
of "master" branch into "quicklisp" branch and I can maintain it.
The main problem is that I broke mk-defsystem, and I can not support
this system. Deploying of maxima depends on mk-defsystem and now it is
broken too. If there will be many users, I can repair packaging of
maxima, but it will be something, like:
(crossplatform:save-lisp-and-die (lambda() (cl-user::run)) )
For windows/macos/linux bat/sh file:
fill environment variables with maxima share, doc, etc paths;
execute maxima image.
More information about the Maxima