Re: [Axiom-developer] RE: algebra Makefiles with explicit dependencies, bootstrap, fixed-points etc.

[root]

Bill,

> > I don't think we need to rush ahead with this task as it
> > is much more important to make sure it is right than it is
> > to do it quickly.
> 
> I agree that it is important to make sure that it is right.
> In fact that is why I started to look at this. I was worried
> that the current build does not (quite) do it right. The
> fact that the generated lisp files change after an iteration
> of the build proves that, I think. So on the contrary I do
> think there is some urgency.

If you remember the primary reason why we decided that there should
be monthly releases of Axiom was to undermine this sort of reasoning.
The monthly release cycle is intended to ensure that we have timely
releases of changes. The argument was that a 6 month release cycle
would delay a bug fix for an average of 9 months. A monthly release
cycle reduces that to an average of 1.5 months. 

Yes, I agree that there is an interest in Axiom and, yes, I agree that
this might be an important issue. Then again, the suggested change
might have no effect on the algebra at all. I do not believe that
we have sufficient time to 
(a) understand the nature of the problem
(b) decide if it is a bug
(c) decide that we have the correct fix
(d) document the problem and the fix
(e) decide that we haven't broken anything
(f) correctly merge the changes
(g) do "round-trip" system builds

We have 20 days left before the February 1 release. At the moment 
I understand that we have found a difference between versions of
the BOOTSTRAP code and the later compiled forms. I do not yet
understand (a) above, the nature of the problem. Why are they
different? Even if they are different the build system intentionally
rebuilds all of the BOOTSTRAP files as the last step of the build
in order to guard against some potential problems. So I'm not sure
that (b) it is a bug. After all, if we mass-replace 85 files of
the build there will be one of two cases:
 1) the input files are the same and no bugs are fixed.
      so why change the algebra?
 2) the input files are different and either bugs are fixed or introduced
      so why change the algebra? 

Clearly case 1 will require a massive change to the system with no
apparent gain. If it doesn't fix anything then there is no hurry.
We can study the fixed-point problem at our leisure. I agree that
a change is needed, just not how urgent it is.

Clearly case 2 will require further study to decide what broke and
which version is correct. If the input files break in some way then
we need to clearly understand how the massive change broke or fixed
the system. If it fixes things then we need to think about the best
way to ensure that the problem can't happen again. If it breaks things
then we need to re-evaluate the change. And we need to docoument it.

This is a change to the very heart of the system. It deserves careful
time and attention and much careful checking. And as yet I don't 
believe we fully understand anything but the symptoms of a possible,
but not proven, bug. The changes are not uploaded anywhere, they are
not "round-trip" tested, they are not hand checked, there is no 
documentation of the problem and its fixes, etc. Given all that 
I believe February 1 is too soon.

Lets upload the changes to axiom--algebra--1 where we can all work 
on it.

Quality counts and it takes time.

> > I'd suggest that the "fixed-point" bootstrap be merged into 
> > axiom--algebra--1 so we can test it first.
> 
> I am a little confused by the large number of axiom branches.
> Can you remind me what is axiom--algebra--1? How does the code
> in this branch compare to the current axiom--main--1 and
> axiom--windows--1? Steve also mentioned axiom--language--1.
> What is that? I see the titles at http://arch.axiom-developer.org
> but shouldn't we have a more complete discription somewhere
> of the goals of each project, a list of who is working on
> them? Someone names as the "owner" etc.?

The various projects exist because I've had mail exchanges with
people who want to work on various aspects of Axiom. For example,
Steve Wilson wants to examine deep changes to the language so we
agreed that this task should be broken out into its own branch
axiom--language--1. Steve is listed at the primary contact on
the arch.axiom-developer.org website.

Some of the branches are a "combing out" of the various threads
that I'm currently working on either with others (axiom--zlc--1
for the zero-learning-curve work) or (axiom--algebra--1 for
algebra changes and enhancements that are not ready to ship).
There will be more of these threads as time permits (e.g. soon
to be a CATS thread for the Computer Algebra Test Suite work).
I have about 2 dozen "sub-projects" locally that need to be
branched, some of which will take time to collect, comb out,
clean, and upload. 

The arch server came about because people complained that I took
too long to get things like sman running and since all of the
code resided in my local swamp there was no way to share the
work. So I've been "draining the swamp" and putting the code
up where it can be shared, mostly prioritized by developer 
requests. As for a "complete description"... well, I'm just too
time-limited and lazy to write a "project description" for work
in progress. The people working on a branch generally know why
it is there (e.g. axiom--windows--1) and what state it is in.

If you want a particular branch in order to pursue some new idea
(e.g. getting BRL/CAD to work with Axiom) you can send me a note.
(Actually, you already have write permission to do it yourself)

> > By test it I mean that we have to compare, line by line, the
> > output of the current input files to see if anything breaks.
> > There are also a set of known broken input files
> > (see src/input/Makefile.pamphlet) and we need to see if this
> > fixes any known problems there.
> 
> That should be pretty easy since we already save the output as
> .output files. I think we just need to cache the first version
> of these files somewhere and then delete them and re-run 'make'
> to create a new set. Then run a diff. I will do this later
> tonight with my current axiom--windows--1 build and let you
> know the result.

Ah. The easy part. But you missed the hard part. There are 
input files listed in src/input/Makefile.pamphlet that do not
currently get built. They have various errors which I have not
had time to track yet. If we are going to change the basic
algebra we need to check each of these files to either make
sure they are still broken in the same way or are fixed.

> I think it is *essential* that the build system CHECKS to see
> if there is a difference between the bootstrap files and the
> build files. 

This is reasonable. However the .lsp files contain gensym symbols
which are very sensitive to any changes. So the diff procedure
either needs to be written in lisp or needs a filter to ensure
that gensyms don't cause spurious "failure" reports.

> My conclusion is that the current build is already subtly broken
> and we probably do not want to release a february build *until*
> we fix this problem. 

Different is not the same as broken. Broken means the algebra
gives wrong answers. 

> > The february build will be the first "real axiom" version for
> > most people and it is important that it run properly.
> 
> I agree. That is the reason why I think it is quite urgent that
> we resolve the current problem first.

We disagree on this. There will always be bugs. There will always be
an urgency to fix them. Axiom, as it exists, has many known bugs.  The
previous release system I used would update Axiom with every fix. The
result of the mailing list discussion was that this was unacceptable
and needed a schedule. So far we have had "one release in a row on
schedule".  Unless the algebra is shown to be badly broken,
i.e. giving many NEW wrong answers and that the new BOOTSTRAP change
fixes them I feel we can release a version on February 1 without it.
It will certainly make the March 1 release.

So, basically, there's the bar.... show me "stop the press"
failures that the BOOTSTRAP changes will fix. Or any new failures.

Otherwise there are people waiting on the newly merged graphics and
hyperdoc. One person I'm working with offline is developing hyperdoc
pages for a linear algebra course and needs the working hyperdoc.

Tim