On May 4, 8:26 am, Jaap Spies <j.sp...@hccnet.nl> wrote:
<SNIP>
> > Nope, it was commonly handled that way. But since the 'real' releases
> > are build more widely that either alpha or rc releases I have been
> > changing this to even run some test suites even then. This has already
> > flushed out various bugs in MPIR and in the past also FLINT. This
> > might seem like a waste of time to some people, but compared to
> > running Sage's test suite it seems like a low price to pay.
>
> Agreed, but how often did you get feedback from failures in the FLINT
> library from users of the 'real' releases in the field?
At least once, but these days I tend to catch the majority of build
and testing issues in FLINT before it makes it even into a Sage
release. But with more exotic CPUs, i.e MIPS, Sparc and Itanium it
isn't very hard to catch a miscompilation of FLINT depending on the
gcc release used and I much rather catch those in the test suite than
some incredibly odd segfaults in Sage's test suite. FLINT is also the
first test to determine if MPIR/GMP use truly working inline semantics
since that is not caught in either the MPIR or GMP test suites and
that cannot be determined by just building FLINT, the test suite
shakes that problem out if it exists by linking bits from FLINT. And
that is something that can easily break on OSX 10.4 for example (and
indeed, FLINT caught this in the past :))
At least on Linux on x86 and x86-64 it is admittedly not very useful
to run the test suite in the vast majority of the cases since it is so
well tested already, but there is no obvious heuristic to determine
when it is worth testing and when it isn't because if we knew we would
have already fixed the problem. And once you assume that it will not
break you will run out of luck and get hit by a bug ;)
> > You wouldn't consider running the test suite a waste of time either I
> > assume. If someone really wants to we can introduce a special
> > SAGE_CHECK_OVEWRITE flag that completely turns off all checks if
> > anyone does thing this is really desirable, but I am hesitant to do
> > so. Testing makes software better and way too often has a point
> > upgrade that was supposedly safe introduced problems, so I am always
> > in favor of testing.
>
> +1 for the last sentence.
>
> On relative slow hardware it looks like a good idea to make
> installation of ATLAS and e.g. FLINT less time consuming.
Well, for ATLAS we don't even run the test suite, so what you see at
the moment is as close to optimum as it gets. You can reuse a
previously build ATLAS (assuming we didn't upgrade).
> Jaap
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
