Richard Fateman wrote:
>
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
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
