Final 3.4.2 sources released

[mabshoff]

Hello folks,

the final release for 3.4.2 is done and sources, the upgrade bits and
a sage.math binary are in the usual place at

http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/

I was cocky and labeled the release 3.4.2 instead of 3.4.2.final since
I am pretty confident we won't need another 3.4.2 release. The final
release contains more changes than I wanted, but I feel that all of
the changes have been well tested and should not cause any trouble
(famous last words). Should a show stopper bug pop up we could do a
really small 3.4.3, but I hope this won't be needed.

I am already building my 4.0.alpha0 merge tree and the time to get
everything done as planned is definitely tight. Alpha0 should drop
fairly quickly since there is plenty of material in trac ready to go
in, i.e. unless something goes wrong in the next 24 hours.

Please build, test and report issues as usual.

Cheers,

Michael

Merged in Sage 3.4.2.final:

#5951: John Palmieri: fix a few minor issues with the reference manual
in 3.4.2.rc0 [Reviewed by Michael Abshoff]
#5953: Michael Abshoff, John Palmieri: sage/modular/modform/
vm_basis.py is missing verbatim areas for doctests [Reviewed by Minh
Van Nguyen]
#5955: Michael Abshoff: Sage 3.4.2.rc0: Set stacksize during
clisp.spkg build to 32kb [Reviewed by David Roe]
#5957: Michael Abshoff: 3.4.2.rc0: Maxima related doctest failure in
matrix/matrix_symbolic_dense.pyx [Reviewed by Michael Abshoff]
#5963: Michael Abshoff: 3.4.2.a0: prime_pi returns wrong results on
some platforms for large input [Reviewed by David Roe]
#5966: Michael Abshoff: sage/sets/primes.py: change doctest so that we
check for Primes being != to x^2+x [Reviewed by David Roe]
#5972: William Stein: segfault in degenerate matrix multiply [Reviewed
by Michael Abshoff]
#5973: Michael Abshoff: Fix spkg-check target for FLINT on OSX 64 bit
[Reviewed by William Stein]

[mabshoff]

On May 4, 5:53 am, mabshoff <mabsh...@googlemail.com> wrote:
> Hello folks,

<SNIP>

> #5957: Michael Abshoff: 3.4.2.rc0: Maxima related doctest failure in
> matrix/matrix_symbolic_dense.pyx [Reviewed by Michael Abshoff]

Oops, author credit here goes to William. I uploaded the patch, so
that caused the confusion. Sorry :(

Cheers,

Michael

[Jaap Spies]

mabshoff wrote:
> Hello folks,
>
> the final release for 3.4.2 is done and sources, the upgrade bits and
> a sage.math binary are in the usual place at
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
>
> I was cocky and labeled the release 3.4.2 instead of 3.4.2.final since
> I am pretty confident we won't need another 3.4.2 release.

Except setting testing in FLINT off!

Jaap

[mabshoff]

Well, I knew FLINT still ran its test suite and given we updated MPIR
I do prefer for it to run. There was also no 3.4.2 ticket to turn it
off :p.

In Sage 4.0 I will hopefully have a more flexible system for testing
so that people who don't want to run the "mandated" testing can turn
it off more easily.

Originally FLINT 1.2.5 was supposed to go into 3.4.2, but while
testing it I saw a doctest failure in some cohomology code and I did
not feel like tracking this down since the main change in FLINT 1.2.5
was the update to zn_poly 0.9 (which contained a fix that was supposed
to resolve the problem completely). The issue that popped up might
also be a padics problem since 2/3 of the doctest failure has been
resolved by the new zn_poly, I guess we might find out in Sage 4.0 or
4.0.x. ;)

> Jaap

Cheers,

Michael

[William Stein]

On Mon, May 4, 2009 at 7:36 AM, mabshoff <mabs...@googlemail.com> wrote:
>
>
>
> On May 4, 7:30 am, Jaap Spies <j.sp...@hccnet.nl> wrote:
>> mabshoff wrote:
>> > Hello folks,
>>
>> > the final release for 3.4.2 is done and sources, the upgrade bits and
>> > a sage.math binary are in the usual place at
>>
>> >  http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
>>
>> > I was cocky and labeled the release 3.4.2 instead of 3.4.2.final since
>> > I am pretty confident we won't need another 3.4.2 release.
>>
>> Except setting testing in FLINT off!
>
> Well, I knew FLINT still ran its test suite and given we updated MPIR
> I do prefer for it to run. There was also no 3.4.2 ticket to turn it
> off :p.

