[Top][All Lists]

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

RE: [Axiom-developer] Minor bugs

From: Bill Page
Subject: RE: [Axiom-developer] Minor bugs
Date: Sun, 19 Dec 2004 12:48:26 -0500


I have been plugging away trying to apply some of the
outstanding patches recorded on Savannah to my local
copy of axiom--main--1. After a few miss-steps I think
I now almost understand the procedure that you sketched
below. But I am still confused about how to do the
regression testing part. Is this described somewhere?

As I understand it the idea is to maintain a set of hand
verified result files (*.output) and to compare the output
of selected (*.input) files to their corresponding (*.output)
file. If the comparison fails then a error is raised. (How?
Where?) How does this relate to the "Daly bug" hack that
you have also described.

Anyway, I am looking for a quick recipe and an example.

So far this what I have done is:

1) Applied the negative float rounding/truncation patch from
Savannah to the floats.spad.pamphlet file.

2) Created a simple input file called
   in the src/input directory that executes some Axiom
   commands illustrating the bugs

3) Modified the file src/input/Makefile.pamphlet to
   include the following new subsection and stanzas

${OUT}/negfloats.input: ${MID}/negfloats.input
        @ echo 426 making ${OUT}/negfloats.input from ${MID}/negfloats.input
        @ cp ${MID}/negfloats.input ${OUT}/ngefloats.input

${MID}/negfloats.input: ${IN}/negfloats.input.pamphlet
        @ echo 427 making ${MID}/negfloats.input from
        @(cd ${MID} ; \
          ${TANGLE} ${IN}/negfloats.input.pamphlet >negfloats.input )

4) Made a new entry for negfloats in

FILES= ${OUT}/algaggr.input  ${OUT}/algbrbf.input    ${OUT}/algfacob.input \
       ${OUT}/ndftip.input   ${OUT}/newlodo.input \
       ${OUT}/negfloats.input \

5) Added a reference to <<negfloats>> in <<*>>=


6) Did axiom 'make' to compile the revised floats domain and
   (hopefully) run the negfloats.input test file.

   (set AXIOM and PATH manually ... yuck :)


Now what about checking the results of negfloats.input?
Where do I look? Provided I like the output, how do I make
it part of the regression suite? How can I easily tell if the
new .input file "passes"?

If you could spend a bit of time completing and correcting this
recipe for me, I will put it on a web page somewhere for easy

BTW, all of this stuff seems so excrutiatingly low-level to
me and SO EASY to break one way or another

 <b>like most of the Axiom build process --  !!</b>

<sigh />

I am becoming used to the idea of automated tools that make
this "messing around with picky details" less unnecessary.
Documentation is of course is still important but when it is
at such a low level and burdened with many details, just the
"on ramp" to the learning curve becomes very high even if the
process itself is quite simple.

I find I spend an enormous amount of time just correctly
stupid simple silly mistakes like the use of a space some
place in a Makefile rather than a tab. Using "stupid tools"
always makes me feel stupid...

Since a lot of the "pickiness" is just in the use of the
noweb/pamphlet low-level literature programming stuff, we
could for example (if we had infinite time and resources :),
invest in a more high-level literate programming tool such
as Leo.

  The highlights of Leo 4.2: 
  - @thin trees make Leo much more friendly to cvs. 
  - Leo's data structures have been reorganized to make outline
    operations significantly faster. All old scripts still work. 
  - @test and @script nodes convert scripts to unit tests
    automatically. You can convert scripts to unit tests in
  - A faster and more robust spell checker plugin. (requires
    Python 2.3) 
  - Leo is now much more friendly to using spaces instead of
  - The Execute Script command reports erroneous lines more
  - Leo draws large outlines more quickly using less memory. 
  - Dozens of other improvements. 

Leo provides some very nice project outlining tools including
folding etc., that can considerably reduce the apparent
complexity. And it serves (more or less) like an integrated
development environment for literate programming.

At the very least I think we need to spend more time
structuring the whole build process in a simpler way (i.e.
make more use of the advanced features of gnu make). I think
the whole thing from start to finish could be MUCH simpler
and the Makefiles much smaller. But then, what we have now
works (at least for those who designed it ... :) so of course
the incentive is not so great to change it. Still it seems
to me to be a significant barrier to greater participation
by other developers.


Bill Page.


Here is my new negfloats.input.pamphlet file:

\title{\$SPAD/src/input float.input}
\author{The Axiom Team}
--Copyright The Numerical Algorithms Group Limited 1991.

-- check results of rounding, truncation etc. on negative floats
)cl all
\bibitem{1} nothing

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> .org] On Behalf Of root
> Sent: Wednesday, December 15, 2004 2:31 PM
> To: address@hidden
> Cc: address@hidden; address@hidden
> Subject: Re: [Axiom-developer] Minor bugs
> Bill,
> First make a .input file that contains these test cases
> and add it to the src/input subdir and Makefile.pamhlet.
> Yes, please apply them to axiom--main and axiom--windows.
> After applying the patches we need to do a complete rebuild
> from the tla sources (be sure you download them fresh from
> the archive as I've been burned in the past by assuming that
> my copy was clean).
> Let me know 
>  (a) when the patches are applied (i'll also test them here)
>  (b) when the rebuilds are cleanly compiled and the .input
>      passes
> at which point we can tag the axiom--main build and push it
> to savannah.
> t

reply via email to

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