[Top][All Lists]

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

[Axiom-developer] RE: proposed fixes

From: Martin Rubey
Subject: [Axiom-developer] RE: proposed fixes
Date: Tue, 12 Jul 2005 13:24:48 +0200

Dear Bikk, Tim, Camm, *,

Page, Bill writes:
 > > Bill: could you transfer the remaining open bugs from savannah,
 > > especially #9298...
 > Ok. Do you know if any other reports form Savannah are missing?

Well, you can easily find out yourself, since you tagged those which are
already transferred with a "transferred" tag on savannah...

I don't really know which of those are duplicates. However, it is no problem in
IssueTracker to mark them as duplicate. I'd propose that you transfer all of
them, and with time I mark those as duplicate that are. (Usually this happens
when I try to debug one)

 > > Camm: when Bill has done this, could you please upload your
 > > (temporary) fix for the bug in new!
 > Is that an Axiom patch or a GCL patch? If it is GCL then it
 > might already be in the version of GCL that we use to build
 > Axiom.

It was an axiom patch. And as far as I remember, even Manuel Bronstein was
d'accord. There was only some minor non-issue, which wouldn't introduce any
bugs anyway.

 > > -------------------------------------------------------------------
 > >
 > > I must say that I'm a bit unhappy about the bug fixing - pro{c,gr}ess.

 > The bottleneck in getting proposed fixes into Axiom is just that no besides
 > Tim Daly is actually posting any changes to the Axiom source archives. Tim
 > has a million other things to do in this project beside test patches and
 > commit changes to the archive, so these get done when he manages to steal
 > time from something else that he would rather be doing. (We all have lives
 > besides Axiom, I guess ... but we tend to forget that of others. :)

Very true.

 > So the best solution of this problem is if someone (or more people) besides
 > Tim would start to actively contribute changes directly to one of the source
 > archives.

OK, send me a password and some instructions and I'll do it. I'd follow the
following lines:

  When a proposed fix remains (in principle) unmodified for at least one month
  on IssueTracker, I'll ask on axiom-developer and axiom-math whether anybody
  is against applying this fix.

  If this is not the case, I'll try to organize the documentation and patch the
  pamphlet file.

(Un)fortunately, I don't have the skills for patching Makefiles, or .boot
files, so I think I'll stay with the .spad files only.

What I'd need are instructions (and passwords) how I can apply a patch in the
archive. And the OK from Tim.

 > > We simply don't have the (wo)manpower to do everything the
 > > "right" way immediately.
 > I certainly agree with that!
 > > I'm absolutely certain that a bad fix is better than no fix.
 > We definitely have different opinions about this. I think that usually a
 > "bad fix" is much worse than "no fix". As long as we clearly document what
 > the problem is, then most users can compensate for such "known
 > problems". The existence of these known problems is what motivates proper
 > solutions. If one accepts temporary "bad" solutions, these very often become
 > permanent since we have no extra resources to correct things that are now
 > "more or less ..." working.

I think this depends on the documentation: A documented "bad" fix does not
create any problems. If it is marked as "bad fix", I doubt that it will attract
*less* attention than something that doesn't work at all.

 > Of course there is a limit to how many such problems one can live with.

 > > -----------------------------------------------------------
 > >
 > > Bounties:
 > >
 > > I'd like to propose two bounties:
 > >
 > > * a bounty for somebody who implements a fast rational
 > >   interpolation algorithm
 > Sounds like a good one to me.
 > > * a bounty for somebody who implements an interpreter for
 > >   aldor in lisp.
 > Say what?! Isn't that exactly what Axiom's interpreter is right now? What do
 > you mean?
 > Aldor used to be Axiom's prefer library compiler. I don't see any reason why
 > this cant be again. Only a few technical problems remain for it's
 > re-integration in to the new open source version of Axiom.

In fact, most of the technicalities have been adressed (by Peter, I think),
however, they have only been applied partially. This is the content of Issue

What is completely open however is the following: 

First, the Aldor compiler is not free. Thus, I think it would be good to have a
free replacement, and it is obvious to me that this should be done in lisp.

Second, Aldor and Spad differ slightly, for example, Aldor allows more
flexibility with dependend types than Spad. The interpreter in Axiom is not yet
prepared to handle this. I think it will be easier to integrate a free Lisp
Aldor interpreter than a non-free C Aldor interpreter.

Finally, note that Aldor is a well defined language. There is not much room for
changes. I expect, that Aldor won't change at all in the next few years (apart
from bugs that get fixed). Thus it is *possible* to write a replacement.

 > > If you reply before tommorow afternoon (european time), I could formulate
 > > these bounties and send them to comp.lang.lisp and sci.math.
 > I think that is a good idea.
 > > I'd give only symbolic prices, i.e., 200$ each.
 > Sounds good to me. The Axiom Foundation is very poor financially speaking
 > and could afford much more than that anyway.

Bill, you were the only one who replied. Since the Aldor bounty is not enough
thought-through, I think I concentrate on the rational-interpolation bounty. Do
I have to wait for permission from the other axiom-foundation members?

 > ---------------------------------------------------------------
 > > I'm off for two weeks of holidays saturday, so: no email,
 > > no axiom.
 > Ah, a life beside Axiom ... :) How's your (new) family coming
 > along?

Great. I wish I had more time for both Family and Axiom and Maths...

 > Have a great vacation.

Thanks, it was great indeed.


reply via email to

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