939
Comment:
|
7993
|
Deletions are marked like this. | Additions are marked like this. |
Line 2: | Line 2: |
Tarballs are here: http://sage.math.washington.edu/home/was/tmp |
|
Line 12: | Line 16: |
== eno: x86_64-Linux-fc8 == | == eno: x86_64-Linux-fc8 (status: 10/10) == |
Line 14: | Line 18: |
Using gcc-4.3.1: | Using gcc-4.3.1: I (william) can't build ntl. I'm totally stuck until getting past this. Fixed by using this environment (put in my .bash_profile): {{{ # From mabshoff if [ `hostname` = "eno" ]; then export PATH=/usr/local/gcc-4.3.1/x86_64-Linux-fc8/bin/:$PATH export LD_LIBRARY_PATH=/usr/local/gcc-4.3.1/x86_64-Linux-fc8/lib64:/usr/local/gmp-4.2.2/x86_64-Linux-fc8-gcc-4.1.2-rh/lib:/usr/local/mpfr-2.3.1/x86_64-Linux-fc8-gmp-4.2.2-gcc-4.1.2-rh/lib |
Line 16: | Line 26: |
I (william) can't build ntl. I'm totally stuck until getting past this. | fi }}} |
Line 18: | Line 29: |
== cicero: x86-Linux-fc8 == | Me (mabshoff) just build 4.0.3.rc1 with gcc 4.3.1 and all tests pass with flying colors. |
Line 20: | Line 31: |
Using gcc-4.1.2: build fine out of the box; all tests for rc1 pass. | == cicero: x86-Linux-fc8 (status: 10/10) == |
Line 22: | Line 33: |
== cleo: ia64-Linux-rhel5 == | UPDATE: I just built rc2 using gcc-4.3.1, and I definitely do *not* get an illegal instruction when testing devel/sage/sage/functions/special.py. The only doctest failure I get is one digit being off in time_series.py (numerical noise), which I've fixed in the release tree. {{{ wstein@cicero sage-3.0.4.rc2]$ ./sage -t devel/sage/sage/functions/special.py sage -t devel/sage/sage/functions/special.py [10.2 s] ---------------------------------------------------------------------- All tests passed! }}} I wonder if Mariah has some screwed up fortran libraries or something in her path? From a clean bash login shell I setup my environment as follows {{{ export PATH=/usr/local/bin/x86-Linux-fc8/:$PATH LDPATH=/usr/local/gcc-4.3.1/x86-Linux-fc8/lib LDPATH=${LDPATH}:/usr/local/gmp-4.2.2/x86-Linux-fc8-gcc-4.1.2-rh/lib LDPATH=${LDPATH}:/usr/local/mpfr-2.3.1/x86-Linux-fc8-gmp-4.2.2-gcc-4.1.2-rh/lib }}} OLD: Using gcc-4.1.2: built fine out of the box; all tests for rc1 pass. Using gcc-4.3.1: Mariah gets an "illegal instruction" error when testing {{{ sage -t devel/sage/sage/functions/special.py }}} See http://trac.sagemath.org/sage_trac/ticket/2303 Replicate sage-free: {{{ sage -python >>> import scipy.special; scipy.special.iv(float(1),complex(1,0)) /tmp/foo/sage-3.0.4.rc0-x86-Linux-fc8/local/bin/sage-sage: line 359: 2638 Illegal instruction python "$ }}} * Michael suggested upgrading to the newest version of scipy. This is certainly worth a try. == cleo: ia64-Linux-rhel5 (status: 7/10) == Using gcc-4.1.2: Built fine out of the box. Currently testing; many tests have timed out since this machine is so slow. Possible serious singular crash in groups/matrix_gps/matrix_group.py, though it could be a timeout. There is something massively foobar'd about this machine or its file system or something. For example: {{{ [wstein@cleo sage-3.0.4.rc0]$ time ./sage -c "print 1+1" 2 real 0m26.532s user 0m1.447s sys 0m3.224s }}} A 26 second startup time? Ick. Is there something seriously wrong with the build of Python? |
Line 26: | Line 87: |
== iras: ia64-Linux-suse == | == iras: ia64-Linux-suse (status: 9/10) == UPDATE: these fail for me: {{{ Singular crashing on startup via pexpect for these 3: sage -t devel/sage/sage/rings/polynomial/multi_polynomial_ideal_libsingular.pyx # 1 doctes ts failed sage -t devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py # 6 doctests failed sage -t devel/sage/sage/groups/matrix_gps/matrix_group.py # 3 doctests failed }}} |
Line 28: | Line 98: |
There is a major bug in flint. See http://trac.sagemath.org/sage_trac/ticket/3616 | Everything else listed below as failing does not fail for me anymore. |
Line 30: | Line 100: |
== menas: x86_64-Linux-suse == | ------------ |
Line 32: | Line 102: |
With gcc-4.2.1 and reverting to the old version of clisp all tests pass for sage-4.3.1.rc0: |
* With gcc-4.3.1 the following tests all fail out of the box {{{ The following tests failed: (done) sage -t devel/sage/sage/rings/polynomial/polynomial_element.pyx # 1 doctests failed sage -t devel/sage/sage/rings/polynomial/multi_polynomial_ideal_libsingular.pyx # 1 doctes ts failed sage -t devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py # 6 doctests failed sage -t devel/sage/sage/rings/number_field/totallyreal.py # Segfault sage -t devel/sage/sage/plot/plot3d/transform.pyx # 1 doctests failed sage -t devel/sage/sage/misc/prandom.py # 1 doctests failed sage -t devel/sage/sage/matrix/matrix_symbolic_dense.pyx # 1 doctests failed sage -t devel/sage/sage/groups/matrix_gps/matrix_group.py # 3 doctests failed sage -t devel/sage/sage/functions/piecewise.py # 1 doctests failed sage -t devel/sage/sage/dsage/tests/testdoc.py # 10 doctests failed sage -t devel/sage/sage/dsage/interface/dsage_interface.py # 2 doctests failed sage -t devel/sage/sage/rings/polynomial/polynomial_integer_dense_flint.pyx # 0 doctests f ailed }}} Update to 3.0.4.alpha2: With a fix to the python.spkg (build without -fwrapv) results in: {{{ sage -t -long devel/sage/sage/finance/time_series.pyx sage -t -long devel/sage/sage/misc/cython.py sage -t -long devel/sage/sage/rings/number_field/totallyreal.py sage -t -long devel/sage/sage/rings/polynomial/polynomial_element.pyx sage -t -long devel/sage/sage/rings/polynomial/polynomial_integer_dense_flint.pyx }}} It seems that all the above failures are know issue and we have leads for all of them. In particular: * trac #3605 (ell_finite_field.py: libSingular - "Use of uninitialised value of size 8" * trac #3606 (totallyreal_data.py: "Use of uninitialised value of size 8" * There is a major bug in flint that freezes doctesting. See http://trac.sagemath.org/sage_trac/ticket/3616 * segmentation fault {{{ sh: line 1: 16098 Segmentation fault /home/wstein/iras/build/sage-3.0.4.rc0/local/bin/python /home/wstein/iras/build/sage-3.0.4.rc0/tmp/.doctest_totallyreal.py >/tmp/tmpW-loSD 2>/tmp/tmp8ZjloU sage -t devel/sage/sage/rings/number_field/totallyreal.py A mysterious error (perphaps a memory error?) occurred, which may have crashed doctest. }}} I think this is related to the valgrind issues that mabshoff observed and reported. * Bill Hart says: {{{ FLINT definitely isn't working on ia64. I've tracked the problem a bit further through now that I know lots of tests are failing in long_extras-test. The problem appears to be in the function z_ll_mod_precomp in long_extras.c This function uses udiv_qrnnd from GMP's longlong.h and not a whole lot else, so that is a hint. This doesn't mean there is a bug in GMP, it probably just means that on this architecture FLINT is setting something up incorrectly before using longlong.h. It shouldn't take too much to sort out. I mean the function that is causing all the problems is only 20 lines of code and all pretty basic. }}} Update from Bill Hart: There will be a FLINT 1.0.11 in a couple hours (i.e. July 9th, 2008) == menas: x86_64-Linux-suse (status: 9/10) == With gcc-4.2.1 and reverting to the old version of clisp all tests pass for sage-4.3.1.rc0: |
Line 39: | Line 182: |
Without reverting clisp, maxima hangs on certain integrals. | Without reverting clisp, maxima hangs on certain integrals: {{{ integrate(1/(x^3 *(a+b*x)^(1/3)), x); }}} I think reverting clisp will be ok for this architecture and for this release since the only reason for the new version was build support on more architectures. === Pentium4: Another "relevant" machine (status: 9/10) === * (done) A bug in FLINT 1.011. See http://trac.sagemath.org/sage_trac/ticket/3627 * doctests fail for: {{{ sage -t devel/sage/sage/dsage/tests/testdoc.py sage -t devel/sage/sage/server/simple/twist.py }}} These both involve network services. The testdoc failure is a pure timeout issue with a.wait(30), so safe to ignore -- everything else in that file passes fine. O think the twist.py issue also involves some sort of timeout. |
Getting Sage-3.0.4 to build and pass all tests on Skynet
Tarballs are here:
http://sage.math.washington.edu/home/was/tmp
To get from rc0 to rc1 from within a built sage do this:
sage: hg_sage.apply('http://sage.math.washington.edu/home/was/patches/a.hg') sage: hg_sage.merge() sage: hg_sage.ci()
Then do "./sage -br" at the prompt.
eno: x86_64-Linux-fc8 (status: 10/10)
Using gcc-4.3.1: I (william) can't build ntl. I'm totally stuck until getting past this. Fixed by using this environment (put in my .bash_profile):
# From mabshoff if [ `hostname` = "eno" ]; then export PATH=/usr/local/gcc-4.3.1/x86_64-Linux-fc8/bin/:$PATH export LD_LIBRARY_PATH=/usr/local/gcc-4.3.1/x86_64-Linux-fc8/lib64:/usr/local/gmp-4.2.2/x86_64-Linux-fc8-gcc-4.1.2-rh/lib:/usr/local/mpfr-2.3.1/x86_64-Linux-fc8-gmp-4.2.2-gcc-4.1.2-rh/lib fi
Me (mabshoff) just build 4.0.3.rc1 with gcc 4.3.1 and all tests pass with flying colors.
cicero: x86-Linux-fc8 (status: 10/10)
UPDATE: I just built rc2 using gcc-4.3.1, and I definitely do *not* get an illegal instruction when testing devel/sage/sage/functions/special.py. The only doctest failure I get is one digit being off in time_series.py (numerical noise), which I've fixed in the release tree.
wstein@cicero sage-3.0.4.rc2]$ ./sage -t devel/sage/sage/functions/special.py sage -t devel/sage/sage/functions/special.py [10.2 s] ---------------------------------------------------------------------- All tests passed!
I wonder if Mariah has some screwed up fortran libraries or something in her path? From a clean bash login shell I setup my environment as follows
export PATH=/usr/local/bin/x86-Linux-fc8/:$PATH LDPATH=/usr/local/gcc-4.3.1/x86-Linux-fc8/lib LDPATH=${LDPATH}:/usr/local/gmp-4.2.2/x86-Linux-fc8-gcc-4.1.2-rh/lib LDPATH=${LDPATH}:/usr/local/mpfr-2.3.1/x86-Linux-fc8-gmp-4.2.2-gcc-4.1.2-rh/lib
OLD: Using gcc-4.1.2: built fine out of the box; all tests for rc1 pass.
Using gcc-4.3.1: Mariah gets an "illegal instruction" error when testing
sage -t devel/sage/sage/functions/special.py
See http://trac.sagemath.org/sage_trac/ticket/2303
Replicate sage-free:
sage -python >>> import scipy.special; scipy.special.iv(float(1),complex(1,0)) /tmp/foo/sage-3.0.4.rc0-x86-Linux-fc8/local/bin/sage-sage: line 359: 2638 Illegal instruction python "$
* Michael suggested upgrading to the newest version of scipy. This is certainly worth a try.
cleo: ia64-Linux-rhel5 (status: 7/10)
Using gcc-4.1.2: Built fine out of the box. Currently testing; many tests have timed out since this machine is so slow. Possible serious singular crash in groups/matrix_gps/matrix_group.py, though it could be a timeout. There is something massively foobar'd about this machine or its file system or something. For example:
[wstein@cleo sage-3.0.4.rc0]$ time ./sage -c "print 1+1" 2 real 0m26.532s user 0m1.447s sys 0m3.224s
A 26 second startup time? Ick. Is there something seriously wrong with the build of Python?
iras: ia64-Linux-suse (status: 9/10)
UPDATE: these fail for me:
Singular crashing on startup via pexpect for these 3: sage -t devel/sage/sage/rings/polynomial/multi_polynomial_ideal_libsingular.pyx # 1 doctes ts failed sage -t devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py # 6 doctests failed sage -t devel/sage/sage/groups/matrix_gps/matrix_group.py # 3 doctests failed
Everything else listed below as failing does not fail for me anymore.
- With gcc-4.3.1 the following tests all fail out of the box
The following tests failed: (done) sage -t devel/sage/sage/rings/polynomial/polynomial_element.pyx # 1 doctests failed sage -t devel/sage/sage/rings/polynomial/multi_polynomial_ideal_libsingular.pyx # 1 doctes ts failed sage -t devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py # 6 doctests failed sage -t devel/sage/sage/rings/number_field/totallyreal.py # Segfault sage -t devel/sage/sage/plot/plot3d/transform.pyx # 1 doctests failed sage -t devel/sage/sage/misc/prandom.py # 1 doctests failed sage -t devel/sage/sage/matrix/matrix_symbolic_dense.pyx # 1 doctests failed sage -t devel/sage/sage/groups/matrix_gps/matrix_group.py # 3 doctests failed sage -t devel/sage/sage/functions/piecewise.py # 1 doctests failed sage -t devel/sage/sage/dsage/tests/testdoc.py # 10 doctests failed sage -t devel/sage/sage/dsage/interface/dsage_interface.py # 2 doctests failed sage -t devel/sage/sage/rings/polynomial/polynomial_integer_dense_flint.pyx # 0 doctests f ailed
Update to 3.0.4.alpha2: With a fix to the python.spkg (build without -fwrapv) results in:
sage -t -long devel/sage/sage/finance/time_series.pyx sage -t -long devel/sage/sage/misc/cython.py sage -t -long devel/sage/sage/rings/number_field/totallyreal.py sage -t -long devel/sage/sage/rings/polynomial/polynomial_element.pyx sage -t -long devel/sage/sage/rings/polynomial/polynomial_integer_dense_flint.pyx
It seems that all the above failures are know issue and we have leads for all of them. In particular:
- trac #3605 (ell_finite_field.py: libSingular - "Use of uninitialised value of size 8"
- trac #3606 (totallyreal_data.py: "Use of uninitialised value of size 8"
There is a major bug in flint that freezes doctesting. See http://trac.sagemath.org/sage_trac/ticket/3616
- segmentation fault
sh: line 1: 16098 Segmentation fault /home/wstein/iras/build/sage-3.0.4.rc0/local/bin/python /home/wstein/iras/build/sage-3.0.4.rc0/tmp/.doctest_totallyreal.py >/tmp/tmpW-loSD 2>/tmp/tmp8ZjloU sage -t devel/sage/sage/rings/number_field/totallyreal.py A mysterious error (perphaps a memory error?) occurred, which may have crashed doctest.
I think this is related to the valgrind issues that mabshoff observed and reported.
* Bill Hart says:
FLINT definitely isn't working on ia64. I've tracked the problem a bit further through now that I know lots of tests are failing in long_extras-test. The problem appears to be in the function z_ll_mod_precomp in long_extras.c This function uses udiv_qrnnd from GMP's longlong.h and not a whole lot else, so that is a hint. This doesn't mean there is a bug in GMP, it probably just means that on this architecture FLINT is setting something up incorrectly before using longlong.h. It shouldn't take too much to sort out. I mean the function that is causing all the problems is only 20 lines of code and all pretty basic.
Update from Bill Hart: There will be a FLINT 1.0.11 in a couple hours (i.e. July 9th, 2008)
menas: x86_64-Linux-suse (status: 9/10)
With gcc-4.2.1 and reverting to the old version of clisp all tests pass for sage-4.3.1.rc0:
sage -i clisp-2.41.p14.spkg sage -f maxima-5.13.0.p2.spkg
Without reverting clisp, maxima hangs on certain integrals:
integrate(1/(x^3 *(a+b*x)^(1/3)), x);
I think reverting clisp will be ok for this architecture and for this release since the only reason for the new version was build support on more architectures.
Pentium4: Another "relevant" machine (status: 9/10)
(done) A bug in FLINT 1.011. See http://trac.sagemath.org/sage_trac/ticket/3627
- doctests fail for:
sage -t devel/sage/sage/dsage/tests/testdoc.py sage -t devel/sage/sage/server/simple/twist.py
These both involve network services. The testdoc failure is a pure timeout issue with a.wait(30), so safe to ignore -- everything else in that file passes fine. O think the twist.py issue also involves some sort of timeout.