On Wednesday 24 October 2001 02:55, Vadim V. Zhytnikov wrote:
>
> It seems to me that the best strategy is to maintain Maxima compatible
> with as many background lisps as possible both free and commercial
> (if someone cares to do this). Tighting Maxima to any particular Lisp
> incarnation which would be a terrible mistake. Whenever possible
> any piece of Maxima code which is particular Lisp dependent
> must be replaced by standard compliant code. This is not easy way but
> it seems that this is the only way to make Maxima future safe.
> Lisps come and go...
>
OK, but is there someone who knows maxima well enough to decide what code
could stay and what has to be changed? My feeling is that there isn't even a
list of the maxima commands which are working.
And if we had a maxima tied to a standard (is that common lisp), how about
letting maxima use all the goodies cl comes with? I read (as good as I can)
Common Lisp the Language and it was like reading a recipe of Mathematica
commands for manipulating lists and all that (which I'm badly missing). If
I'm right, couldn't one have all that stuff in maxima too?
> This is theory. But what do we have in practice right now?
> We have three Common Lisp implementations -
> GCL, clisp and cmucl. Naturally GCL is good with Maxima
> (btw I compiled GCL with the readline patch and it works
> to me fine both in GCL and in Maxima).
In case it works fine with 128 M for me that means it does not work fine.
>And I think the
> immediate task is to make Maxima completely compatible
> with clisp and cmucl as well.
To me it looks as if maxima were no less compatible with clisp and/or cmucl
as it is with gcl. Or should I say it the other way around, maxima isn't more
compatible with gcl...?
>And as far as I know this
> goal is almost achieved especially with clisp. At present
> clisp seems to be the most reliable and stable but indeed
> clisp is slowest of the three. Cmucl is the fastest option
> and porting Maxima to it is not insurmountable as well.
I have it running on cmucl, of course without any idea of how good. And I
haven't any idea about how it is done, I just followed instructions: If you
have a look at the makefile in .../maxima/src (my version is the one debian
distributes, with the diff also of debian, maxima_5.6-12.diff, applied) you
will find (lines 279-285) what you have to tell make to have a cmucl maxima
and how to call it afterwards. To me it works. (Sorry for the mess, but
that's the way I do it.) And if you have a look at ChangeLog in the same
directory you will find:
(2001-04-20 Bill Schelter <wfs@sonia.ma.utexas.edu>
* Now clisp and gcl work ok on all tests No errors found,
and apparently cmulisp does too.
> As for GCL I expect more troubles with it in near future.
> It has problems with gcc 2.96 and I guess it will have
> troubles with gcc 3.0 as well (not tried yet).
> But even with gcc 2.95.3 it suddenly stop to build
> for me after recent glibc upgrade. I wish I'm
> wrong about GCL and It would be excellent if
> someone take care of it.
>
> Best wishes,
>
> Vadim
You state that clisp is the slowest of all three, to me this is not clear at
all. First of all, to me gcl was the slowest, but of course it could be
possible you know how to fix it. Second, gcl eats up memory that is not
acceptable (I have 512 M RAM, but I'm very happy with that and I think I
would better waste my memory in other things, say using pari for lots of
calculations.
J?rgen