Re: [fricas-devel] Re: Project
David Joyner
Thanks for these very interesting emails! Some of my reactions are below.
- David Joyner
On Sun, Apr 20, 2008 at 9:35 AM, Bill Page <bill...@newsynthesis.org> wrote:
>
> Martin,
>
> I think discussing things like off the email lists does more damage to
> the community then it would if you were to be more public about these
> opinions. Are far as I am concerned, you have nothing to fear from
> exploring these ideas and other people might benefit greatly by your
> experience.
>
> Sage is not going away (It should not go away!) and I think the Axiom
> community needs to deal with how it should interact with Sage in the
> future.
>
> Regards,
> Bill Page.
>
> On Sun, Apr 20, 2008 at 3:10 AM, Martin Rubey <martin...@univie.ac.at> wrote:
> > I don't have the guts to send this to a public mailing list. I probably
> > should. If you want to, you have my permission.
> >
> >
> > "Alfredo Portes" <doyen...@gmail.com> writes:
> >
> > > > Axiom is so huge, so if Sage would be a part of Axiom that just handles
> > > > the web interface, why not?
> > >
> > > If you think Axiom is huge, then you need to look at Sage. It is ~10x Axiom.
> > > And in the other hand Axiom making a standard package will not happen. There
> > > are discussions on their list to remove lisp and maxima.
IMHO, I don't think removing lisp or maxima will happen anytime soon. Lots of
topics are open for discussion on the sage-devel list, and William
Stein of course
makes the final decision, but I've not heard any specific plans for
that. On the other hand,
I think a lot of people would be very happy if SymPy could, as if by
magic, implement
all the functionality of Maxima and Axiom overnight:-)
> >
> > That's bad news, at least for me. I was hoping a lot that Axiom could be
> > merged into Sage at some point, in some way. After all, Axiom does have some
> > interesting and huge packages, like the integration stuff. But maybe I'm
> > mistaken.
> >
> > It seems that Sage is going to connect with OLPC. If all those kids do their
> > math using Sage, I think there is no way around Sage anymore. Sage can already
> > do many many things better than Axiom, I suppose, so we need really good
> > reasons to continue with Axiom, I think. Maybe I should just redo the guessing
> > package in Python and be done with it? Some time ago I said that I'll quit
I think that would be awesome!!
> > Axiom if there are less than twenty contributors by the end of 2008. However,
> > it seems to me that the number of algebra contributors actually went down!
> >
> > I'd really like to hear some comments on the general plan. Do you think it's
> > feasible to
> >
> > a) attract other people, not working on Sage
> > b) merge our community into the Sage community
I personally like this idea very much, but don't have any ideas for
how this would
evolve. Again, it depends on what William Stein thinks about it. Maybe
eventually a sage-...@googlegroups.com list could be formed?
If I can help in some small way, please let me know.
> >
> > Martin
> >
> >
>
> >
>
Ondrej Certik
That will take longer than one night. :) Axiom contains a lot of
mathematics stuff that isn't implemented in SymPy, but with Maxima
I believe we'll be able to do the same things.
Maxima is very good, so I thought that when Sage wrapped Maxima in Python,
it would solve all problems, but as anyone can easily see by browsing
Sage lists, lisp is not a good technology, because it makes very hard
these days to reuse it, fix it, etc., because not so many people can
do any programming in lisp.
> > > Axiom if there are less than twenty contributors by the end of 2008. However,
> > > it seems to me that the number of algebra contributors actually went down!
> > >
> > > I'd really like to hear some comments on the general plan. Do you think it's
> > > feasible to
> > >
> > > a) attract other people, not working on Sage
> > > b) merge our community into the Sage community
>
> I personally like this idea very much, but don't have any ideas for
> how this would
> evolve. Again, it depends on what William Stein thinks about it. Maybe
> eventually a sage-...@googlegroups.com list could be formed?
> If I can help in some small way, please let me know.
I think Martin, that you would enjoy the Sage community, because all
people I met (either face to face, or just over emails) are very
friendly and they respect that people have different opinions. And the
overall atmosphere is very healthy imho, one can ask and question
basically anything on Sage lists, including all controversial topics
(like licences, languages, etc.) and the discussion was always
constructive.
I suggest you come to some Sage Days, I am sure you'll enjoy it and
learn a lot of new things as much as I did, here are my impressions
from SD6 and SD8:
http://ondrejcertik.blogspot.com/2007/11/sage-days-6.html
http://ondrejcertik.blogspot.com/2008/03/sage-days-8.html
When I was at the Axiom workshop in Hagenberg, there also was a very
good atmosphere, but I am not sure if people could reuse the actual
work of each other so easily -- you and Ralf work with Axiom, I,
Mateusz and Mike Hansen were using Python, some other people were
using MuPAD, etc. etc. The advantage of Sage is that it's easier for
other people to reuse your work. So e.g. if you write your guessing
package in Python/Sage, a lot of people could use it and work with you
on it.
Ondrej
William Stein
>
> Hi Martin, Bill:
>
> Thanks for these very interesting emails! Some of my reactions are below.
>
> - David Joyner
>
> On Sun, Apr 20, 2008 at 9:35 AM, Bill Page <bill...@newsynthesis.org> wrote:
> >
> > Martin,
> >
> > I think discussing things like off the email lists does more damage to
> > the community then it would if you were to be more public about these
> > opinions. Are far as I am concerned, you have nothing to fear from
> > exploring these ideas and other people might benefit greatly by your
> > experience.
Yep. This is one of the basic axioms of how to run a successful
open source project, according to http://producingoss.com/,
much of which I agree with.
> > Sage is not going away (It should not go away!) and I think the Axiom
> > community needs to deal with how it should interact with Sage in the
> > future.
> >
> > Regards,
> > Bill Page.
I hope Sage doesn't go away :-), since I really like open source
math software. Certainly improving Sage/Axiom community
interaction would be good.
> >
> > On Sun, Apr 20, 2008 at 3:10 AM, Martin Rubey <martin...@univie.ac.at> wrote:
> > > I don't have the guts to send this to a public mailing list. I probably
> > > should. If you want to, you have my permission.
> > >
> > >
> > > "Alfredo Portes" <doyen...@gmail.com> writes:
> > >
> > > > > Axiom is so huge, so if Sage would be a part of Axiom that just handles
> > > > > the web interface, why not?
The part of Sage that deals with the web interface is written
in pure Python and depends only on Python, Twisted, and
Pexpect. At present it is somewhat tightly integrated into
the Sage distribution. But this is only *temporary*, which
we intend to change in the future, most likely this summer.
Thus if you just want to have an Axiom GUI and or web notebook
interface, you could just ship or depend on
Python+Twisted+Pexpect+a small part of Sage.
There is also Knoboo by some other Sage developers,
which isn't as stable and full featured (yet!), but looks
very nice: http://knoboo.com/
> > > >
> > > > If you think Axiom is huge, then you need to look at Sage. It is ~10x Axiom.
The entire Sage distribution is about 5 million lines of code. Much of
this is things like scipy (around 450 thousand lines), Python itself,
etc., The core Sage library -- which we wrote in Python/Cython --
is now around 200 thousand lines.
I don't understand the Axiom distribution enough to understand
how big it is, but my impression is that it is *also* huge. Looking
in the src/src/algebra directory there are many hundreds of
thousands of lines of code (over 300,000 distinct lines just of
dot-lsp files). By the way, how do you guys read
some of this stuff? I looked in INTALG.lsp and it is
pages of code that look like this:
(PROGN
(LETT #0# NIL
|INTALG;palglogint|)
(SEQ
(LETT |q| NIL
|INTALG;palglogint|)
(LETT #1#
(SPADCALL (QCDR |fc|)
|lf| (QREFELT $ 79))
|INTALG;palglogint|)
G190
(COND
((OR (ATOM #1#)
(PROGN
(LETT |q|
(CAR #1#)
|INTALG;palglogint|)
NIL))
(GO G191)))
(SEQ
(EXIT
(LETT #0#
(CONS
(SPADCALL
(SPADCALL
(QCAR |q|) 0
(QREFELT $ 82))
(QREFELT $ 83))
#0#)
|INTALG;palglogint|)))
This is from INTALG.lsp. Surely this is some machine-generated
code that isn't meant to be human readable, so I'm
measuring the wrong thing!
Some of the code is funny (from zmod.lsp):
(DEFUN |ZMOD;coerce;I$;24| (|n| $) (|ZMOD;bloodyCompiler| |n| $))
Ahh, maybe the pamphlet files are what generate the lsp files.
It looks like the pamphlet files that come with fricas are between
100,000 and 200,000 lines long.
How does the fricas/axiom source code layout work?
Is it all written in pamphlets that lisp is generated from?
Anyway, I would love if somebody who knows what they
are talking about regarding axiom (not me!) would
explain what the human-written/readable code
parts of the axiom distro are and roughly how big each is,
in some sense. Or just point me to an article or wiki page
about this. And who are some of the Axiom original
authors? Some files have headers like:
++ Author: Grabmeier, Gschnitzer, Williamson
++ Date Created: 1987
++ Date Last Updated: July 1990
I wonder who those guys were...?
> > > > And in the other hand Axiom making a standard package will not happen. There
> > > > are discussions on their list to remove lisp and maxima.
>
>
> IMHO, I don't think removing lisp or maxima will happen anytime soon. Lots of
> topics are open for discussion on the sage-devel list, and William
> Stein of course
> makes the final decision, but I've not heard any specific plans for
> that.
There are rumblings but *definitely* no specific plans to remove
lisp or maxima. More likely is that we will reduce our dependence
on Maxima slowly for the core area of symbolic simplification.
That said, the main build manager -- Michael Abshoff -- has as
a critically important goal to get Sage to build on a huge range
of architecture, and surprisingly getting a lisp interpreter (namely
clisp) to work on such a large range of machines is really really
really painful. He might comment on this.... Anyway, Michael's
summary of the situation is:
"I know of three open source implementations of lisp
that do not need to bootstrap themselves"
a) gcl: no Solaris support, depends on libbfd, no stable release in
nearly five years. I broke this trivially on RedHat Enterprise 5 - a
platform which should be well supported. The issue was easy to fix,
but that is a different story.
b) clisp: broken with gcc 4.2.x and gcc 4.3.0 for at least six months.
In effect a single developer. compiles on Solaris with gcc 4.2.2, but
segfaults in make check, segfaults building Maxima
c) ecls: the ray of hope? Bug Maxima can't be build on top of it due
to same issues with save and load image. FriCAS has been ported to it.
Slower than clisp at the moment, but things are improving. Like clisp
in effect a single developer is working on this."
This is an area where I think the Sage project could really use help
from some of the Fricas people; namely it would be great if we could
get Maxima to build on ECLS, since then we could get rid of clisp
completely. Since Axiom has been ported to ECLS, maybe
Waldek or whoever could help a little with getting Maxima to
run on ECLS.
That might sound weird, since why would an Axiom guy want to
help with working on or improving Maxima? But that's the
** Sage WAY ** which is to get all open source software packages
to work better. I think any and all competition/fighting between
open source math software is completely counterproductive.
The goal we should all have is to provide a viable free open
source alternative to Maple, Mathematica, Matlab, and Magma.
Especially the first three systems are the ones we should view
as the competition -- everything else that's free is on our team.
> On the other hand,
> I think a lot of people would be very happy if SymPy could, as if by
> magic, implement
> all the functionality of Maxima and Axiom overnight:-)
That's not going to happen, partly by design. Sympy has (is is
starting to have) a pretty clear goal, and it's not to fully replace
the sort of functionality Axiom (or to a less extent Maxima) has,
as far as I can tell. The current plan is to rewrite symbolic
manipulation in Cython using lots of tricks so it will be very
fast, flexible, and not depend on Maxima at all. This is important,
because Maxima (via pexpect) is too slow and,
much more importantly, it is too hard for developers to improve
and change. This difficulty for developers has stopped dead
promising Sage development projects related to symbolic
calculus computation. This symbolic manipulation rewrite
is actually well on its way; Gary Furnish has been working on
it day and night for a few months now, and has been funded
by the NSF and Google (thanks!) to work on it full time at UW
all summer.
>
> > >
> > > That's bad news, at least for me. I was hoping a lot that Axiom could be
> > > merged into Sage at some point, in some way. After all, Axiom does have some
> > > interesting and huge packages, like the integration stuff. But maybe I'm
> > > mistaken.
You are not mistaken that Axiom does have interesting and huge
packages.
You guys could certainly make a version of Sage that includes Axiom along
with anything extra and built however you want, with maybe some
Axiom-specific enhancements. Just install Sage, install axiom into
it, and type
sage -bdist sage-axiom-3.0
and look in your
dist/
subdirectory for the resulting binary.
I can't explain to you why Axiom definitely hasn't been made a
part of Sage, and that it is unlikely to happen as far as I can tell.
Probably one of the most honest reasons is that I guess few
of the active Sage developers are also Axiom users/developers,
so maybe we're ignorant. I don't know. Nowadays, nothing ever gets into
Sage by just "hoping a lot". Usually somebody has to really really
want it, make many many compelling arguments, demonstrate
use cases, offer to work hard to solve problems that come up
with integration of the component into Sage, etc. Also, we have
pretty strict rules about platforms that have to be fully supported.
> > > It seems that Sage is going to connect with OLPC.
Someday it will I hope. The size of Sage is a problem though, of course,
and for us the size isn't a problem, since our goal is to compete with
the likes of Mathematica and Matlab, which are both *huge* themselves.
> > > If all those kids do their
> > > math using Sage, I think there is no way around Sage anymore.
More likely sympy (and Python!) will have a big impact on OLPC.
But I still think there is no way around Sage.
And really, the central system in all this discussion which is really
taking the entire world of mathematics by storm is ** PYTHON **.
Sage/Sympy/etc. are all just part of that.
>>> Sage can already
> > > do many many things better than Axiom, I suppose, so we need really good
> > > reasons to continue with Axiom, I think. Maybe I should just redo the guessing
> > > package in Python and be done with it? Some time ago I said that I'll quit
>
>
> I think that would be awesome!!
>
Yes, indeed redo the guessing package in Sage/Python.
It will only help improve the code in both systems. If you
have the time I would strongly encourage you to do that.
> > > Axiom if there are less than twenty contributors by the end of 2008. However,
> > > it seems to me that the number of algebra contributors actually went down!
> > >
> > > I'd really like to hear some comments on the general plan. Do you think it's
> > > feasible to
> > >
> > > a) attract other people, not working on Sage
Yes. There's tons of people who like to work on mathematics software,
and who have a wide range of tastes. Make your project as developer
friendly as possible. Go out of your way, busting your back, to make
it so new contributors are treated well, etc. etc.
> > > b) merge our community into the Sage community
Yes, that would be great too. I think there should just be one big
community of open source mathematics software developers,
all trying to together do a better job than the closed commercial
Maple/Mathematica/Magma communities.
> I personally like this idea very much, but don't have any ideas for
> how this would
> evolve. Again, it depends on what William Stein thinks about it.
+1
> Maybe
> eventually a sage-...@googlegroups.com list could be formed?
> If I can help in some small way, please let me know.
>
>
> > >
> > > Martin
> > >
> > >
> >
> > >
> >
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Alfredo Portes
Given that I started this thread, I will try to share some of my ideas
regarding your questions.
I am not an Axiom developer, probably Bill Page can answer
these questions better than anybody.
On Sun, Apr 20, 2008 at 10:29 AM, William Stein <wst...@gmail.com> wrote:
> > > Sage is not going away (It should not go away!) and I think the Axiom
> > > community needs to deal with how it should interact with Sage in the
> I hope Sage doesn't go away :-), since I really like open source
> math software. Certainly improving Sage/Axiom community
> interaction would be good.
One thing it will be good to start differentiating the projects. Like currently
the interface to Sage uses Fricas but it says Axiom...I know this is annoying
but I think it is something it should be done. This also applies to OpenAxiom.
> The part of Sage that deals with the web interface is written
> in pure Python and depends only on Python, Twisted, and
> Pexpect. At present it is somewhat tightly integrated into
> the Sage distribution. But this is only *temporary*, which
> we intend to change in the future, most likely this summer.
> Thus if you just want to have an Axiom GUI and or web notebook
> interface, you could just ship or depend on
>
> Python+Twisted+Pexpect+a small part of Sage.
>
> There is also Knoboo by some other Sage developers,
> which isn't as stable and full featured (yet!), but looks
> very nice: http://knoboo.com/
An this is very good news. In my opinion the Sage Notebook can become
the default interface to all of these systems ... and by promoting it
in this way you can find many more developers from other projects, so
having the Sage Notebook as a separate but related project like you did
with Cython will be good. Of course you would need somebody to take
the lead (Alex maybe? :-).
> I don't understand the Axiom distribution enough to understand
> how big it is, but my impression is that it is *also* huge. Looking
> in the src/src/algebra directory there are many hundreds of
> thousands of lines of code (over 300,000 distinct lines just of
> How does the fricas/axiom source code layout work?
> Is it all written in pamphlets that lisp is generated from?
> Anyway, I would love if somebody who knows what they
> are talking about regarding axiom (not me!) would
> explain what the human-written/readable code
> parts of the axiom distro are and roughly how big each is,
> in some sense. Or just point me to an article or wiki page
> about this. And who are some of the Axiom original
> authors? Some files have headers like:
>
> ++ Author: Grabmeier, Gschnitzer, Williamson
> ++ Date Created: 1987
> ++ Date Last Updated: July 1990
>
> I wonder who those guys were...?
The issue of the size came about because of if we want to use
the Sage notebook. The other thing was for Axiom or Fricas or
OpenAxiom to replace Maxima in Sage, but I know there is not
enough lobbying power :-) for this to happen.
> This is an area where I think the Sage project could really use help
> from some of the Fricas people; namely it would be great if we could
> get Maxima to build on ECLS, since then we could get rid of clisp
> completely. Since Axiom has been ported to ECLS, maybe
> Waldek or whoever could help a little with getting Maxima to
> run on ECLS.
I would think that Waldek will help to get Fricas running in Sage as
a standard component. That will be a good way of keeping a system
like Axiom alive.
> You are not mistaken that Axiom does have interesting and huge
> packages.
>
> You guys could certainly make a version of Sage that includes Axiom along
> with anything extra and built however you want, with maybe some
> Axiom-specific enhancements. Just install Sage, install axiom into
> it, and type
> sage -bdist sage-axiom-3.0
> and look in your
> dist/
> subdirectory for the resulting binary.
You mean Fricas or OpenAxiom right :-)
> I can't explain to you why Axiom definitely hasn't been made a
> part of Sage, and that it is unlikely to happen as far as I can tell.
> Probably one of the most honest reasons is that I guess few
> of the active Sage developers are also Axiom users/developers,
> so maybe we're ignorant. I don't know. Nowadays, nothing ever gets into
> Sage by just "hoping a lot". Usually somebody has to really really
> want it, make many many compelling arguments, demonstrate
> use cases, offer to work hard to solve problems that come up
> with integration of the component into Sage, etc. Also, we have
> pretty strict rules about platforms that have to be fully supported.
But isn't Axiom like the "mac daddy" off all CAS or is this all vapor ware???
Isn't Axiom better than Maxima? or this is not the case anymore? I say
this because maybe many people out there can show why Axiom would
be useful. Didn't Bill convince you at Sage Days :-)
> > > > b) merge our community into the Sage community
>
> Yes, that would be great too. I think there should just be one big
> community of open source mathematics software developers,
> all trying to together do a better job than the closed commercial
> Maple/Mathematica/Magma communities.
Well this is hard to do. There are currently a lead developer for each of the
projects. What does it mean to merge communities? So I assume you
will have to decide on which project you want to merge and talk to that person.
I know it sounds divisive, but I think a decision needs to be made.
Regards,
Alfredo
William Stein
>
> Hi William,
>
> Given that I started this thread, I will try to share some of my ideas
> regarding your questions.
>
> I am not an Axiom developer, probably Bill Page can answer
> these questions better than anybody.
>
>
> On Sun, Apr 20, 2008 at 10:29 AM, William Stein <wst...@gmail.com> wrote:
>
> > > > Sage is not going away (It should not go away!) and I think the Axiom
> > > > community needs to deal with how it should interact with Sage in the
>
>
> > I hope Sage doesn't go away :-), since I really like open source
> > math software. Certainly improving Sage/Axiom community
> > interaction would be good.
>
> One thing it will be good to start differentiating the projects. Like currently
> the interface to Sage uses Fricas but it says Axiom...I know this is annoying
> but I think it is something it should be done. This also applies to OpenAxiom.
>
I hope you fix this and submit a patch :-)
>
> > The part of Sage that deals with the web interface is written
> > in pure Python and depends only on Python, Twisted, and
> > Pexpect. At present it is somewhat tightly integrated into
> > the Sage distribution. But this is only *temporary*, which
> > we intend to change in the future, most likely this summer.
> > Thus if you just want to have an Axiom GUI and or web notebook
> > interface, you could just ship or depend on
> >
> > Python+Twisted+Pexpect+a small part of Sage.
> >
> > There is also Knoboo by some other Sage developers,
> > which isn't as stable and full featured (yet!), but looks
> > very nice: http://knoboo.com/
>
> An this is very good news. In my opinion the Sage Notebook can become
> the default interface to all of these systems ... and by promoting it
> in this way you can find many more developers from other projects, so
> having the Sage Notebook as a separate but related project like you did
> with Cython will be good. Of course you would need somebody to take
> the lead (Alex maybe? :-).
A good unifying graphical interface is extremely important to creating
something that is a viable alternative to
Maple/Mathematica/Magma/Matlab. In some sense it is perhaps it
is *the* most important thing.
>
>
> > I don't understand the Axiom distribution enough to understand
> > how big it is, but my impression is that it is *also* huge. Looking
> > in the src/src/algebra directory there are many hundreds of
> > thousands of lines of code (over 300,000 distinct lines just of
>
> > How does the fricas/axiom source code layout work?
> > Is it all written in pamphlets that lisp is generated from?
> > Anyway, I would love if somebody who knows what they
> > are talking about regarding axiom (not me!) would
> > explain what the human-written/readable code
> > parts of the axiom distro are and roughly how big each is,
> > in some sense. Or just point me to an article or wiki page
> > about this. And who are some of the Axiom original
> > authors? Some files have headers like:
> >
> > ++ Author: Grabmeier, Gschnitzer, Williamson
> > ++ Date Created: 1987
> > ++ Date Last Updated: July 1990
> >
> > I wonder who those guys were...?
>
> The issue of the size came about because of if we want to use
> the Sage notebook.
As mentioned above this is no problem. But I am just plain curious
about the size of Axiom.
> The other thing was for Axiom or Fricas or
> OpenAxiom to replace Maxima in Sage, but I know there is not
> enough lobbying power :-) for this to happen.
>
>
> > This is an area where I think the Sage project could really use help
> > from some of the Fricas people; namely it would be great if we could
> > get Maxima to build on ECLS, since then we could get rid of clisp
> > completely. Since Axiom has been ported to ECLS, maybe
> > Waldek or whoever could help a little with getting Maxima to
> > run on ECLS.
>
> I would think that Waldek will help to get Fricas running in Sage as
> a standard component. That will be a good way of keeping a system
> like Axiom alive.
Waldek has been very helpful getting Axiom to stay an optional
Sage package, by making it easy to build with clisp.
>
>
> > You are not mistaken that Axiom does have interesting and huge
> > packages.
> >
> > You guys could certainly make a version of Sage that includes Axiom along
> > with anything extra and built however you want, with maybe some
> > Axiom-specific enhancements. Just install Sage, install axiom into
> > it, and type
> > sage -bdist sage-axiom-3.0
> > and look in your
> > dist/
> > subdirectory for the resulting binary.
>
> You mean Fricas or OpenAxiom right :-)
>
Yep.
> > I can't explain to you why Axiom definitely hasn't been made a
> > part of Sage, and that it is unlikely to happen as far as I can tell.
> > Probably one of the most honest reasons is that I guess few
> > of the active Sage developers are also Axiom users/developers,
> > so maybe we're ignorant. I don't know. Nowadays, nothing ever gets into
> > Sage by just "hoping a lot". Usually somebody has to really really
> > want it, make many many compelling arguments, demonstrate
> > use cases, offer to work hard to solve problems that come up
> > with integration of the component into Sage, etc. Also, we have
> > pretty strict rules about platforms that have to be fully supported.
>
> But isn't Axiom like the "mac daddy" off all CAS or is this all vapor ware???
I don't know.
> Isn't Axiom better than Maxima?
I don't know. For some things Axiom is probably better. For others
Maxima is probably better. When I talked to people who worked on
the original projects, they say there was a lot of exchange back and
forth between the two.
From the point of view of the future and developers, my impression
is that neither project excites a lot of modern developers because
they are written in lisp and ALDOR. This is just an observation,
and I'm not making any claims about the quality of either language
or trying to start a flame war. It's just that language choices do
influence the type of programmers one gets:
http://www.paulgraham.com/pypar.html
Maxima has I think more users than Axiom.
Just look at the size of the mailing list archives for this year for Maxima:
http://www.math.utexas.edu/pipermail/maxima/2008/thread.html
But still the number of users of Axiom + Maxima + Sage (probably
less than 50,000 in the world?) still pails in comparison to the number
of users of Maple (easily 1 million?). And that's the *real* problem
we should be worrying -- and worrying *hard* -- about.
> or this is not the case anymore? I say
> this because maybe many people out there can show why Axiom would
> be useful. Didn't Bill convince you at Sage Days :-)
Bill Page did a lot of heroic work which we greatly appreciate, and we
learned a great deal from him. Thanks Bill!!
>
>
> > > > > b) merge our community into the Sage community
> >
> > Yes, that would be great too. I think there should just be one big
> > community of open source mathematics software developers,
> > all trying to together do a better job than the closed commercial
> > Maple/Mathematica/Magma communities.
>
> Well this is hard to do. There are currently a lead developer for each of the
> projects. What does it mean to merge communities? So I assume you
> will have to decide on which project you want to merge and talk to that person.
> I know it sounds divisive, but I think a decision needs to be made.
All I mean I guess is something psychological. We view each other
as being on the same team, and have a common goal, which is to genuinely
compete with Maple/Mathematica/Matlab/Magma.
By the way, regarding Sage, though I'm the lead developer decision
making is done via some form of voting. The main reasons for this is
so that we can more efficiently make more correct decisions, and also
to reduce the Sage bus factor.
-- William
TimDaly
> How does the fricas/axiom source code layout work?
> Is it all written in pamphlets that lisp is generated from?
Fricas about source code layout and it is fairly fundamental.
Axiom has everything in pamphlet files and is gradually moving
to book-style layout. (As far as I know this is the only project
that is structured this way). One of Axiom's fundamental goals
is to restructure the complete source tree to be literate
programs. See the Lisp in Small Pieces or Tex, The Program books.
Fricas is a project fork and one of its fundamental goals is to
remove the literate programming structure. This is an ongoing
effort (as evidenced by the post in late March, 2008:
<http://groups.google.com/group/fricas-commit/browse_thread/thread/
ba4f3be7d257fef?hl=en>
So I really cannot comment on the non-Axiom processes.
In Axiom all of the source code lives in Knuth-style literate
documents. So the basic process is to extract the source code
from the document and then compile it. This can involve several
steps since the algebra code has its own language (Spad). Thus
algebra goes thru the steps:
extract spad from pamphlet ->
compile code with spad compiler to lisp ->
compile lisp code with GCL to C ->
compile C code to machine code with GCC
> Anyway, I would love if somebody who knows what they
> are talking about regarding axiom (not me!) would
> explain what the human-written/readable code
> parts of the axiom distro are
The idea is that you should be able to open (using a div/pdf
viewer) the file and read it like a book.
The rational for this huge change is based on experience. I
was one of the original authors of Axiom. I got my own code
back after 15 years and found it unreadable. This is despite
my best efforts at the time to write dirt-simple, clear code.
(You will encounter the same problem with Sage in the future.)
I spent some time reading and pondering this issue and eventually
discovered that Knuth had already solved it using Web technology
for literate programs. I STRONGLY encourage you to learn about
this technology because Sage is going to have the same fundamental
problems that Axiom encountered.
One problem is that the research is not associated with the source
code. A recent example is the Pollard-Rho algorithm that was part
of the Sage/Fricas discussion. It turns out that Axiom implements
Brent's algorithm which is an extension of Pollard-Rho, despite
the comments to this list. The only way to know that is to read
the code, read the literature, and "discover" what the code does.
Sage is being built by experts who are the primary source for the
material. This is excellent while it lasts but it won't last. At
some point in the future these experts will no longer be available.
If you think long term it becomes clear what this implies.
Code is guaranteed to be opaque because the world's expert in some
area (L-functions?) wrote clever, highly optimized code that does
not correspond to anything in the literature. Thus, the only person
who can properly maintain, modify, and extend the code will no
longer be available and the code will be frozen in time. My
Magnus infinite group theory project has this problem.
New people coming onto the project cannot find the literature
that corresponds to the actual code because it does not exist.
Most published results are 5 page conference papers that just
hint at the non-core, but vitally important, details if they
mention them at all. This problem has 2 parts, both of which
stem from the lack of focus on the new discipline of computational
mathematics. Part 1 is that journals and conferences only want
short papers, which are adequate for math, not the complete
implementation. Part 2 is that there is no place to describe the
actual code-level optimizations that make the implementation
practical and fast.
I believe that the Knuth's literate programming technology will
solve the long term problem and keep the code as a living,
understandable, maintainable, and extensible object. It directly
addresses the problem of bringing the research and the code together.
It gives a place to explain both the algorithm and the current
code optimizations. Further, I've been working with Carlo Traverso
(Univ. of Pisa, Math) to create a journal of these literate
programs so the algorithms and their implementations can be made
widely available for study and improvement.
This is a controversial position and led to a philosophical
split between Axiom and Fricas. Fricas has the stated goal of
competing with Mathematica. Axiom plans to change the game so
Mathematica is irrelevant.
> and roughly how big each is, in some sense.
other systems. Axiom is highly structured using categories
and domains. It is trivially easy to construct a domain which
overrides the categorical definition of a single function
but uses all of the rest by inheritance. Thus, "line of code"
have nothing to do with "conceptual size".
That said, Axiom is still huge by any measure. It represents
about 30 years and 300 man-years of research. It covers a
wide range of computational mathematics.
> Or just point me to an article or wiki page
> about this. And who are some of the Axiom original
> authors? Some files have headers like:
>
> ++ Author: Grabmeier, Gschnitzer, Williamson
> ++ Date Created: 1987
> ++ Date Last Updated: July 1990
>
> I wonder who those guys were...?
There is a very active community based around the ISSAC
(International Symposium on Scientific and Algebraic
Computation) and ECCAD (East Coast Computer Algebra Days)
which is attended by almost everyone in the computational
mathematics community. It has a long history. There are
a large number of people still active from the early Axiom
days. You can see a list of the some of the people by
starting Axiom and typing )credits. Sage may be new but
we've been at this for a long time :-)
Sage should definitely concentrate on presenting at ISSAC.
You could probably start a Sage paper track. Since I know
most of the people involved I'd be willing to help.
> There are rumblings but *definitely* no specific plans to remove
> lisp or maxima.
face. But since that discussion is a prelude to a language war
I'll end it here.
>
> That might sound weird, since why would an Axiom guy want to
> help with working on or improving Maxima?
different. Axiom algebra is in the spad language, not Lisp.
Thus "fixing maxima" (which works fine, btw) would be like
working in a completely separate language. I know James
(the Maxima Lead) and we're not in any kind of competition.
> But that's the
> ** Sage WAY ** which is to get all open source software packages
> to work better. I think any and all competition/fighting between
> open source math software is completely counterproductive.
> The goal we should all have is to provide a viable free open
> source alternative to Maple, Mathematica, Matlab, and Magma.
the last 7 years doing that with Axiom) I have to question the
"viable" point. I think "viable" needs to be discussed within
Sage because it is vital.
If you looked at the list of credits from Axiom mentioned above
you'll notice that, of the 140+ contributors, some of them are dead.
I just attended a funeral for one in January.
Sage is too new to think about this problem but what happens when
your expertise "disappears"? What happens when you are the only
use of an open source program (such as Magnus, an infinite group
theory package)? Suppose the maintainer quits or dies? What will
Sage do (WWSD)? Do you just drop the package? Do you let it rot?
Will I find that my notebooks won't work in the next release?
If Magnus fails to compile under C++0X do you just drop it?
Do you try to recode it in Python? Do you know enough infinite
group theory to recode it? Do you know anyone willing to recode
it? Do you even know what algorithms it has?
I would hope to convince the Sage team that THE most important
contribution they can make is to provide a firm base for future
computational mathematics. Think of the science and the long
term. Insist that people document their code in a literate form
so that others can maintain and extend the code. Your REAL
issue is not the "4Ms". They are going to die because all
companies die and they are going to disappear because dying
companies take their code with them (witness Symbolics and
Macsyma). The REAL issue is the science of computational
mathematics.
Open source suffers from "project rot". Lead developers and
maintainers move on to other things and the projects die.
(Witness "Pinger", which was my open source implementation of
a closed source network management tool for Worldcom, another
company that "couldn't disappear" but did.)
> because Maxima (via pexpect) is too slow and,
> much more importantly, it is too hard for developers to improve
> and change. This difficulty for developers has stopped dead
> promising Sage development projects related to symbolic
> calculus computation. This symbolic manipulation rewrite
> is actually well on its way; Gary Furnish has been working on
> it day and night for a few months now, and has been funded
> by the NSF and Google (thanks!) to work on it full time at UW
> all summer.
documentation of a system like Maxima and know the details of
how to implement the algorithm? This IS the late 90s and we can
construct real documentation of real computational mathematics
if we want so that the science as a whole benefits. I hope that
Gary generates literate documents so I can re-implement his
algorithms in Axiom.
Ralf Hemmecke
On 04/20/2008 05:29 PM, William Stein wrote:
>> > On Sun, Apr 20, 2008 at 3:10 AM, Martin Rubey <martin...@univie.ac.at> wrote:
>> > > I don't have the guts to send this to a public mailing list. I probably
>> > > should. If you want to, you have my permission.
>> > >
>> > >
>> > > "Alfredo Portes" <doyen...@gmail.com> writes:
>> > >
>> > > > > Axiom is so huge, so if Sage would be a part of Axiom that just handles
>> > > > > the web interface, why not?
>
> The part of Sage that deals with the web interface is written
> in pure Python and depends only on Python, Twisted, and
> Pexpect. At present it is somewhat tightly integrated into
> the Sage distribution. But this is only *temporary*, which
> we intend to change in the future, most likely this summer.
> Thus if you just want to have an Axiom GUI and or web notebook
> interface, you could just ship or depend on
>
> Python+Twisted+Pexpect+a small part of Sage.
Oh, that looks interesting. The question is, who is going to implement
that? Are there any volunteers around?
> I don't understand the Axiom distribution enough to understand
> how big it is, but my impression is that it is *also* huge.
Well, one cannot cover a big part of mathematics ant not being huge.
> Looking
> in the src/src/algebra directory there are many hundreds of
> thousands of lines of code (over 300,000 distinct lines just of
> dot-lsp files). By the way, how do you guys read
> some of this stuff?
Nobody should have need to read LISP. Mathematicians are used to "higher
level". I would prefer if under src/algebra there would be only spad
files with nothing but SPAD (or Aldor) and documentation in them.
One can write relatively compact code in SPAD/Aldor and nothing like
LISP should distract from that.
Of course. And of course, nobody reads that. Or is there someone?
> How does the fricas/axiom source code layout work?
> Is it all written in pamphlets that lisp is generated from?
> Anyway, I would love if somebody who knows what they
> are talking about regarding axiom (not me!) would
> explain what the human-written/readable code
> parts of the axiom distro are and roughly how big each is,
> in some sense.
William, since you are an invited speaker at ISSAC, why not staying a
little longer and attending the Aldor & Axiom Workshop right after
ISSAC? There might be some people around that could explain.
> And who are some of the Axiom original
> authors? Some files have headers like:
> ++ Author: Grabmeier, Gschnitzer, Williamson
> ++ Date Created: 1987
> ++ Date Last Updated: July 1990
>
> I wonder who those guys were...?
I agree, nothing is perfect. But as for this particular case, I know Dr.
Johannes Grabmeier personally, and since he is working near Linz, he
might be around at the Aldor & Axiom Workshop.
Ralf
Alfredo Portes
> I hope you fix this and submit a patch :-)
Yeah I know talk is cheap. :-) but if there is no users what is the point?
Same happened to the livecd. I was thinking on creating an optional package
for OpenAxiom but just a a learning thing for myself.
> A good unifying graphical interface is extremely important to creating
> something that is a viable alternative to
> Maple/Mathematica/Magma/Matlab. In some sense it is perhaps it
> is *the* most important thing.
I look forward to this.
> Waldek has been very helpful getting Axiom to stay an optional
> Sage package, by making it easy to build with clisp.
Fricas :-)
> From the point of view of the future and developers, my impression
> is that neither project excites a lot of modern developers because
> they are written in lisp and ALDOR. This is just an observation,
> and I'm not making any claims about the quality of either language
> or trying to start a flame war. It's just that language choices do
> influence the type of programmers one gets:
> http://www.paulgraham.com/pypar.html
Yeah I think the use of a mainstream language like python in the case
of Sage was a very good one.
> Bill Page did a lot of heroic work which we greatly appreciate, and we
> learned a great deal from him. Thanks Bill!!
Yes he does. He is a very good voice to have on any project.
> By the way, regarding Sage, though I'm the lead developer decision
> making is done via some form of voting. The main reasons for this is
> so that we can more efficiently make more correct decisions, and also
> to reduce the Sage bus factor.
As it should be. Thank you.
mabshoff
On Apr 20, 3:57 pm, "David Joyner" <wdjoy...@gmail.com> wrote:
<SNIP>
> IMHO, I don't think removing lisp or maxima will happen anytime soon. Lots of
> topics are open for discussion on the sage-devel list, and William
> Stein of course
> makes the final decision,
you are wrong about William making the final decision. While William
is "Benevolent Dictator for Life" of the Sage project his opinion has
lost on technical grounds once. One of the reason I switched to the
Sage project is because things are decided on a technical level by the
community.
> but I've not heard any specific plans for
> that. On the other hand,
> I think a lot of people would be very happy if SymPy could, as if by
> magic, implement
> all the functionality of Maxima and Axiom overnight:-)
"Every long journey starts with the firs step". As people around here
should know by now Sage time can be different than real time. And many
people besides me see the dependency for basic symbolic arithmetic on
Maxima+pexpect as bad since it kills performance. That has much more
to do initially with Pexpect than Maxima, but once you benchmark
Maxima (on gcl to be fair) against some other systems on arithmetic it
loses. Integration, differentiation, limits and so on are a different
story, but Maxima seems not to be a leader there, especially compared
with the commercial systems. And that is what Sage competes with at
the end of the day.
<SNIP>
Cheers,
Michael
TimDaly
> > A good unifying graphical interface is extremely important to creating
> > something that is a viable alternative to
> > Maple/Mathematica/Magma/Matlab. In some sense it is perhaps it
> > is *the* most important thing.
important. But I find that Sage is again not thinking "long term".
Another lesson from history.... Axiom has a help system that was
wildly innovative at the time it was created. Hyperdoc did things
like "back buttons", "tear-off pages" (aka open a new window),
"live embedded graphics" (click on an image and get a graph you
can actively manipulate), "client-server interaction" (AJAX),
"network based" (e.g browser/server model).
It WAS wildly innovative at the time but "just barely" matches
what you can do in today's browser for the clever ideas it did
forsee. However, its "age is showing" and Axiom is moving to a
Firefox-based front end, similar in concept to the Sage notebook.
What causes me pause about the Sage notebook is that it is not
very innovative. Throw yourself into the future 30 years from now.
You have infinite CPU, memory, disk, and bandwidth. What will the
researcher use all of this power for? And what interface will they
use to structure their work? And what concepts will be "painfully
obvious" that everyone "should have"?
Axiom is working on a user interface based around a simple idea
called "the crystal". Think of your "problem" as a graph hanging
in space that gets continually updated with information from the
"river of the internet". Wrap a crystal with many facets around
that graph. Each facet of the crystal shows a different (but
consistent) view of the current state of the problem. Each facet
can be a face of many recursive sub-crystals covering smaller
parts of the problem. The crystals maintain the "intensional
stance" (what the user appears to be trying to do) of the user
and the graph is actively updated dynamically in anticipation
of potential requests. Thus, mentioning "L-functions" will kick
off a dynamics search and classification of all known work from
the "internet river" into the graph. Oh, yeah, and clicking for
"help" on a function brings up a LITERATE version of the function
documentation so you can learn how it really works in readable
form along with clickable bibliographic references to yet-other
literate algorithms.
It is not an issue that this cannot be done efficiently with
today's hardware. The issue is that it is a conceptual structure
that allows a consistent growth path. In the language of design
(e.g. Winograd's books) it has new tacits and new affordances
with less breakage. I'd encourage you to read Winograd or other
"design philosophy" books and think about the design of the user
interface further. Norman's design books are especially entertaining:
<http://www.amazon.com/Design-Everyday-Things-Donald-Norman/dp/
0385267746>
Ask the questions: What does a computational mathematician need?
How can we structure the science platform so those needs are
fulfilled? What conceptual structures underlie that solution?
The 4Ms cannot make this kind of leap. The corporate structure won't
allow anything so innovative to set direction. In fact, I doubt you
could get Google, despite its corporate cleverness, to even consider
funding the development of such an interface, despite the fact that
they ARE "the river of the internet". At best, you get funded for
yet-another-notebook. Sigh.
You can continue to copy the 4Ms or by defining the new tacits and
affordances you can make the 4Ms irrelevant. To paraphrase Sun Tzu,
"A great general wins wars by not fighting them"
Think long term. Look toward the 30 year horizon.
Tim
William Stein
<Michael...@mathematik.uni-dortmund.de> wrote:
>
>
>
> On Apr 20, 3:57 pm, "David Joyner" <wdjoy...@gmail.com> wrote:
> <SNIP>
>
>
> > IMHO, I don't think removing lisp or maxima will happen anytime soon. Lots of
> > topics are open for discussion on the sage-devel list, and William
> > Stein of course
> > makes the final decision,
>
> David,
>
> you are wrong about William making the final decision. While William
> is "Benevolent Dictator for Life" of the Sage project his opinion has
> lost on technical grounds once. One of the reason I switched to the
> Sage project is because things are decided on a technical level by the
> community.
+1 I vote for my decisions not being final. Compelling
technical arguments that convince people should be what
decides things.
>
>
> > but I've not heard any specific plans for
> > that. On the other hand,
> > I think a lot of people would be very happy if SymPy could, as if by
> > magic, implement
> > all the functionality of Maxima and Axiom overnight:-)
>
> That will not happen overnight, but as the Chinese proverb goes:
> "Every long journey starts with the first step". As people around here
> should know by now Sage time can be different than real time. And many
> people besides me see the dependency for basic symbolic arithmetic on
> Maxima+pexpect as bad since it kills performance. That has much more
> to do initially with Pexpect than Maxima, but once you benchmark
> Maxima (on gcl to be fair) against some other systems on arithmetic it
> loses. Integration, differentiation, limits and so on are a different
> story, but Maxima seems not to be a leader there, especially compared
> with the commercial systems. And that is what Sage competes with at
> the end of the day.
Just to add to this the other "peformance" issue is how long it takes developers
to implement new symbolic code that builds on the existing
symbolic infrastructure in Sage. With Sage building everything
on Maxima building such new code in nearly impossible. Serious
problems problems have come up thrice in practice that I can
recall regarding this: (1) Josh Kantor tried *very* hard to
create a bunch of differential geometry code building on
Maxima/Sage, but just couldn't, (2) Ondrej Certik had
many issues trying to implement something (limits)
using Sage's symbolic code, and (3) much like (1) Gary Furnish
wants to do very fast multivariable differential geometry related
to physics in Sage, but can't build it on the existing system.
>
> <SNIP>
>
> Cheers,
>
> Michael
William Stein
>
>
> > How does the fricas/axiom source code layout work?
> > Is it all written in pamphlets that lisp is generated from?
>
> There is a bit of a philosophical split between Axiom and
> Fricas about source code layout and it is fairly fundamental.
Thanks for your explanation of this, which I think was very helpful.
> Axiom has everything in pamphlet files and is gradually moving
> to book-style layout. (As far as I know this is the only project
> that is structured this way). One of Axiom's fundamental goals
> is to restructure the complete source tree to be literate
> programs. See the Lisp in Small Pieces or Tex, The Program books.
>
> Fricas is a project fork and one of its fundamental goals is to
> remove the literate programming structure. This is an ongoing
> effort (as evidenced by the post in late March, 2008:
> <http://groups.google.com/group/fricas-commit/browse_thread/thread/
> ba4f3be7d257fef?hl=en>
> So I really cannot comment on the non-Axiom processes.
>
> In Axiom all of the source code lives in Knuth-style literate
> documents. So the basic process is to extract the source code
> from the document and then compile it. This can involve several
> steps since the algebra code has its own language (Spad). Thus
> algebra goes thru the steps:
>
> extract spad from pamphlet ->
> compile code with spad compiler to lisp ->
> compile lisp code with GCL to C ->
> compile C code to machine code with GCC
What kind of runtime/build dependencies does the code
generated by GCL have? It would be cool if Axiom/Maxima/whatever
could be built as a pure C program, with no lisp involved at all,
and GCL were only used say on linux to do the
lisp --> C conversion. I have no idea if this makes any sense,
but this is what happens with Cython.
> > Anyway, I would love if somebody who knows what they
> > are talking about regarding axiom (not me!) would
> > explain what the human-written/readable code
> > parts of the axiom distro are
>
> In the near term every "source code file" is a literate document.
> The idea is that you should be able to open (using a div/pdf
> viewer) the file and read it like a book.
>
> The rational for this huge change is based on experience. I
> was one of the original authors of Axiom. I got my own code
> back after 15 years and found it unreadable. This is despite
> my best efforts at the time to write dirt-simple, clear code.
> (You will encounter the same problem with Sage in the future.)
Some people are a lot better at jumping into random code
and making sense of it than others. My thesis adviser -- Hendrik
Lenstra -- didn't code, but he was amazingly good at jumping
into "random mathematics" and making sense of it. Reading
code is similar. Actually, this whole problem you'll describing
is a problem also in mathematics research. When a person
decides to read a serious research paper in mathematics,
they will often allocate weeks (at least) to really understand the
paper (especially if they can't talk to any experts in the area).
I'm not talking about computational math here, but just research
mathematics in general, which is really the culture I was
trained in.
> I spent some time reading and pondering this issue and eventually
> discovered that Knuth had already solved it using Web technology
> for literate programs. I STRONGLY encourage you to learn about
> this technology because Sage is going to have the same fundamental
> problems that Axiom encountered.
I'm unconvinced that literate programming is a silver bullet that
solves the problem of making code easier to understand later. I do
strongly
advocate documenting and writing excellent test suites for code.
All code that goes into Sage has every function tested, documented,
and it is refereed by a different person (who may as well be somebody
reading the code 15 years later...). I think peer review is a valuable
step in the right direction toward solving the problem you are addressing.
That's what's done in mathematics to increase the chances that
somebody can understand a math paper 15 years after it is written.
> One problem is that the research is not associated with the source
> code. A recent example is the Pollard-Rho algorithm that was part
> of the Sage/Fricas discussion. It turns out that Axiom implements
> Brent's algorithm which is an extension of Pollard-Rho, despite
> the comments to this list. The only way to know that is to read
> the code, read the literature, and "discover" what the code does.
>
> Sage is being built by experts who are the primary source for the
> material. This is excellent while it lasts but it won't last.
Why won't it last? I mean, the experts will change, but I see no
reason that the statement "Sage is being built by experts ..." will
not last.
> At some point in the future these experts will no longer be available.
I guess that's true. At some point in the future nobody in particular
will be available.
> If you think long term it becomes clear what this implies.
How longterm are you thinking?
> Code is guaranteed to be opaque because the world's expert in some
> area (L-functions?) wrote clever, highly optimized code that does
> not correspond to anything in the literature. Thus, the only person
> who can properly maintain, modify, and extend the code will no
> longer be available and the code will be frozen in time.
I simply do *NOT* have such a pessimistic view of the capabilities
of the people who work on Sage.
> My Magnus infinite group theory project has this problem.
>
> New people coming onto the project cannot find the literature
> that corresponds to the actual code because it does not exist.
> Most published results are 5 page conference papers that just
> hint at the non-core, but vitally important, details if they
> mention them at all. This problem has 2 parts, both of which
> stem from the lack of focus on the new discipline of computational
> mathematics. Part 1 is that journals and conferences only want
> short papers, which are adequate for math, not the complete
> implementation. Part 2 is that there is no place to describe the
> actual code-level optimizations that make the implementation
> practical and fast.
I assume your talking specifically about your project(s) and not
all computational mathematics projects. Since the above is
not true of all such projects.
> I believe that the Knuth's literate programming technology will
> solve the long term problem and keep the code as a living,
> understandable, maintainable, and extensible object. It directly
> addresses the problem of bringing the research and the code together.
> It gives a place to explain both the algorithm and the current
> code optimizations. Further, I've been working with Carlo Traverso
> (Univ. of Pisa, Math) to create a journal of these literate
> programs so the algorithms and their implementations can be made
> widely available for study and improvement.
>
> This is a controversial position and led to a philosophical
> split between Axiom and Fricas. Fricas has the stated goal of
> competing with Mathematica. Axiom plans to change the game so
> Mathematica is irrelevant.
I'm surprised by how convinced you are that using a specific
technology/language -- literate programming -- can be a silver
bullet to solve such a difficult problem. I think peer review,
and many many other things, are steps in the right direction,
but *not* solutions to the problem. I think it's just a difficult
problem, with no easy solutions.
> > and roughly how big each is, in some sense.
>
> Ah, size. Here is where Axiom parts company with most of the
> other systems. Axiom is highly structured using categories
> and domains. It is trivially easy to construct a domain which
> overrides the categorical definition of a single function
> but uses all of the rest by inheritance.
I think Magma (and Sage) are exactly like that.
> Thus, "line of code" have nothing to do with "conceptual size".
>
> That said, Axiom is still huge by any measure. It represents
> about 30 years and 300 man-years of research. It covers a
> wide range of computational mathematics.
Sorry I was mainly interested in how many lines of code, in
some rough sense, are in the Axiom codebase, since this
whole thread started discussing the difficulties involved with
the code size of Axiom (since it's about combining source
code for project). I'm still really curious how big the Axiom
codebase is.
>
>
>
> > Or just point me to an article or wiki page
> > about this. And who are some of the Axiom original
> > authors? Some files have headers like:
> >
> > ++ Author: Grabmeier, Gschnitzer, Williamson
> > ++ Date Created: 1987
> > ++ Date Last Updated: July 1990
> >
> > I wonder who those guys were...?
>
> Ummm, who these guy *ARE*.
>
> There is a very active community based around the ISSAC
> (International Symposium on Scientific and Algebraic
> Computation) and ECCAD (East Coast Computer Algebra Days)
> which is attended by almost everyone in the computational
> mathematics community. It has a long history. There are
> a large number of people still active from the early Axiom
> days. You can see a list of the some of the people by
> starting Axiom and typing )credits. Sage may be new but
> we've been at this for a long time :-)
So have I. I've been seriously involved in writing mathematical
software for over 10 years. I worked as a developer on Magma
for 5 years...
> Sage should definitely concentrate on presenting at ISSAC.
> You could probably start a Sage paper track. Since I know
> most of the people involved I'd be willing to help.
I'm speaking at the next ISSAC... we'll see how it goes.
If that community likes Sage, then I bet a lot of positive
things will come of it. I really don't know what to expect.
> > There are rumblings but *definitely* no specific plans to remove
> > lisp or maxima.
>
> Lisp has already solved a lot of the problems Python has yet to
> face. But since that discussion is a prelude to a language war
> I'll end it here.
That's where you're a *lot* more fun to discuss mathematical
software with that Richard Fateman! Thanks for taking the
time to write.
>
>
> >
> > That might sound weird, since why would an Axiom guy want to
> > help with working on or improving Maxima?
>
> While both are coded in Lisp they are philosophically wildly
> different. Axiom algebra is in the spad language, not Lisp.
> Thus "fixing maxima" (which works fine, btw) would be like
> working in a completely separate language. I know James
> (the Maxima Lead) and we're not in any kind of competition.
I have the impression that Waldek Habisch is extremely
talented at hacking build systems and building code that
involves lisp. I wouldn't be surprised if he could make
many positive contributions toward getting Maxima to
run on http://ecls.sourceforge.net/.
>
> > But that's the
> > ** Sage WAY ** which is to get all open source software packages
> > to work better. I think any and all competition/fighting between
> > open source math software is completely counterproductive.
> > The goal we should all have is to provide a viable free open
> > source alternative to Maple, Mathematica, Matlab, and Magma.
>
> While I agree with "free" and "open source" (given that I've spent
> the last 7 years doing that with Axiom) I have to question the
> "viable" point. I think "viable" needs to be discussed within
> Sage because it is vital.
What do you mean? Do you mean that disagree with making
mathematical software that is viable? Instead you only want to
make mathematical software that is free and open source, but
isn't viable?
>
> If you looked at the list of credits from Axiom mentioned above
> you'll notice that, of the 140+ contributors, some of them are dead.
> I just attended a funeral for one in January.
Sage also unfortunately has a deceased contributor listed at
http://lite.sagemath.org/devmap.html
> Sage is too new to think about this problem but what happens when
> your expertise "disappears"?
It happens all the time. Iregardless of whether developers die or
not, they do disappear -- e.g., they go into industry instead of
academia and are legally obliged to no longer contribute (or just
not interested) -- or they move onto other things -- or get a job
with an incredibly high teaching load. It happens all the time.
What happens? You deal with it. You realize that it is going to
keep happening, so you constantly build in a wide range of
strategies to protect against it. This is the way it is with all
large software projects, or indeed all large group enterprises.
> What happens when you are the only
> use of an open source program (such as Magnus, an infinite group
> theory package)?
It typically dies.
> Suppose the maintainer quits or dies?
If there is only one user and that person quits, who cares?
> What will
> Sage do (WWSD)?
> Do you just drop the package? Do you let it rot?
We don't like having things in Sage with only 1 users in
the entire world. In fact, if there is only 1 and they vanish,
who cares?
> Will I find that my notebooks won't work in the next release?
> If Magnus fails to compile under C++0X do you just drop it?
We don't include Magnus in Sage.
> Do you try to recode it in Python? Do you know enough infinite
> group theory to recode it? Do you know anyone willing to recode
> it? Do you even know what algorithms it has?
No. No. No. No.
We would ask all those questions if somebody proposed adding
Magnus to Sage. All those no answers would likely cause
people to vote against it and it wouldn't get included.
> I would hope to convince the Sage team that THE most important
> contribution they can make is to provide a firm base for future
> computational mathematics. Think of the science and the long
> term. Insist that people document their code in a literate form
> so that others can maintain and extend the code.
We insist that people document their code and that it passes
peer review.
> Your REAL issue is not the "4Ms".
Yes it is. It's *my* personal real issue at least.
> They are going to die because all
> companies die and they are going to disappear because dying
> companies take their code with them (witness Symbolics and
> Macsyma).
All that matters to me regarding the above comments are
the *next* 30 years, since after that I'll likely be "done".
And it's possible that none of Maple/Mathematica/Matlab
will die in the next 30 years.
> The REAL issue is the science of computational
> mathematics.
Not for me. I just want to "finish" Sage as soon as possible,
so I can do research and teaching using it. From this point
of view, Sage is surprisingly close to where I want.
It's I think at most 1 or 2 years away. One important thing that we aren't
yet close on is very good native Microsoft Windows support;
and I don't mean crippled Cygwin support or virtual machines.
> Open source suffers from "project rot". Lead developers and
> maintainers move on to other things and the projects die.
> (Witness "Pinger", which was my open source implementation of
> a closed source network management tool for Worldcom, another
> company that "couldn't disappear" but did.)
Some open source projects don't die. Witness Linux, which is
an operating system that "could easily disappear" but didn't.
> > because Maxima (via pexpect) is too slow and,
> > much more importantly, it is too hard for developers to improve
> > and change. This difficulty for developers has stopped dead
> > promising Sage development projects related to symbolic
> > calculus computation. This symbolic manipulation rewrite
> > is actually well on its way; Gary Furnish has been working on
> > it day and night for a few months now, and has been funded
> > by the NSF and Google (thanks!) to work on it full time at UW
> > all summer.
>
> Gee, wouldn't it be great if Gary could just read the literate
> documentation of a system like Maxima and know the details of
> how to implement the algorithm?
> This IS the late 90s and we can
^^^^^^^^^^^^^^^^^^^^
Last I checked it is not the late 90s. ???
> construct real documentation of real computational mathematics
> if we want so that the science as a whole benefits. I hope that
> Gary generates literate documents so I can re-implement his
> algorithms in Axiom.
I'm sure he's not generating literate documents. He's probably also
mostly not coming up with any new algorithms easier. He's just
doing what he is doing because he is a very talented programming
and he needs the results to support his research interests.
-- William
William Stein
>
>
> > > A good unifying graphical interface is extremely important to creating
> > > something that is a viable alternative to
> > > Maple/Mathematica/Magma/Matlab. In some sense it is perhaps it
> > > is *the* most important thing.
>
> I fully agree that a unifying graphical interface is extremely
> important.
Cool.
> But I find that Sage is again not thinking "long term".
Quite true.
> Another lesson from history.... Axiom has a help system that was
> wildly innovative at the time it was created. Hyperdoc did things
> like "back buttons", "tear-off pages" (aka open a new window),
> "live embedded graphics" (click on an image and get a graph you
> can actively manipulate), "client-server interaction" (AJAX),
> "network based" (e.g browser/server model).
>
> It WAS wildly innovative at the time but "just barely" matches
> what you can do in today's browser for the clever ideas it did
> forsee. However, its "age is showing" and Axiom is moving to a
> Firefox-based front end, similar in concept to the Sage notebook.
Good. I remember reading about a Google Summer of Code project
to implement something like that for Axiom from 2005, I think.
That project failed; maybe the software environment offered
by lisp/axiom didn't provide enough basic building blocks to complete
the project in a few months. (However, projects can fail for numerous
reasons, and I do *not* know the real reason.)
> What causes me pause about the Sage notebook is that it is not
> very innovative.
True. It's completely straightforward and obvious. That's exactly
why I like it.
> Throw yourself into the future 30 years from now.
> You have infinite CPU, memory, disk, and bandwidth.
No they won't.
> What will the researcher use all of this power for?
> And what interface will they
> use to structure their work? And what concepts will be "painfully
> obvious" that everyone "should have"?
I don't know. 30 years from now I'll hopefully be hanging out
with my wife in the mountains of Alaska or something...
Really, my involvement in mathematics software has nothing
to do with trying to change the future of computational mathematics
in the sense you have. I care much more about having tools
*now* so that I can do the research I want to do, teach classes
in the way I want to, and write the books and articles that I
want to write. I couldn't do that with the tools available 4
years ago, hence Sage. The whole point of Sage is to solve
today's problems today.
If that turns out to be a good idea, probably my student's (or their
students) will implement it in Maple, Mathematica, Matlab, Magma,
and Sage. I hope they do.
Go for it! (Regarding any idea you have.)
Come up with a cool prototype for people to try out.
If it is actually really useful and improves the quality of
mathematical research, then unless you patent it to death,
it'll likely show up in Sage and the Ma's too.
Sage is not meant to be tomorrow's research system; it's
*today's* free open source alternative to the big
commercial mathematical software. That's it. Sage doesn't
come from the computer algebra research community;
it's not aimed at that community; and it's mostly not
being written by that community. I really don't see a problem
with that. Do you?
> The 4Ms cannot make this kind of leap. The corporate structure won't
> allow anything so innovative to set direction. In fact, I doubt you
> could get Google, despite its corporate cleverness, to even consider
> funding the development of such an interface, despite the fact that
> they ARE "the river of the internet". At best, you get funded for
> yet-another-notebook. Sigh.
I am *very* grateful to Google for their volunteer funding of open source
during the last several years!
> You can continue to copy the 4Ms or by defining the new tacits and
> affordances you can make the 4Ms irrelevant. To paraphrase Sun Tzu,
> "A great general wins wars by not fighting them"
>
> Think long term. Look toward the 30 year horizon.
Ask anybody who knows me. I'm way too impatient for that sort
of thinking. That's just my personality. I think there is a place
for both kinds of thinking, and I'm not telling you to think like
me (though you tell me to think like you). In fact, I strongly encourage
(and encouraged you above) to continue thinking about the 30 year
horizon, etc.
-- William
mabshoff
<SNIP>
> The 4Ms cannot make this kind of leap. The corporate structure won't
> allow anything so innovative to set direction. In fact, I doubt you
> could get Google, despite its corporate cleverness, to even consider
> funding the development of such an interface, despite the fact that
> they ARE "the river of the internet". At best, you get funded for
> yet-another-notebook. Sigh.
>
> You can continue to copy the 4Ms or by defining the new tacits and
> affordances you can make the 4Ms irrelevant. To paraphrase Sun Tzu,
> "A great general wins wars by not fighting them"
>
> Think long term. Look toward the 30 year horizon.
I have often joked that you would have told Linus: "Why bother with
Linux? The competition, i.e. Windows, will be dead in thirty years
anyway and we will have something better." That comparison isn't very
accurate and fair, but we [the Sage commuity] have the goal to compete
*now* with the 4Ms.
Sure, Macsyma and Symbolics died, but that is IMHO because the 4Ms
were good enough. Axiom failed as a commercial product and you did
explain to me that it was more for political reasons, i.e. platform
choice by NAG than purely technical reasons, but that is part of
"reality" and we have to deal with it and not some ideal utopia where
software projects actually make it on technical merit alone and the
playing field is level.
Windows 95 and Windows NT4 were technologically a joke compared to
the competition [NT4 less so], but the Windows franchise won in the
end in large portions of the computing sector because it was also good
"enough". And in the end I see Axiom vs. the rest of the CAS world in
the same light. Windows Server 2003 R2 and Windows Server 2008 are
solid products and while I prefer not to use them I am not ignorant
about the reality that they do the work well for people who chose to
use them. Many people might see Sage as an upstart who will fail once
it gets to the point of growth where the other systems are, but I
would like to point out that on average patches from *28* people got
patches into 2.10.x and 2.11 where the merge Window was less than two
weeks each. So I am quite bullish about Sage and its growth potential.
And I follow other CASes quite closely and I fail to see any other
system where 25+ people contribute two in a two week cycle. Those 25+
people aren't the same by the way and in the last three months more
than 70 people contributed patches to Sage. I checked that yesterday
since we are updating the credit page.
That "good enough wins" might not be ideal and/or fair, but we have to
deal with reality. The goal of the Axiom project is well spelled out
and since you are convinced that it is the right thing to do you
should follow that path. But many of us disagree with your approach
and the good thing about Open Source is that there is no "one size
fits all approach." History might judge which approach will work out
[and it can be *both*] and it is just the start of the race ;)
> Tim
Cheers,
Michael
TimDaly
> some rough sense, are in the Axiom codebase, since this
> whole thread started discussing the difficulties involved with
> the code size of Axiom (since it's about combining source
> code for project). I'm still really curious how big the Axiom
> codebase is.
for i in `find . -name "*.pamphlet" ; do cat $i >>pile ; done
wc pile
yields 814723 lines of code, which, we all agree is meaningless
in any real sense. But, roughly speaking about 4/5 of a million
lines. That does not include the embedded GCL/noweb/tools, nor
the extensive image data and hyperdoc documentation pages. It
also does not include the crystal work, the CATS work, and other
research/development tasks "in the pipe". Its just the literate
portion of the standard distribution.
I'd really roughly estimate the "size" of the system at pretty
close to 1 million "things of code".
Tim
TimDaly
> technology/language -- literate programming -- can be a silver
> bullet to solve such a difficult problem. I think peer review,
> and many many other things, are steps in the right direction,
> but *not* solutions to the problem. I think it's just a difficult
> problem, with no easy solutions.
But I do think that it exposes the real work that is needed to make
something like Sage live (see my power-of-3 screed a while back).
If Gary is going to figure out "the way up the mountain face"
wouldn't it make sense to write it down so others can read it?
Or is it better to let the next person figure it out (badly) from
reading the code and inferring the path?
Mathematical equations are "icons". You read a paper or book which
explains all the meaning of the terms and then summarize it all in
an iconic equation "E=MC^2". A book on mathematics would be rather
worthless if you just collected up all the equations, sorted them
by some random metric into collections of files, and then passed
them on to the next person. That is, however, what we do with the
code now.
Tim
David Roe
>
> > I'm surprised by how convinced you are that using a specific
> > technology/language -- literate programming -- can be a silver
> > bullet to solve such a difficult problem. I think peer review,
> > and many many other things, are steps in the right direction,
> > but *not* solutions to the problem. I think it's just a difficult
> > problem, with no easy solutions.
>
> Actually, I don't think that literate programming is a silver bullet.
> But I do think that it exposes the real work that is needed to make
> something like Sage live (see my power-of-3 screed a while back).
>
> If Gary is going to figure out "the way up the mountain face"
> wouldn't it make sense to write it down so others can read it?
> Or is it better to let the next person figure it out (badly) from
> reading the code and inferring the path?
Yes, it would be great if Gary could write that down, write a book
about it and let us know how it went. But Gary has only finite time,
and lots of things he wants to do with it. He has to choose what the
best use of his time is. And there's a lot of work that goes into
making a book that has little to do with a direct explanation of what
this line/section of code does.
There's a distinction between the style of "literate programming" and
writing documentation within your code so that others can understand
what it's doing. I understand the argument that you want the writing
to be "explanation-centric" rather than "code-centric." But writing
documentation in other ways can serve to explain what you're doing to
future readers as well. For me, I'm happy when I write good comments:
I don't want to take the time to write a book surrounding my code.
David
William Stein
>
> > I'm surprised by how convinced you are that using a specific
> > technology/language -- literate programming -- can be a silver
> > bullet to solve such a difficult problem. I think peer review,
> > and many many other things, are steps in the right direction,
> > but *not* solutions to the problem. I think it's just a difficult
> > problem, with no easy solutions.
>
> Actually, I don't think that literate programming is a silver bullet.
> But I do think that it exposes the real work that is needed to make
> something like Sage live (see my power-of-3 screed a while back).
OK, I'm glad to hear that you do *not* think literate programming is
a silver bullet, since I was really getting that impression from you.
> If Gary is going to figure out "the way up the mountain face"
> wouldn't it make sense to write it down so others can read it?
Of course.
> Or is it better to let the next person figure it out (badly) from
> reading the code and inferring the path?
Of course not.
> Mathematical equations are "icons". You read a paper or book which
> explains all the meaning of the terms and then summarize it all in
> an iconic equation "E=MC^2". A book on mathematics would be rather
> worthless if you just collected up all the equations, sorted them
> by some random metric into collections of files, and then passed
> them on to the next person. That is, however, what we do with the
> code now.
Computer code is *not* equivalent to equations. At least Python
code isn't. Any computer language (or code in a language)
where code is equivalent to only the equations in a book
is a terrible language to chose as the main implementation
language for a large mathematical software system.
I actually really like code because it is so precise. One can
use debugging techniques (especially on interpreted code)
to find out more about what code is really doing.
Comments, English paragraphs, papers, etc., tend
to be ambiguous and sometimes just wrong.
mabshoff
> > There are rumblings but *definitely* no specific plans to remove
> > lisp or maxima.
>
> Lisp has already solved a lot of the problems Python has yet to
> face.
Big" from 1991 at http://www.dreamsongs.com/WIB.html
While I disagree with the author on many points, i.e. calling Unix bad
names and so, the interesting comment is:
"The good news is that in 1995 we will have a good operating system
and programming language; the bad news is that they will be Unix and C+
+."
How prophetic ;)
>But since that discussion is a prelude to a language war I'll end it here.
at solving some programming problem. This is fundamentally about the
lisp ecosystem, i.e. how viable is the Open Source lisp tool world.
And I have build numerous lisp implementations on a wide range of
platforms and compared to building C, C++, Fortran compilers or Python
itself there are numerous problems. I have often said that your whole
ecosystem cannot be viable if your fundamental tools are hanging on by
a thread.
After I posted about *my* intention to make clisp disappear from Sage
in the long term at alt.sci.symbolic William and I got in a long off
list discussion with Fateman about Maxima, Axiom, Sage and lisp in
general. Among the point Fateman made about me pointing out that
building lisp from source sucked were:
He never had to build lisp from source, so what is the problem?
That is so short sighted it isn't even funny, i.e. water comes out of
the spout, electricity is supplied by the socket in the wall. And I
can only say the the Open Source lisp community is far behind on its
tools and since it has been decades where the situation has either
stagnated or gotten worse I don't see much of a future there. Compare
the vitality of the "lisp machine" vs. gcc, compare the support gcc
experiences by companies like Apple and IBM which are very interested
in it succeeding. Where is the lisp support? lisp in itself is no
better or worst than Python and assuming one is a master at a given
language one will likely will write a "better" program than a n00b or
bad programmer in a competing language.
In the end it all boils down to platform support and I see ecls as the
silver bullet here for Sage+lisp. I am porting Sage to Linux/PPC 64
[PPC 32 works] and Linux/Sparc[32|64] at the moment and once we get
access to AIX runnning on Power64 I will also port Sage to it. I have
even been thinking about porting it to OSX/ARM, i.e. the iPhone. We
have started on the Sage/MSVC 32 and 64 bit ports to Windows. In each
of those cases clisp will be a pain to deal with. ecls could fill the
gap and I would personally throw a huge effort in making sure ecls
does build and work on all of those platforms and all platforms Sage
already supports assuming Maxima would work with it. So, the ball is
in your court.
Cheers,
Michael
TimDaly
On Apr 20, 5:23 pm, "David Roe" <r...@math.harvard.edu> wrote:
at the "finite time" issue because I just spent the last 2 weeks
coding in python using wxPython as a front end. The net seems to
think that wxPython is "well documented".... because it appears that
python has some sort of Doxygen/JavaDoc tool and all anyone ever
needs to know is the names of the classes and methods. There is
hardly a human-readable line of text anywhere. When all else fails
(which happened 3 times in fairly fundamental bugs) we could always
"read the source code". And we all know that SWIG generates very
understandable code. But that's ok because wxPython is yet-another
of the 100 windowing systems and nobody really cares if the answers
are correct.... I was just hoping that computational mathematicians
were more motivated, since it matters.
Knuth pointed out that explaining his code forced him to think
about it in ways that vastly improved the correctness. So much so
that he felt a near-religious conversion to literate programming.
Given that TeX has so few errors after so many millions of uses
(and he PAYS for errors found), I tend to think it worthwhile.
And I do find that explaining code has the same effect for me.
Prior to using LP I have a measured error rate of 3 mistakes
per hundred operations. I believe that literate programming will
reduce that number (but have not yet done enough for meaningful
measurements). I have had the experience of catching bug while
writing the explanation so I'm hopeful.
I recommend reading a short book called "Leisure, The Basis of
Culture" by Josef Pieper. (1963 Random House).
TimDaly
> After I posted about *my* intention to make clisp disappear from Sage
> in the long term at alt.sci.symbolic William and I got in a long off
> list discussion with Fateman about Maxima, Axiom, Sage and lisp in
> general. Among the point Fateman made about me pointing out that
> building lisp from source sucked were:
>
> He never had to build lisp from source, so what is the problem?
subject, more than he lets on, but that's up to him to defend. I
have great respect for his opinions.
I helped William Schelter in the development of GCL back when it
was known as AKCL. He used my office often during his visits and
we worked closely on portions of its development. I have written
parts of the garbage collector and some other small pieces so I'm
intimately familiar with the guts of it.
>
> That is so short sighted it isn't even funny, i.e. water comes out of
> the spout, electricity is supplied by the socket in the wall. And I
> can only say the the Open Source lisp community is far behind on its
eh? really? not for me. but that way lies language-wars so lets stop.
> In the end it all boils down to platform support and I see ecls as the
> silver bullet here for Sage+lisp.
I
moved Axiom onto the handheld Zaurus using GCL. And many years ago I
moved Axiom onto DOS 3.0 using GCL. Maxima runs (fast) using GCL. Why
do you want to move off that platform? It contains everything you
need,
it builds from source, it is actively maintained, and is very fast.
I'm
sure you have good reasons for choosing ECLS but I don't understand.
Frankly, I'd think that it would be straightforward to write a python
compiler in lisp (if only the EU would give me the $20M Euro it gave
the other project). Once that was done you could compile and optimize
the python automatically. My son implemented a commercially available
PHP compiler in lisp in under 3 years and python is about the same
complexity. In fact, if I were still teaching the compiler course, I'd
assign it as a class project. Until python has a decent compiler I
have trouble considering it anything more than MS-basic with classes.
(And that, of course, is certainly NOT gonna make me popular).
Tim
Ondrej Certik
just speaking for myself here:
another way at looking at things is that I want to use today's (maybe
imperfect) tools and today's (maybe busy) people and
I want to get something useful (maybe imperfect) today. And the beauty
of it is to manage everything just right to get something useful out
of it,
that people actually find interesting and usable. Yes, I love to live
just now. :)
Also I love the Linus quote "Talk is cheap. Show me the code.". So
it's nice it's maybe theoretically possible to write a python
interpreter in lisp, but
right now, at this very moment, there is no such thing in Debian, so
that is not a technology for me.
Ondrej
mabshoff
On Apr 21, 12:46 am, TimDaly <d...@axiom-developer.org> wrote:
Hi Tim,
> > After I posted about *my* intention to make clisp disappear from Sage
> > in the long term at alt.sci.symbolic William and I got in a long off
> > list discussion with Fateman about Maxima, Axiom, Sage and lisp in
> > general. Among the point Fateman made about me pointing out that
> > building lisp from source sucked were:
>
> > He never had to build lisp from source, so what is the problem?
>
> Richard was deeply involved in lisp and knows a fair bit about the
> subject, more than he lets on, but that's up to him to defend. I
> have great respect for his opinions.
nature of things.
> I helped William Schelter in the development of GCL back when it
> was known as AKCL. He used my office often during his visits and
> we worked closely on portions of its development. I have written
> parts of the garbage collector and some other small pieces so I'm
> intimately familiar with the guts of it.
to use in Sage.
> > That is so short sighted it isn't even funny, i.e. water comes out of
> > the spout, electricity is supplied by the socket in the wall. And I
> > can only say the the Open Source lisp community is far behind on its
> > tools ...
>
> eh? really? not for me. but that way lies language-wars so lets stop.
it at that ;)
> > In the end it all boils down to platform support and I see ecls as the
> > silver bullet here for Sage+lisp.
>
> I have no idea why you think ECLS is a silver bullet. Three years ago
> I
> moved Axiom onto the handheld Zaurus using GCL. And many years ago I
> moved Axiom onto DOS 3.0 using GCL. Maxima runs (fast) using GCL. Why
> do you want to move off that platform? It contains everything you
> need,
> it builds from source, it is actively maintained, and is very fast.
essential importance we will/cannot use it. It used to be quite bad on
OSX, but it has gotten much better there. I am certain I can get some
sort of lisp running on pretty much any system, but that is not the
Sage way. We want a self hosted, compile from source anywhere lisp
that Maxima supports and we are now talking about the empty set. Feel
free to prove me wrong, I would be very, very happy to be proven wrong
on this. Ironically the most portable lisp implementation is the one
in Emacs, but I don't think it is common lisp.
> I'm
> sure you have good reasons for choosing ECLS but I don't understand.
since it uses a C compiler directly.
> Frankly, I'd think that it would be straightforward to write a python
> compiler in lisp (if only the EU would give me the $20M Euro it gave
> the other project).
never solved it. I am sure you have read the mythical man month. ;)
> Once that was done you could compile and optimize
> the python automatically. My son implemented a commercially available
> PHP compiler in lisp in under 3 years and python is about the same
> complexity.
Fateman) prefer lisp and think it is the answer. But if I look around
at people at the university level or a couple years out of it there is
very, very little lisp. So, while the absolute number of lisp
programmers might have grown over the years its part of the
programming market has shrunk since the programming market has gotten
so much bigger. The beautiful thing about Open Source is that as long
as one person cares a project does not die. But that doesn't mean that
lisp+Sage is a good match ;)
> In fact, if I were still teaching the compiler course, I'd
> assign it as a class project. Until python has a decent compiler I
> have trouble considering it anything more than MS-basic with classes.
> (And that, of course, is certainly NOT gonna make me popular).
>
> Tim
done a python to lisp machine port but it never got very far and there
is quite a difference between "something that works for me" to
"something that works!" - I experience this daily with Sage and it is
hard, hard work to make Sage run and compile beyond the normal Linux &
OSX mix.
Cheers,
Michael
mabshoff
interpreter into an external library, hence we would be able to use
Maxima as a library instead of using the inefficient pexpect
interface. I am not sure how much work this would be, but if I were a
Maxima coder I would certainly look into that possibility since it
opens a whole lot of possibilities for Maxima IMHO - totally
independent of Maxima's role in Sage.
<SNIP>
Cheers,
Michael
William Stein
This webpage has a ranking of programming language popularity,
which might be a bit more scientific then the above anecdotal when
"I look around". This page is for the following purpose:
"The index can be used to check whether your programming
skills are still up to date or to make a strategic decision about
what programming language should be adopted when starting
to build a new software system."
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
It goes:
Java, C, Visual Basic, PHP, C++, Perl, Python
then
C#, Ruby, Delphi, Javascript, D, PL/SQL,
then
SAS, Pascal, Lisp/Scheme, FoxPro, Cobol, ADA,
so lisp is number 17. In raw numbers Python is ten times
as popular as Lisp and Scheme.
In the next group (below 20) is:
ColdFusion, Logo, Lua, ActionScript, FORTRAN, RPG,
Matlab, Prolog, AWK, ...
and R is at 45th.
-- William
> The beautiful thing about Open Source is that as long
> as one person cares a project does not die. But that doesn't mean that
> lisp+Sage is a good match ;)
Also projects (even closed ones) can die and be resurrected.
Maybe Scratchpad/Axiom an example of such a project...
That's a good thing.
> > In fact, if I were still teaching the compiler course, I'd
> > assign it as a class project. Until python has a decent compiler I
> > have trouble considering it anything more than MS-basic with classes.
> > (And that, of course, is certainly NOT gonna make me popular).
> >
> > Tim
>
> Well, I don't see lisp making a come back any time soon. People have
> done a python to lisp machine port but it never got very far and there
> is quite a difference between "something that works for me" to
> "something that works!" - I experience this daily with Sage and it is
> hard, hard work to make Sage run and compile beyond the normal Linux &
> OSX mix.
Disagree with Michael about porting/building issues at your own peril.
-- William
root
>
>I forgot one important argument here: With ecls you can embed the lisp
>interpreter into an external library, hence we would be able to use
>Maxima as a library instead of using the inefficient pexpect
>interface. I am not sure how much work this would be, but if I were a
>Maxima coder I would certainly look into that possibility since it
>opens a whole lot of possibilities for Maxima IMHO - totally
>independent of Maxima's role in Sage.
I looked at pexpect. It appears to be a process controller of sorts
that interprets and parses console I/O.
Axiom has its own version called sman (superman). You don't normally
type directly at the axiom command prompt but are talking to sman
which mediates the console i/o. Sman manages a set of processes
(the AXIOMsys interpreter, the graphics, hyperdoc, etc) but makes
it appear that you are talking to axiom. You could talk directly
to the AXIOMsys system prompt or directly to AXIOMsys thru a network
port (which is how the Axiom Firefox works). But sman doesn't actually
parse anything at all. It is just a very small C program which forks
processes and sets up ptys and thus has nearly zero overhead.
I'm not sure what Maxima does. But I'd bet that almost all of the
overhead you're seeing isn't Maxima but pexpect delay. Somebody
is probably playing parsing games to get prompt and end-of-input
processing and that has got to cost a lot. Why not just reach into
the lisp and do it directly? Why use a console connection at all?
Using pexpect has got to be the worst of all possible ways to talk
to Maxima.
In any case, it is certainly possible to use lisp as a library
element rather than using pexpect. I'm not sure why ECLS is special
in this context since I've never used it.
Tim
William Stein
>
> >> I have no idea why you think ECLS is a silver bullet.
> >
> >I forgot one important argument here: With ecls you can embed the lisp
> >interpreter into an external library, hence we would be able to use
> >Maxima as a library instead of using the inefficient pexpect
> >interface. I am not sure how much work this would be, but if I were a
> >Maxima coder I would certainly look into that possibility since it
> >opens a whole lot of possibilities for Maxima IMHO - totally
> >independent of Maxima's role in Sage.
>
> I looked at pexpect. It appears to be a process controller of sorts
> that interprets and parses console I/O.
> Axiom has its own version called sman (superman). You don't normally
> type directly at the axiom command prompt but are talking to sman
> which mediates the console i/o. Sman manages a set of processes
> (the AXIOMsys interpreter, the graphics, hyperdoc, etc) but makes
> it appear that you are talking to axiom. You could talk directly
> to the AXIOMsys system prompt or directly to AXIOMsys thru a network
> port (which is how the Axiom Firefox works). But sman doesn't actually
> parse anything at all. It is just a very small C program which forks
> processes and sets up ptys and thus has nearly zero overhead.
>
> I'm not sure what Maxima does. But I'd bet that almost all of the
> overhead you're seeing isn't Maxima but pexpect delay.
Are you saying that all the *overhead* we're seeing with communicating
with Maxima via pexpect is overhead associated with pexpect?
That's kind of circular.
> Somebody
> is probably playing parsing games to get prompt and end-of-input
> processing and that has got to cost a lot. Why not just reach into
> the lisp and do it directly?
How does one just "reach into lisp"?
> Why use a console connection at all?
> Using pexpect has got to be the worst of all possible ways to talk
> to Maxima.
Sort of like how democracy is the worst of all possible
governments that work or something.
Anyway, one bonus of using Maxima via pexpect is that
it works, and moreover almost the same code that works
for this works for using about 15 other math software
systems from Sage in almost exactly the same way.
> In any case, it is certainly possible to use lisp as a library
> element rather than using pexpect.
That's great news. Could you implement using lisp as a library
element from python? Thanks.
William
mabshoff
> >> I have no idea why you think ECLS is a silver bullet.
> >I forgot one important argument here: With ecls you can embed the lisp
> >interpreter into an external library, hence we would be able to use
> >Maxima as a library instead of using the inefficient pexpect
> >interface. I am not sure how much work this would be, but if I were a
> >Maxima coder I would certainly look into that possibility since it
> >opens a whole lot of possibilities for Maxima IMHO - totally
> >independent of Maxima's role in Sage.
>
> I looked at pexpect. It appears to be a process controller of sorts
> that interprets and parses console I/O.
> Axiom has its own version called sman (superman). You don't normally
> type directly at the axiom command prompt but are talking to sman
> which mediates the console i/o. Sman manages a set of processes
> (the AXIOMsys interpreter, the graphics, hyperdoc, etc) but makes
> it appear that you are talking to axiom. You could talk directly
> to the AXIOMsys system prompt or directly to AXIOMsys thru a network
> port (which is how the Axiom Firefox works). But sman doesn't actually
> parse anything at all. It is just a very small C program which forks
> processes and sets up ptys and thus has nearly zero overhead.
be some kind of ASCII I assume.
> I'm not sure what Maxima does. But I'd bet that almost all of the
> overhead you're seeing isn't Maxima but pexpect delay. Somebody
> is probably playing parsing games to get prompt and end-of-input
> processing and that has got to cost a lot. Why not just reach into
> the lisp and do it directly? Why use a console connection at all?
> Using pexpect has got to be the worst of all possible ways to talk
> to Maxima.
embedded in a library offers the possibility to work directly with the
data without the need to translate anything [unless you want to get
you data back into Sage structures or the other way around]. It would
also kill synchronization issues that crop up with pexpect for
example.
> In any case, it is certainly possible to use lisp as a library
> element rather than using pexpect. I'm not sure why ECLS is special
> in this context since I've never used it.
in a C library. Can you point me to one?
> Tim
Cheers,
Michael
root
>> element rather than using pexpect. I'm not sure why ECLS is special
>> in this context since I've never used it.
>
>I am not aware of any other lisp interpreter that you can easily embed
>in a C library. Can you point me to one?
GCL is just a C program. Use memory mapped I/O to map your input string
as a "file" and your output area as another file. See
<http://www.ecst.csuchio.edu/~beej/guide/ipc/mmap.html>
Give GCL the memory map file handles for I/O. Call read. (See
<http://cvs.savannah.gnu.org/viewvc/gcl/o/read.d?root=gcl&view=markup>)
Fetch the output from the mmapped memory output "file" region.
Zero parsing overhead using filelength to delimit the output.
The "problem" with this approach is that (a) it isn't generic like
pexpect and (b) it requires programming (although this is posix).
You could probably hack it up in Cython.
Tim
Bill Page
> ...
> I do not doubt that gcl is a good tool, but I doubt it is a good tool
> to use in Sage.
> > > In the end it all boils down to platform support and I see ecls as
> > > the silver bullet here for Sage+lisp.
> >
> > I have no idea why you think ECLS is a silver bullet. Three years
> > ago I moved Axiom onto the handheld Zaurus using GCL.
?? The Debian arm version of Axiom installs on Zaurus without
problems. As far as I know all of the Debian Axiom builds were done by
Camm Maguire who is also the primary maintainer of GCL.
> > And many years ago I moved Axiom onto DOS 3.0 using GCL. Maxima
> > runs (fast) using GCL. Why do you want to move off that platform? It
> > contains everything you need, it builds from source, it is actively
> > maintained, and is very fast.
>
I am not so sure one could honestly say that "it is actively
maintained", but I would have to agree that Camm Maguire is usually
very responsive.
> No, it fails to build on Solaris and since Sage on Solaris is of
> essential importance we will/cannot use it.
That is strange. I have built recent versions of GCL from cvs on
Solaris 10 - both sparc and x86 - without problems. I am using the gnu
tool chain from Blastwave. Have you contacted Camm Maguire about the
problems you are having?
> ...
> I just works with little need to do have a magic lisp machine working
> since it uses a C compiler directly.
>
GCL uses the C compiler directly. I am not suggesting that GCL is
necessarily the "right" lisp for Sage (or even that Sage needs a lisp
compiler at all) but I do rather think you should give GCL another
try. I would be glad to try to help you debug the problems on Solaris.
Regards,
Bill Page.
mabshoff
On Apr 21, 6:48 am, "Bill Page" <bill.p...@newsynthesis.org> wrote:
> On Sun, Apr 20, 2008 at 7:22 PM, mabshoff wrote:
> > I do not doubt that gcl is a good tool, but I doubt it is a good tool
> > to use in Sage.
> > ...
> > > > In the end it all boils down to platform support and I see ecls as
> > > > the silver bullet here for Sage+lisp.
>
> > Tim Daly wrote:
> > > I have no idea why you think ECLS is a silver bullet. Three years
> > > ago I moved Axiom onto the handheld Zaurus using GCL.
>
> ?? The Debian arm version of Axiom installs on Zaurus without
> problems. As far as I know all of the Debian Axiom builds were done by
> Camm Maguire who is also the primary maintainer of GCL.
>
> > > And many years ago I moved Axiom onto DOS 3.0 using GCL. Maxima
> > > runs (fast) using GCL. Why do you want to move off that platform? It
> > > contains everything you need, it builds from source, it is actively
> > > maintained, and is very fast.
>
> I am not so sure one could honestly say that "it is actively
> maintained", but I would have to agree that Camm Maguire is usually
> very responsive.
>
> > No, it fails to build on Solaris and since Sage on Solaris is of
> > essential importance we will/cannot use it.
>
> That is strange. I have built recent versions of GCL from cvs on
> Solaris 10 - both sparc and x86 - without problems. I am using the gnu
> tool chain from Blastwave. Have you contacted Camm Maguire about the
> problems you are having?
Solaris 9. It builds every other components of Sage unlike the
Blastwave toolchain ;)
> > ...
> > I just works with little need to do have a magic lisp machine working
> > since it uses a C compiler directly.
>
> GCL uses the C compiler directly. I am not suggesting that GCL is
> necessarily the "right" lisp for Sage (or even that Sage needs a lisp
> compiler at all) but I do rather think you should give GCL another
> try. I would be glad to try to help you debug the problems on Solaris.
to try switching away from clisp. Let me give it a whirl and see what
happens.
> Regards,
> Bill Page.
Cheers,
Michael
mabshoff
> GCL uses the C compiler directly. I am not suggesting that GCL is
> necessarily the "right" lisp for Sage (or even that Sage needs a lisp
> compiler at all) but I do rather think you should give GCL another
> try. I would be glad to try to help you debug the problems on Solaris.
Solaris 9 and 10 in the same spot:
Solaris 9:
# Subconfigure of BFD done
# ------------------------
#
checking size of long... 4
checking size of int... 4
checking size of short... 2
checking size of char... 1
checking for number of bits in char... 8
checking whether byte ordering is bigendian... yes
checking for sbrk... yes
checking for randomized sbrk... no
checking for required object alignment... 8
checking for C extension variable alignment... __attribute__ ((aligned
(8)))
checking TYPE_BITS macro... 0xff09
checking sizeof struct contblock... 8
checking for pagewidth... 13
checking DBEGIN... 0x20000
checking CSTACK_ADDRESS... 0xffbfffff
checking NEG_CSTACK_ADDRESS... yes
checking finding CSTACK_ALIGNMENT... 8
checking CSTACK_DIRECTION... -1
checking for shared library/C stack ceiling to heap... failed
Solaris 10:
#
# Subconfigure of BFD done
# ------------------------
#
checking size of long... 4
checking size of int... 4
checking size of short... 2
checking size of char... 1
checking for number of bits in char... 8
checking whether byte ordering is bigendian... yes
checking for sbrk... yes
checking for randomized sbrk... no
checking for required object alignment... 8
checking for C extension variable alignment... __attribute__ ((aligned
(8)))
checking TYPE_BITS macro... 0xff09
checking sizeof struct contblock... 8
checking for pagewidth... 13
checking DBEGIN... 0x20000
checking CSTACK_ADDRESS... 0xffbfffff
checking NEG_CSTACK_ADDRESS... yes
checking finding CSTACK_ALIGNMENT... 8
checking CSTACK_DIRECTION... -1
checking for shared library/C stack ceiling to heap... ./configure: !:
not found
usage: tail [+/-[n][lbc][f]] [file]
tail [+/-[n][l][r|f]] [file]
failed
This second failure leaves me to believe that someone is assuming a
version of GNU tail. I am using a gcc 4.2.2 compiled from sources both
times.
mabshoff
On Apr 21, 7:33 am, mabshoff <Michael.Absh...@mathematik.uni-
actually the root cause.
And some more build tests:
3) OSX 10.5.2 Intel, current XCode 3.0:
bsd:gcl mabshoff$ uname -a
Darwin bsd.local 9.2.0 Darwin Kernel Version 9.2.0: Tue Feb 5
16:13:22 PST 2008; root:xnu-1228.3.13~1/RELEASE_I386 i386
checking how to switch to text section... .text
checking how to switch to data section... .data
checking what assembly label suffix to use... :
checking how to export a symbol... .globl
checking if globals are prefixed by underscore... configure: error:
Test program links neither with nor without underscore.
#
#
#
# Subconfigure of GMP done
# ------------------------
#
cp: gmp3/gmp.h: No such file or directory
checking for leading underscore in object symbols... yes
checking for GNU ld option -Map... no
checking for size of gmp limbs... Cannot determine mpsize
4) And the most ironic build failure on an x86-64 Debian box:
mabshoff@sage:~/gcl$ uname -a
Linux sage 2.6.18-6-amd64 #1 SMP Sun Feb 10 17:50:19 UTC 2008 x86_64
GNU/Linux
mabshoff@sage:~/gcl$ make
make: *** No rule to make target `/usr/lib/libbfd.a', needed by
`copy_bfd'. Stop.
I have hit the same bug months ago with RHEL 4 x86-64, so I am not
being the unluckiest person on the planet and check out cvs on the
wrong day.
On a positive note it build fine on RHEL 5/Itanium.
So, in the end I only hope that you can understand why I am more than
a little dubious about the build quality of gcl. All these are boxen
that build Sage fine [the Solaris boxen need a little help, i.e. about
2,3 fixes, but all that is getting merged back into Sage 3.0.1 or
3.0.2], so this is far from some FUBAR build box where I set gcl up to
fail.
> > Regards,
> > Bill Page.
>
> Cheers,
>
> Michael
Michael
Martin Rubey
"William Stein" <wst...@gmail.com> writes:
> I don't understand the Axiom distribution enough to understand
> how big it is, but my impression is that it is *also* huge. Looking
> in the src/src/algebra directory there are many hundreds of
> thousands of lines of code (over 300,000 distinct lines just of
> dot-lsp files).
These files are *not* the source code, they are the code produced by the SPAD
compiler. The compilation process goes SPAD -> Lisp -> whatever the lisp
produces.
What you want to read are the xxx.spad.pamphlets. They should be very clear to
read. In fact, that was one of the more important reasons why I switched from
Maxima to Axiom.
> This is from INTALG.lsp. Surely this is some machine-generated code that
> isn't meant to be human readable, so I'm measuring the wrong thing!
Oh, sorry. You realized it already. Well, it won't hurt.
> Some of the code is funny (from zmod.lsp):
>
> (DEFUN |ZMOD;coerce;I$;24| (|n| $) (|ZMOD;bloodyCompiler| |n| $))
If you want to, I could even explain that line :-)
> Ahh, maybe the pamphlet files are what generate the lsp files.
>
> It looks like the pamphlet files that come with fricas are between 100,000
> and 200,000 lines long.
>
> How does the fricas/axiom source code layout work? Is it all written in
> pamphlets that lisp is generated from?
The current strategy (at least from my point of view) is to have the maths
(i.e., everything in the algebra directory) in noweb (AKA pamphlet) form. The
compiler and the interpreter itself use traditional documentation. In my
opinion, this makes sense, since I want to use LaTeX to explain certain maths
(LaTeX was made for that), but the compiler and the interpreter do not contain
math on that level.
> "I know of three open source implementations of lisp that do not need to
> bootstrap themselves"
What's wrong with bootstrapping, and in particular with sbcl?
http://www.sbcl.org/platform-table.html
Do you insist on building the lisp from scratch? If so, why?
In any case, I think that clisp is not a very good choice for FriCAS except
that it is available almost everwhere. SBCL based FriCAS is *a lot* faster. I
do not have a clisp version handy, but SBCL vs. GCL makes a *factor* of 2 for,
eg., guessing. CLISP is still slower.
> Yes, indeed redo the guessing package in Sage/Python. It will only help
> improve the code in both systems. If you have the time I would strongly
> encourage you to do that.
No, I'm currently struggling to get a job, and it's not unlikely that I'll have
to quit in January anyway. Furthermore, I doubt that it's interesting to
improve the code. It would be interesting to improve the algorithm, though.
Martin
mabshoff
> Just a quick note now, maybe more later:
Hi Martin,
> > "I know of three open source implementations of lisp that do not need to
> > bootstrap themselves"
>
> What's wrong with bootstrapping, and in particular with sbcl?http://www.sbcl.org/platform-table.html
> Do you insist on building the lisp from scratch?
> If so, why?
Shipping binaries is not an option due to size constraints. Requiring
some external version of lisp is tricky and Maxima for example behaves
differently, i.e. default precision of floats is different, with
different lisp implementations. And Sage is supposed to be a compile
from scratch & self hosting experience and while it usually isn't a
problem to find or install some version of lisp on Linux it is a pain
to do so on Windows or OSX. And Sage is supposed to be "easy" to
install and run and every external requirement makes it more
complicated. There are also important Sage users who greatly
appreciate the fact that every bit in Sage can be delivered in source.
> In any case, I think that clisp is not a very good choice for FriCAS except
> that it is available almost everwhere. SBCL based FriCAS is *a lot* faster. I
> do not have a clisp version handy, but SBCL vs. GCL makes a *factor* of 2 for,
> eg., guessing. CLISP is still slower.
compared to gcl and especially sbcl, but we prefer a buildable lisp
over a potentially faster version that creates even more build
problems.
<SNIP>
> Martin
Cheers,
Michael
Ondrej Certik
Well, you can first build clisp and then sbcl using clisp. :)
Ondrej
William Stein
>
>
> On Mon, Apr 21, 2008 at 9:25 AM, mabshoff
> <Michael...@mathematik.uni-dortmund.de> wrote:
> >
> > On Apr 21, 9:09 am, Martin Rubey <martin.ru...@univie.ac.at> wrote:
> > > Just a quick note now, maybe more later:
> >
> > <SNIP>
> >
> > Hi Martin,
> >
> >
> > > > "I know of three open source implementations of lisp that do not need to
> > > > bootstrap themselves"
> > >
> > > What's wrong with bootstrapping, and in particular with sbcl?http://www.sbcl.org/platform-table.html
> >
> > I like sbcl and it works well.
> >
> >
> > > Do you insist on building the lisp from scratch?
> >
> > Yes.
> >
> > > If so, why?
> >
> > Shipping binaries is not an option due to size constraints. Requiring
> > some external version of lisp is tricky and Maxima for example behaves
> > differently, i.e. default precision of floats is different, with
> > different lisp implementations. And Sage is supposed to be a compile
> > from scratch & self hosting experience and while it usually isn't a
> > problem to find or install some version of lisp on Linux it is a pain
> > to do so on Windows or OSX. And Sage is supposed to be "easy" to
> > install and run and every external requirement makes it more
> > complicated. There are also important Sage users who greatly
> > appreciate the fact that every bit in Sage can be delivered in source.
Just to emphasize -- the fact that Sage can be built from source
on the supported platforms is perhaps the most basic requirement
at the core of the Sage project.
Sage is three things: (1) an easily buildable-from-source distribution
of math software; (2) a new library; (3) interfaces. Part of the
definition of part (1) is that Sage be buildable from source
with only the following potentially nonstandard dependencies:
gcc, g++, make, m4, perl, ranlib, and tar
This has not changed since day 1 of Sage and it won't, except
that eventually we may include gfortran in the list.
Note -- we currently ship some Fortran binaries with the Sage
source tarball, but they can easily be deleted if one has gfortran,
which is fairly standard.
> >
> >
> > > In any case, I think that clisp is not a very good choice for FriCAS except
> > > that it is available almost everwhere. SBCL based FriCAS is *a lot* faster. I
> > > do not have a clisp version handy, but SBCL vs. GCL makes a *factor* of 2 for,
> > > eg., guessing. CLISP is still slower.
> >
> > Yes, we are well aware that clisp is quite bad performance wise
> > compared to gcl and especially sbcl, but we prefer a buildable lisp
> > over a potentially faster version that creates even more build
> > problems.
Hopefully the table here is wrong:
http://www.sbcl.org/platform-table.html
It says the only supported platform for the most recently
released version of SBCL is Linux MIPS. The most
recent before that -- version 1.0.12 ? -- says the only supported
platforms are:
Linux x86, Linux x86_64, and Mac OS X x86,
and that is it! There is no version that has ever supported Microsoft Windows
according to that chart.
So unless the Sage developers want to start spending our time
porting sbcl, then SBCL is a non-option. This is because we're
not going to start messing with using SBCL on one architecture, another
SBCL version on another architecture, GCL on another,
and clisp on yet a third. The more I think about the mess
that is lisp compilers, the more I wish we didn't have any lisp
in Sage.
> Well, you can first build clisp and then sbcl using clisp. :)
The *show stopper* problem with sbcl isn't building it but that
it doesn't support nearly enough platforms, and that nobody
seriously involved in Sage wants to work on porting lisp
compilers (as far as I know -- maybe I'm wrong?).
-- William
William Stein
In the defense of GCL, *most* components of Sage were a mess
like above when I/you/whoever first tried to add them to Sage.
I personally haven't tried much using cvs GCL only, partly because
it scares me to use cvs for a deployed quality product. Since cvs
might be broken one day, not the next, etc., and one has no clue
if the code has been tested or not or what. The last released
version is from 2005, and it's clear the website is just dead (maybe
somebody lost the password?!) I mean, it just looks a little silly
for the website (http://www.gnu.org/software/gcl/) to start with:
NEW! (20050810) GCL 2.6.7 is released. The release notes can be found here.
NEW! (20050427) Patch added to the errata page to reenable support
for si::run-process on linux.
NEW! (20050402) Support for new texinfo format and precompiled
regexp searching posted to errata page.
The GCL-devel mailing list has on average about 5-6 messages a month
during the last couple of months, except for a bunch of messages in
January about people trying to build GCL from cvs.
I've made a gcl Sage optional spkg:
http://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg
It's just GCL-from-cvs + a simple spkg-install. I have never got it to build
on any system. It's a pretty big spkg, since it appears to include the
entire gas assembler, some version of GMP, etc. Try it out and see if
it *doesn't* work for you too :-)
wget http://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg
sage -i gcl-20080421.spkg
Bill Page -- I would be interested in any comments you might have.
For example, is the fact that GCL doesn't build for us anywhere, something
that you think we'll get passed by just trying harder? Or is it going
to be really really hard.
-- William
root
>that you think we'll get passed by just trying harder? Or is it going
>to be really really hard.
<http://axiom.axiom-developer.org/axiom-website/download.html>
All versions are built with GCL. I do not have access to a Sparc
although GCL has run there in the past. I no longer have access
to my Zaurus although GCL has run there in the past. I do have
access to an OLPC-XO. I release Axiom every two months so I'm
likely to get it working in the next release cycle.
GCL runs on windows although I have not spent any time on a
windows port. Waldek has, so he might have an opinion. Given
what I know about GCL internals I have every reason to believe
that it would compile using MS or Borland compilers (modulo a
few #ifdefs to pay homage to C). I don't have access to a native
C compiler for windows.
GCL is just a (big) C program and like every other C program I've
ever used, it is <sarcasm lang="C">easily ported</scarcasm>. But
the actual fact of the matter is that it does run everywhere I've
ever tried to make it run. All it requires is the right set of
./configure switches. My collection above includes, I86-32,
I86-64, and PowerPC.
> The GCL-devel mailing list has on average about 5-6 messages a month
> during the last couple of months, except for a bunch of messages in
> January about people trying to build GCL from cvs.
You claim that you pass problem reports upstream but I don't see many
Sage postings to the GCL mailing list. Camm, the GCL maintainer, has
always been very responsive and effective in his replies. But, like
you, he needs good, clear, effective bug reports.
I think you'd feel the same frustrations with Python if you compiled
Python from scratch for every platform. You ship "sources" but assume
that the python language exists and is compatible, which is not likely
to be the case when 3.0 arrives. If you can assume the python language,
why can't you assume the lisp language? If you can't assume the lisp
language, why can you assume the python language?
Having spent a fair portion of my life porting software, I understand
the frustrations you feel. And having spent the bulk of my life using
Lisp I "get" the get-rid-of-lisp pushback. But a lot of astonishingly
good computer algebra exists in lisp (we won't discuss the reasons).
Reproducing Axiom's "million-things-of-code" in Python would be no
small task, especially since some of the experts are dead.
Tim
David Harvey
On Apr 21, 2008, at 12:09 PM, root wrote:
> I think you'd feel the same frustrations with Python if you compiled
> Python from scratch for every platform. You ship "sources" but assume
> that the python language exists and is compatible, which is not likely
> to be the case when 3.0 arrives. If you can assume the python
> language,
> why can't you assume the lisp language? If you can't assume the lisp
> language, why can you assume the python language?
We do compile python from scratch on every platform. It's part of the
Sage distribution.
david
William Stein
>
> >For example, is the fact that GCL doesn't build for us anywhere, something
> >that you think we'll get passed by just trying harder? Or is it going
> >to be really really hard.
>
> <http://axiom.axiom-developer.org/axiom-website/download.html>
>
> All versions are built with GCL. I do not have access to a Sparc
> although GCL has run there in the past. I no longer have access
> to my Zaurus although GCL has run there in the past. I do have
> access to an OLPC-XO. I release Axiom every two months so I'm
> likely to get it working in the next release cycle.
>
> GCL runs on windows although I have not spent any time on a
> windows port. Waldek has, so he might have an opinion. Given
> what I know about GCL internals I have every reason to believe
> that it would compile using MS or Borland compilers (modulo a
> few #ifdefs to pay homage to C). I don't have access to a native
> C compiler for windows.
>
> GCL is just a (big) C program and like every other C program I've
> ever used, it is <sarcasm lang="C">easily ported</scarcasm>. But
> the actual fact of the matter is that it does run everywhere I've
> ever tried to make it run. All it requires is the right set of
> ./configure switches.
It also requires the right set of dependencies. And those themselves
can have all kinds of issues....
> My collection above includes, I86-32,
> I86-64, and PowerPC.
>
>
>
>
>
> > The GCL-devel mailing list has on average about 5-6 messages a month
> > during the last couple of months, except for a bunch of messages in
> > January about people trying to build GCL from cvs.
>
> You claim that you pass problem reports upstream but I don't see many
> Sage postings to the GCL mailing list. Camm, the GCL maintainer, has
> always been very responsive and effective in his replies. But, like
> you, he needs good, clear, effective bug reports.
We chose clisp instead of GCL long ago for a number of reasons, so
there's been no reason for me to post to the gcl mailing list.
> I think you'd feel the same frustrations with Python if you compiled
> Python from scratch for every platform. You ship "sources" but assume
> that the python language exists and is compatible, which is not likely
> to be the case when 3.0 arrives. If you can assume the python language,
> why can't you assume the lisp language? If you can't assume the lisp
> language, why can you assume the python language?
You don't know what you're talking about here. The python
build-from-source ecosystem is in much better shape than the lisp
one. Python has easily 100 times as many people supporting it
as clisp or gcl.
> Having spent a fair portion of my life porting software, I understand
> the frustrations you feel. And having spent the bulk of my life using
> Lisp I "get" the get-rid-of-lisp pushback. But a lot of astonishingly
> good computer algebra exists in lisp (we won't discuss the reasons).
> Reproducing Axiom's "million-things-of-code" in Python would be no
> small task, especially since some of the experts are dead.
In my opinion the best computer algebra system for research mathematics
on the planet is Magma, and it is written in C.
-- William
root
+1 for you, -1 for me.
t
Gabriel Dos Reis
> GCL runs on windows although I have not spent any time on a
> windows port. Waldek has, so he might have an opinion.
Well, *I* spend considerable time making Axiom buildable
on Windows back when I was working
on Axiom.build-improvements, which is the basis for both OpenAxiom
and Fricas. The build environment requirement
is the usual msys/mingw (which makes the life a bit more
bearable on that platform, when working with most software
based on GNU toolchains). You need on thing: you need
to make rsym.exe callable when dumping the final image to disk.
rsym.exe is built by GCL but for some reasons (mostly related to
pathnames I guess), GCL is unable to find it. See the hack
@axiom_gcl_rsym_hack@ I introduced here
http://axiom.svn.sourceforge.net/viewvc/axiom/branches/build-improvements/configure.ac.pamphlet?r1=393&r2=395
to be used in:
http://axiom.svn.sourceforge.net/viewvc/axiom/branches/build-improvements/src/lisp/Makefile.in?revision=395&view=markup
> Given
> what I know about GCL internals I have every reason to believe
> that it would compile using MS or Borland compilers (modulo a
> few #ifdefs to pay homage to C). I don't have access to a native
> C compiler for windows.
Please try it for real and tell us how is works, for GCL has a strong dependency
on GCC.
-- Gaby
Mike Hansen
;; Compiling ../lsp/gcl_listlib.lsp.
;; End of Pass 1.
;; End of Pass 2.
;; OPTIMIZE levels: Safety=3, Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling ../lsp/gcl_listlib.o.
;; Loading /opt/sage-3.0.alpha6/spkg/build/gcl-20080421/src/lsp/gcl_listlib.o
__stack_chk_fail is undefined
Error: ERROR "Cannot get relocated section contents
"
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by LOAD1.
ERROR "Cannot get relocated section contents
"
Broken at LOAD1. Type :H for Help.
>>make: *** [unixport/saved_pre_gcl] Error 255
Error building GCL.
--Mike
mabshoff
> > during the last couple of months, except for a bunch of messages in
> > January about people trying to build GCL from cvs.
>
> You claim that you pass problem reports upstream but I don't see many
> Sage postings to the GCL mailing list. Camm, the GCL maintainer, has
> always been very responsive and effective in his replies. But, like
> you, he needs good, clear, effective bug reports.
are required to get anything fixed.
But I get paid to do a job:
* port Sage to Solaris
* support Sage on Linux/Itanium
* port Sage to Windows
While I am at it I do a number of other Sage related jobs:
* play a release manager
* hunt down memory leaks in general
* port Sage to FreeBSD
* port Sage to Linux/Sparc
* port Sage to Linux/PPC64
When I am done with the above [i.e. in the "evening" ;)] I would
really, really like to do:
* audit Singular for memory leaks with its test suite and fix those
bugs ;)
* get deeply into PolyBoRi and help dealing with their memory
management issues
* compile gcc 4.4CVS [or whatever is next] and make Sage build with
it. After fixing all the bugs push them upstream [I did many of those
with gcc 4.3 about six months ago, but only finished pushing the fixes
in 3.0]
The above three tasks are something that gives me credit with my peers
and would certainly benefit me and my reputation in the CAS community
[at least with many algebra people ;)].
Now let's contrast this with gcl:
* gcl is a mature project, i.e. it should just work out of the box
most of the time
* It *should* build on the vast majority of platforms that it claims
it supports. Reality: there are many, many problems - and that is with
me not being an ass and deliberately doing something stupid on
purpose
Looking at the above lists you will hopefully understand that I have
no interest in working on gcl since doing efficient bug reporting
would require that I get familiar with the code. I would likely get
into it since I could fix many of those bugs myself. But since I have
no interest in lisp and would like to spend my time on projects where
I would I personally know the people and share common goals with I
will not do that.
To put it nicely: gcl is "stagnating". The last release was in 2005
[not 5 years ago like I mistakenly claimed]. If the lisp community
would be a large thriving community *I* wouldn't have to do anything
about that issue, but you would likely have had some release since
2005 and many of the problems I saw would have already been solved,
i.e. it would "just work". Am I wrong to assume that the gcl community
does not have access to a reasonably large number of non-Linux boxen?
I spend a huge amount of time on any exotic and not so exotic build
problem with Sage, hence I expect other projects to do the same thing.
If that is not the case I will not use their code and due to the
insane number of issues with clisp, gcl and so on I have drawn the
conclusion that Sage without a lisp dependency in its core [i.e. code
I am getting paid to support] would be a better Sage. That doesn't
mean that Sage will not be very accommodating to say Maxima, Axiom,
FriCAS and OpenAxiom via an optional lisp package, but as long as they
depend on lisp [forever would be my guess here] I do not see a chance
for them to stay in the core or become part of the core long term.
Prove me wrong: Get gcl to build out of the box on various Linuxes
[with gcc], Solaris 9, 10 with Sun Forte, OSX 10.4, 10.5 with XCode
[no stupid MacPorts here] and Windows with MSVC and I will be the
first guy to help you out. I see ecls potentially in that role, but as
long as it isn't supported in Maxima I see no urgent reason to spend
any work on that.
But I have dealt with the ecls maintainer, both by reporting problems
and submitting patchlets, so I know he is up to the job. He for
example already uses MSVC on Windows to build ecls, so he is far ahead
of any other Open Source lisp AFAIK. That gives me hope since his
goals and understanding of the importance to support non-gcc compilers
are very much aligned to my personal opinions.
> I think you'd feel the same frustrations with Python if you compiled
> Python from scratch for every platform. You ship "sources" but assume
> that the python language exists and is compatible, which is not likely
> to be the case when 3.0 arrives. If you can assume the python language,
> why can't you assume the lisp language? If you can't assume the lisp
> language, why can you assume the python language?
Once Python 2.6 comes out [in parallel with Python 3K] we will migrate
first to 2.6 and then likely to 3.0 at some point. But since we build
Python we control our own destiny here.
> Having spent a fair portion of my life porting software, I understand
> the frustrations you feel. And having spent the bulk of my life using
> Lisp I "get" the get-rid-of-lisp pushback. But a lot of astonishingly
> good computer algebra exists in lisp (we won't discuss the reasons).
> Reproducing Axiom's "million-things-of-code" in Python would be no
> small task, especially since some of the experts are dead.
in Sage, so it isn't that Sage without Axiom isn't viable [not that
you implied that]. If a sufficient number of people want Lisp to
remain a significant player in the CAS world [and computer science in
general] it will be so. We are not forcing you to use Python or Sage.
This is all about what tool gets the job done for you and in your case
it is Axiom ;)
> Tim
Cheers,
Michael
root
>> the frustrations you feel. And having spent the bulk of my life using
>> Lisp I "get" the get-rid-of-lisp pushback. But a lot of astonishingly
>> good computer algebra exists in lisp (we won't discuss the reasons).
>> Reproducing Axiom's "million-things-of-code" in Python would be no
>> small task, especially since some of the experts are dead.
>
>Well, many things are available in non-lisp CASes and many of them are
>in Sage, so it isn't that Sage without Axiom isn't viable [not that
>you implied that]. If a sufficient number of people want Lisp to
>remain a significant player in the CAS world [and computer science in
>general] it will be so. We are not forcing you to use Python or Sage.
>This is all about what tool gets the job done for you and in your case
>it is Axiom ;)
Well, Sage doesn't actually use Axiom. William has no long term focus
except to compete with the 4Ms. Sage doesn't use GCL. And the project
is strongly motivated to elide lisp. Except for my involvement in the
Sage program committee for the Nancy conference, I don't see that I
can be of much help. Sorry for the noise.
Tim
Robert Dodier
> I forgot one important argument here: With ecls you can embed the lisp
> interpreter into an external library, hence we would be able to use
> Maxima as a library instead of using the inefficient pexpect
> interface. I am not sure how much work this would be, but if I were a
> Maxima coder I would certainly look into that possibility since it
> opens a whole lot of possibilities for Maxima IMHO - totally
> independent of Maxima's role in Sage.
to start with), the more difficult problem is that Maxima is written
with a pervasive assumption that there is someone at the console,
e.g you ask for an integral or a limit and Maxima comes back with
a question about some parameter. That make interaction with
another program very difficult (as I think you know already).
I have attempted to resolve this by converting questions into
conditional expressions e.g. "Is x positive, negative, or zero?"
=> if x > 0 then ... elseif x < 0 then ... else ....
It sort of works but there are difficulties. If anyone wants to
work on it with me, I'd be glad to have the help.
Robert Dodier
Maxima developer
mabshoff
On Apr 21, 11:48 pm, Robert Dodier <robert.dod...@gmail.com> wrote:
> On Apr 20, 5:55 pm, mabshoff <Michael.Absh...@mathematik.uni-
> dortmund.de> wrote:
> > I forgot one important argument here: With ecls you can embed the lisp
> > interpreter into an external library, hence we would be able to use
> > Maxima as a library instead of using the inefficient pexpect
> > interface. I am not sure how much work this would be, but if I were a
> > Maxima coder I would certainly look into that possibility since it
> > opens a whole lot of possibilities for Maxima IMHO - totally
> > independent of Maxima's role in Sage.
>
> Aside from just getting stuff linked together (plenty of trouble
> to start with),
> the more difficult problem is that Maxima is written
> with a pervasive assumption that there is someone at the console,
> e.g you ask for an integral or a limit and Maxima comes back with
> a question about some parameter. That make interaction with
> another program very difficult (as I think you know already).
but others certainly have.
> I have attempted to resolve this by converting questions into
> conditional expressions e.g. "Is x positive, negative, or zero?"
> => if x > 0 then ... elseif x < 0 then ... else ....
> It sort of works but there are difficulties. If anyone wants to
> work on it with me, I'd be glad to have the help.
myself opening up soon to work on this end of the problem. But I read
your message on fricas-devel about ecls support for Maxima and I am
certainly willing to help make that happen and test ecls build and
building Maxima on top of ecls on a wide range of platforms. I am also
willing to work on ecls itself and fix potential portability issues.
On top of that once ecls+Maxima "works" I will also likely lead the
push to get that combo merged into Sage. There are some other issues
you mention in your email to fricas-devel, but I will answer them over
there.
> Robert Dodier
> Maxima developer
Cheers,
Michael
mabshoff
over there, too. Since his wish is my command ;) here we go:
On Apr 21, 9:46 pm, Robert Dodier <robert.dod...@gmail.com> wrote:
> On Apr 20, 9:29 am, "William Stein" <wst...@gmail.com> wrote:
Hello folks,
> > c) ecls: the ray of hope? Bug Maxima can't be build on top of it due
> > to same issues with save and load image.
> Well, if there is any interest in resolving the problems,
> let's join forces then. I got Maxima compiled by ECLS some
> months ago; there were some problems but if there is enough
> interest, I would be willing to try again.
This is excellent news. As I wrote in this thread over on sage-devel I
am willing to put some serious time into getting ecls to build on
Sage's current and future supported platforms as well do serious
testing that Maxima works on top of it. And it certainly sounds like
FriCAS would not mind ecls being in Sage per default instead of clisp
since the clisp we shop seems to be too broken to support FriCAS.
> > The current plan is to rewrite symbolic manipulation in
> > Cython using lots of tricks so it will be very
> > fast, flexible, and not depend on Maxima at all.
> I have an agenda to push here, so you can take this with a grain
> of salt, but: Lisp was invented in part to do the kind of
> expression mogrification which is needed for symbolic
> algebra. A symbolic system written in some other language is
> probably going to replicate a lot of Lisp functionality.
> I am pretty sure that trying to get Maxima recompiled with
> some/any Lisp implementation will be easier than reinventing
> both Maxima and Lisp.
Well, we are looking at several problems here:
a) we use Maxima via pexpect, i.e. we dump some data into ASCII issue
some commands and parse the results. While that is something that
works well for say integrals or ODEs it is a huge performance drain on
arithmetic. For example: Moving some operation on permutation groups
form GAP+pexpect to Cython made the operation 4,000 times as fast. The
implementation in Cython is roughly 3 times slower than the same
operation in the GAP kernel, but since pexpect is out of the equation
the somewhat slower Cython implementation is a huge win since we have
not connected the GAP kernel to Sage as a library. Nobody has
attempted to do that, but it will likely be quite a bit of work and a
large effort.
b) Using Maxima in itself is not bad and the thread that started this
whole discussion was motivated by build issues with self hosted lisp.
Since Maxima is written in lisp and the only reason we ship lisp
currently with Sage my desire was to solve the lisp build problem and
Maxima would have ended up as potential road kill in the process.
c) Maxima has a lot of well debugged, well working code, but it seems
for many things the 4 Ms are much faster. Factorization is one
example, I am not quite clear how Integration compares, but my general
impression from alt.sci.symbolic is that it is not on par with the
commercial systems [feel free to correct me].
d) Sage itself wants to compete with the 4Ms, but it isn't the only
Open Source CAS out there, in fact it is a quite young effort and
William's method called for building on top of existing systems. But
while he went through what I call the "rapid expansion phase" it was
more important to get things working than to implement because doing
things "right" as you point out would take many, many man years of
effort. But now people are demanding more performance and due to (a)
symbolic arithmetic is being rewritten. And according to Gary [the guy
implementing it] it is much faster than Maxima [even accounting for
clisp vs. sbcl and so on]. I cannot verify the number but since he is
quite serious about the issue and he really, really *needs* fast
symbolics I have little reason to doubt him.
So, now the question is: "Why doesn't he work with the Maxima code
then and improve it there. Everybody would benefit [Sage & Maxima] and
all the higher level algorithms would likely get a boost by it." And
the answer is: Because he prefers not to use lisp and that is
something that is completely up to him. It is difficult to recruit
developers and most people in Sage prefer C/C++/Python/Cython over
list just like Maxima developers prefer lisp. Both camps are self
selecting, so no surprises there.
But to get back to the issue at hand: Once Maxima runs on ecls nearly
all the issues I have with the build side of things will likely
evaporate and I will put my energy toward other issues. It would
likely also lessen the drive to "get rid of Maxima" considerably, but
I am certain that over the next couple years more and more
functionality that Maxima provides by Sage will be implemented on top
of other systems unless Maxima gets faster. Systems inside Sage
compete and it would be naive to believe that Sage does not compete
will all its components for users as well as developers. But in the
end Sage is supposed to be inclusive and should function as a unifying
force of the Open Source CAS world that wants to join efforts with us.
We should not be fighting among ourselves for the table scraps of the
4Ms, but go on and be able to compete with them on features *and*
performance. I am actually convinced that the mathematical Open Source
community can come up with something better than the 4Ms since an Open
Source development model can and has created software superior to
anything commercial out there.
> All the best,
David Joyner
Way down the road, thin will be a big deal i think.
Bill Page
> ...
> In the defense of GCL, *most* components of Sage were a mess
> like above when I/you/whoever first tried to add them to Sage.
> I personally haven't tried much using cvs GCL only, partly because
> it scares me to use cvs for a deployed quality product. Since cvs
> might be broken one day, not the next, etc., and one has no clue
> if the code has been tested or not or what. The last released
> version is from 2005, and it's clear the website is just dead (maybe
> somebody lost the password?!) I mean, it just looks a little silly
> for the website (http://www.gnu.org/software/gcl/) to start with:
> NEW! (20050810) GCL 2.6.7 is released. The release notes can
> be found here.
> The GCL-devel mailing list has on average about 5-6 messages
> a month during the last couple of months, except for a bunch of
> messages in January about people trying to build GCL from cvs.
>
No doubt about it - GCL does not have sufficient resources for
maintenance and has been somewhat neglected of late. As you say: It is
not a situation that you find entirely uncommon among the packages
that have been added to Sage in the past. Necessity is what drives
most of this kind of work.
> I've made a gcl Sage optional spkg:
>
> http://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg
>
> It's just GCL-from-cvs + a simple spkg-install. I have never got it to
> build on any system. It's a pretty big spkg, since it appears to
> include the entire gas assembler, some version of GMP, etc. Try
> it out and see if it *doesn't* work for you too :-)
>
> wget http://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg
> sage -i gcl-20080421.spkg
>
Thanks. It doesn't work for me either. :-(
You are right that the source is bloated by a bunch of code that it
does not use. As I understand it gcl needs only a small part of
binutils - depending on the build options for a particular system.
Is this source from cvs head at:
http://savannah.gnu.org/projects/gcl/
as of today?
This version of GCL fails on my Solaris x86 system with the following
obscure error message:
gcc -c -fsigned-char -pipe -Wall -O3 -fomit-frame-pointer -I/export/home0/wspa
ge/gcl-sage/gcl-20080421/src/o -I../h -I../gcl-tk cmpaux.c
cmpaux.c: In function `object_to_fcomplex':
cmpaux.c:329: error: `_Imaginary_I' undeclared (first use in this function)
cmpaux.c:329: error: (Each undeclared identifier is reported only once
cmpaux.c:329: error: for each function it appears in.)
cmpaux.c: In function `object_to_dcomplex':
cmpaux.c:366: error: `_Imaginary_I' undeclared (first use in this function)
gmake[1]: *** [cmpaux.o] Error 1
rm list.c
gmake[1]: Leaving directory `/export/home0/wspage/gcl-sage/gcl-20080421/src/o'
gmake: *** [unixport/saved_pre_gcl] Error 2
-------
At 'http://cvs.savannah.gnu.org/viewvc/gcl/?root=gcl' I see changes as
recent as 3 months ago. The last time I built GCL from head was about
10 months ago.
The most recent branch 'Version_2_6_8pre' is what we normally use to
build Axiom. There is a change about 4 months old. If I recall
correctly 'Version_2_6_8pre' actually corresponds to the version
distributed on Debian and would probably be the most likely to be
stable on the largest number of platforms.
> Bill Page -- I would be interested in any comments you might have.
> For example, is the fact that GCL doesn't build for us anywhere,
> something that you think we'll get passed by just trying harder?
> Or is it going to be really really hard.
>
The fact that it doesn't build for you anywhere is definitely strange.
I would give it a try again with
$ cvs -z3 -d:pserver:anon...@cvs.savannah.gnu.org:/sources/gcl co
-r Version_2_6_8pre gcl
I do expect that (with the right help) you will be able to build gcl
everywhere that you build Sage. Instead of just trying harder I think
it is very appropriate to ask for help. Only if there is no help
forthcoming, perhaps I would agree that the problems might be of a
kind that you will not be able to get passed just by "trying harder".
I expect that like me, you would find the learning curve for the GCL
source code very high.
------
Now since you asked, maybe I should take a deep breath and try to
explain my personal views on this subject...
I am in fact fully sympathetic with the expressed desire to eliminate
Lisp from Sage. As you may know, I am also in favor of eliminating
Lisp from Axiom! I believe that was the direction in which Axiom was
headed when it was last sold as commercial software and would have
very much preferred it if that development had continued. The Aldor
compiler (written in C) was positioned to replace the exising library
compiler for Axiom. Aldor could be targeted to produce either Lisp or
object code linked into a C run-time environment based on an abstract
machine specification (FOAM). Also the version of Lisp underlying the
commercial version of Axiom (CCL) was heavily modified and optimized
as the preferred run time environment, i.e. moving away from being a
general purpose lisp system. In fact Axiom uses only a very small part
of the normal Lisp environment.
William, you have said that you started Sage because when you looked
three years ago you could find no alternative to the commercial
systems. I think that perhaps the timing of your interest was quite
unfortunate. All license issues for proprietary software components
aside, maybe if you had known that only a year or two earlier NAG
(Mike Dewar) was looking for someone who wanted to take Axiom open
source, and if you had had some previous experience with the
commercial version of Axiom previously sold by NAG instead of Magma,
then you might have chosen Axiom as a basis for Sage instead of
Python. From my point of view both the original Axiom library compiler
(SPAD) and the Aldor language resemble Python in more than just the
indented code layout. The last commercial version of Axiom even had a
web-based "notebook" style interface not so different from the Sage
notebook today. So who knows where we might be today...
Unfortunately the open source agreement with NAG took the Axiom system
back to it's situation in the late 1980's as primarily a Lisp-based
system. NAG would not (or could not) release the Aldor and web
interface components at the same time as part of the Axiom open source
release. But NAG (through the kind assistance of Arthur Norman of
Codemist Ltd.) did provide an open source version of the optimized CCL
run-time system. However the initial open source re-release of Axiom
was not based on that version of Lisp but rather on an earlier version
of Lisp AKCL that had been previously used with Axiom/ScratchPad
during the IBM days. (In a parallel development AKCL had become open
sourced as the GCL project.)
Lisp remains a focus of the original Axiom project, but both forks of
the Axiom project (FriCAS and OpenAxiom) have been considering the
possibility of developing an optimized formally specified run-time
environment based on something much less than full Lisp. And most
recently Aldor was finally made available as at least (semi-)open
source software.
-----------
Anyway, none of this solves the immediate problem of providing support
for symbolic mathematics in Sage without adding the burden of
supporting Lisp in all target environments. Right now you depend on
the linkage with Maxima for this feature, And I think you see symbolic
manipulation as a particular domain or mode of computation within Sage
rather than the reason d'etre of computer algebra systems.
I would like to argue however that from an overall design perspective
Axiom is a better match for Sage than Maxima. Like Sage itself, the
Axiom library is built-up in a (more or less) rigorous manner from
more fundamental mathematical constructions. One of these complex
constructions is called 'Expression'. This is the domain in which most
symbolic calculations are done in Axiom. However as it will be in
Sage, it is necessary that Expression interact in a well-defined
manner with other Axiom domains of computation. I believe that if you
were to re-implement the Maxima symbolic functionality within Sage
(Python) then you would essentially be implementing something rather
similar to the Expression domain in Axiom.
In the longer term (pending resolution of the remaining open source
license issues), Aldor could provide much of the same set of
functionality of Axiom through it's BasicMath and other libraries
without the overhead of the Axiom interpreter interface. This would
completely eliminate the need for Lisp. I still have some hope that
this could happen in the near future. If Sage were to pursue this
path, I think the Aldor license issues might be resolved more quickly.
Regards,
Bill Page.
mabshoff
> On Mon, Apr 21, 2008 at 9:03 AM, William Stein wrote:
> > ...
> > In the defense of GCL, *most* components of Sage were a mess
imagine. But then I wasn't around in the early days of Sage ;)
>
> Thanks. It doesn't work for me either. :-(
>
> You are right that the source is bloated by a bunch of code that it
> does not use. As I understand it gcl needs only a small part of
> binutils - depending on the build options for a particular system.
>
> Is this source from cvs head at:
>
> http://savannah.gnu.org/projects/gcl/
>
> as of today?
> This version of GCL fails on my Solaris x86 system with the following
> obscure error message:
>
> gcc -c -fsigned-char -pipe -Wall -O3 -fomit-frame-pointer -I/export/home0/wspa
> ge/gcl-sage/gcl-20080421/src/o -I../h -I../gcl-tk cmpaux.c
> cmpaux.c: In function `object_to_fcomplex':
> cmpaux.c:329: error: `_Imaginary_I' undeclared (first use in this function)
> cmpaux.c:329: error: (Each undeclared identifier is reported only once
> cmpaux.c:329: error: for each function it appears in.)
> cmpaux.c: In function `object_to_dcomplex':
> cmpaux.c:366: error: `_Imaginary_I' undeclared (first use in this function)
> gmake[1]: *** [cmpaux.o] Error 1
> rm list.c
> gmake[1]: Leaving directory `/export/home0/wspage/gcl-sage/gcl-20080421/src/o'
> gmake: *** [unixport/saved_pre_gcl] Error 2
part of the Sun's libc or libm - I would need to check.
> -------
>
> At 'http://cvs.savannah.gnu.org/viewvc/gcl/?root=gcl'I see changes as
> recent as 3 months ago. The last time I built GCL from head was about
> 10 months ago.
times with disastrous results.
> The most recent branch 'Version_2_6_8pre' is what we normally use to
> build Axiom. There is a change about 4 months old. If I recall
> correctly 'Version_2_6_8pre' actually corresponds to the version
> distributed on Debian and would probably be the most likely to be
> stable on the largest number of platforms.
last tarball from the website predates OSX 10.5 and also Solaris 10,
so maybe it is time to cut another bug fix release since everybody
seems to be using 2.6.8CVS anyway. But when I build stable releases I
do not poke around in the CVS repo. Asking could have helped, but if
nobody bothered to update the website in three years anyway what is
the point? 2.6.7 actually also miserably fails on Solaris 9 for me,
and that has been out for a while before 2.6.7.
> > Bill Page -- I would be interested in any comments you might have.
> > For example, is the fact that GCL doesn't build for us anywhere,
> > something that you think we'll get passed by just trying harder?
> > Or is it going to be really really hard.
>
> The fact that it doesn't build for you anywhere is definitely strange.
> I would give it a try again with
>
>
> I do expect that (with the right help) you will be able to build gcl
> everywhere that you build Sage. Instead of just trying harder I think
> it is very appropriate to ask for help. Only if there is no help
> forthcoming, perhaps I would agree that the problems might be of a
> kind that you will not be able to get passed just by "trying harder".
> I expect that like me, you would find the learning curve for the GCL
> source code very high.
ecls soon the decision has been made on our end to switch to Maxima
+ecls. There is no point in beating the dead horse that is gcl. ecls
has MSVC support *today* and is probably trivially to port to Sun
Forte if it doesn't run already. The mailing list is alive and well. I
have looked at the code and fixed some issues myself, so why would I
want to touch gcl?
who weren't around back then ;)
We have discussed the issue here before and everybody agrees that it
is GPL incompatible. But I have little hope that Sage's potential
interest in Aldor would get somebody to change the license. A "non-
commercial only" Open Source license is often the kiss of death to a
project. Abandoned by its commercial parent company, but not free in
reality it is neither here nor there. Either you make the code free
[your choice: GPL, LGPL, MIT, BSD] or you don't. It is either Open
Source code or it isn't, just like you can't be a little big
pregnant :)
Alfredo Portes
<Michael...@mathematik.uni-dortmund.de>
> Well, I think NAG chose the "non-commercial only" license on purpose.
> We have discussed the issue here before and everybody agrees that it
> is GPL incompatible. But I have little hope that Sage's potential
> interest in Aldor would get somebody to change the license. A "non-
> commercial only" Open Source license is often the kiss of death to a
> project. Abandoned by its commercial parent company, but not free in
> reality it is neither here nor there. Either you make the code free
> [your choice: GPL, LGPL, MIT, BSD] or you don't. It is either Open
> Source code or it isn't, just like you can't be a little big
> pregnant :)
Yes, just like QT...oh wait. A petition to really open source Aldor won't hurt
I think. What is the worst that can happen? Yes, I know the answer "go and
start one" :-(
My not needed 2 cents,
Alfredo
mabshoff
On Apr 22, 9:15 am, "Alfredo Portes" <doyenatc...@gmail.com> wrote:
> On Tue, Apr 22, 2008 at 1:41 AM, mabshoff
Hi,
> > Well, I think NAG chose the "non-commercial only" license on purpose.
> > We have discussed the issue here before and everybody agrees that it
> > is GPL incompatible. But I have little hope that Sage's potential
> > interest in Aldor would get somebody to change the license. A "non-
> > commercial only" Open Source license is often the kiss of death to a
> > project. Abandoned by its commercial parent company, but not free in
> > reality it is neither here nor there. Either you make the code free
> > [your choice: GPL, LGPL, MIT, BSD] or you don't. It is either Open
> > Source code or it isn't, just like you can't be a little big
> > pregnant :)
>
> Yes, just like QT...oh wait.
Open Source way back. Axiom was released under BSD, so why the
different treatment for Aldor?
> A petition to really open source Aldor won't hurt
> I think. What is the worst that can happen? Yes, I know the answer "go and
> start one" :-(
source? Is there any kind of estimate of user numbers? How far along
is FriCAS and/or OpenAxiom from using "pure" Aldor and no lisp? Are
there any benchmarks to compare those two?
> My not needed 2 cents,
>
> Alfredo
Michael
Alfredo Portes
<Michael...@mathematik.uni-dortmund.de> wrote:
> Well, I don't think the situation is comparable. TrollTech understood
> Open Source way back. Axiom was released under BSD, so why the
> different treatment for Aldor?
Sorry if it sounded like a troll. Tim and others can explain why this happen
I can't :(. But my example of TrollTech, is because I feel they felt an urgency
from the community for this to happen. I guess what I am saying is not to
give up so easily if Aldor can benefit Sage...that's it. I think that
is what Bill
was trying to explain in his post.
Gabriel Dos Reis
> The most recent branch 'Version_2_6_8pre' is what we normally use to
> build Axiom. There is a change about 4 months old. If I recall
> correctly 'Version_2_6_8pre' actually corresponds to the version
> distributed on Debian and would probably be the most likely to be
> stable on the largest number of platforms.
It is but, it does not build everywhere. I failed to build it on stock
openSUSE-10.3/x86_64, Fedora 8/x86_64, Macintel OS Lepoard.
(it builds fine on the 32-bit machines though).
-- Gaby
Gabriel Dos Reis
> > On Tue, Apr 22, 2008 at 1:41 AM, mabshoff
>
> > <Michael.Absh...@mathematik.uni-dortmund.de>
>
> Hi,
>
>
> > > Well, I think NAG chose the "non-commercial only" license on purpose.
> > > We have discussed the issue here before and everybody agrees that it
> > > is GPL incompatible. But I have little hope that Sage's potential
> > > interest in Aldor would get somebody to change the license. A "non-
> > > commercial only" Open Source license is often the kiss of death to a
> > > project. Abandoned by its commercial parent company, but not free in
> > > reality it is neither here nor there. Either you make the code free
> > > [your choice: GPL, LGPL, MIT, BSD] or you don't. It is either Open
> > > Source code or it isn't, just like you can't be a little big
> > > pregnant :)
> >
> > Yes, just like QT...oh wait.
>
> Well, I don't think the situation is comparable. TrollTech understood
> Open Source way back. Axiom was released under BSD, so why the
> different treatment for Aldor?
From the little I know, the situation -- as it has been carefully explained
to me -- is far more complicated, and I'm not sure it is one that can be
resolved by emails. All I can say is that there really are good guys at
NAG who would not like to see Axiom die (as it was) and they did the best
to make it open source under a very liberal license (no poison). The
surrounding environment and conditions for releasing Aldor had changed from
what they were back when Axiom was released. I would recommend
you talk to Mike Dewar, Stephen Watt, Barry Trager (among others) about
the situation. However, I doubt it can be resolved by public emails -- and if
it is resolved by public emails, then that is fantastic!.
>
>
> > A petition to really open source Aldor won't hurt
> > I think. What is the worst that can happen? Yes, I know the answer "go and
> > start one" :-(
>
> Out of curiosity: Are there download statistics of Aldor binaries and
> source? Is there any kind of estimate of user numbers? How far along
> is FriCAS and/or OpenAxiom from using "pure" Aldor and no lisp? Are
> there any benchmarks to compare those two?
Because of licensing issues -- OpenAxiom is released under BSD license --
and dependency problems, I cannot make OpenAxiom purely depending
on Aldor. Whoever, it should be possible to call Aldor libraries from OpenAxiom
and vice versa (and if that does not work, it is likely a bug in OpenAxiom).
As I have stated many times, and part of the reasons for OpenAxiom, I
would like to
get away from Lisp as soon as possible: This isn't negociable.
From my perspective, it is NOT a scalable technology for writing large
scale systems
given the zoo of users, developers, and development environments we have today.
I know Lisp enthusiasts think the opposite and are likely to say "you
don't get it".
At the moment, I don't have formal benchmark to assess OpenAxiom,
except the tiny
regression testsuite. I must also confess that most of my work wo far
has concentrated
on getting rid of as mush Lisps as can and fixing the compiler and
interpreter. The
design of the Algebraic Virtual Machine for OpenAxiom is still progressing.
-- Gaby
William Stein
I can imagine. Is the conclusion to draw from the above that you think
it unlikely Aldor will be released under a standard open source license
in the near future, but that you very much wish it would be?
>
>
> >
> >
> > > A petition to really open source Aldor won't hurt
> > > I think. What is the worst that can happen? Yes, I know the answer "go and
> > > start one" :-(
> >
> > Out of curiosity: Are there download statistics of Aldor binaries and
> > source? Is there any kind of estimate of user numbers? How far along
> > is FriCAS and/or OpenAxiom from using "pure" Aldor and no lisp? Are
> > there any benchmarks to compare those two?
>
> Because of licensing issues -- OpenAxiom is released under BSD license --
> and dependency problems, I cannot make OpenAxiom purely depending
> on Aldor. Whoever, it should be possible to call Aldor libraries from OpenAxiom
> and vice versa (and if that does not work, it is likely a bug in OpenAxiom).
You didn't answer the questions about downloads/users/etc. Should we
write to NAG to ask?
>
> As I have stated many times, and part of the reasons for OpenAxiom, I
> would like to
> get away from Lisp as soon as possible: This isn't negociable.
For people in Sage-devel who don't know, OpenAxiom has the following
goal (from their website): "OpenAxiom strives to support ubiquitous,
advanced, high quality open source computer algebra on major operating
systems, in particular major Unix variants, GNU/Linux variants,
Windows, and handheld devices. It aims at being the open source
computer algebra system of choice for research, teaching, engineering,
etc."
Thus their goals overlap a lot with Sage, and they do care a great deal about
portability to different platforms. Gaby -- since our goals are so similar
I hope there are ways we can work together.
> From my perspective, it is NOT a scalable technology for writing large
> scale systems
> given the zoo of users, developers, and development environments we have today.
> I know Lisp enthusiasts think the opposite and are likely to say "you
> don't get it".
Well I agree completely with you.
> At the moment, I don't have formal benchmark to assess OpenAxiom,
> except the tiny
> regression testsuite. I must also confess that most of my work wo far
> has concentrated
> on getting rid of as mush Lisps as can and fixing the compiler and
> interpreter. The
> design of the Algebraic Virtual Machine for OpenAxiom is still progressing.
How are you getting rid of as much Lisp as you can in OpenAxiom? Does
this involve porting Lisp code to Aldor, or ?
Also, what is the Alebraic Virtual Machine?
I think these are all good questions to discuss on #sage-devel, since
Sage is about unifying all mathematical software systems, so it is
very good to be aware of what ideas you have in the pipeline for
OpenAxiom.
-- William
Bill Page
Wow, it sure it nice to have someone on the "other end of the phone",
so as to speak ... :-) I think it is really great that Google came
through with financial support that is making it possible for you and
others to dedicate so much time to this.
On Tue, Apr 22, 2008 at 2:41 AM, mabshoff wrote:
>
> On Apr 22, 7:36 am, "Bill Page" wrote:
> ...
> > The most recent branch 'Version_2_6_8pre' is what we normally
> > use to build Axiom. There is a change about 4 months old. If I
> > recall correctly 'Version_2_6_8pre' actually corresponds to the
> > version distributed on Debian and would probably be the most
> > likely to be stable on the largest number of platforms.
>
> At least testing ships CVS head.
Are you sure? I suppose that we had better check with Camm.
> And not to be too picky here: The last tarball from the website
> predates OSX 10.5 and also Solaris 10, so maybe it is time to
> cut another bug fix release since everybody seems to be using
> 2.6.8CVS anyway.
Yes, 2.6.8pre (as in pre-release). 2.6.8 was never "officially" released.
> But when I build stable releases I do not poke around in the CVS
> repo. Asking could have helped, but if nobody bothered to update
> the website in three years anyway what is the point? 2.6.7 actually
> also miserably fails on Solaris 9 for me, and that has been out for
> a while before 2.6.7.
>
This is open source age and GCL existed well before that. I am not
making excuses but ...
> ...
> Well, since the Maxima folks now have told us that they will
> support ecls soon the decision has been made on our end to
> switch to Maxima +ecls.
Choose your own poison. ;-) Actually I don't know much about ecl but I
seriously doubt the long term viability of ecl will be any different
than the half dozen other alternatives. Of course I am all for
co-operation between projects so if Maxima is willing to make a
version that is more suitable for use in Sage, the more power (money
and resources ...) to them! :-)
> There is no point in beating the dead horse that is gcl.
I take offense. gcl is not a dead horse no matter how neglected it
might look to you.
> ecls has MSVC support *today* and is probably trivially to port to
> Sun Forte if it doesn't run already. The mailing list is alive and well.
> I have looked at the code and fixed some issues myself, so why
> would I want to touch gcl?
>
I don't know. The OpenAxiom and FriCAS forks of Axiom work on ecl so I
am also not too worried about gcl in the long run.
Well yes, of course it was on purpose. They have stated that they felt
obligated to do this by the terms under which they originally received
Axiom (and Aldor) from IBM. NAG itself is a non-commerical
organization.
> We have discussed the issue here before and everybody agrees
> that it is GPL incompatible.
Yes, that is the said truth. Some people at NAG apparently also have a
philosophical disagreement with the Free Software Foundation about the
reasonableness of GPL but I am still optimistic that this can be
overcome. Afterall, you can only shoot yourself in the foot so many
times ... ;-)
> But I have little hope that Sage's potential interest in Aldor
> would get somebody to change the license.
I think you greatly under estimate the power and momentum that Sage
has now and how it is about to grow in the next year. (Too bad no one
is issuing "shares".)
I should also admit that most of my rant in the previous email was in
fact a prelude to asking William to try to intervene with NAG on our
behalf precisely become of this new found influence.
> A "non-commercial only" Open Source license is often the kiss
> of death to a project. Abandoned by its commercial parent
> company, but not free in reality it is neither here nor there. Either
> you make the code free [your choice: GPL, LGPL, MIT, BSD]
> or you don't. It is either Open Source code or it isn't, just like
> you can't be a little big pregnant :)
>
Apparently the Free Software Foundation does not agree:
http://www.gnu.org/philosophy/categories.html#semi-freeSoftware
But I agree in principle with your point of view.
Regards,
Bill Page.
Gabriel Dos Reis
Stephen Watt has indicated, at many times, that he is very willing to clarify
the Aldor license terms -- I believe he intends to write a sort of FAQ
that would shed light on the issue. I can imagine that the voice of a
big player
(Sage) is not the same as that of a small group (Axiom community at
the time); so it might be that Sage could be more persuasive; but I suspect
it would take lot of face-to-face conversions. At ISSAC'08, you'd very likely
to meet people would shaped the development and release of Axiom and Aldor.
However, unless there is a new player with new material in the
discussion, I would
not expect the situation to change.
> >
> >
> > >
> > >
> > > > A petition to really open source Aldor won't hurt
> > > > I think. What is the worst that can happen? Yes, I know the answer "go and
> > > > start one" :-(
> > >
> > > Out of curiosity: Are there download statistics of Aldor binaries and
> > > source? Is there any kind of estimate of user numbers? How far along
> > > is FriCAS and/or OpenAxiom from using "pure" Aldor and no lisp? Are
> > > there any benchmarks to compare those two?
> >
> > Because of licensing issues -- OpenAxiom is released under BSD license --
> > and dependency problems, I cannot make OpenAxiom purely depending
> > on Aldor. Whoever, it should be possible to call Aldor libraries from OpenAxiom
> > and vice versa (and if that does not work, it is likely a bug in OpenAxiom).
>
> You didn't answer the questions about downloads/users/etc.
Sorry about that -- I did not have enough coffee :-)
Download: The numbers I have are the ones from SF website. When I ask
for the raw number for the last two months ( Feb 23, 2008 - Apr 22,
2008), it says
685 downloads. I see a peak at 34 yesterday (I have no clue about
what was going on
yesterday).
http://sourceforge.net/project/stats/detail.php?group_id=203172&ugn=open-axiom&type=prdownload
The Windows binary is said to have been downloaded 319 times but Alfredo and I
know that the actual numbers are higher than that because the count was reset
when the binary file was upgraded. The source tarball has been downloaded 133
times. Combined, the RPMs have been downloaded 78 times.
Users: I have no numbers, except extrapolating from downloads and people sending
me emails.
> Should we write to NAG to ask?
Yes, that is a very good initiative. Mike Dewar is among the NAG people you
might want to talk to.
>
>
> >
> > As I have stated many times, and part of the reasons for OpenAxiom, I
> > would like to
> > get away from Lisp as soon as possible: This isn't negociable.
>
> For people in Sage-devel who don't know, OpenAxiom has the following
> goal (from their website): "OpenAxiom strives to support ubiquitous,
> advanced, high quality open source computer algebra on major operating
> systems, in particular major Unix variants, GNU/Linux variants,
> Windows, and handheld devices. It aims at being the open source
> computer algebra system of choice for research, teaching, engineering,
> etc."
>
> Thus their goals overlap a lot with Sage, and they do care a great deal about
> portability to different platforms. Gaby -- since our goals are so similar
> I hope there are ways we can work together.
Yes, that is my hope too -- in fact, I got similar requests from users
in Europe.
>
>
> > From my perspective, it is NOT a scalable technology for writing large
> > scale systems
> > given the zoo of users, developers, and development environments we have today.
> > I know Lisp enthusiasts think the opposite and are likely to say "you
> > don't get it".
>
> Well I agree completely with you.
>
>
> > At the moment, I don't have formal benchmark to assess OpenAxiom,
> > except the tiny
> > regression testsuite. I must also confess that most of my work wo far
> > has concentrated
> > on getting rid of as mush Lisps as can and fixing the compiler and
> > interpreter. The
> > design of the Algebraic Virtual Machine for OpenAxiom is still progressing.
>
> How are you getting rid of as much Lisp as you can in OpenAxiom? Does
> this involve porting Lisp code to Aldor, or ?
What I've done so far is:
(1) reduce the amount of Lisp code (usually replacing with Boot codes).
(2) the non-portable Lisp codes have been replaced by C codes , and
Foreign Function
Interface is used to glue things together -- that has proven
far more effective than
series of `#+', `#-' with no end in sight.
The core non-algebra part is written in a domain specific language called Boot
(a pun on bootstrapping Axiom). Originally, it originated as a syntactic
sugar over Lisp, but a sugar that makes writing the interpreter and compiler
an enjoyable exercise. The Boot code has some complement written in Lisp
(essentially for some macros assisting the runtime system). Boot can be thought
of as the `weakly typed' version of Spad (the library extension
language) -- though I
have been busy adding type annotations back (so that silly errors get caught as
early as possible).
For some reasons, the base Axiom source code I started working with has
Boot code translated back to Lisp, which I found curious. I removed
those Lisp codes, replacing them with the Boot equivalent. I believe
that, as of
today, OpenAxiom has much less Lisp codes for the interper and compiler than
the others from the Axiom family. The goal is to remove any reference to Lisp.
To succeed, there must be a Boot translator, and one that can
translate to something other than Lisp -- either C++ or Java (anything with
better support than Lisp). Fortunately, Boot is not complicated and the
translator (called Bemol) written in C++ is progressing quite well. I hope that
by OpenAxiom-2.0, the Bemol translator would be a viable alternative.
(Last fall, I had students who attempted to write a Spad->C++ translator, but
they did not have the runtime system).
>
> Also, what is the Alebraic Virtual Machine?
>
> I think these are all good questions to discuss on #sage-devel, since
> Sage is about unifying all mathematical software systems, so it is
> very good to be aware of what ideas you have in the pipeline for
> OpenAxiom.
The Algebraic Virtual Machine is my idea for replacing the current
runtime system. The idea is that the AVM should:
(1) interoperate with native codes (e.g. codes written in C or C++), without
requiring excessive work, and without adding overhead.
(2) contain primitives for supporting algebraic codes. For example,
`reduction' operation
should be supported at the basic level. The reason for this is that, if
OpenAxiom is to scale to multicores and effectivelly support
parallel algorithms,
the basic primitives should be part of the AVM, as opposed to
be grafted as
an afterthought to Spad.
(3) the AVM should shield library codes from non-portability issues
such as multithreading
support, OS-specific requirements, etc.
-- Gaby
Robert Dodier
> Well, since the Maxima folks now have told us that they will support
> ecls soon the decision has been made on our end to switch to Maxima
> +ecls.
am willing to try to resolve the problems compiling Maxima with
ECLS, but I can't promise that anyone else is going to be interested.
> There is no point in beating the dead horse that is gcl.
list to drop GCL. The main issue is that GCL runs on Windows
and some other Lisps of interest (SBCL, CMUCL) do not.
Robert Dodier
William Stein
>
> Michael,
>
> Wow, it sure it nice to have someone on the "other end of the phone",
> so as to speak ... :-) I think it is really great that Google came
> through with financial support that is making it possible for you and
> others to dedicate so much time to this.
I'm very thankful to them. By the way, Microsoft Research
is also funding Sage work right now, and I'm also very grateful
to them.
> On Tue, Apr 22, 2008 at 2:41 AM, mabshoff wrote:
> >
> > On Apr 22, 7:36 am, "Bill Page" wrote:
> > ...
>
> > > The most recent branch 'Version_2_6_8pre' is what we normally
> > > use to build Axiom. There is a change about 4 months old. If I
> > > recall correctly 'Version_2_6_8pre' actually corresponds to the
> > > version distributed on Debian and would probably be the most
> > > likely to be stable on the largest number of platforms.
> >
> > At least testing ships CVS head.
>
> Are you sure? I suppose that we had better check with Camm.
Please do.
>
> > And not to be too picky here: The last tarball from the website
> > predates OSX 10.5 and also Solaris 10, so maybe it is time to
> > cut another bug fix release since everybody seems to be using
> > 2.6.8CVS anyway.
>
> Yes, 2.6.8pre (as in pre-release). 2.6.8 was never "officially" released.
>
>
> > But when I build stable releases I do not poke around in the CVS
> > repo. Asking could have helped, but if nobody bothered to update
> > the website in three years anyway what is the point? 2.6.7 actually
> > also miserably fails on Solaris 9 for me, and that has been out for
> > a while before 2.6.7.
> >
>
> This is open source age and GCL existed well before that. I am not
> making excuses but ...
GCL started in 1984 I guess.
>
> > ...
>
> > Well, since the Maxima folks now have told us that they will
> > support ecls soon the decision has been made on our end to
> > switch to Maxima +ecls.
>
> Choose your own poison. ;-) Actually I don't know much about ecl but I
> seriously doubt the long term viability of ecl will be any different
> than the half dozen other alternatives.
Perhaps you should "know more about ecl" before you make such assertions.
I also don't know much about ecl, but I do know that Michael Abshoff
knows how to evaluate code and build systems well, and if he says that ecls
is much more viable codewise I wouldn't try to refute it by simply saying
"I seriously doubt it" without a good argument. Michael did give real
technical arguments for ecls.
Aside: Several very successful senior industry-type people
have mentioned to me on several occasions that successful
software projects tends to have a life cycle, which is maybe around 30 years.
I do not know if I believe this, but their reasoning goes that software does
something like this:
Years 0-9: rapid growth of new project by a bunch of "smart kids"
Years 10-19: stability; usability
Years 20-29: decline
GCL is from 1984.
I'm still not at all sure I buy into this "30 year lifecycle" deal,
but there is probably something to it. Perhaps the only
way to escape it is to reinvent the software -- e.g.,
Cayley which started in 1973, was reinvented as Magma
in the early 1990s. Maybe Magma is being reinvented
as Sage... :-)
> Of course I am all for
> co-operation between projects so if Maxima is willing to make a
> version that is more suitable for use in Sage, the more power (money
> and resources ...) to them! :-)
Good.
This suggests that there is no possible way Aldor would ever
be released under a GPL-compatible license. Bummer. That
can only be bad for our community.
>
> > We have discussed the issue here before and everybody agrees
> > that it is GPL incompatible.
>
> Yes, that is the said truth. Some people at NAG apparently also have a
> philosophical disagreement with the Free Software Foundation about the
> reasonableness of GPL but I am still optimistic that this can be
> overcome. Afterall, you can only shoot yourself in the foot so many
> times ... ;-)
Just release under a GPL compatible license:
http://www.dwheeler.com/essays/gpl-compatible.html
>
>
> > But I have little hope that Sage's potential interest in Aldor
> > would get somebody to change the license.
>
> I think you greatly under estimate the power and momentum that Sage
> has now and how it is about to grow in the next year. (Too bad no one
> is issuing "shares".)
:-)
I'm really excited to see where Sage goes in the next year. I've been
very pleased with the progress we had during the last year.
> I should also admit that most of my rant in the previous email was in
> fact a prelude to asking William to try to intervene with NAG on our
> behalf precisely become of this new found influence.
Interesting. I think you have a point -- in connection with Sage we
have successfully got I think about 10 or more projects now to go
GPL-compatible (GPL or BSD). I think this is really good for the
open source math software community. [Note: many of these
packages are fairly specialized math software programs or libraries,
but are very very important to researchers in those area.]
Will there be any NAG people at ISSAC in Austria this summer?
I'll be there.
> > A "non-commercial only" Open Source license is often the kiss
> > of death to a project. Abandoned by its commercial parent
> > company, but not free in reality it is neither here nor there. Either
> > you make the code free [your choice: GPL, LGPL, MIT, BSD]
> > or you don't. It is either Open Source code or it isn't, just like
> > you can't be a little big pregnant :)
> >
>
> Apparently the Free Software Foundation does not agree:
> http://www.gnu.org/philosophy/categories.html#semi-freeSoftware
>
> But I agree in principle with your point of view.
The following page makes a compelling argument I think:
http://www.dwheeler.com/essays/gpl-compatible.html
Personally I only agree with only some of what the Free Software Foundation
claims. I'm generally more of an Open Source guy than a Free Software guy.
Basically, I want to use the best possible tools for the job, and I think that
Open Source has the potential to make said tools for certain application
domains. Math software is definitely one of them.
-- William
Gabriel Dos Reis
> > There is no point in beating the dead horse that is gcl.
>
> It has been proposed more than once on the Maxima mailing
> list to drop GCL. The main issue is that GCL runs on Windows
> and some other Lisps of interest (SBCL, CMUCL) do not.
Yes, that is a strong argument. See
http://sourceforge.net/mailarchive/message.php?msg_name=877ifavq4r.fsf%40cantab.net
-- Gaby
mabshoff
On Apr 22, 3:50 pm, "Bill Page" <bill.p...@newsynthesis.org> wrote:
> Michael,
Hi Bill,
> > At least testing ships CVS head.
>
> Are you sure? I suppose that we had better check with Camm.
2.6.7-36.1. So I might have gotten my wires crossed with unstable
here. So my bad. But it still raises the point that the website should
either have snap shots or a pointer to the Debian page. I know that
Camm is heavily involved with Debian, so I knew where to look after
the 2.7CVS failed for me the first time I checked it eight months or
so ago.
> > And not to be too picky here: The last tarball from the website
> > predates OSX 10.5 and also Solaris 10, so maybe it is time to
> > cut another bug fix release since everybody seems to be using
> > 2.6.8CVS anyway.
>
> Yes, 2.6.8pre (as in pre-release). 2.6.8 was never "officially" released.
> > But when I build stable releases I do not poke around in the CVS
> > repo. Asking could have helped, but if nobody bothered to update
> > the website in three years anyway what is the point? 2.6.7 actually
> > also miserably fails on Solaris 9 for me, and that has been out for
> > a while before 2.6.7.
>
> This is open source age and GCL existed well before that. I am not
> making excuses but ...
>
> > ...
> > Well, since the Maxima folks now have told us that they will
> > support ecls soon the decision has been made on our end to
> > switch to Maxima +ecls.
>
> Choose your own poison. ;-) Actually I don't know much about ecl but I
> seriously doubt the long term viability of ecl will be any different
> than the half dozen other alternatives. Of course I am all for
> co-operation between projects so if Maxima is willing to make a
> version that is more suitable for use in Sage, the more power (money
> and resources ...) to them! :-)
baggage and it does already run with a lot more compilers than the
competition. It might currently not be as fast as sbcl for example but
if I have to chose between lisp working and no lisp that isn't really
a hard choice. And because of its design I can hack on ecls without
spending significant time on getting to know the inner workings of
some lisp machine or some obscure library like libbfd.
And if Maxima wouldn't want to port to ecls it isn't the end of the
road. During Dev1 in about two months we will see how Gary's fast
symbolics code is doing. During Sage Days 10 in Nancy in October we
will likely talk with Parisse [author of giac] and see if we cannot
cooperate there. We can certainly shoulder the pain the doing lisp for
another year or two without switching to ecls, but lisp based CASes do
not have a monopoly on symbolic computation. giac has its issues, but
I am certain I can beat all build issues out of that code in 2-4 weeks
if I have to. And that is a much quicker solution than to wait for
things with gcl and clisp to improve. I hope that the Maxima on ecls
build becomes a reality soon. If not there is always door B and C.
> > There is no point in beating the dead horse that is gcl.
>
> I take offense. gcl is not a dead horse no matter how neglected it
> might look to you.
"polishing a turd" to "a death march". Just because people can install
binary gcl versions by "apt get gcl-$FOO" doesn't mean that it is
working well. If Sage were that hard to build because it only worked
on William's exact configuration Sage would likely have a much smaller
user base. Developers work on Sage because my mother could compile
Sage. And if one fails because there is a bug and you report it it
will likely get fixed.
The state of gcl is actually much worst than I assumed before this
thread got started and that is why I think that the tools for
developing with lisp suck. There is no other way of putting it. Gaby
tried gcl-2.6.8cvs and it was broken for him for any platform he
tested by x86. I didn't know that Gaby held those views about lisp,
but I think it is telling that somebody deeply involved with Axiom
[and then OpenAxiom] came to that conclusion.
Re gcl again: Please don't tell me to report build bugs and so on to
make it better. Any gcl developer can download a VMWare image of
Fedora, OpenSuSE, Gentoo, FreeBSD, Solaris and so on and should be
able to find plenty of bugs before I have to get involved here. I have
done software for a long, long time and been in the trenches. One look
at the gcl situation tells me to get the hell away from it as fast as
possible since I have no stake in the lisp community and hence no
interest of fixing this. This brings me back to my original point I
made many, many posts ago: If the lisp community were alive and well
their tools would be alive and well. That is clearly not the case of
gcl and clisp certainly has some serious issues to deal with with
newer gcc releases as well as compilers not gcc.
Can gcl be improved? Certainly. But I am not holding my breath.
somewhat depends on the unit you deal with.
> NAG itself is a non-commerical organization.
is non-commerical also, but that doesn't make it open source. You
didn't claim that, but non-commercial \nRightarrow Open Source.
> > We have discussed the issue here before and everybody agrees
> > that it is GPL incompatible.
>
> Yes, that is the said truth. Some people at NAG apparently also have a
> philosophical disagreement with the Free Software Foundation about the
> reasonableness of GPL but I am still optimistic that this can be
> overcome. Afterall, you can only shoot yourself in the foot so many
> times ... ;-)
> > But I have little hope that Sage's potential interest in Aldor
> > would get somebody to change the license.
>
> I think you greatly under estimate the power and momentum that Sage
> has now and how it is about to grow in the next year. (Too bad no one
> is issuing "shares".)
into Sage" is not the solution and will not magically make a project
better.
> I should also admit that most of my rant in the previous email was in
> fact a prelude to asking William to try to intervene with NAG on our
> behalf precisely become of this new found influence.
> > A "non-commercial only" Open Source license is often the kiss
> > of death to a project. Abandoned by its commercial parent
> > company, but not free in reality it is neither here nor there. Either
> > you make the code free [your choice: GPL, LGPL, MIT, BSD]
> > or you don't. It is either Open Source code or it isn't, just like
> > you can't be a little big pregnant :)
>
> Apparently the Free Software Foundation does not agree:
>
> http://www.gnu.org/philosophy/categories.html#semi-freeSoftware
>
> But I agree in principle with your point of view.
compatible will not be part of the core of Sage.
mabshoff
> mabshoff wrote:
Hi Robert,
> > Well, since the Maxima folks now have told us that they will support
> > ecls soon the decision has been made on our end to switch to Maxima
> > +ecls.
>
> Michael, I don't mean to rain on the parade, but: I personally
> am willing to try to resolve the problems compiling Maxima with
> ECLS, but I can't promise that anyone else is going to be interested.
characterize it that way. My bad.
> > There is no point in beating the dead horse that is gcl.
>
> It has been proposed more than once on the Maxima mailing
> list to drop GCL. The main issue is that GCL runs on Windows
> and some other Lisps of interest (SBCL, CMUCL) do not.
can do *anything* to help you out there. I would greatly prefer to
solve the problem before the fall. I know that is your time, so it is
certainly your decision how you allocate resources.
Sage is working on a full scale MSVC 64 bit port of all its
components. So it is likely that it will be relatively little work on
my end to make a Maxima+ecls 32 and 64 bit MSI installer. And I am
hoping that people in the Maxima community will see this as an
incentive to help out doing the work.
> Robert Dodier
Cheers,
Michael
root
> If the lisp community were alive and well
>their tools would be alive and well. That is clearly not the case of
>gcl and clisp certainly has some serious issues to deal with with
>newer gcc releases as well as compilers not gcc.
>
I'm also on the clisp mailing list and I don't recall seeing any
sage-related bug reports there either.
>Can gcl be improved? Certainly. But I am not holding my breath.
>
>..<snip>...
I know you don't care about lisp and that's fine. And I know you've
encountered problems with lisp builds. And we both know that when
someone encounters problems with open source tools it is expected
behavior to post bug reports (as I did with Sage this morning).
Please post specific bug reports. We all know that's the only real
way anything will get done to solve the problems. The clisp maintainers
are very responsive to mailing list bug reports.
Tim
Gabriel Dos Reis
> I know you don't care about lisp and that's fine. And I know you've
> encountered problems with lisp builds. And we both know that when
> someone encounters problems with open source tools it is expected
> behavior to post bug reports
August 08, 2007
http://lists.gnu.org/archive/html/gcl-devel/2007-08/msg00004.html
August 19, 2007:
http://lists.gnu.org/archive/html/gcl-devel/2007-08/msg00017.html
No answer, no acknowledgment.
If I'm reading `date` output correctly, today is April 22, 2008.
How long do you think Don Winieki -- who is *begging* to contribute to
GCL -- should wait
till he gets an answer to this basic question:
http://lists.gnu.org/archive/html/gcl-devel/2008-04/msg00004.html
http://lists.gnu.org/archive/html/gcl-devel/2008-02/msg00004.html
-- Gaby
mabshoff
Hi Tim,
> >..<snip>...
> > If the lisp community were alive and well
> >their tools would be alive and well. That is clearly not the case of
> >gcl and clisp certainly has some serious issues to deal with with
> >newer gcc releases as well as compilers not gcc.
>
> I'm also on the clisp mailing list and I don't recall seeing any
> sage-related bug reports there either.
not all my email that I send is stored locally and searchable]:
* "clisp 2.43 Solaris 9 build failure" 11/09/2007
* "clisp.run 2.41 segfaults on Solaris 9 in 32 bit mode" 08/18/2007
I send more emails about two two months ago, but much of that traffic
was off-list to Sam directly with William in the CC. Sam has an
account on one of William's Solaris boxen, so he can't claim that he
doesn't have access. The gcc 4.2 and 4.3 issues are well documented in
clisp's sf bugtracker. The report originally was by "cartman", which
used to hang around in #sage-devel. I have also commented on various
ticket at clisp's sf based bug tracker. So I would say I have met the
burden of being involved and attempted to fix things.
> >Can gcl be improved? Certainly. But I am not holding my breath.
>
> >..<snip>...
>
> I know you don't care about lisp and that's fine. And I know you've
> encountered problems with lisp builds. And we both know that when
> someone encounters problems with open source tools it is expected
> behavior to post bug reports (as I did with Sage this morning).
reported in 3.0.1. The README.txt says that the minimal supported
version of gcc is 3.4 and when building FLINT [later on after eclib]
it will error out telling you that you need a C99 compiler. We will
move that test to the start of the Sage build process so the error
will not happen.
> Please post specific bug reports. We all know that's the only real
> way anything will get done to solve the problems. The clisp maintainers
> are very responsive to mailing list bug reports.
boils down to: "We know it miscompiles, it is likely a bug in gcc, so
if you figure out what is wrong let us know". Well, after 6+ months I
decided that enough is enought [and I looked at their code to get it
to compile with Sun Forte's cc or CC] and we are building the code
with "-O0" to avoid hitting that bug. But even "-O0" doesn't help on
Solaris for example. The last working clisp on Solaris is 2.39
compiled with gcc 3.3 on Solaris 8. I got it to run as a binary by
tricking it [it wants readline.so.4, but causes it to segfault, so
linking readline.so.5 to readline.so.4 and manipulating
LD_LIBRARY_PATH for clisp does the trick].
I feel that I have done more than a reasonable amount of work here. Do
you agree or disagree?
> Tim
Cheers,
Michael
Bill Page
>
> I googled for it and it seems lenny is using 2.6.7 while sid is using
> 2.6.7-36.1. So I might have gotten my wires crossed with unstable
> here. So my bad.
Beware of the release numbering. The most recent reference I could find is:
http://lists.gnu.org/archive/html/gcl-devel/2008-01/msg00002.html
"2.6.8pre by contrast is nearer at hand. I do think we will need a
windows installer for this release. I'd also like a working mac intel
port. Otherwise, the image (packaged as Debian gcl-2.6.7-36) is
carrying axiom, maxima, acl2, and hol88 to all 12 Debian platforms."
So I guess as of January this year Debian "2.6.7-36.1" was actually
"2.6.8pre" in cvs.
> But it still raises the point that the website should either
> have snap shots or a pointer to the Debian page. I know that
> Camm is heavily involved with Debian, so I knew where to look
> after the 2.7CVS failed for me the first time I checked it eight
> months or so ago.
>
Yes it would be nice to have accurate up to date information at the
gcl website. Maybe a wiki would be nice but it still takes someone
with time and motivation.
> > ...
> > > Well, I think NAG chose the "non-commercial only" license on
> > > purpose.
> >
> > Well yes, of course it was on purpose. They have stated that they
> > felt obligated to do this by the terms under which they originally
> > received Axiom (and Aldor) from IBM.
>
> Odd, IBM as a whole seems to be very OS friendly, but in reality
> it somewhat depends on the unit you deal with.
>
I also suspect that if it were possible to approach IBM about the
license situation with Axiom and Aldor now, one might obtain a
different picture than the one presented by NAG. But NAG's
relationship with IBM was circa 1995 and this is now. Different people
are involved.
>
> > NAG itself is a non-commerical organization.
>
> Well, be that as it may, but their numerical library isn't free.
Therein lies the rub. Originally, acquiring Axiom was a way for NAG to
package and market it's numerical library. They did a *lot* of work to
link Axiom to the numerical library - all of which was lost in the
open source version of Axiom. When the numerical library was licensed
to Maple circa 2000, NAG found themselves in a bit of a conflicted
position.
> ...
> Nope, I am fully aware of "the power of Sage." But "let's get $FOO
> into Sage" is not the solution and will not magically make a project
> better.
>
It seems to me that my proposal for the place that Axiom/Aldor could
have in Sage has more depth to it than that... :-(
> ...
Regards,
Bill Page.
Ondrej Certik
>
> On Tue, Apr 22, 2008 at 3:25 PM, mabshoff wrote:
> >
> > I googled for it and it seems lenny is using 2.6.7 while sid is using
> > 2.6.7-36.1. So I might have gotten my wires crossed with unstable
> > here. So my bad.
>
> Beware of the release numbering. The most recent reference I could find is:
>
> http://lists.gnu.org/archive/html/gcl-devel/2008-01/msg00002.html
>
> "2.6.8pre by contrast is nearer at hand. I do think we will need a
> windows installer for this release. I'd also like a working mac intel
> port. Otherwise, the image (packaged as Debian gcl-2.6.7-36) is
> carrying axiom, maxima, acl2, and hol88 to all 12 Debian platforms."
>
> So I guess as of January this year Debian "2.6.7-36.1" was actually
> "2.6.8pre" in cvs.
Just for the record -- I looked at the source package of gcl
2.6.7-36.1 a couple days ago,
and it's a big mess. The orig.tar.gz is smaller than the debian.diff,
that patches nearly every file.
Also the debian/ directory contains garbage like this:
$ ls debian/.#*
debian/.#changelog.1.220.2.1.4.1.2.1.2.1.2.2.2.1.2.19.2.207.2.23.2.11.2.14.2.13.4.7.2.22.2.97
debian/.#control..1.2.2.1.2.5.6.1.2.1.2.3.2.8
debian/.#control.1.35.4.1.4.5.6.1.2.1.2.5.2.8
debian/.#control.cvs.1.1.2.1.2.5.6.1.2.1.2.3.2.8
debian/.#rules.1.41.4.2.2.7.4.1.2.1.2.2.2.1.2.8
But that's minor.
Well, I am glad I don't have to touch and maintain such a thing.
Ondrej
root
>you agree or disagree?
Have you done a reasonable amount of work? That's for you to judge
since you're the person with the need.
But lets see what seems to be going on with Clisp.
Sam's reply to you seems to be that you need a certain combination of
operating systems and compilers and libraries to generate a supported
build. (This is very similar to the reply to my Sage bug report,
essentially "fix your compiler".) So the expected response would be
for you to reinstall Solaris to the "correct" version with the
"correct" libraries and the bug goes away. Asking a user to "fix
their system" is not a valid response but that seems to be the essence
of the replies.
Ask yourself why you might get this kind of response.
Sam (and Camm) may have time constraints. I know that Camm does the
work in his free time. I know Camm is working on a massive rewrite
(probably NOT in public). I don't know what Sam does for a living but
I suspect his work is also a free time activity. Axiom is also free
time support. Dormant bug reports are not an indication of inactivity.
Sage may have a few bug reports that are a few months old. Clisp is
free software. You have the source code, you have the need, post a
patch.
Sam (and Camm) may have hardware/operating system constraints.
Possibly the boxen that they use are borrowed and they cannot
reproduce your exact environment. I have 9 physical machines here with
32 virtual boxen and I still cannot reproduce all of the
combinations. I don't have access to a Sparc, for instance.
Sourceforge took down their compile farm and HP doesn't have a large
set in their farm. Axiom runs in many more places than I publish but
there are outstanding build issues so I won't claim it "runs" anywhere
but on a published subset of combinations. You do the same thing
(e.g. no redhat9 gcc x.x.x). I did ask Google, Microsoft, and
Sourceforge to put up compile farms but nothing happened. If we
all used a "standard compile farm" this problem might be minimized.
For now, though, the odds are good that Sam does not have your
Solaris machine configuration and cannot reproduce your bug.
We are both in the same business; you package Sage to run everywhere
and I package Axiom to run everywhere. As soon as you touch anything
at all, something breaks. When GCL breaks, I post a patch and locally
apply the patch until it is accepted upstream (if at all). If Clisp
fails for you then fix it, post a patch, locally apply the patch
until it gets applied upstream, and move on.
It is not a question of "reasonable amount of work".
It is a question of expectations.
What, exactly, do you expect? Instant, top-of-the-pile bug fixes on
all of YOUR hardware/software combinations? This is free and open
source software. The only thing you can expect is to get the source
code so you can fix it and post a patch. Everything else is not in the
contract. That's why people pay for software. Franz would be willing
to fix your issues immediately. I'm not sure your check to Sam has
cleared yet. If you don't want to build patches then send Sam a
contract. I'm sure he'd be happy to get paid. Sage will have this same
problem in the future as various package maintainers move on or you
can no longer reach your Sparc.
What if your expectations are not fulfilled? Well, that generally
leads to anger and frustration, both natural reactions. But it seems
that you have used "hasty generalization" to conclude that Lisp is
dead. And from there to conclude that Lisp should be removed from
everywhere. That's a shame because Maxima contains an astonishing
amount of well debugged algorithms by recognized experts in the field.
And characterizing Lisps like SBCL (fork of CMUCL, child of the CMU
Spice Lisp research project) as "polishing a turd", implies that
Scott Fahlman wasted his time studying dynamic language optimization
in compilers. Python has yet to even think about these issues, most
of which have already been solved by Scott. Everywhere else in Sage
I see people struggle over milliseconds. Then I see Maxima built on
Clisp (an interpreter) rather than SBCL, a optimizing compiler.
Ultimately the point of my post was that, despite not seeing immediate
results, it is STILL worthwhile to post bug reports. At minimum, other
people can google them and find that they also have the problem.
As for your original question, if your bug reports contain a patch
THEN you've done a reasonable amount of work, at least by my
definition of "reasonable". Your definition might differ.
Tim
Bill Page
>
> On Tue, Apr 22, 2008 at 6:50 AM, Bill Page wrote:
> ...
> > I should also admit that most of my rant in the previous email
> > was in fact a prelude to asking William to try to intervene with
> > NAG on our behalf precisely become of this new found
> > influence.
>
> Interesting. I think you have a point -- in connection with Sage
> we have successfully got I think about 10 or more projects now
> to go GPL-compatible (GPL or BSD). I think this is really good
> for the open source math software community. [Note: many of
> these packages are fairly specialized math software programs
> or libraries, but are very very important to researchers in those
> area.]
>
> Will there be any NAG people at ISSAC in Austria this summer?
> I'll be there.
>
I also plan to be there.
http://www.risc.uni-linz.ac.at/about/conferences/issac2008
I think it is great that you were invited to present at ISSAC. As you
probably know, the ISSAC meetings have a very long history with ACM.
I believe that your presentation of Sage at this meeting should be
considered a significant milestone for Sage! :-)
I am quite sure there will be several people from NAG at ISSAC 2008
but I cannot name names right now.
Following ISSAC there will also be a meeting specifically about Axiom
and Aldor. A very preliminary draft announcement (not yet formally
announced) is here:
http://axiom-wiki.newsynthesis.org/SandboxWorkShopRISC2008
I will be there. I think it would be great if you and anyone else
interested in Axiom and Aldor could also be present.
For more information please contact Ralf Hemmecke or Martin Rubey.
Regards,
Bill Page.
mabshoff
> >you agree or disagree?
>
> Have you done a reasonable amount of work? That's for you to judge
> since you're the person with the need.
>
> But lets see what seems to be going on with Clisp.
>
> Sam's reply to you seems to be that you need a certain combination of
> operating systems and compilers and libraries to generate a supported
> build. (This is very similar to the reply to my Sage bug report,
> essentially "fix your compiler".) So the expected response would be
> for you to reinstall Solaris to the "correct" version with the
> "correct" libraries and the bug goes away. Asking a user to "fix
> their system" is not a valid response but that seems to be the essence
> of the replies.
>
> Ask yourself why you might get this kind of response.
were in private. To set the record clear:
* I have build various toolchains on that box, i.e. 25+ packages and
** gcc 3.4.6
** gcc 4.0.3
** gcc 4.1.2
** gcc 4.2.2
[** Sun Forte - but I didn't compile that]
With those compilers I have attempted to compile
* clisp CVS numerous times
* clisp 2.39
* clisp 2.40
* clisp 2.41
* clisp 2.42
* clisp 2.43
* clisp 2.43.1
* clisp 2.44
* clisp 2.44.1
With all tricks, i.e. "-O0" and so on. Some of them actually compile
and I get a working clisp binary. *None* of them get even close to
pass "make check". *None* of them are able to compile Maxima with the
clisp binaries that actually started up. I have poked around in the
code and found it hard to read and difficult to understand. Now I
might not be so bright, but it is quite an odd coincidence that
a) All 5 million lines of code of Sage compile more or less out of the
box [2, 3 patches are needed, clisp usually doesn't build] - and I did
most of the work there
b) http://trac.sagemath.org/sage_trac/query?status=assigned&status=closed&owner=mabshoff&order=priority
[380 closed tickers, second only to William]
I am far, far from some idiot n00b who can't compile his way out of a
paper bag. I have been doing this professionally for close to fifteen
years.
> Sam (and Camm) may have time constraints. I know that Camm does the
> work in his free time. I know Camm is working on a massive rewrite
> (probably NOT in public). I don't know what Sam does for a living but
> I suspect his work is also a free time activity.
incompetent. I am sure they are *very* competent. If they have day
jobs they can only work so much on clisp/gcl. But my conclusion
looking at the state of the projects they lead is that the code is
subpar - at least for my purposes.
> Axiom is also free
> time support. Dormant bug reports are not an indication of inactivity.
> Sage may have a few bug reports that are a few months old. Clisp is
> free software. You have the source code, you have the need, post a
> patch.
> Sam (and Camm) may have hardware/operating system constraints.
> Possibly the boxen that they use are borrowed and they cannot
> reproduce your exact environment. I have 9 physical machines here with
> 32 virtual boxen and I still cannot reproduce all of the
> combinations. I don't have access to a Sparc, for instance.
not to use it: Well, I don't have to use clisp. Solaris 9 and 10 isn't
some run-of-the-mill Unix. Its configuration is very homogeneous and I
am not trying to run clisp on my toaster with netbsd and some odd
toolchain. Sage wants to play with the big boys and that means Linux
Itanium, Solaris on Sparc, PPC64 boxen by IBM and hopefully soon HPUX
11i on Itanium. If clisp doesn't want to go there: fine by me. But I
do not feel an obligation to help *anybody*. *You* do not pay my
salary, so I while I want to be a nice guy in general I can very much
decide on my own what to do.
> Sourceforge took down their compile farm and HP doesn't have a large
> set in their farm. Axiom runs in many more places than I publish but
> there are outstanding build issues so I won't claim it "runs" anywhere
> but on a published subset of combinations. You do the same thing
> (e.g. no redhat9 gcc x.x.x). I did ask Google, Microsoft, and
> Sourceforge to put up compile farms but nothing happened. If we
> all used a "standard compile farm" this problem might be minimized.
> For now, though, the odds are good that Sam does not have your
> Solaris machine configuration and cannot reproduce your bug.
Sam has access to the machine in question as I mentioned above.
> We are both in the same business; you package Sage to run everywhere
> and I package Axiom to run everywhere. As soon as you touch anything
> at all, something breaks. When GCL breaks, I post a patch and locally
> apply the patch until it is accepted upstream (if at all). If Clisp
> fails for you then fix it, post a patch, locally apply the patch
> until it gets applied upstream, and move on.
is being written and has been funded. On top of that we can do
* Maxima+ecls
* Maxima+clisp [this would likely mean that we would be looking for
alternative like giac]
> It is not a question of "reasonable amount of work".
> It is a question of expectations.
> What, exactly, do you expect? Instant, top-of-the-pile bug fixes on
> all of YOUR hardware/software combinations? This is free and open
> source software. The only thing you can expect is to get the source
> code so you can fix it and post a patch. Everything else is not in the
> contract. That's why people pay for software. Franz would be willing
> to fix your issues immediately. I'm not sure your check to Sam has
> cleared yet. If you don't want to build patches then send Sam a
> contract. I'm sure he'd be happy to get paid.
problem. Since I don't want to pay to maintain clisp my conclusion is
to either move to a free and open source lisp that works or get the
wheels in motion to dump all code in Sage that depends on it. I have
given back for years in the Open Source community and I am not
expecting wonders here. I will be an essential part to port a
*massive* numbers of mathematical and other code in Sage to Windows.
So I am not some leech sitting on the sideline and complaining that
the people doing the work for free aren't getting shit done.
> Sage will have this same
> problem in the future as various package maintainers move on or you
> can no longer reach your Sparc.
Picking up a used Sparc runs a couple hundred dollars. Buying a
reasonable Sparc new isn't exactly big money either.
> What if your expectations are not fulfilled? Well, that generally
> leads to anger and frustration, both natural reactions. But it seems
> that you have used "hasty generalization" to conclude that Lisp is
> dead. And from there to conclude that Lisp should be removed from
> everywhere. That's a shame because Maxima contains an astonishing
> amount of well debugged algorithms by recognized experts in the field.
>
> And characterizing Lisps like SBCL (fork of CMUCL, child of the CMU
> Spice Lisp research project) as "polishing a turd", implies that
> Scott Fahlman wasted his time studying dynamic language optimization
> in compilers.
no problem defending my opinion. I don't hate lisp, I hate crap
implementation of anything.
> Python has yet to even think about these issues, most
> of which have already been solved by Scott.
But in earnest here: After this barrage of issues [also by Gaby or
Ondrej's comment about the Debian source deb]: how can you pretend
that the lisp world is one happy place where things work?
> Everywhere else in Sage
> I see people struggle over milliseconds. Then I see Maxima built on
> Clisp (an interpreter) rather than SBCL, a optimizing compiler.
>
> Ultimately the point of my post was that, despite not seeing immediate
> results, it is STILL worthwhile to post bug reports. At minimum, other
> people can google them and find that they also have the problem.
tracker there is plenty of work to do.
> As for your original question, if your bug reports contain a patch
> THEN you've done a reasonable amount of work, at least by my
> definition of "reasonable". Your definition might differ.
> Tim
I don't want this discussion to go out of hand [too late], but
ultimately this is all about what is best for the Sage project. And my
opinion there counts a whole lot more in that regard than yours, just
as my opinion about Axiom is totally irrelevant.
Cheers,
Michael
Gabriel Dos Reis
<Michael...@mathematik.uni-dortmund.de> wrote:
>
> I don't want this discussion to go out of hand [too late], but
> ultimately this is all about what is best for the Sage project. And my
> opinion there counts a whole lot more in that regard than yours, just
> as my opinion about Axiom is totally irrelevant.
Michael --
Don't worry too much about being distracted by Tim. Just providing
data as you have
been doing so well is sufficient for us to form opinion. Please keep
the good work up.
And certainly, I value your opinion about CASs for the Axiom family.
-- Gaby
mabshoff
On Apr 23, 1:58 am, "Gabriel Dos Reis" <dosr...@gmail.com> wrote:
> On Tue, Apr 22, 2008 at 6:50 PM, mabshoff
>
>
> > I don't want this discussion to go out of hand [too late], but
> > ultimately this is all about what is best for the Sage project. And my
> > opinion there counts a whole lot more in that regard than yours, just
> > as my opinion about Axiom is totally irrelevant.
>
> Michael --
> Don't worry too much about being distracted by Tim. Just providing
> data as you have
> been doing so well is sufficient for us to form opinion. Please keep
> the good work up.
> And certainly, I value your opinion about CASs for the Axiom family.
contribute code I meant to say that Tim is free to ignore my opinion.
I certainly have an opinion on Axiom, but this thread is loaded enough
that I do not need to pour gasoline in the flames ;)
But it is important to me that sage-devel is a forum where each voice
is heard and while I fundamentally disagree with Tim I greatly prefer
him to be around. This forum should not be some cult like thing where
we all tell each other how great we are and that William walks on
water. I am rude, opinionated and I state my opinion honestly. I have
been wrong, very wrong, very, very wrong and will be wrong again in
the future, but in that case I am the first to call myself an idiot in
public. Tim might be right 99% of the time, but he fights for his
ideas as fiercely even for the 1% where he might be wrong. So, in the
end I might owe Tim an apology on some of the things where he is
right, but in my point of view he is wrong about lisp and also wrong
about literate programming. This is a free country [planet :)], so
both of us are free to follow up on their own opinion. I am sure Sage
will succeed, which is all that matters to me.
What is also important is that in sage-devel technical reasons trumps
all else, i.e. just because you are are reputable, widely respected
person in the mathematical world expect no lenience from me if I think
you are wrong. In mathematics you are either wrong or right - we don't
have that luxury in programming, hence we have "discussions" like
this. I immensely enjoy those, but I am getting back to work on Sage
3.0.1 now. :=)
> -- Gaby
Cheers,
Michael