J?rgen Tischer wrote:
> 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.
I'm not proposing to revise whole Maxima code. As far as I understand Maxima
is mostly CL compliant. This is question of testing and fixing pieces of code
which give incorrect result on some Lisp. For example right now Maxima
works almost fine with clisp. It passes all tests. This is already very nice
but plot3d doesn't work and some other problems still can be discovered.
It is good idea to check all demo included in Maxima distributive.
>
> 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?
Frankly I do not quite understand what do you mean.
>
>
> > 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.
>
Actually 128Mb is too much and preallocating just 20Mb
is good for many problems.
>
> >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...?
As I tried to say earlier Maxima was never extensively tested
with clisp and cmucl it was mostly tested 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.
The week point of GCL is memory allocation but if this issue is resolved
somehow then it is 2-5 times faster than clisp. Once again I repeat that
preallocating 128MB is too much for common needs.
The init.lsp I posted a few days ago allocates such huge amount of RAM
with the purpose to eliminate garbage collections completely even for such
large expression like (x+y+z)^300.
--
[ Vadim V. Zhytnikov <vvzhy@mail.ru> <vvzhy@td.lpi.ac.ru> ]