Fork of maxima for make it more embeddable.

On 12/28/2011 7:54 AM, Michael Filonenko wrote:
> I understand, that web ui to one lisp machine for multiple remote users is
> dangerous project. I am doing it only for "personal use", now:)
>
> Goal of fork to provide maxima from quicklisp. Maxima big project and I
> need community opinion about fork. I am ready to merge my changes with
> main repo. Only non-mathematical parts were changed by me.
I do not know what extra is needed for quicklisp packaging, but I do not 
see why it requires any
changes to existing source code files.  I am able to load almost all of 
maxima
(except graphics) into Allegro common lisp by essentially taking a list 
of all
files and compiling and loading them. (optionally, making a binary dump)

I have not done this recently, but as I recall, the only difficulty I 
have encountered has
to do with my preference for a "bothcases" lisp, and Maxima's case 
hacking in its
parser, where upper and lower cases are reversed.  So I just used the 
default common
lisp option in Allegro.


>
> Also it will be possible to develop some maxima graphical interface
> using pure-lisp
> solutions.
ANSI common lisp does not standardize graphics, so any CL programs would
use the extensions to the lisp that are available in that CL 
implementation.  Unless you
find a common set of graphics extensions to use under ALL supporting 
implementations,
and provide facilities that are equal to or superior to existing ones, 
you probably won't
have any impact on the distribution.

On the other hand, I am all in favor of experimentation in interfaces, 
and have worked on
handwriting and  voice for example.

  Such experimentation is quite independent of  quicklisp if you write 
your new GUI in any of
  the already-supported lisps.
>
> 2011/12/23 Steve Haflich<smh at franz.com>:
>> Richard Fateman<fateman at eecs.berkeley.edu>  wrote:
>>
>>    The most appealing solution to these problems is to run some kind of
>>    virtual machine.
>>
>> I have some experience with the issue of multiple users in a single Lisp
>> execution.
>>
>> As a practical matter, it cannot be made secure such that one hostile
>> user is prevented from affecting other users, or harming the Lisp
>> execution itself.  I could discuss detaild, but instead if anyone
>> provided me with a multi-user maxima that isn't restricted in ways that
>> limit maima, I'm sure I could crack it.
>>
>> If the goal is to create a server that can support multiple remote users
>> to use Maxima, running each user in a sepaate VM isn't efficient.
>> Duplicate vm's require duplicating memory for the entire OS.  The VM,
>> properly configured, protects your local machine against access or
>> attacks from a remote user.  But if you need to protect users from one
>> another, that isn't enough.  You should instead launch a separate
>> Maxina/Lisp execution for each connecting user, within a single vm, and
>> you should use permissions and chroot to ensure that each maxima
>> execution cannot harm the vm.  Even that is hard, but probably
>> achievable.
>
>