Fork of maxima for make it more embeddable.

I move maxima from "standalone" to "library" application. For this goal I remove
"configure" step, which setup maxima paths. Instead of "configure" I use "asdf"
api for searching maxima directories. Now, paths setup depends on maxima.asd
file. Environment variables have advantage as in original version.

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

Experimental interfaces usually are based on some framework, your's examples
it is audio and graphical inputs. There are some good opensource cl
implementations
and it's not so easy to install such frameworks for newbie developer,
without quicklisp.

2011/12/28 Richard Fateman <fateman at eecs.berkeley.edu>:
> 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.
>
>
> ?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.
>>
>>
>>
>



-- 
With best regards, Michael Filonenko