It takes like 2-3 hours to run on some of my build machines, nearly
doubling the time of building Sage from source.

> In Sage 4.0 I will hopefully have a more flexible system for testing
> so that people who don't want to run the "mandated" testing can turn
> it off more easily.

What's wrong with the current SAGE_CHECK (or whatever) system where
spkg-check is run only if a certain environment variable is set?

>
> Originally FLINT 1.2.5 was supposed to go into 3.4.2, but while
> testing it I saw a doctest failure in some cohomology code and I did
> not feel like tracking this down since the main change in FLINT 1.2.5
> was the update to zn_poly 0.9 (which contained a fix that was supposed
> to resolve the problem completely). The issue that popped up might
> also be a padics problem since 2/3 of the doctest failure has been
> resolved by the new zn_poly, I guess we might find out in Sage 4.0 or
> 4.0.x. ;)
>

Good.

[mabshoff]

On May 4, 7:40 am, William Stein <wst...@gmail.com> wrote:

> On Mon, May 4, 2009 at 7:36 AM, mabshoff <mabsh...@googlemail.com> wrote:
>
> > On May 4, 7:30 am, Jaap Spies <j.sp...@hccnet.nl> wrote:
> >> mabshoff wrote:
> >> > Hello folks,
>
> >> > the final release for 3.4.2 is done and sources, the upgrade bits and
> >> > a sage.math binary are in the usual place at
>
> >> >  http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
>
> >> > I was cocky and labeled the release 3.4.2 instead of 3.4.2.final since
> >> > I am pretty confident we won't need another 3.4.2 release.
>
> >> Except setting testing in FLINT off!
>
> > Well, I knew FLINT still ran its test suite and given we updated MPIR
> > I do prefer for it to run. There was also no 3.4.2 ticket to turn it
> > off :p.
>
> It takes like 2-3 hours to run on some of my build machines, nearly
> doubling the time of building Sage from source.

I seriously doubt that. On sage.math the tests run in roughly 10
minutes. Since building FLINT is more or less instant you should show
me the build log, but then the total build time is not going to be in
the 4 to 6 hour range. Running the FLINT test suite flushes out bugs
and I am running it on Solaris/Sparc where this is quite painful and
from experience I would claim that the build on Sparc takes even
longer than on Atom for example.

> > In Sage 4.0 I will hopefully have a more flexible system for testing
> > so that people who don't want to run the "mandated" testing can turn
> > it off more easily.
>
> What's wrong with the current SAGE_CHECK (or whatever) system where
> spkg-check is run only if a certain environment variable is set?

That system is all or nothing and since for example R's spkg-check
fails on every platform I do not use it. Something that white- or
blacklists individual spkgs via a control file seems a much saner
mechanism to me.

> > Originally FLINT 1.2.5 was supposed to go into 3.4.2, but while
> > testing it I saw a doctest failure in some cohomology code and I did
> > not feel like tracking this down since the main change in FLINT 1.2.5
> > was the update to zn_poly 0.9 (which contained a fix that was supposed
> > to resolve the problem completely). The issue that popped up might
> > also be a padics problem since 2/3 of the doctest failure has been
> > resolved by the new zn_poly, I guess we might find out in Sage 4.0 or
> > 4.0.x. ;)
>
> Good.

I did list the failure in the FLINT 1.2.5 update ticket if anyone
wants to take a look.

Cheers,

Michael

[Jaap Spies]

mabshoff wrote:
>
>
> On May 4, 7:30 am, Jaap Spies <j.sp...@hccnet.nl> wrote:
>> mabshoff wrote:
>>> Hello folks,
>>> the final release for 3.4.2 is done and sources, the upgrade bits and
>>> a sage.math binary are in the usual place at
>>> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
>>> I was cocky and labeled the release 3.4.2 instead of 3.4.2.final since
>>> I am pretty confident we won't need another 3.4.2 release.
>> Except setting testing in FLINT off!
>
> Well, I knew FLINT still ran its test suite and given we updated MPIR
> I do prefer for it to run. There was also no 3.4.2 ticket to turn it
> off :p.
>

