Fork of maxima for make it more embeddable.

Hi;



> Quicklisp-able

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:
https://github.com/filonenko-mikhail/maxima/commits/quicklisp

> 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:

sbcl
(ql:quickload :maxima)
(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.