New PARI needs testing
Jeroen Demeyer
As far as we know, there are no more remaining issues for the PARI
update (#9343). We haven't had any doctest failures for a while now.
The main issues recently have been with PARI not compiling properly on
various machines, but all those seem to be fixed now.
I have made a complete Sage distribution sage-4.6.prealpha4, based on
sage-4.5.3.rc0 with the new PARI and some more updates. You can
download it from
http://sage.math.washington.edu/home/jdemeyer/dist/sage-4.6.prealpha4.tar
In order to test this thoroughly, extract the tarball and then:
cd sage-4.6.prealpha4
make
env SAGE_CHECK=yes SAGE_TUNE_pari=yes ./sage -f
pari-2.4.3.svn-12577.p5.spkg
make ptestlong
On sage.math.washington.edu, this worked without problems (apart from a
sometimes-reproducible error in devel/sage/sage/tests/startup.py)
The following tickets have been merged in sage-4.6.prealpha4 (w.r.t.
sage-4.5.3.rc0):
#9343: PARI upgrade
#9860: Port changes in PARI 2.3.5.p4 (#9722) to current 2.4.3
#9591: Upgrade genus2reduction due to Pari upgrade to svn snapshot 12577
- a pre-release of Pari 2.4.3
#9592: Upgrade lcalc to work with Pari svn snapshot 12577 - a
pre-release of Pari 2.4.3
#9845: lcalc doesn't build on cygwin due to missing time.h include
#9750: Document that PARI no longer assumes more than GRH.
#9636: Catch output from PARI in Sage.
#9400: Modify the NumberField constructor to pass in optional integer B
such that all the internal PARI routines will replace the discriminant
by its gcd with B, making some things massively faster.
Jeroen.
Dan Drake
> As far as we know, there are no more remaining issues for the PARI
> update (#9343). We haven't had any doctest failures for a while now.
> The main issues recently have been with PARI not compiling properly on
> various machines, but all those seem to be fixed now.
>
> I have made a complete Sage distribution sage-4.6.prealpha4, based on
> sage-4.5.3.rc0 with the new PARI and some more updates. You can
> download it from
> http://sage.math.washington.edu/home/jdemeyer/dist/sage-4.6.prealpha4.tar
>
> In order to test this thoroughly, extract the tarball and then:
> cd sage-4.6.prealpha4
> make
> env SAGE_CHECK=yes SAGE_TUNE_pari=yes ./sage -f
> pari-2.4.3.svn-12577.p5.spkg
> make ptestlong
For what it's worth, I followed your instructions above and got a
working copy of Sage that passes doctests. This on a 64-bit Ubuntu 10.04
system with 8 Xeon E5504 cores.
I do get intermittent failures when I run "make ptestlong"; the doctest
will fail with something like this:
sage -t -long devel/sage/sage/structure/proof/all.py
python: can't open file '/home/drake/.sage//tmp/all.py': [Errno 2] No such file
or directory
running the test manually always works. In three doctest runs, I've seen
this happen twice. It seems unrelated to the PARI upgrade stuff.
Dan
--
--- Dan Drake
----- http://mathsci.kaist.ac.kr/~drake
-------
Dr. David Kirkby
>
> I do get intermittent failures when I run "make ptestlong"; the doctest
> will fail with something like this:
>
> sage -t -long devel/sage/sage/structure/proof/all.py
> python: can't open file '/home/drake/.sage//tmp/all.py': [Errno 2] No such file
> or directory
>
> running the test manually always works. In three doctest runs, I've seen
> this happen twice. It seems unrelated to the PARI upgrade stuff.
>
> Dan
I've seen the "No such file or directory" issue on several occasions.
As you may have read, I run 'make ptestlong' 100 times with sage-4.5.3.alpha2.
The error occurred 5 times in 100 runs. The numbers of the text file below refer
to the run - so I see this on my 11th, 22nd, 24th, 26th and 66th attempts at
running 'make ptestlong'.
drkirkby@hawk:~/sage-4.5.3.alpha2$ grep "No such file or dire" pte*
ptestlong.log.11.txt:python: can't open file
'/export/home/drkirkby/.sage//tmp/quaternion_algebra.py': [Errno 2] No such file
or directory
ptestlong.log.22.txt:python: can't open file
'/export/home/drkirkby/.sage//tmp/quaternion_algebra.py': [Errno 2] No such file
or directory
ptestlong.log.24.txt:python: can't open file
'/export/home/drkirkby/.sage//tmp/quaternion_algebra.py': [Errno 2] No such file
or directory
ptestlong.log.26.txt:python: can't open file
'/export/home/drkirkby/.sage//tmp/space.py': [Errno 2] No such file or directory
ptestlong.log.66.txt:python: can't open file
'/export/home/drkirkby/.sage//tmp/classical.py': [Errno 2] No such file or directory
So getting the odd such failure when parallel doctesting is nothing unusual. I
think people have found that the temporary directories used by some files is not
unique, and two tests with the same name can end up writing to the same directory.
luisfe
compiles without problems and passes all doctests. The test wheree
made with only two threads.
kcrisman
fails at GSL (this machine built and passed nearly all tests with
4.5.2):
libtool: link: ar cru .libs/libgslintegration.a .libs/qk15.o .libs/
qk21.o .libs/qk31.o .libs/qk41.o .libs/qk51.o .libs/qk61.o .libs/
qk.o .libs/qng.o .libs/qag.o .libs/qags.o .libs/qagp.o .libs/
workspace.o .libs/qcheb.o .libs/qawc.o .libs/qmomo.o .libs/
qaws.o .libs/qmomof.o .libs/qawo.o .libs/qawf.o .libs/glfixed.o
ar: .libs/qk41.o: No such file or directory
make[4]: *** [libgslintegration.la] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
Error building GSL
real 33m33.849s
user 11m34.412s
sys 4m5.941s
sage: An error occurred while installing gsl-1.14
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of
of /Users/student/Desktop/sage-4.6.prealpha4/install.log. Describe
your computer, operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/Users/student/Desktop/sage-4.6.prealpha4/spkg/build/gsl-1.14 and type
'make check' or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
(cd '/Users/student/Desktop/sage-4.6.prealpha4/spkg/build/gsl-1.14' &&
'/Users/student/Desktop/sage-4.6.prealpha4/sage' -sh)
When you are done debugging, you can type "exit" to leave the
subshell.
make[1]: *** [installed/gsl-1.14] Error 1
real 376m31.125s
user 164m9.254s
sys 62m10.214s
Error building Sage.
./sage -docbuild all html 2>&1 | tee -a dochtml.log
python: can't open file '/Users/student/Desktop/sage-4.6.prealpha4/
devel/sage/doc/common/builder.py': [Errno 2] No such file or directory
Dr. David Kirkby
> Hello sage-devel,
>
> As far as we know, there are no more remaining issues for the PARI
> update (#9343). We haven't had any doctest failures for a while now.
> The main issues recently have been with PARI not compiling properly on
> various machines, but all those seem to be fixed now.
>
> I have made a complete Sage distribution sage-4.6.prealpha4, based on
> sage-4.5.3.rc0 with the new PARI and some more updates. You can
> download it from
> http://sage.math.washington.edu/home/jdemeyer/dist/sage-4.6.prealpha4.tar
>
> In order to test this thoroughly, extract the tarball and then:
> cd sage-4.6.prealpha4
> make
> env SAGE_CHECK=yes SAGE_TUNE_pari=yes ./sage -f
> pari-2.4.3.svn-12577.p5.spkg
Done that on OpenSolaris (32-bit build).
* Testing thue for gp-sta..TIME=1457 for gp-dyn..TIME=1522
* Testing trans for gp-sta..TIME=48 for gp-dyn..TIME=38
* Testing zetak for gp-sta..TIME=2486 for gp-dyn..TIME=2454
* Testing zn for gp-sta..TIME=2 for gp-dyn..TIME=3
+++ Total bench for gp-sta is 225384
+++ Total bench for gp-dyn is 233333
make[1]: Leaving directory
`/export/home/drkirkby/sage-4.6.prealpha4/spkg/build/pari-2.4.3.svn-12577.p5/src/Osolaris-ix86'
The PARI self-tests all passed
Now cleaning up tmp files.
Making Sage/Python scripts relocatable...
Making script relocatable
Finished installing pari-2.4.3.svn-12577.p5.spkg
> make ptestlong
sage -t -long devel/sage/sage/quadratic_forms/quadratic_form__siegel_product.py
[156.7 s]
sage -t -long devel/sage/sage/modular/ssmod/ssmod.py
[335.5 s]
----------------------------------------------------------------------
All tests passed!
Total time for all tests: 1943.7 seconds
So it seems fine. I'm trying the same on t2.math, but that will take some time
to complete.
Dave
John H Palmieri
> Hello sage-devel,
>
> As far as we know, there are no more remaining issues for the PARI
> update (#9343). We haven't had any doctest failures for a while now.
> The main issues recently have been with PARI not compiling properly on
> various machines, but all those seem to be fixed now.
>
> I have made a complete Sage distribution sage-4.6.prealpha4, based on
> sage-4.5.3.rc0 with the new PARI and some more updates. You can
> In order to test this thoroughly, extract the tarball and then:
> cd sage-4.6.prealpha4
> make
> env SAGE_CHECK=yes SAGE_TUNE_pari=yes ./sage -f
> pari-2.4.3.svn-12577.p5.spkg
> make ptestlong
>
> On sage.math.washington.edu, this worked without problems (apart from a
> sometimes-reproducible error in devel/sage/sage/tests/startup.py)
>
> The following tickets have been merged in sage-4.6.prealpha4 (w.r.t.
> sage-4.5.3.rc0):
> #9343: PARI upgrade
> #9860: Port changes in PARI 2.3.5.p4 (#9722) to current 2.4.3
> #9591: Upgrade genus2reduction due to Pari upgrade to svn snapshot 12577
> - a pre-release of Pari 2.4.3
> #9592: Upgrade lcalc to work with Pari svn snapshot 12577 - a
> pre-release of Pari 2.4.3
> #9845: lcalc doesn't build on cygwin due to missing time.h include
> #9750: Document that PARI no longer assumes more than GRH.
> #9636: Catch output from PARI in Sage.
> #9400: Modify the NumberField constructor to pass in optional integer B
> such that all the internal PARI routines will replace the discriminant
> by its gcd with B, making some things massively faster.
>
> Jeroen.
menas (x86_64-Linux-core2-suse), and fulvia (x86_64-SunOS-core2).
Tests are still in progress for mark2 (sparc-SunOS-ultrasparc3).
These all use gcc 4.5.1.
On t2.math, just running "make ptestlong" (without setting SAGE_CHECK
or SAGE_TUNE_pari) worked fine: all tests passed. However, setting
SAGE_CHECK produced an error:
+++ [BUG] Total bench for gp-sta is 3288122
+++ [BUG] Total bench for gp-dyn is 3363785
PROBLEMS WERE NOTED. The following files list them in diff format:
Directory: /scratch/palmieri/sage-4.6.prealpha4/spkg/build/
pari-2.4.3.svn-12577.p5/src/Osolaris-sparcv9
rnfkummer-sta.dif
rnfkummer-dyn.dif
I'm now trying with SAGE_TUNE_pari=yes (but SAGE_CHECK unset).
Everything worked fine on an Intel Mac OS X 10.6 box.
--
John
mhampton
machines (they have quite different processors, one is an 8-core intel
i7 860, the other a dual core intel e8400).
-Marshall Hampton
On Sep 7, 5:09 am, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> Hello sage-devel,
>
> As far as we know, there are no more remaining issues for the PARI
> update (#9343). We haven't had any doctest failures for a while now.
> The main issues recently have been with PARI not compiling properly on
> various machines, but all those seem to be fixed now.
>
> I have made a complete Sage distribution sage-4.6.prealpha4, based on
> sage-4.5.3.rc0 with the new PARI and some more updates. You can
Jeroen Demeyer
> Mac OS X 10.4 with 512 MB memory, 700 MHz PPC
>
> fails at GSL (this machine built and passed nearly all tests with
> 4.5.2):
does not depend on PARI). Does sage-4.5.3 build on that machine?
Jeroen.
mhampton
http://trac.sagemath.org/sage_trac/ticket/9533
Looks like that spkg was really well tested in general, but not on a
OS X 10.4 machine. Unfortunately I don't have one available.
-Marshall
Jeroen Demeyer
> +++ [BUG] Total bench for gp-sta is 3288122
> +++ [BUG] Total bench for gp-dyn is 3363785
>
> PROBLEMS WERE NOTED. The following files list them in diff format:
> Directory: /scratch/palmieri/sage-4.6.prealpha4/spkg/build/
> pari-2.4.3.svn-12577.p5/src/Osolaris-sparcv9
> rnfkummer-sta.dif
> rnfkummer-dyn.dif
I also get an error in rnfkummer on a PPC Mac OS X 10.4, see #9876. You
should check whether you get the same error.
Jeroen.
Dr. David Kirkby
> Yes, I would guess this is related to
> http://trac.sagemath.org/sage_trac/ticket/9533
>
> Looks like that spkg was really well tested in general, but not on a
> OS X 10.4 machine. Unfortunately I don't have one available.
>
> -Marshall
The GSL update was well tested on all these platforms.
* Cygwin
* FreeBSD
* HP-UX
* Linux
* OpenSolaris
* OS X
* Solaris
including building in parallel. The packages self-tests were run on all those
platforms too.
I suspect there's a race condition which means the parallel build is unsafe.
These things are very hard to detect.
I think setting
MAKE="$MAKE -j1"
export MAKE
in both spkg-install and spkg-text will probably solve it.
Can someone test that.
If there's a bug in the code which means it will never build on OS X 10.4, then
that's another issue.
Dave
Jeroen Demeyer
> If there's a bug in the code which means it will never build on OS X
> 10.4, then that's another issue.
I tested sage-4.6.prealpha4 (based on sage-4.5.3, so it includes the GSL
update) on a PPC OS X 10.4 and all tests were successful (make testlong).
Jeroen.
kcrisman
make and it did fine, then the same thing happened in libsingular, I
restarted make, all was well. Currently building all the Sage Cython
libraries, no more problems. Sorry for the noise (hopefully that's
all it was).
- kcrisman
Dr. David Kirkby
Could you build it in a number of times in a loop and let us know if it ever fails.
GSL has its own test suite too, which one gets with SAGE_CHECK=yes.
Dave
Dan Drake
> cd sage-4.6.prealpha4
> make
> env SAGE_CHECK=yes SAGE_TUNE_pari=yes ./sage -f
> pari-2.4.3.svn-12577.p5.spkg
> make ptestlong
Another data point: with the above tarball and instructions, on a 32-bit
Ubuntu Dapper system, everything built and passed doctests (except for a
Singular-related failure in free_module.py; see #9865).
For reference, that virtual machine has gcc 4.0.3, 1 GB RAM, and uses
one core of an Intel Core 2 Quad.
Jeroen Demeyer
> Could you build it in a number of times in a loop and let us know if it
> ever fails.
I built it 100 times (without SAGE_CHECK) and it was successful every time.
Dr. David Kirkby
I think given that, and even the person that had the failure now has it working,
it's best to leave the GSL package unchanged.
Otherwise would disable parallel builds in GSL package.
If a ticket was opened showing the failure, it could be reported to the upstream
developers to see if they have any comments. Has anyone done that yet? If not,
I'll open a ticket and report the failure upstream.
Dave
kcrisman
things too much for what I need it for now.
However, I noticed something weird:
Dasher-03:~/Desktop/sage-4.6.prealpha4 student$ ./sage
----------------------------------------------------------------------
| Sage Version 4.6.prealpha4, Release Date: 2010-09-07 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
**********************************************************************
* *
* Warning: this is a prerelease version, and it may be unstable. *
* *
**********************************************************************
sage: 2+2
4
sage:
Exiting Sage (CPU time 0m0.28s, Wall time 0m3.25s).
Exiting spawned GP/PARI interpreter process.
Note the last line. This is repeatable. Do we really want this? We
do get an exit of a spawned GAP process when one moves Sage to a new
location, but that's the only time I can think of that Sage makes such
a message without any other programs being started. Don't tell me we
started GP/PARI to compute 2+2! Those aren't really the size of
integers we should need that for :)
- kcrisman
Jeroen Demeyer
> sage:
> Exiting Sage (CPU time 0m0.28s, Wall time 0m3.25s).
> Exiting spawned GP/PARI interpreter process.
>
> Note the last line. This is repeatable. Do we really want this? We
> do get an exit of a spawned GAP process when one moves Sage to a new
> location, but that's the only time I can think of that Sage makes such
> a message without any other programs being started. Don't tell me we
> started GP/PARI to compute 2+2! Those aren't really the size of
> integers we should need that for :)
that message. This HAS changed w.r.t. sage-4.5.3 but I don't know
exactly what the reason is.
Jeroen.
kcrisman
On Sep 9, 12:40 pm, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> On 2010-09-09 14:48, kcrisman wrote:> sage:
> > Exiting Sage (CPU time 0m0.28s, Wall time 0m3.25s).
> > Exiting spawned GP/PARI interpreter process.
>
> > Note the last line. This is repeatable. Do we really want this? We
> > do get an exit of a spawned GAP process when one moves Sage to a new
> > location, but that's the only time I can think of that Sage makes such
> > a message without any other programs being started. Don't tell me we
> > started GP/PARI to compute 2+2! Those aren't really the size of
> > integers we should need that for :)
>
> The "2+2" has nothing do with it.
- kcrisman
ggrafendorfer
built successful and almost all test passed (ptestlong) on AMD Phenom
X4 II, Fedora 13
one test failed, this is related to
http://trac.sagemath.org/sage_trac/ticket/9847
Georg
On Sep 7, 12:09 pm, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> Hello sage-devel,
>
> As far as we know, there are no more remaining issues for the PARI
> update (#9343). We haven't had any doctest failures for a while now.
> The main issues recently have been with PARI not compiling properly on
> various machines, but all those seem to be fixed now.
>
> I have made a complete Sage distribution sage-4.6.prealpha4, based on
> sage-4.5.3.rc0 with the new PARI and some more updates. You can
John Cremona
the gp interpreter (to turn off the default debugging mode), which may
mean that the interpreter is really started up on creation of the
interpreter object, every time, instead of only being started when a
"real" gp command is needed.
That's a non-trivial fix in something I had to work out how to change
in the first place; not impossible though. But I will not be able to
do this before Saturday... so someone else is welcome to take a look.
>
> - kcrisman
Justin C. Walker
On Sep 7, 2010, at 03:09 , Jeroen Demeyer wrote:
> Hello sage-devel,
>
> As far as we know, there are no more remaining issues for the PARI
> update (#9343). We haven't had any doctest failures for a while now.
> The main issues recently have been with PARI not compiling properly on
> various machines, but all those seem to be fixed now.
>
> I have made a complete Sage distribution sage-4.6.prealpha4, based on
> sage-4.5.3.rc0 with the new PARI and some more updates. You can
> download it from
> http://sage.math.washington.edu/home/jdemeyer/dist/sage-4.6.prealpha4.tar
I used your instructions.
Built from scratch on Mac OS X, 10.5.8 (Dual Quad Xeon) with no
problems. Testing had one failure:
sage -t -long devel/sage/sage/interfaces/ecm.py
*** *** Error: TIMED OUT! PROCESS KILLED! *** ***
[1800.2 s]
I ran this command again, and it completed successfully in ~14
seconds. This system doesn't sleep, and the only unusual entries in
the system logs were a couple of "out of paging space" messages.
The messages were logged at 7:58 last night. The failure was the last
test in the test log, and the timestamp on the log file was 8:42 last
night, so there is a gun which, while not actually smoking, is warm [*].
Would the 'ecm.py' test generate a lot of temp data? Would any other
test? Something must have chewed up a lot of temp/paging space,
either by creating lots of data files or by having lots of bloated
processes running. My temp-space/paging disk has about 100GB of
available space, so to get the "out of paging space" message is a bit
surprising.
Justin
[*] <http://en.wikipedia.org/wiki/Happiness_Is_a_Warm_Gun>
--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Enhancement of the Director's Income
--------
Experience is what you get
when you don't get what you want.
--------