axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] fixes and patches


From: Waldek Hebisch
Subject: [Axiom-developer] fixes and patches
Date: Tue, 27 Feb 2007 02:05:07 +0100 (CET)

> > Anyway, patch follows (note that this patch will probably do
> > no good without other pathname changes from wh-sandbox
> 
> Here is where my problem arises. When trying to build a system that
> many people will use, such as Gold, it is important that I don't
> introduce more, or more subtle, errors than I fix. I'm very reluctant
> to change what I don't understand since, in the long run I and others
> may need to maintain it.
> 
> In order to apply your changes I will need to evaluate every other
> change you've made to decide if it is related or a prerequisite change.
> It can take a day or more to difference your source tree from Gold and
> do this evaluation since there is no documentation in the source files
> explaining why the change was made. And it is not clear if these changes
> depend on other parts of your sandbox, such as Gaby's build system.
> 
> This change is a worthwhile idea and should be brought forward to Gold.
> It would be most helpful, and Gold would happen a lot faster, if you 
> could take the time to make a diff-Naur Gold patch containing the
> complete changeset.
>

I am trying to help, but sorry ATM I am very busy.  The list I posted
contains all changes that I consider to be user visible changes.  I belive
they are mostly independent of other patches.  Patches to .spad files
should apply to Gold with no (or little) changes.  Most algebra patches
reference bug numbers in Issue tracker.  Having Issue tracker number
you can find a testcase and frequently disscusion. Some fixes are
taken from Issue tracker.  Many algebra fixes show in test result
(the script I posted helps to automate comparison).  In particular
bug 312 is prominently visible (IIRC in series2.output) -- just
compare test results.

IIRC one fix to .spad files depends on changes to file handling
in interpreter (this should be obvious since those changes form
a single changeset == form single patch).  I think that changes
to interpreter files are independent of build system. One change
affecting Hyperdoc, that is installation on libdb etc, changes
Makefiles -- IIRC I have posted a version of this patch which
applies to Gold.  One change to Hyperdoc (extra change in protocol)
must be done both to Hyperdoc and to interpreter (otherwise
things will break), I belive that other Hyperdoc changes can be
applied independently (but some fixes concern Hyperdoc crashes,
so if you take incomplete set of fixes crash may eliminate 
possibility to see improvement due to other fixes).

I do not have time to make (and test) diffs to Gold.  But even
if I had time I do not know if making such diffs would be a
good idea: IIUC your devlopement version is different from
published one and you apply diffs manually.  Most of the time
different between Gold and wh-sandbox is trivial and will
cause no trouble.  The only trouble points are likely to
be due to removal of duplicate code in wh-sandbox and improvements
to build machinery.  But those to changes are made precisely
to avoid doing extra work.  Gaby spent time cleaning build
system, I spent time identifying duplicate/unused code (I do
_not_ remove code lightly).  Now you want us to spent time
working with issues that our work eliminated?

Note, if you want changes to wh-sandbox as separate patches
I can provide this (but I think you already have them from
the commit mailing list).  Also, if you have specific questions
concering patches I will try to answer.

-- 
                              Waldek Hebisch
address@hidden 




reply via email to

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