On Mon, Apr 21, 2008 at 9:03 AM, William Stein wrote: > ... > 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:[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. ------ 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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
