Re: [Axiom-developer] next release

[Waldek Hebisch]

> Challenge 2: LESS OBVIOUS CHANGES, such as eliding "member" from
>   the boot code. This change was made with no documentation added
>   to the source code making it impossible to (a) guess why and
>   (b) test. Furthermore, there are no test cases so even if I
>   understood it I'd have to develop the test cases again (assuming
>   you had them in the first place) from scratch.
>

That issue has been discussed on the mailing list: 

Shoe tranlates member to MEMBER and passes MEMBER unchanged
Boot tranlates MEMBER to |member| and passes member as |member|

(to check just look at generated Lisp).  MEMBER and |member| have
different semantics.  If you look at generated spad files you
may easily see that compiler which uses MEMBER (insted of |member|)
mistranslate many files.

> 
> 
> 
> Challenge 3: ALGEBRA CHANGES. these are clearly beneficial as
>   they address known bugs. Unfortunately I'm not an expert in ALL
>   of the algebra and I'm adverse to changing what I don't understand.
>   (Consider me the first in a long line of people maintaining this 
>    code over the next 30 years. If I can't understand it how will they?)
>   There was a change to the series code which went into Gold. Now we
>   find out that the "fix" was wrong and a new "fix" is proposed.

If somebody compared test results the problem would be recognized
immediately.  
 
>   I spoke with Clifton Williamson, the original author of the code, to
>   try to validate the original code vs the new fix, so far with no
>   decision. Do we want algebra bug fixes to lay around unmerged?
>   Do we want to change algebra we don't understand? If we understand
>   it do we want to share that information with future maintainers?
> 

I wrote an explanation.  And my conclusion is simple: original code
was correct, but did not handle some cases with negative powers.
After change those cases were handled correctly, but fix missed
the last line from original code.  I restored the this missing
line (which is needed _only_ when constant term is 0).


> > The axiom-commit mailing list has the history of all commits
> > to SVN -- when they are not truncated due to SF policy
> 
> The axiom-commit mailing list posts are essentially worthless as a
> Gold-merge resource. I can reclaim the same information in more detail
> by doing 
>    diff -r --brief build-improvements gold
> 
> What's missing is the (a) changesets (b) documentation (c) tests
>

Tim, at least in wh-sandbox I tried to have changeset == commit.  There
are some exceptions (merge from build improvements was split into
few commits, once or twice I made a mistake and next commit fixed this),
but essentially having commits you have changesets.
 
> The "changeset" mentality is that all of the changes necessary to
> produce a final single effect are packaged in a single set of patches.
> 
> Changesets are essential to contain all of a change and only a change.

If you want to make changes completly indepenent then I must say sorry.
I try to avoid unneded dependencies, but changes I do are all part
of larger effort to make Axiom better.  Each is self contained but
may depend on previous changes.  Note that identifying independent
sets is a nonlinear and essentially useless task -- we want _one_
good version, not a myriad of combiantions of various patches.


> In the current bi/wh branches even simple changes, such as eliding
> the C protoype code are spread over multiple commits and not fully
> implemented everywhere. The new asq requires new database formats
> and changes to the database generation code, all of which have to
> happen at the same time.
>

No.  New asq should work fine with old databases.  Old asq can not
work with compressed or pretty printed databases (note that 
database documentation claims that compression is optional and
says that hunks are just Lisp forms -- nothing forbiding
pretty printing).  So new asq just implements what is documented
(removes undocumented restrictions from old asq).  The new
asq is _required_ if you want to use asq with uncompressed
databases (or prett print them).
 

-- 
                              Waldek Hebisch
address@hidden