This testing feels ok for alpha and rc releases, but not on a final
source release. IIRC this was standard procedure.

Jaap

[mabshoff]

On May 4, 7:57 am, Jaap Spies <j.sp...@hccnet.nl> wrote:
> mabshoff wrote:

<SNIP>

> > Well, I knew FLINT still ran its test suite and given we updated MPIR
> > I do prefer for it to run. There was also no 3.4.2 ticket to turn it
> > off :p.
>
> This testing feels ok for alpha and rc releases, but not on a final
> source release. IIRC this was standard procedure.

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.

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.

> Jaap

Cheers,

Michael

[William Stein]

On Mon, May 4, 2009 at 7:52 AM, mabshoff <mabs...@googlemail.com> wrote:
>
>
>
> On May 4, 7:40 am, William Stein <wst...@gmail.com> wrote:
>> On Mon, May 4, 2009 at 7:36 AM, mabshoff <mabsh...@googlemail.com> wrote:
>>
>> > On May 4, 7:30 am, Jaap Spies <j.sp...@hccnet.nl> wrote:
>> >> mabshoff wrote:
>> >> > Hello folks,
>>
>> >> > the final release for 3.4.2 is done and sources, the upgrade bits and
>> >> > a sage.math binary are in the usual place at
>>
>> >> >  http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
>>
>> >> > I was cocky and labeled the release 3.4.2 instead of 3.4.2.final since
>> >> > I am pretty confident we won't need another 3.4.2 release.
>>
>> >> Except setting testing in FLINT off!
>>
>> > Well, I knew FLINT still ran its test suite and given we updated MPIR
>> > I do prefer for it to run. There was also no 3.4.2 ticket to turn it
>> > off :p.
>>
>> It takes like 2-3 hours to run on some of my build machines, nearly
>> doubling the time of building Sage from source.


>
> I seriously doubt that. On sage.math the tests run in roughly 10
> minutes. Since building FLINT is more or less instant you should show

You're right, it's just over an hour on ATOM:

real 62m23.286s
user 57m57.825s
sys 3m24.089s
Successfully installed flint-1.2.4.p1
Now cleaning up tmp files.
Making Sage/Python scripts reloc

> me the build log, but then the total build time is not going to be in
> the 4 to 6 hour range. Running the FLINT test suite flushes out bugs
> and I am running it on Solaris/Sparc where this is quite painful and
> from experience I would claim that the build on Sparc takes even
> longer than on Atom for example.
>
>> > In Sage 4.0 I will hopefully have a more flexible system for testing
>> > so that people who don't want to run the "mandated" testing can turn
>> > it off more easily.
>>
>> What's wrong with the current SAGE_CHECK (or whatever) system where
>> spkg-check is run only if a certain environment variable is set?
>
> That system is all or nothing and since for example R's spkg-check
> fails on every platform I do not use it. Something that white- or
> blacklists individual spkgs via a control file seems a much saner
> mechanism to me.

You're right. Just like with "make test", we should change the
spkg-check system to simply report the results at the end, instead of
stopping if anything isn't perfect.

>
>> > Originally FLINT 1.2.5 was supposed to go into 3.4.2, but while
>> > testing it I saw a doctest failure in some cohomology code and I did
>> > not feel like tracking this down since the main change in FLINT 1.2.5
>> > was the update to zn_poly 0.9 (which contained a fix that was supposed
>> > to resolve the problem completely). The issue that popped up might
>> > also be a padics problem since 2/3 of the doctest failure has been
>> > resolved by the new zn_poly, I guess we might find out in Sage 4.0 or
>> > 4.0.x. ;)
>>
>> Good.
>
> I did list the failure in the FLINT 1.2.5 update ticket if anyone
> wants to take a look.
>
> Cheers,
>
> Michael
> >
>

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

[Jaap Spies]

mabshoff wrote:
>
>
> On May 4, 7:57 am, Jaap Spies <j.sp...@hccnet.nl> wrote:
>> mabshoff wrote:
>
> <SNIP>
>
>>> Well, I knew FLINT still ran its test suite and given we updated MPIR
>>> I do prefer for it to run. There was also no 3.4.2 ticket to turn it
>>> off :p.
>> This testing feels ok for alpha and rc releases, but not on a final
>> source release. IIRC this was standard procedure.
>
> 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?

> 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.

Jaap

[mabshoff]

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

