[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] branches/daly/axiom

From: daly
Subject: [Axiom-developer] branches/daly/axiom
Date: Sun, 20 May 2007 12:08:50 -0500

> 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

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]