Re: [Axiom-developer] Axiom project goals

[Tim Daly]

> Bug tracker in book form? I don't think that's a good idea.

Because?

I can already see benefits.

Organizing bugs in book form makes it easier to search. The

chapter (e.g. hyperdoc), section (e.g. content, typo, wishlist),

and cross-reference (e.g. to the other books) make it easier

to find already-reported bugs.

The ability to intertwine words with the bugs means that what

appears to be a bug (e.g. lack of simplification) can be explained.

The ability to extract literate chunks means that the testing of

bugs can be automated. They can be extracted at build time,

added to the test suite, and run with the other test cases. Using

Axiom's --SRE testing markup, the "expected bad results" can

be tested against the actual results to highlight changed behavior.

So a bug that "succeeds", that is, one that still exists, can be

tested to see if the behavior has changed ("fixed").

Known bugs are just another volume in the series. They can

be cited and cross-referenced from the interpreter or the algebra.

So when an algorithm has a known bug but no-one can agree

on the "proper fix", the discussion can be cited. This will be

especially useful in the Computer Algebra Test Suite where

bug are mostly "limitations" (e.g. can't simplify nested sqrts).

Promoting bugs to book form also means that they get regular

review. They are not "someplace else", such as a bug tracker

on a website. Submitting a bug report is the same process as

submitting a patch.

I've always thought of bugs as something-but-not-code. I have

come to understand that all systems always have bugs. Why not

make bugs "first class", just like code?

On Fri, Aug 5, 2016 at 6:58 AM, oldk1331 <address@hidden> wrote:

Bug tracker in book form? I don't think that's a good idea.

On Fri, Aug 5, 2016 at 4:17 AM, Tim Daly <address@hidden> wrote:
> In the spirit of the game I'm moving the buglist to be a full
> literate volume, published like all the others. This will allow
> automation, extraction and testing of various bugs
> during build time and keep the bug list up to date and public.
>
> I'm also re-ordering it so that the various bugs/warnings/etc
> are grouped logically (e.g. interpreter, category, domain, etc)
> rather than the prior "stack by most recent" orientation. That
> will make it easier to find duplicates as well as simplify the
> focus of any debugging effort.
>
> This will be followed by a review of all outstanding bugs to
> see if they are still valid.
>
> There goes another few weeks.
>