compiling Maxima by ECL
Robert Dodier
I have gotten Maxima (current CVS head + ECL-specific changes)
compiled by ECL (current CVS head, release 0.9j won't work).
I committed the ECL-specific stuff on the branch patches-for-ecl-branch
in Maxima CVS. I merged in a patch posted by Michael Goffioul in 2005
and some stuff I did a few months ago.
Many thanks to Michael G for his contribution.
I couldn't get the autoconf/automake stuff to work, but I was able
to get Maxima compiled by following the instructions in
maxima/INSTALL.lisp.
The resulting maxima.fas sort of works but the testsuite
shows a lot of errors. I haven't looked into it in detail, but
it appears that the assume stuff (inferences about sign of
expressions) isn't working, and my first guess about that
is that all the EVAL-WHEN stuff is dorked up.
Incidentally run_testsuite() itself barfs out an error,
that the name of a file that needs to be loaded (namely
testsuite.lisp) is not a stream. I worked around it by
loading testsuite.lisp separately first.
I have a couple of motivations for attempting Maxima + ECL.
(1) ECL is a potential replacement for GCL on Windows.
(2) It appears that the Sage project is interested only in
Maxima + ECL. If Maxima continues to be usable through
Sage, we might get some bug reports and, who knows,
even bug fixes from Sage.
I'll look into this some more & let you know if I can resolve anything.
I would like to take this opportunity to invite interested parties
of any/all projects to try this also, maybe your luck is better.
FWIW & HTH.
Robert Dodier
Maxima developer
Michael.Abshoff
> Hello,
Hi,
> I have gotten Maxima (current CVS head + ECL-specific changes)
> compiled by ECL (current CVS head, release 0.9j won't work).
> I committed the ECL-specific stuff on the branch patches-for-ecl-branch
> in Maxima CVS. I merged in a patch posted by Michael Goffioul in 2005
> and some stuff I did a few months ago.
> Many thanks to Michael G for his contribution.
>
> I couldn't get the autoconf/automake stuff to work, but I was able
> to get Maxima compiled by following the instructions in
> maxima/INSTALL.lisp.
This sounds like a very promising start.
> The resulting maxima.fas sort of works but the testsuite
> shows a lot of errors. I haven't looked into it in detail, but
> it appears that the assume stuff (inferences about sign of
> expressions) isn't working, and my first guess about that
> is that all the EVAL-WHEN stuff is dorked up.
>
> Incidentally run_testsuite() itself barfs out an error,
> that the name of a file that needs to be loaded (namely
> testsuite.lisp) is not a stream. I worked around it by
> loading testsuite.lisp separately first.
>
> I have a couple of motivations for attempting Maxima + ECL.
> (1) ECL is a potential replacement for GCL on Windows.
Yes, I am certainly happy to help out with packaging 32 & 64 bit MSI
installer for Maxima+ecl on Windows.
> (2) It appears that the Sage project is interested only in
> Maxima + ECL. If Maxima continues to be usable through
> Sage, we might get some bug reports and, who knows,
> even bug fixes from Sage.
We do have one or two open issues, but those are with 5.13.0 and I will
upgrade to 5.15.0 first before contacting the Maxima list.
> I'll look into this some more & let you know if I can resolve anything.
> I would like to take this opportunity to invite interested parties
> of any/all projects to try this also, maybe your luck is better.
>
> FWIW & HTH.
>
> Robert Dodier
> Maxima developer
Cheers,
Michael
> >
>
Michael.Abshoff
> Hi Michael:
Hi Richard,
> Out of curiosity, I visited the ECL home page.
It is my understand that the sf website is mostly out of date, so I
never took a closer look. The current state can be found in a
presentation at
http://ecls.wiki.sourceforge.net/space/showimage/eclm2008.pdf
> I would be fairly surprised if this worked well for Maxima, for SAGE, in
> spite of some signs of life.
The paramount reason to attempt to go with ecl instead of gcl or clisp
[only self-hosted, build from source, Open Source lisps need apply :)]
was that it has compiler support for all our current and intended port
targets. gcl has build issues galore [2.6.8cvs as well as 2.7cvs], clisp
has problems with gcc 4.2 and 4.3, but that was discussed at great
length in the recent "Project" thread in sage-devel.
> It is based on "a bytecodes compiler and interpreter". with a translator to
> C. It uses the Gnu Multiprecision
> Library, which suggests to me that all short-integer arithmetic, the most
> common kind,
> will be slow and bulky.
Probably, but for the above reasons we do not have a whole lot of
choice. So the Sage project prefers a working common lisp implementation
that is slower in relative terms to a non-working much faster one. We do
not want the user to provide some common lisp implementation since a lot
of non-technical users, especially on Windows, would then take a look at
Sage and move on to the next system.
> The benchmark section says the competitive CLISP is astonishingly fast in
> comparison with ECL.
Those numbers seem to be outdated. The above linked presentation has
some comparisons IIRC of more current code. A couple months back Waldek
Herbish started building FriCAS on top of ecl and over the course of a
couple weeks ecl's performance for pretty printing code and some other
things was improved dramatically. So I am convinced that the ecl
maintainer [Juan, whom I CCed] is more than interested in solving any
performance issue and while he might be busy with his own work other
people have supplied patches to solve performance problems. So IMHO
there is much more life in the ecl community than the other open source
lisp communities.
Right now about 2/3rds of the downloads of Sage seem to be by Windows
users and as Sage will hopefully be used by more and more less technical
people the ratio will likely go up. Download statistics from sf for
Maxima indicate that the vast majority of Maxima users who download
Maxima directly actually use Windows [the ratio seems to be about 10:1
last time I looked], so I consider a well working lisp on Windows
important. Obviously many people on Linux or *BSD use the
distribution/ports provided Maxima, so they never show up at the sf
download statistics, but if 40,000 people chose to download Maxima for
Windows it seems to me that a substantial number of Maxima users are on
Windows, so it ought to be well supported, even if they were to
represent only a small percentage of overall Maxima users.
> It has a "simple conservative mark & sweep garbage collector" which means
> it will be very bad for
> long-running jobs.
The garbage collector in the current ecl release is pluggable and boehm
is used per default [IIRC it is the only choice at the moment]. I am
fairly clueless about the different garbage collection libraries out
there, so I do not know how boehm compares to what you would expect. It
was my impression that boehm is widely used, but that obviously wouldn't
make it a good implementation ;).
> It seems to be lacking tools for collecting information on memory use etc.
Judging from the presentation it is possible. But I know too little to
form an informed opinion.
> Of course, with enough effort anything can be made from anything in a Turing
> sense.
Yes :)
> Regards
> RJF
Cheers,
Michael
>
>> -----Original Message-----
>> From: maxima-...@math.utexas.edu
>> [mailto:maxima-...@math.utexas.edu] On Behalf Of Michael.Abshoff
>> Sent: Saturday, April 26, 2008 8:53 PM
>> To: sage-...@googlegroups.com
>> Cc: ecls...@lists.sourceforge.net; maxima list
>> Subject: Re: [Maxima] [sage-devel] compiling Maxima by ECL
>>
>> Robert Dodier wrote:
>>> Hello,
>> Hi,
>>
>>> I have gotten Maxima (current CVS head + ECL-specific changes)
>>> compiled by ECL (current CVS head, release 0.9j won't work).
>>> I committed the ECL-specific stuff on the branch
>> .... snip
>
>
Michael.Abshoff
>
Hello,
> ....
>> The paramount reason to attempt to go with ecl instead of gcl
>> or clisp
>> [only self-hosted, build from source, Open Source lisps need
>> apply :)]
>
> As I've mentioned previously, this seems to me an arbitrary requirement;
Yes, I am well aware of your point of view on this. But we do things the
Sage way because we think it is the better way. At the same time while
we are interested in criticism we have come a long way, so in our view
we are doing the right thing. But we do not impose our view on other
people, so if you think that your way is the better one [and I know you
do ;)] for you personally I am perfectly fine with that. I do not want
to "convert" anybody to use Sage. The success of Sage does also not
imply the failure of Maxima or any other open source CAS. There are more
than enough users to go around for everybody.
> as far as I'm concerned, I do not see as an essential requirement that
> I only run software that I can build ON MY OWN MACHINE. I only
> require that the software can be built on SOME machine, and I prefer
> that it be built by someone else, somewhere else.
Sure, but one of the reasons my job is funded is precisely because Sage
is build from sources and *every* piece of Sage is source, i.e. no
binary data. This is not a new requirement, i.e. it was part of
William's approach to Sage when he started, and many people see this as
a strength of Sage. Other people are perfectly fine with
"yum install $FOO", "apt-get whatever" or even "ebuild gcl"
We are not. Life is too short to argue about this.
> For example, I have not had a copy of GCL on any computer for many years,
> except one that was a Maxima-system-build.
Sure. But as I mentioned in
https://groups.google.com/group/sage-devel/browse_thread/thread/c65e235f83cb2cd1#
I struck out badly with gcl on multiple platforms - and I ported and/or
got everything in Sage but clisp (5 million lines of code) to build on
Solaris 9 and 10 and actually work reasonably well. gcl 2.6.8cvs as well
as gcl 2.7cvs seems to be missing OSX Intel support as I type this. So,
one of the most important Sage platforms [a majority of Sage developers
run Apple hardware and OSX - at a Sage Day you will see more Apple
notebooks than all other hardware combined] does not have gcl support
[except via Rosetta] and I would think that if gcl was a viable and
alive project that somebody would have fixed that over the last couple
years that Apple switched to Intel.
>> was that it has compiler support for all our current and
>> intended port
>> targets. gcl has build issues galore [2.6.8cvs as well as
>> 2.7cvs], clisp
>> has problems with gcc 4.2 and 4.3, but that was discussed at great
>> length in the recent "Project" thread in sage-devel.
>>
> .. snip..>
>>> RJF: The benchmark section says the competitive CLISP is
>> astonishingly fast in
>>> comparison with ECL.
>> Those numbers seem to be outdated. The above linked presentation has
>> some comparisons IIRC of more current code.
>
> I looked at that. It shows ECL slower than CLISP slower than GCL, but
> this is pretty much irrelevant because the test being timed is an ANSI CL
> standards compliance test, not a runtime efficiency test. Programs are
> run only enough to see they compute the right thing.
Sure, you certainly know more about that than I do. But if/once Maxima
works on ecl we will run the test suite of Maxima and of that works it
is good enough for me.
> A couple months
>> back Waldek
>> Herbish started building FriCAS on top of ecl and over the
>> course of a
>> couple weeks ecl's performance for pretty printing code and
>> some other
>> things was improved dramatically.
>
> A test to see how fast a program formats texts for printing does not
> seem that useful a test in the context of a computer algebra system.
> Dunno about "some other things".
It was about the amount of garbage collection needed and also about the
speed of closures. I am not expert there, but Juan can probably say
something about the issues that were fixed.
>> So I am convinced that the ecl
>> maintainer [Juan, whom I CCed] is more than interested in solving any
>> performance issue and while he might be busy with his own work other
>> people have supplied patches to solve performance problems. So IMHO
>> there is much more life in the ecl community than the other
>> open source
>> lisp communities.
>
> Seems dubious to me, but I can't say first hand if the GCL and SBCL
> communities
I didn't talk about sbcl, but clisp. sbcl seems to have more momentum
behind it than gcl or clisp, but I cannot be sure since I never
interacted with them.
> are down to less than 1-person equivalent or whatever Juan's time
> allocation is.
Well, look at the mailing list. There is more than one person working on
this and those people are contributing patches. And even if it were less
than one person working on ecl it doesn't matter to me too much because
ecl already works with MSVC and also on Solaris. Neither gcl nor clisp
does [clisp has some old Visual Studio 2003 project files, but AFAIK
nobody has tested them in a long time and the current binary is based on
MinGW], so ecl fits the bill for Sage and me.
>> snip...
>
>> last time I looked], so I consider a well working lisp on Windows
>> important.
>
> Me too. That's probably why GCL is important. And why I would prefer
> that GCL be improved.
Sure, it would be great if gcl's Windows support would be better and if
it compiled with native compilers and/or in 64 bit mode. I stated so
much and more of my reasoning in the thread I linked above, so I don't
think it will be benefit anyone from me repeating those points here.
> If ECL can be perfected without diverting resources
> from GCL or other Lisps for which Maxima already works well, that is
> fine.
Michael Goffioul did some work in 2005 as Robert stated and he himself
did some work in January of this year. And since it seems Robert's
concern that the support of Maxima on Windows could be better he has
spend some of his time working on the problem. I am hoping it will all
work out and I doubt the Maxima project would be in trouble if he spends
a couple weekends on this.
> <snip>
>> The garbage collector in the current ecl release is pluggable
>> and boehm
>> is used per default [IIRC it is the only choice at the moment]. I am
>> fairly clueless about the different garbage collection libraries out
>> there, so I do not know how boehm compares to what you would
>> expect.
>
> Well, I expect that it is unsatisfactory. You have a choice for long-running
> programs. You can spend 30% of your time in GC, increasing memory access
> time as you go, as your memory becomes fragmented, and have your system
> grind
> to a halt, or you can have a real garbage collector. ECL's experience
> may be different, but probably not.
Well, I can only restate some point I made earlier: The Sage project
cares for a working common lisp build from source a whole lot more than
one that doesn't work. ecl may have shortcomings, but it the Sage
project wants to use it we do so at our own peril. Maxima in Sage is not
used for a whole lot of computations that push the envelope because of
the way we use it via pexpect. Maxima was added for two reasons:
a) to provide some symbolic capabilities
b) to enable Sage to be used as a tool to teach Calculus
Assuming ecl works those two requirements are perfectly satisfied by
Maxima as is. But there are people in the Sage project who want to do
symbolics much more quickly and who want to write code for example to do
differential geometry. They don't want to implement that functionality
in Maxima since they do prefer C/Python/Cython and are willing to do the
work.
Sage does build on top of other systems since many times those systems
do a better job at certain tasks than could be achieved with even a
couple man years of work if you started from scratch. So we are
certainly very thankful to all the systems we use since Sage is standing
on the shoulders of giants. But any given system is only in the core of
Sage as long as the functionality provided by it is better than the
other systems and while we provide numerous ways to factor an integer
for example the default is chosen to be the "best" we have. So
functionality like operation on symbolics will move from Maxima to the
core of Sage. Integration or limits will remain with Maxima as long as
it does the best job. If somebody wrote code that did the job faster and
was on average less buggy assuming the same capabilities we will switch
that functionality per default to the new system. That is just the way
Sage works.
>> It
>> was my impression that boehm is widely used, but that
>> obviously wouldn't
>> make it a good implementation ;).
>
> It wouldn't even make it a good idea (for Lisp). It might be ok for
> short-running
> C programs, or hacked-together demos.
Well, M2 runs on top of boehm and I wouldn't call the computation of
Gröbnerbasis neither short running nor hacked together. And last time I
checked M2 did a much better job at GB computations than Maxima. That
doesn't prove the point, but there is much more in between "stupid, heap
fragmenting malloc" and garbage collection. But I had that argument with
you before, so no in getting into this again.
> Think about the widely-used OTHER software you might encounter.
Yes, widely used != quality software and we are all thinking of the same
piece of software here ;)
> ECL may be just fine for what it is, an experiment in building a Lisp with a
> slightly
> different design. If it runs Maxima and SAGE uses it, that is your decision;
> I
> hope it does not divert Maxima resources though.
Yes, I hope that in the end there will be a benefit to Maxima from
running on ecl and that the work to get this done will be quick and
painless.
Cheers,
Michael