On Apr 22, 7:36 am, "Bill Page" <[EMAIL PROTECTED]> wrote: > On Mon, Apr 21, 2008 at 9:03 AM, William Stein wrote:
Hello folks, > > ... > > In the defense of GCL, *most* components of Sage were a mess gcl is in way more of a mess than any other component in Sage I can imagine. But then I wasn't around in the early days of Sage ;) > > 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 :-) > > > wgethttp://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? Yes. > 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 That is an issue most likely with complex.h - IIRC _Imaginary_I is 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. I tried 8 months or so ago and then roughly 4 months or so ago, both 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. At least testing ships CVS head. 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. 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 > > $ cvs -z3 -d:pserver:[EMAIL PROTECTED]:/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. 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. 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? > ------ > > 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. This is very interesting to know. Thanks for writing this down for us who weren't around back then ;) > ----------- > > 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. 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 :) > 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 -~----------~----~----~----~------~----~------~--~---