[Jaap Spies]

mabshoff wrote:
> Hello folks,
>
> the final release for 3.4.2 is done and sources, the upgrade bits and
> a sage.math binary are in the usual place at
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
>
> I was cocky and labeled the release 3.4.2 instead of 3.4.2.final since
> I am pretty confident we won't need another 3.4.2 release. The final
> release contains more changes than I wanted, but I feel that all of
> the changes have been well tested and should not cause any trouble
> (famous last words). Should a show stopper bug pop up we could do a
> really small 3.4.3, but I hope this won't be needed.
>
> I am already building my 4.0.alpha0 merge tree and the time to get
> everything done as planned is definitely tight. Alpha0 should drop
> fairly quickly since there is plenty of material in trac ready to go
> in, i.e. unless something goes wrong in the next 24 hours.
>
> Please build, test and report issues as usual.
>

On Fedora 9, 32 bit upgraded from alpha0 -> rc0-> sage-3.4.2
and on Fedora 10, 32 bit upgraded from rc0 I get tons
of failures with prime_pi, e.g.:

sage -t "devel/sage/sage/functions/prime_pi.pyx"
**********************************************************************
File "/home/jaap/Download/sage-3.4.2.rc0/devel/sage/sage/functions/prime_pi.pyx", line 74:
sage: prime_pi(7)
Exception raised:
Traceback (most recent call last):
File "/home/jaap/Download/sage-3.4.2.rc0/local/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/home/jaap/Download/sage-3.4.2.rc0/local/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/home/jaap/Download/sage-3.4.2.rc0/local/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_3[2]>", line 1, in <module>
prime_pi(Integer(7))###line 74:
sage: prime_pi(7)
File "prime_pi.pyx", line 175, in sage.functions.prime_pi.PrimePi.__call__ (sage/functions/prime_pi.c:1101)
NotImplementedError: computation of prime_pi() greater 2**40 not implemented
**********************************************************************
File "/home/jaap/Download/sage-3.4.2.rc0/devel/sage/sage/functions/prime_pi.pyx", line 76:
sage: prime_pi(100)
Exception raised:

Jaap

[mabshoff]

On May 4, 9:07 am, Jaap Spies <j.sp...@hccnet.nl> wrote:
> mabshoff wrote:
> > Hello folks,

<SNIP>

Arrg, this is cause by Integer(2**40) on 32 bit systems being "0" in
Cython. I didn't use any long representation of 2^40 to avoid running
into 32 vs. 64 bit issues. Oh well, please open a ticket, I guess
there will be another "final" 3.4.2 tarball :(

> Jaap

Cheers,

Michael

[mabshoff]

On May 4, 9:33 am, mabshoff <mabsh...@googlemail.com> wrote:
> On May 4, 9:07 am, Jaap Spies <j.sp...@hccnet.nl> wrote:

<SNIP>

> Arrg, this is cause by Integer(2**40) on 32 bit systems being "0" in
> Cython. I didn't use any long representation of 2^40 to avoid running
> into 32 vs. 64 bit issues. Oh well, please open a ticket, I guess
> there will be another "final" 3.4.2 tarball :(

This is now #5981 with a proto patch attached. With it prime_pi.pyx
passes doctests on a 32 bit box for me.

Cheers,

Michael

[Jaap Spies]

I'm ready to give this patch a positive review :)

./sage -t "devel/sage/sage/functions/prime_pi.pyx"
sage -t "devel/sage/sage/functions/prime_pi.pyx"
[48.1 s]

----------------------------------------------------------------------
All tests passed!
Total time for all tests: 48.1 seconds

Jaap

[mabshoff]

On May 4, 10:03 am, Jaap Spies <j.sp...@hccnet.nl> wrote:
> mabshoff wrote:

<SNIP>

As mentioned on #5980 I checked if you had opened the ticket already
before I opened #5981, but you did open it parallel to my ticket - so
great minds think alike I guess ;)

> > This is now #5981 with a proto patch attached. With it prime_pi.pyx
> > passes doctests on a 32 bit box for me.
>
> I'm ready to give this patch a positive review :)
>
>   ./sage -t  "devel/sage/sage/functions/prime_pi.pyx"
> sage -t  "devel/sage/sage/functions/prime_pi.pyx"
>          [48.1 s]
>
> ----------------------------------------------------------------------
> All tests passed!
> Total time for all tests: 48.1 seconds
>
> Jaap

Good. I tested on 32 and 64 bit and it works for me, too. The patch is
formally up and the ticket is also open against 3.4.2, so feel free to
review. I will wait for all my other build tests to finish doctesting
before pushing out the new tarball (just in case something else pops
up).

Cheers,

Michael

[Jaap Spies]

mabshoff wrote:
>
>
> On May 4, 10:03 am, Jaap Spies <j.sp...@hccnet.nl> wrote:
>> mabshoff wrote:
>
> <SNIP>
>
> As mentioned on #5980 I checked if you had opened the ticket already
> before I opened #5981, but you did open it parallel to my ticket - so
> great minds think alike I guess ;)
>

