On Apr 22, 3:50 pm, "Bill Page" <[EMAIL PROTECTED]> wrote:
> Michael,
Hi Bill,
> > At least testing ships CVS head.
>
> Are you sure? I suppose that we had better check with Camm.
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. 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.
Well, then mayne somebody should cut a release.
> > 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! :-)
Well, for now ecls seems to be a good choice. It certainly has less
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.
Well, I would call working on code that quality anywhere from
"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.
> > 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.
>
>
>
> > > -----------
>
> > > 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.
>
> > 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.
> NAG itself is a non-commerical organization.
Well, be that as it may, but their numerical library isn't free. Magma
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 ... ;-)
Well, I disagree with the FSF on many points, too ;)
> > 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".)
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.
> 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.
Understood.
> > 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.
Yes. While it is Open Source by the letter of the law anything non-GPL
compatible will not be part of the core of Sage.
> Regards,
> Bill Page.
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
