> You recently committed changes to the axiom/branches/daly; it is good?
Well, I'll leave the judgement of "good" to you :-) The latest commit to branches/daly/axiom is the end result of a merge of BI, wh-sandbox, my work, and gold. This is what has been referred to as "silver". Once the algebra has been brought up to speed, the community has a chance to fix obvious breakage, and new code gets added it will certainly become "gold". It contains changes in the interpreter that everyone has made, such as removing xrun and xruncomp and other dead code. It contains a gcl-based prototype of cliff's common lisp web idea which will be replace by cliff's work once we move to ansi. There are no ansi-based changes yet because that work happened after I made "the cut" from the BI and wh-sandbox code bases in March. The same is true of all of the most recent work. It contains changes to the graphics (dead code elimination). I tried to merge the hyperdoc changes but did not understand how .pht handling works. Some of the algebra is changed (e.g. quat.spad) as well as some initial structure for unit testing the algebra. Most of the algebra changes were not yet merged. I'm working on trying to merge Martin's work at the moment. There are two concerns here: First, I think we need to be very conservative about algebra changes. We need good documentation applied to any algebra we change including unit tests of the algebra showing what used to be broken vs what is now fixed. I have a prototype mechanism in place in a couple algebra files. Second, I think we need to concentrate on having a comprehensive test mechanism for the algebra that will alert us to things we break. I'm concerned that "obvious" fixes in one domain end up introducing "non-obvious" breakage in another. It is not obvious how to do this. I've been pondering attacking the "algebra graph" Bill discussed years ago as a basis but there is no code to support this in the last release. The input files have been rewritten to automate checking for errors. In addition a new file (regress.lisp.pamphlet) was added to automate that checking. The build procedure now automatically checks every file in the build tree for changes. This allows us to make one change, build the system, and see what other files have changed. The advantage is that you can tell when changes to the interpreter actually end up changing the algebra in unintended ways. This lives in src/regress/REGRESS. Not everything was merged, mostly because I couldn't understand the details of the changes. So things like the autoconf build mechanism, the .pht file handling, the build-from-scratch algebra, etc. still remain to be merged. The fact that they are not yet merged does NOT mean that they won't be in the future. It does mean that the changes are not documented enough and the dependencies are not clear. It would help a LOT if you would "box up" a changeset against this latest version that added a new feature and was well tested. This takes a long time (I know because I've been at it for months). I'd encourage everyone to try to build it and report bugs (to the list and to bugzilla). Future plans are to look at updating the algebra, do a review of the outstanding bugs, and a review of the complaints and comments posted to the mailing list archives. It would be useful if other people did the same and, hopefully, create a diff-Naur patch. Now that I've got a version that works I spent some time "opening up" the silver code. It lives in parallel on SVN and in a git repository. I know there are a lot of religious debates over the source code control mechanism. I'm not trying to open the debate again. However, during the big SVN-storm back in January I ended up trying git and my eyes were opened. I've been using it ever since for all of my work. (The big hurdle is that git tracks "changes" whereas everyone else tracks "files".) Git has the potential to eliminate my special position as "the point of failure" and to make everyone "the central repository". This eliminates the need for sourceforge, automates the construction of complex "changesets", and makes the whole social network much more flexible. Linus really did "get it right". I'm also using SVN just to avoid opening up the big debate again. If you don't like git, don't use it. Changes will appear in both places. The "gold" version will still live in Arch and be mirrored to CVS at sourceforge and CVS at savannah so that ordinary mortals can get the code in the form they expect. I put together a table of binary files on a web pages someplace (can't remember where). This time around I think we need to give some thought to providing a range of binary files. Tim _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