:)

[...]

>
> Good. I tested on 32 and 64 bit and it works for me, too. The patch is
> formally up and the ticket is also open against 3.4.2, so feel free to
> review. I will wait for all my other build tests to finish doctesting
> before pushing out the new tarball (just in case something else pops
> up).
>

Done. I'll rerun all the tests too.


Jaap


> Cheers,
>
> Michael
> >
>

[John Cremona]

On Bill Hart's machine (64-bit ubuntu) I build ok but get a failure here:
sage -t "devel/sage/sage/interfaces/sage0.py"
which is random, i.e. rerunning it usually works fine. But not always.

Two other builds on slower / heavily loaded machines still building...

John

2009/5/4 Jaap Spies <j.s...@hccnet.nl>:

[mabshoff]

On May 4, 11:30 am, John Cremona <john.crem...@gmail.com> wrote:

Hi John,

> On Bill Hart's machine (64-bit ubuntu) I build ok but get a failure here:
>         sage -t  "devel/sage/sage/interfaces/sage0.py"
> which is random, i.e. rerunning it usually works fine.  But not always.
>
> Two other builds on slower / heavily loaded machines still building...
>
> John

For the record: The 32 bit prime_pi() issue causes doctest failure in

sage -t -long "devel/sage/sage/numerical/optimize.py"
sage -t -long "devel/sage/sage/tests/book_stein_ent.py"
sage -t -long "devel/sage/sage/combinat/sloane_functions.py"
sage -t -long "devel/sage/sage/functions/transcendental.py"
sage -t -long "devel/sage/sage/functions/prime_pi.pyx"

so applying #5981 before reporting any failures might be a good idea.

Cheers,

Michael

[Jaap Spies]

mabshoff wrote:
>
>

>
> Good. I tested on 32 and 64 bit and it works for me, too. The patch is
> formally up and the ticket is also open against 3.4.2, so feel free to
> review. I will wait for all my other build tests to finish doctesting
> before pushing out the new tarball (just in case something else pops
> up).
>

As a follow up: on Fedora 9 and Fedora 10, 32 bit all tests passed
after applying the patch.

Jaap

[John Cremona]

2009/5/4 mabshoff <mabs...@googlemail.com>:

OK on ubuntu 32-bit after applying the patch.

The odd failure on Bill's 64-bit machines was something else...

John

>
> Cheers,
>
> Michael
> >
>

[Justin C. Walker]

On May 4, 2009, at 05:53 , mabshoff wrote:

>
> Hello folks,
>
> the final release for 3.4.2 is done and sources, the upgrade bits and
> a sage.math binary are in the usual place at
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/

Built on Mac OS X, 10.5.6 (Dual Quad Xeon) with no problems.

Before patch #5981, I got these failures:

sage -t "devel/sage/sage/combinat/sloane_functions.py"
sage -t "devel/sage/sage/functions/prime_pi.pyx"
sage -t "devel/sage/sage/functions/transcendental.py"
sage -t "devel/sage/sage/numerical/optimize.py"
sage -t "devel/sage/sage/tests/book_stein_ent.py"

After applying the patch, I reran all the tests, and all passed.

Justin

--
Justin C. Walker, Curmudgeon at Large
Director
Institute for the Enhancement of the Director's Income
-----------
Nobody knows the trouble I've been
-----------

[Pablo De Napoli]

>>
>> 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

For this reason I would love to be able to be able to make a selective upgrade
and say something like "upgrade everything except for ATLAS this time"
(for example, assume that the last ATLAS has some fixes that are only
for another
architecture...

Pablo