sage-4.5.2.alpha0 released
Dan Drake
Mitesh Patel and I have released Sage 4.5.2.alpha0. Source tarball is at
http://sage.math.washington.edu/home/release/sage-4.5.2.alpha0/sage-4.5.2.alpha0.tar
Upgrade path:
http://sage.math.washington.edu/home/release/sage-4.5.2.alpha0/sage-4.5.2.alpha0/
This release has been tested on sage.math and bsd.math. A build on
t2.math is underway. Please build, test, and report any issues.
* Doctesting coverage
Sage 4.5.1 has doctest coverage of 82.7%; in 4.5.2.alpha0, we have 83.5%.
* Known issues
Intermittent failure with
sage -t devel/sage/sage/tests/startup.py
on sage.math. This seems like a minor problem, and may only occur when
doctesting under heavy load.
There's also a doctest failure with
sage -t local/lib/python2.6/site-packages/sagenb-0.8.1-py2.6.egg/sagenb/misc/sageinspect.py
where something gets flipped around:
sage: sage_getvariablename(A)
Expected:
['A', 'B']
Got:
['B', 'A']
This problem is now #9554.
There are also a couple warnings when building documentation; those
tickets are #9561 and #9571. There's an error building the PDF ref
manual; that's #9573.
It also looks like we're missing a file from .hgignore in the scripts
repo; see #9574.
We merged 98 tickets in sage-4.5.2.alpha0:
#1396: Simon King: Ideal.groebner_basis should accept keyword arguments for strategy parameters [Reviewed by Martin Albrecht]
#5467: Andrey Novoseltsev: The sage/macaulay2 interface doesn't work at all on large input [Reviewed by Mike Hansen]
#6409: Mark Jordan: srange inconsistent when including endpoints [Reviewed by Luis Felipe Tabera Alonso]
#6449: David Loeffler: Additive abelian groups [Reviewed by John Cremona, Jim Stankewicz]
#6904: Clément Pernet: change ring broken over QQ and GF(2) [Reviewed by William Stein]
#6922: Kwankyu Lee: Matrix term ordering [Reviewed by Martin Albrecht]
#7859: Håkan Granath: bug in QQbar (easy to fix!) [Reviewed by Robert Bradshaw]
#7889: Oscar Gerardo Lazo Arjona: revolution plot [Reviewed by Karl-Dieter Crisman, Jason Grout, Marshall Hampton, John Palmieri]
#7897: Andrey Novoseltsev: Macaulay2 interface update/improvement for version 1.3.1 [Reviewed by Mike Hansen]
#7915: Andrey Novoseltsev: Improve TAB-completion in Macaulay2 [Reviewed by Mike Hansen]
#7930: Chris Wuthrich: strange bug for elliptic curves over number fields [Reviewed by John Cremona]
#8173: Martin Albrecht: segfault in singular resultant [Reviewed by Paul Zimmermann]
#8410: William Stein: Improve robustness of @parallel [Reviewed by Tom Boothby]
#8535: Robert Bradshaw: Various interval field improvements [Reviewed by Jason Grout]
#8562: Nicolas M. Thiéry: Categories for IntegerMod rings [Reviewed by John Palmieri, Rob Beezer]
#8564: Ondrej Certik: fix atan2() conversions between Sage and SymPy [Reviewed by Burcin Erocal, Karl-Dieter Crisman]
#8604: Sébastien Labbé: Add a class for factor-enumerable words [Reviewed by Alexandre Blondin Massé]
#8810: Steve Pon, Anne Schilling, Nicolas M. Thiéry: Implementation of Stanley symmetric functions [Reviewed by Nicolas M. Thiéry, Thomas Lam]
#8909: Simon King: Coercion from Gap to cyclotomic fields; usage of GAP to improve computation of invariant rings [Reviewed by David Loeffler, Mike Hansen]
#8942: Karl-Dieter Crisman: failing calculation with limit [Reviewed by Paul Zimmermann]
#8947: Jason Grout: pretty printing of vectors over callable symbolic rings [Reviewed by Rob Beezer]
#8953: Nathann Cohen: Perfect graph recognition algorithm [Reviewed by Robert Miller]
#8963: Dan Christensen: Make tableau row_stabilizer return group of perms involving all elements of the tableau [Reviewed by Franco Saliola]
#8967: Francis Clarke: Make extensions of general rings work in the same way as they do for number fields [Reviewed by Marco Streng]
#8970: David Loeffler: conversion of integer mods to Gap [Reviewed by Robert Miller]
#8974: Miguel Marco: Added eigenvalues, eigenvector, eigenspaces and minpoly to vector space endomorphisms [Reviewed by David Loeffler]
#8984: Brant Jones: Implementation of the Lenart--Postnikov alcove path crystal [Reviewed by Anne Schilling]
#8986: Andrey Novoseltsev: Add support for convex rational polyhedral cones [Reviewed by Volker Braun]
#8987: Andrey Novoseltsev: Add support for rational polyhedral fans [Reviewed by Volker Braun]
#8988: Andrey Novoseltsev: Add support for toric varieties [Reviewed by Volker Braun]
#8989: Andrey Novoseltsev: Add support for Fano toric varieties [Reviewed by Volker Braun]
#9012: Martin Albrecht: singular_decomposition fails on non-interreduced Gröbner basis [Reviewed by Simon King]
#9051: Robert Bradshaw, David Roe, William Stein: Fast function field arithmetic [Reviewed by Robert Bradshaw, William Stein]
#9062: Andrey Novoseltsev: Add support for toric lattices [Reviewed by Volker Braun]
#9069: Chris Hall: weak popov form [Reviewed by John Cremona]
#9087: John Cremona: implement supersingular/ordinary testing for elliptic curves over finite fields [Reviewed by Chris Wuthrich]
#9088: Jason Grout: line3d does not take a tuple of points [Reviewed by Karl-Dieter Crisman]
#9110: David Harvey: wrong documentation in EllipticCurve.change_weierstrass_model() [Reviewed by Chris Wuthrich]
#9111: Nathann Cohen, Thierry de Montgolfier: modular decomposition [Reviewed by Robert Miller]
#9112: Eric Webster: adding maximum entry option to SemistandardTableaux() [Reviewed by Jason Bandlow]
#9114: Simon King: Improve documentation of infinite polynomial rings [Reviewed by David Loeffler]
#9141: Jason Grout: find cospectral graphs [Reviewed by Nathann Cohen]
#9184: Robert Bradshaw: Gamma function for intervals [Reviewed by Fredrik Johansson]
#9188: Volker Braun: lattice_polytope.facet_normal bug with polytopes of less that full dimension [Reviewed by Andrey Novoseltsev]
#9205: David Loeffler: Discrete logs to composite bases [Reviewed by John Cremona]
#9206: William Stein: faster finite field creation with proof=False, done right (via proof architecture) [Reviewed by Robert Bradshaw]
#9207: Martin Albrecht: random_element does not work for BooleanPolynomialRing of degree 1 or 2 [Reviewed by Mariah Lenox]
#9212: Jason Grout: top-level identity_matrix and zero_matrix functions should return mutable matrices [Reviewed by Rob Beezer]
#9215: Sébastien Labbé: Bring doc coverage of plot/animate.py to 100% [Reviewed by Franco Saliola]
#9216: Sébastien Labbé: Bring doc coverage of groups/group.pyx to 100% [Reviewed by Franco Saliola]
#9218: William Stein, Minh Van Nguyen: add a finance chapter to the sage reference manual [Reviewed by Minh Van Nguyen, Karl-Dieter Crisman]
#9219: William Stein: add a statistics chapter to the sage reference manual [Reviewed by Karl-Dieter Crisman]
#9231: Marshall Hampton: bring tachyon interface code to 100% coverage [Reviewed by Robert Miller]
#9234: Sébastien Labbé: Bring doc coverage of plot/plot3d/texture.py to 100% [Reviewed by Karl-Dieter Crisman, John Palmieri]
#9236: Sébastien Labbé: Bring doc coverage of misc/sage_timeit.py to 100% [Reviewed by Minh Van Nguyen, Dan Drake]
#9239: Florent Hivert: delete the (ridiculous) method __copy__ from matrix0.pyx [Reviewed by William Stein]
#9244: David Loeffler: Number field class group improvements [Reviewed by Francis Clarke, John Cremona, Jim Stankewicz]
#9245: Volker Braun: Add library of toric varieties [Reviewed by Andrey Novoseltsev]
#9246: Minh Van Nguyen: explain the definition of characteristic polynomial for graphs [Reviewed by Nathann Cohen]
#9250: Anne Schilling: Bug in crystal code [Reviewed by Daniel Bump]
#9256: Florent Hivert: Put Set in the category Sets() [Reviewed by John Palmieri]
#9257: Robert Bradshaw: remove misc/darcs.py in Sage 5.0 [Reviewed by Robert Miller]
#9258: Mike Hansen: problem with converting FriCAS domains to Sage objects [Reviewed by Adam Webb]
#9259: Florent Hivert: Wrong markup on the documentation of CombinatorialClass.map [Reviewed by Nicolas M. Thiéry]
#9266: Chris Wuthrich: bug in global_integral_model for Elliptic Curves over Number Fields [Reviewed by John Cremona]
#9267: Jason Bandlow: Update the charge statistic on words [Reviewed by Franco Saliola]
#9270: John Palmieri: document the "-only-optional" flag for doctesting [Reviewed by Robert Miller]
#9271: John Palmieri: fix the "optional: needs CHomP" tags in sage/homology, etc. [Reviewed by Robert Miller]
#9287: Chris Wuthrich: improving doctest coverage for elliptic curves [Reviewed by John Cremona]
#9302: Robert Bradshaw: Heegner point_exact is wrong for 5077a with discriminant -7 [Reviewed by William Stein]
#9313: David Loeffler: delete padic_height.py [Reviewed by Jamie Weigandt]
#9317: Alyson Deines, Radoslav Kirov: prime_to_S_part, is_S_unit, is_S_integral [Reviewed by Anna Haensch, Erin Beyerstedt]
#9318: Martin Albrecht: Fix S-Box CNF generation for non permutations [Reviewed by Yann Laigle-Chapuy]
#9324: John Cremona: bug in Tate's algorithm over number fields [Reviewed by Robert Miller]
#9336: David Loeffler: Improve doctest coverage for sage/rings/number_field [Reviewed by John Cremona, Francis Clarke]
#9342: Lloyd Kilford, Alyson Deines, Jeremy West: rank method for elliptic curves over number fields [Reviewed by David Loeffler]
#9344: Luis Felipe Tabera Alonso: matrix constructor does not honor nrows if given a method to generate the entries [Reviewed by David Loeffler]
#9355: Anna Haensch: 100% coverage for quadratic_forms [Reviewed by David Loeffler]
#9357: Luis Felipe Tabera Alonso: Unhandled SIGFPE: in number_field_element_quadratic [Reviewed by Robert Bradshaw]
#9364: Yann Laigle-Chapuy: add is_symmetric in BooleanFunction [Reviewed by Martin Albrecht]
#9366: Yann Laigle-Chapuy: fix SBox __init__ [Reviewed by Martin Albrecht]
#9372: John Cremona: implement regulator function for elliptic curves over number fields [Reviewed by David Loeffler, Robert Bradshaw]
#9373: Minh Van Nguyen: some overhaul in organization of database of common graph generators [Reviewed by Nathann Cohen]
#9375: Minh Van Nguyen: more documentation & doctests for BalancedTree, BarbellGraph, BubbleSortGraph, BullGraph, ChvatalGraph [Reviewed by Nathann Cohen]
#9376: Robert Miller: non-QQ base rings in modular symbols [Reviewed by John Cremona]
#9387: Justin Walker: Add tamagawa_numbers method for elliptic curves over number fields [Reviewed by David Loeffler]
#9425: Georg S. Weber: bug in kernel_on() in "matrix2.pyx" [Reviewed by William Stein]
#9438: Simon King: IntegerMod_int.log has side-effect in Pari [Reviewed by David Loeffler]
#9441: John Cremona: Atkin-Lehner operators for Cremona modular symbols [Reviewed by Robert Miller]
#9450: Jeroen Demeyer: Implement a factor() function for NumberFieldElement [Reviewed by John Cremona, Mike Hansen]
#9485: Nicolas M. Thiéry: strongly_connected_components_digraph's had no edges [Reviewed by Nathann Cohen]
#9496: Richard Lindner, Michael Schneider: Crypto lattice basis generator [Reviewed by Martin Albrecht, Richard Lindner]
#9499: Martin Albrecht: recovery gracefully from libsingular errors [Reviewed by William Stein]
#9500: William Stein: implement inversion of elements in a (more) general quotient ring [Reviewed by Martin Albrecht]
#9509: Robert Miller: graphs() should give you graphs [Reviewed by Vincent Delecroix]
#9514: Carl Witty: sage/symbolic/random_tests.py wrongly depends on order of dict.values() [Reviewed by Andrey Novoseltsev]
#9532: Carl Witty: fix uncontrolled randomness in sage/graphs [Reviewed by Robert Miller]
#9537: William Stein: trial_division in Sage is really slow [Reviewed by Sebastian Pancratz]
Dan
--
--- Dan Drake
----- http://mathsci.kaist.ac.kr/~drake
-------
William Stein
> Hello,
>
> Mitesh Patel and I have released Sage 4.5.2.alpha0. Source tarball is at
>
> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha0/sage-4.5.2.alpha0.tar
>
> Upgrade path:
Building in my normal way on T2 (sparc solaris) immediately fails:
checking if g++ accepts -dumpversion option... yes
checking g++ version... 4.2.4
configure: Although gcc and g++ are both version 4.2.4
configure: the Fortran compiler
/usr/local/gcc-4.4.1-sun-linker/bin/gfortran is some other versi
on.
configure: The output from
/usr/local/gcc-4.4.1-sun-linker/bin/gfortran --version is below.
GNU Fortran (GCC) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
configure: Exiting since the Fortran compiler is not the same
configure: error: version as the C and C++ compilers
ERROR: You do not have all of the prerequisites needed
to build Sage from source. See the errors above.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAkxH8NIACgkQr4V8SljC5LqEMwCgzVSa1tTAmUs2F+gJGTWF1bpH
> 28EAoJGF52AU2E4mvZH3DxZQdu22SVAC
> =XP7n
> -----END PGP SIGNATURE-----
>
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
Dr. David Kirkby
> On Thu, Jul 22, 2010 at 9:18 AM, Dan Drake<dr...@kaist.edu> wrote:
>> Hello,
>>
>> Mitesh Patel and I have released Sage 4.5.2.alpha0. Source tarball is at
>>
>> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha0/sage-4.5.2.alpha0.tar
>>
>> Upgrade path:
>
> Building in my normal way on T2 (sparc solaris) immediately fails:
>
>
> checking if g++ accepts -dumpversion option... yes
> checking g++ version... 4.2.4
> configure: Although gcc and g++ are both version 4.2.4
> configure: the Fortran compiler
> /usr/local/gcc-4.4.1-sun-linker/bin/gfortran is some other versi
> on.
> configure: The output from
> /usr/local/gcc-4.4.1-sun-linker/bin/gfortran --version is below.
>
> GNU Fortran (GCC) 4.4.1
It looks to me like your script is not setting your path properly. When I typed
# su - wstein
all your variables seem fine. Your versions of gcc, g++ and gfortran are all the
same (4.4.1). Is it possible they are not set when your script is run?
If /usr/local/gcc-4.4.1-sun-linker/bin/ is not early in your path, then you
might get another (older) gcc. If SAGE_FORTRAN is then set to a newer gcc, that
will create a problem as that script wants them all to be the same. It's
designed to detect problems like this.
I've changed nothing on the system to have changed anyones path.
Dave
John Cremona
> On 07/22/10 10:28 AM, William Stein wrote:
>>
>> On Thu, Jul 22, 2010 at 9:18 AM, Dan Drake<dr...@kaist.edu> wrote:
>>>
>>> Hello,
>>>
>>> Mitesh Patel and I have released Sage 4.5.2.alpha0. Source tarball is at
>>>
>>>
>>> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha0/sage-4.5.2.alpha0.tar
>>>
Built from scratch fine on 64-bit ubuntu.
One failure (from ptestlong) which I believe has been reported (or
even fixed) already:
File "/storage/jec/sage-4.5.2.alpha0/local/lib/python2.6/site-packages/sagenb-0.8.1-py2.6.egg/sagenb/misc/sageinspect.py",
line 997:
sage: sage_getvariablename(A)
Expected:
['A', 'B']
Got:
['B', 'A']
32-bit Suse test still running...
John
John Cremona
The following tests failed:
1 sage -t -long ge/sage/graphs/generic_graph.py # 1 doctests failed
2 sage -t -long
b/python2.6/site-packages/sagenb-0.8.1-py2.6.egg/sagenb/misc/sageinspect.py
# 1 doctests failed
3 sage -t -long ge/sage/geometry/toric_lattice_element.pyx # 1 doctests failed
4 sage -t -long ge/sage/geometry/cone.py # 1 doctests failed
5 sage -t -long ge/sage/combinat/words/nfactor_enumerable_word.py # 2
doctests failed
[NB the preceding paths have been pre-eroded somhow, not by me]
3 and 4 look trivial to fix (typo in doctests?) but I am not sure. 5
is an iterator whose output is in a different order than expected.
John
1:
sage -t -long "devel/sage/sage/graphs/generic_graph.py"
**********************************************************************
File "/local/jec/sage-4.5.2.alpha0/devel/sage/sage/graphs/generic_graph.py",
line 11581:
sage: G.get_pos()
Expected:
{0: [1.17..., -0.855...],
1: [1.81..., -0.0990...],
2: [1.35..., 0.184...],
3: [1.51..., 0.644...],
4: [2.00..., -0.507...],
5: [0.597..., -0.236...],
6: [2.04..., 0.687...],
7: [1.46..., -0.473...],
8: [0.902..., 0.773...],
9: [2.48..., -0.119...]}
Got:
{0: [1.1644236010005358, -0.83686858657215979], 1:
[1.7943839700815074, -0.066920666682206337], 2: [1.2689961125613971,
0.14359096356381118], 3: [1.511860539628787, 0.59162048325984706], 4:
[1.9941403734258905, -0.53845815492480542], 5: [0.59110867097474395,
-0.2204272806589378], 6: [2.0144421480067041, 0.70158250822163282], 7:
[1.4603696336476519, -0.46717593533332896], 8: [0.90427280509063312,
0.79073173670301911], 9: [2.4603584159299983, -0.097675067576871527]}
2: reported elsewhere
3:
sage -t -long "devel/sage/sage/geometry/toric_lattice_element.pyx"
**********************************************************************
File "/local/jec/sage-4.5.2.alpha0/devel/sage/sage/geometry/toric_lattice_element.pyx",
line 235:
sage: n.set_immutable()
Expected:
2528502973977326415
Got nothing
4:sage -t -long "devel/sage/sage/geometry/cone.py"
**********************************************************************
File "/local/jec/sage-4.5.2.alpha0/devel/sage/sage/geometry/cone.py", line 559:
sage: c = Cone([(1,0), (0,1)])
Expected:
4372618627376133801
Got nothing
5:
sage -t -long "devel/sage/sage/combinat/words/nfactor_enumerable_word.py"
**********************************************************************
File "/local/jec/sage-4.5.2.alpha0/devel/sage/sage/combinat/words/nfactor_enumerable_word.py",
line 612:
sage: for i in range(10):
for u in w.bispecial_factors_iterator(i):
print i,u
Expected:
0 word:
1 word: 1
1 word: 0
2 word: 10
2 word: 01
3 word: 101
3 word: 010
4 word: 0110
4 word: 1001
6 word: 100110
6 word: 011001
8 word: 10010110
Got:
0 word:
1 word: 1
1 word: 0
2 word: 10
2 word: 01
3 word: 101
3 word: 010
4 word: 0110
4 word: 1001
6 word: 011001
6 word: 100110
8 word: 10010110
**********************************************************************
File "/local/jec/sage-4.5.2.alpha0/devel/sage/sage/combinat/words/nfactor_enumerable_word.py",
line 630:
sage: for u in w.bispecial_factors_iterator(): u
Expected:
word:
word: 1
word: 0
word: 10
word: 01
word: 101
word: 010
word: 0110
word: 1001
word: 100110
word: 011001
word: 10010110
Got:
word:
word: 1
word: 0
word: 10
word: 01
word: 101
word: 010
word: 0110
word: 1001
word: 011001
word: 100110
word: 10010110
>
> John
>
leif
>> 32-bit Suse test still running...
On 32-bit Ubuntu 9.04 (P4 Prescott 3.2GHz, gcc 4.3.3, native code)
I get nearly the same doctest errors as John gets (errors 2-5 are
identical here, see rest of his post at bottom), except:
1: (devel/sage/sage/graphs/generic_graph.py)
Doesn't terminate at all(?), gets killed even if I test just
that file, with SAGE_TIMEOUT_LONG=3600 (1 hour)!
(I hope this was also the reason for ptestlong time enormously
increasing, though the "coverage" went up, too.)
6: (an additional one)
sage -t -long
"devel/sage/sage/schemes/elliptic_curves/ell_number_field.py"
***************************************************************
File
"/home/leif/sage-4.5.2.alpha0/devel/sage/sage/schemes/elliptic_curves/ell_number_field.py",
line 444:
sage: EK.regulator_of_points([P,T])
Expected:
-1.23259516440783e-32
Got:
-4.93038065763132e-32
***************************************************************
1 items had failures:
1 of 42 in __main__.example_5
***Test Failed*** 1 failures.
For whitespace errors, see the file
/home/leif/.sage//tmp/.doctest_ell_number_field.py
[171.9 s]
For failure 2 (.../sagenb/misc/sageinspect.py), a patch is up at #9554
(but that has to be applied to the SageNB package/repo, and since the
SageNB spkg is about 19MB, I haven't uploaded a patched one).
I'm not sure if #9316 will fix that, too, but Mr. Wolf currently doesn't
(properly) act together with the doctesting frame work.
A few days ago, more than half a day after I had run the last doctests,
I found two Python orphans, one with 2 gp children, the other with more
than 30(!) ecm children, of which (at least) one was actually running -
otherwise I wouldn't have noticed that at all. sage-cleaner terminates
as soon as I kill the orphans.
The same happened with doctest failure 1 above, except that the orphan
had a single gap child.
Btw, this was also the very first time ATLAS failed to build on that
machine (with 6 make jobs as usual, since I had successfully built
4.5.alpha0...4.5.1 more than a dozen times with that many).
After pressing ^C (the process seemed to hang after "ATLAS failed to
build."), I resumed the build by simply reissuing "make build".
Apparently all packages not depending on ATLAS had been built at that
time. The continued build then succeeded.
With Sage 4.5/4.5.1, all doctests passed on that system (ptestlong, 2
threads as usual).
On Ubuntu 9.04 x86_64 (Core2, gcc 4.5.0, native code), 4.5.2.alpha0 with
a patched SageNB spkg (see above) passed all tests (ptestlong).
-Leif
John H Palmieri
> Hello,
>
> Mitesh Patel and I have released Sage 4.5.2.alpha0. Source tarball is at
>
sage.math: all tests passed except for the problem reported at #9554.
(I'm not going to keep mentioning this, so if I say "all tests
passed", I mean all tests except for this one.) The patch at #9554
looks pretty obviously right, but I haven't tested it.
a 64 bit Mac OS X 10.6.4 box: one failure:
sage -t -long "devel/sage/sage/symbolic/random_tests.py"
**********************************************************************
File "/Applications/sage_builds/sage-4.5.2.alpha0/devel/sage/sage/
symbolic/random_tests.py", line 236:
sage: random_expr(50, nvars=3, coeff_generator=CDF.random_element)
Expected:
factorial(floor((-0.314177274493 + 0.144437996366*I)/cosh(-v1^2*e/
v3) + cos((-0.708874026302 - 0.954135400334*I)*v3) -
zetaderiv(-0.228070288671 + 0.33842966472*I, 0.520184609653 -
0.734276246499*I)))^(-arccoth(-abs(((-0.804514286089 -
0.0293247734576*I)*v1 + (-0.804514286089 - 0.0293247734576*I)*v3 -
1.0)*elliptic_ec((-0.0263902659909 +
0.153261789843*I)*arccot(pi*catalan)))))
Got:
factorial(floor((-0.314177274493 + 0.144437996366*I)/cosh(-v1^2*e/
v3) - zetaderiv(-0.228070288671 + 0.33842966472*I, 0.520184609653 -
0.734276246499*I) + cos((-0.708874026302 - 0.954135400334*I)*v3)))^(-
arccoth(-abs(((-0.804514286089 - 0.0293247734576*I)*v1 +
(-0.804514286089 - 0.0293247734576*I)*v3 -
1.0)*elliptic_ec((-0.0263902659909 +
0.153261789843*I)*arccot(pi*catalan)))))
**********************************************************************
Looks like a discrepancy in the order terms are printed.
t2.math: seems to build successfully, but I get the following when I
try to start sage:
------------------------------------------------------------
Unhandled SIGSEGV: A segmentation fault occurred in Sage.
This probably occurred because a *compiled* component
of Sage has a bug in it (typically accessing invalid memory)
or is not properly wrapped with _sig_on, _sig_off.
You might want to run Sage under gdb with 'sage -gdb' to debug this.
Sage will now terminate (sorry).
------------------------------------------------------------
I haven't tried to debug this. I don't know how to use gdb, in any
case. Any suggestions about what the problem might be? You can find
the build in /scratch/palmieri/.
skynet machine cicero: still building. I'll report if any issues
arise.
skynet machine cleo: build completed, still doctesting. I'll report
if any issues arise.
skynet machine eno: all tests passed
skynet machine flavius: build completed, still doctesting. I'll
report if any issues arise.
skynet machine iras: the problem at #9456 comes up whenever I build on
this machine with parallel spkg building enabled, preventing the build
from completely successfully. Since that ticket has a patch with a
positive review, I've upgraded it to "blocker".
skynet machine lena: all tests passed
skynet machine menas: still building. I'll report if any issues
arise.
skynet machine sextus: still building. I'll report if any issues
arise.
skynet machine taurus: all tests passed
--
John
leif
> [...]
> skynet machine iras: the problem at #9456 comes up whenever I build on
> this machine with parallel spkg building enabled, preventing the build
> from completely successfully. Since that ticket has a patch with a
> positive review, I've upgraded it to "blocker".
Merged into 4.5.2.alpha1 about 2 hours ago. :)
(To those that don't have an eye on that ticket; it fixes deps s.t. zlib
is built *before* libpng, which actually depends on it.)
-Leif
Dan Drake
building R:
ld.so.1: R: fatal: libgcc_s.so.1: version `GCC_4.0.0' not found (required by fil
e /usr/local/gcc-4.2.4-sun-linker/lib/libgfortran.so.2)
ld.so.1: R: fatal: libgcc_s.so.1: open failed: No such file or directory
Full log is at
http://sage.math.washington.edu/home/drake/r-2.10.1.p2.log-4.5.2.alpha0.t2
David, any ideas? Many spkgs built fine, including ATLAS and numpy, so
it seems like the compiler is set up properly.
Rob Beezer
reported already.
64-bit Kubuntu 9.10 on Intel Core Duo with make -j2 and parallel
spkg building.
Rob
John H Palmieri
> The build of 4.5.2.alpha0 failed on t2.math with a libgcc error while
> building R:
>
> ld.so.1: R: fatal: libgcc_s.so.1: version `GCC_4.0.0' not found (required by fil
> e /usr/local/gcc-4.2.4-sun-linker/lib/libgfortran.so.2)
> ld.so.1: R: fatal: libgcc_s.so.1: open failed: No such file or directory
>
> David, any ideas? Many spkgs built fine, including ATLAS and numpy, so
> it seems like the compiler is set up properly.
Configured with: ../gcc-4.2.4/configure ...
In my log file (/scratch/palmieri/sage...), it says
Configured with: ../gcc-4.4.1/configure ...
So your version of gcc doesn't look right to me.
--
John
John H Palmieri
> skynet machine iras: the problem at #9456 comes up whenever I build on
> this machine with parallel spkg building enabled, preventing the build
> from completely successfully. Since that ticket has a patch with a
> positive review, I've upgraded it to "blocker".
sage -t -long "devel/sage/sage/graphs/genus.pyx"
**********************************************************************
File "/home/palmieri/iras/sage-4.5.2.alpha0/devel/sage/sage/graphs/
genus.pyx", line 129:
sage: get_memory_usage(t)
Expected:
0.0
Got:
-0.28125
**********************************************************************
Several machines (cleo, iras) get timeouts on generic_graph.py.
--
John
Dan Drake
> In your log file, it says
>
> Configured with: ../gcc-4.2.4/configure ...
>
> In my log file (/scratch/palmieri/sage...), it says
>
> Configured with: ../gcc-4.4.1/configure ...
>
> So your version of gcc doesn't look right to me.
Oops! I thought I was sourcing the right bits (as /etc/motd on t2 tells
me to), but I wasn't. Trying again now.
leif
> John Cremona wrote:
>>> 32-bit Suse test still running...
>
> On 32-bit Ubuntu 9.04 (P4 Prescott 3.2GHz, gcc 4.3.3, native code)
> I get nearly the same doctest errors as John gets (errors 2-5 are
> identical here, see rest of his post at bottom), except:
>
> 1: (devel/sage/sage/graphs/generic_graph.py)
>
> Doesn't terminate at all(?), gets killed even if I test just
> that file, with SAGE_TIMEOUT_LONG=3600 (1 hour)!
In Sage 4.5.1 it took 154.4 seconds on that machine (just retried that),
but I noticed the file has changed in 4.5.2.alpha0 anyway.
>
> (I hope this was also the reason for ptestlong time enormously
> increasing, though the "coverage" went up, too.)
Looks like, since ptestlong time hasn't increased that much on x86_64.
> [...]
> I'm not sure if #9316 will fix that, too, but Mr. Wolf currently doesn't
> (properly) act together with the doctesting frame work.
Applying #9316 (the non-rebased version!) just changed the error message
(now "... # Time out"), nothing else.
Deleting ~/.sage/gap/workspace-* and ~/.sage/tmp/.doctest_* and other
files left there didn't help either.
> A few days ago, more than half a day after I had run the last doctests,
> I found two Python orphans, one with 2 gp children, the other with more
> than 30(!) ecm children, of which (at least) one was actually running -
> otherwise I wouldn't have noticed that at all. sage-cleaner terminates
> as soon as I kill the orphans.
> The same happened with doctest failure 1 above, except that the orphan
> had a single gap child.
>
> [...]
>
> With Sage 4.5/4.5.1, all doctests passed on that system (ptestlong, 2
> threads as usual).
>
>
> On Ubuntu 9.04 x86_64 (Core2, gcc 4.5.0, native code), 4.5.2.alpha0 with
> a patched SageNB spkg (see above) passed all tests (ptestlong).
Same with gcc 4.3.3.
-Leif
> [cut off]
leif
> On iras (ia64-Linux-suse), after continuing the build, one failure:
>
> sage -t -long "devel/sage/sage/graphs/genus.pyx"
> **********************************************************************
> File "/home/palmieri/iras/sage-4.5.2.alpha0/devel/sage/sage/graphs/
> genus.pyx", line 129:
> sage: get_memory_usage(t)
> Expected:
> 0.0
> Got:
> -0.28125
> **********************************************************************
So whenever you run out of memory on that machine, start a few instances
of that program... :D :D :D
> Several machines (cleo, iras) get timeouts on generic_graph.py.
(Doesn't terminate within an hour here on 32-bit Ubuntu, Pentium 4...)
Is there somewhere a table mapping skynet (and perhaps *.math) machine
names to operating system, processor etc.?
-Leif
Dr. David Kirkby
> Is there somewhere a table mapping skynet (and perhaps *.math) machine
> names to operating system, processor etc.?
>
>
> -Leif
Not as I know of, but it would be very useful to have one.
I think it would be really useful if people put the hardware/software in trac
tickets and not just sage.math or whatever machine it is. These machines are not
static, and will no doubt change over time. Then when you want to look back at
an old ticket, you will often not know the configuration of the system at the
point the trac ticket was made.
This came an issue yesterday for me, when I was discussing with the Pari
developers this ticket
http://trac.sagemath.org/sage_trac/ticket/6445
A pari developer wanted to know what operating system 't2' was running at the
time, but I could not tell what revision it was from the ticket. The ticket is
about the same age as the time t2. was updated. Since the ticket was opened 13
months ago, I don't know what operating system t2 had at that point in time.
(Actually, I just noticed that if I hover over the '13 months', I can see the
exact date/time. Now I can resolve what OS the machine had - that is more luck
than anything else. I just happen to know the exact date Solaris was updated on
t2.math).
If you look at most of my tickets now, I put full information of the hardware I use
This one for instance refers to 'disk.math'
http://trac.sagemath.org/sage_trac/ticket/9405
It's not a perfect description. I should really fill in the exact hardware,
which I don't know. (Hence Leif's idea would be good).
Hardware �
* disk.math.washington.edu x64 hardware of some sort.
* OpenSolaris 2008.11 (snv_101b)
* 32 GB RAM
* 2 x quad core 2.3 GHz CPUs
but its better than just 'disk.math'.
http://trac.sagemath.org/sage_trac/ticket/9358
is another example
Hardware & associated software �
* Sun Blade 1000
* 2 x 900 MHz UltraSPARC III+ CPUs
* 2 GB RAM
* 8 GB swap
* Solaris 10 03/2005 (first release of Solaris 10)
* 147 GB SEAGATE-ST3146807FC 2 Gbit/s 15,000 rpm fiber channel disk (FCAL)
* UFS local file systems.
* gcc 4.4.3 (uses Sun linker and assembler)
* 64-bit build - SAGE64 was exported to "yes"
The statement of the disks and file system is not really necessary there - that
was a cut and past from a ticket where it was necessary.
I would encourage others to write what the hardware and software is, and not
simply assume others will know what sage.math is. Since in a year or two,
sage.math might be running a different version of the operating system, or have
more RAM. It might even be a different machine!
Once you have written it once, it only needs a cut-and-paste to put it on
another ticket. Just be careful if the hardware gets updated, you don't forget
to update your description.
FWI, 't2.math' is
* Sun SPARC Enterprise T5240 Server
* 2 x 1167 MHz T2+ UltraSPARC processors (16 cores, 128 hardware threads in total)
* 32 GB RAM
* No swap space.
* Solaris 10 5/09 (aka Solaris 10 update 7)
* 128-bit ZFS file systems.
* 2 x 146 GB Sun SCSI disks, in a mirrored configuration.
* gcc 4.4.1 configured to use the Sun linker and Sun assembler
(There are other gcc versions on t2.math, but that is the suggested setup in
/etc/motd)
* A default 32-bit build of Sage (unless you set SAGE64=yes, in which case it
would build 64-bit)
Also worth noting is whether you had MAKE and SAGE_PARALLEL_SPKG_BUILD or not.
Some issues clearly are a result of building in parallel, but that might not be
obvious at the time you create the ticket.
Obviously this is not necessary on all tickets. If spkg-check is missing from a
package, it's irrelevant what hardware you happened to notice it on. But it does
become relevant when you test your changes to put the hardware/software used.
Dave
Mitesh Patel
This is now a blocker for 4.5.2 (unless you disagree):
Mitesh Patel
> t2.math: seems to build successfully, but I get the following when I
> try to start sage:
>
> ------------------------------------------------------------
> Unhandled SIGSEGV: A segmentation fault occurred in Sage.
> This probably occurred because a *compiled* component
> of Sage has a bug in it (typically accessing invalid memory)
> or is not properly wrapped with _sig_on, _sig_off.
> You might want to run Sage under gdb with 'sage -gdb' to debug this.
> Sage will now terminate (sorry).
> ------------------------------------------------------------
>
> I haven't tried to debug this. I don't know how to use gdb, in any
> case. Any suggestions about what the problem might be? You can find
> the build in /scratch/palmieri/.
I've seen this, too, with
env MAKE="make -j64" SAGE_PARALLEL_SPKG_BUILD="yes" make build
(I've deleted the build to make room in t2's /scratch.)
If it helps: We merged only sage library patches (no new spkgs) in
4.5.2.alpha0.
This is now
Mitesh Patel
I've opened an umbrella ticket for these graph theory doctests:
leif
> leif wrote:
>> John Cremona wrote:
>>>> 32-bit Suse test still running...
>> On 32-bit Ubuntu 9.04 (P4 Prescott 3.2GHz, gcc 4.3.3, native code)
>> I get nearly the same doctest errors as John gets (errors 2-5 are
>> identical here, see rest of his post at bottom), except:
>>
>> 1: (devel/sage/sage/graphs/generic_graph.py)
>>
>> Doesn't terminate at all(?), gets killed even if I test just
>> that file, with SAGE_TIMEOUT_LONG=3600 (1 hour)!
Testing with "-verbose", I now experience the same doctest failure John
reported (and only that):
...
Trying:
P = G.plot(save_pos=True, layout='spring')###line 11577:_sage_
>>> P = G.plot(save_pos=True, layout='spring')
Expecting nothing
ok
Trying:
G.get_pos()###line 11581:_sage_ >>> G.get_pos()
Expecting:
{0: [1.17..., -0.855...],
1: [1.81..., -0.0990...],
2: [1.35..., 0.184...],
3: [1.51..., 0.644...],
4: [2.00..., -0.507...],
5: [0.597..., -0.236...],
6: [2.04..., 0.687...],
7: [1.46..., -0.473...],
8: [0.902..., 0.773...],
9: [2.48..., -0.119...]}
**********************************************************************
File
"/home/leif/sage-4.5.2.alpha0/devel/sage/sage/graphs/generic_graph.py",
line 8617, in __main__.example_191
Failed example:
G.get_pos()###line 11581:_sage_ >>> G.get_pos()
Expected:
{0: [1.17..., -0.855...],
1: [1.81..., -0.0990...],
2: [1.35..., 0.184...],
3: [1.51..., 0.644...],
4: [2.00..., -0.507...],
5: [0.597..., -0.236...],
6: [2.04..., 0.687...],
7: [1.46..., -0.473...],
8: [0.902..., 0.773...],
9: [2.48..., -0.119...]}
Got:
{0: [1.1644236010005358, -0.83686858657215979], 1:
[1.7943839700815074, -0.066920666682206337], 2: [1.2689961125613971,
0.14359096356381118], 3: [1.511860539628787, 0.59162048325984706], 4:
[1.9941403734258905, -0.53845815492480542], 5: [0.59110867097474395,
-0.2204272806589378], 6: [2.0144421480067041, 0.70158250822163282], 7:
[1.4603696336476519, -0.46717593533332896], 8: [0.90427280509063312,
0.79073173670301911], 9: [2.4603584159299983, -0.097675067576871527]}
Trying:
T = list(graphs.trees(Integer(7)))###line 11595:_sage_ >>> T =
list(graphs.trees(7))
Expecting nothing
ok
...
The following is the last output I get (note that the examples aren't
tested in order, i.e. original source line numbers usually aren't
monotonic):
Trying:
D.connected_component_containing_vertex(Integer(0))###line
3090:_sage_ >>> D.connected_component_containing_vertex(0)
Expecting:
[0, 1, 2, 3]
ok
Trying:
set_random_seed(0L)
Expecting nothing
ok
Trying:
change_warning_output(sys.stdout)
Expecting nothing
ok
Trying:
graphs.PetersenGraph().blocks_and_cut_vertices()###line 3117:_sage_
>>> graphs.PetersenGraph().blocks_and_cut_vertices()
Expecting:
([[6, 4, 9, 7, 5, 8, 3, 2, 1, 0]], [])
ok
Trying:
graphs.PathGraph(Integer(6)).blocks_and_cut_vertices()###line
3119:_sage_ >>> graphs.PathGraph(6).blocks_and_cut_vertices()
Expecting:
([[5, 4], [*** *** Error: TIMED OUT! PROCESS KILLED! *** ***
[3600.9 s]
----------------------------------------------------------------------
The following tests failed:
sage -t -long -verbose "devel/sage/sage/graphs/generic_graph.py" # Time out
Total time for all tests: 3600.9 seconds
real 60m1.029s
user 0m2.360s
sys 0m0.884s
The funny thing is that with "-verbose", I do not even get the shell
prompt back (I redirected stderr to stdout and tee'd it);
"./sage -t -long ..." terminates, but I guess its now orphan child
("python /home/leif/.sage//tmp/.doctest_generic_graph.py"[sic], which is
actually running - consuming CPU time, in contrast to its two gap
children, which sleep due to blocking reads) keeps at least one of the
file descriptors open...
John (Cremona), do you open a ticket for that (at least the doctest
failure we both get)?
-Leif
>> [cut off]
Mitesh Patel
http://sage.math.washington.edu/home/mpatel/scratch/tmp/old/patches-for-4.5.2.alpha0
is a copy of the patch queue, i.e., the contents of
sage-4.5.1/devel/sage/.hg/patches
we used to make 4.5.2.alpha0.
John H Palmieri
wrote:
>
> > Is there somewhere a table mapping skynet (and perhaps *.math) machine
> > names to operating system, processor etc.?
>
> > -Leif
>
> * disk.math.washington.edu x64 hardware of some sort.
> * OpenSolaris 2008.11 (snv_101b)
> * 32 GB RAM
> * 2 x quad core 2.3 GHz CPUs
For the skynet machines, uname (+ cpucount() in python on the machines
with a recent version of python installed, for the number of cores)
tells me:
eno x86_64-Linux-core2-fc (8 cores)
cicero x86-Linux-pentium4-fc (1 core)
cleo ia64-Linux-rhel (4 cores)
iras ia64-Linux-suse (4 cores)
menas x86_64-Linux-core2-suse (4 cores)
mark sparc-SunOS-ultrasparc3
mark2 sparc-SunOS-ultrasparc3
flavius x86_64-Linus-k8 (2 cores)
fulvia x86_64-SunOS-core2
lena x86_64-Linux-k10 (with NVIDIA GeForce GPUs) (4 cores)
sextus x86_64-Linux-netburst-fc (2 cores)
taurus x86_64-Linux-nehalem-fc (16 cores)
This gives some of the information Leif asked for.
--
John
Dr. David Kirkby
> On Jul 22, 11:43 pm, "Dr. David Kirkby"<david.kir...@onetel.net>
> wrote:
>> On 07/23/10 06:18 AM, leif wrote:
>>
>>> Is there somewhere a table mapping skynet (and perhaps *.math) machine
>>> names to operating system, processor etc.?
>>
>>> -Leif
>
>> Hardware
>>
>> * disk.math.washington.edu x64 hardware of some sort.
>> * OpenSolaris 2008.11 (snv_101b)
>> * 32 GB RAM
>> * 2 x quad core 2.3 GHz CPUs
>
> How do you get this information?
There are a number of commands I would use
* $ uname
* $ kstat
* $ /usr/sbin/prtconf
* $ /usr/sbin/psrinfo
* $ cat /etc/release
* # /usr/sbin/format (you need to be root).
* $ /usr/sbin/zpool
* Look at the contents of /var/adm/messages*
Apart from that, there is memconf
http://www.4schmidts.com/memconf.html
though you need to be root to run that on Some Solaris systems.
There are probably others I've forgotten.
-bash-3.2$ uname -p
i386
tells me it's some sort of x86 hardware.
-bash-3.2$ cat /etc/release
OpenSolaris 2008.11 snv_101b_rc2 X86
Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 19 November 2008
gives me the operating system.
-bash-3.2$ /usr/sbin/psrinfo -p
2
tells me there are two *physical* CPUs
-bash-3.2$ /usr/sbin/psrinfo
0 on-line since 12/30/2008 15:18:10
1 on-line since 12/30/2008 15:18:13
2 on-line since 12/30/2008 15:18:13
3 on-line since 12/30/2008 15:18:13
4 on-line since 12/30/2008 15:18:13
5 on-line since 12/30/2008 15:18:13
6 on-line since 12/30/2008 15:18:13
7 on-line since 12/30/2008 15:18:13
tell me there are 8 CPUs/cores/threads - I'm not sure how to resolve that
difference.
(My own Sun Ultra 27 workstation is a quad core hyperthreaded Xeon, and shows at
8 CPUs, despite there are really only 4 cores.)
-bash-3.2$ /usr/sbin/psrinfo -v
Status of virtual processor 0 as of: 07/23/2010 08:48:15
on-line since 12/30/2008 15:18:10.
The i386 processor operates at 2300 MHz,
and has an i387 compatible floating point processor.
Status of virtual processor 1 as of: 07/23/2010 08:48:15
on-line since 12/30/2008 15:18:13.
The i386 processor operates at 2300 MHz,
etc
tells me they CPUs run at 2300 MHz.
-bash-3.2$ prtconf | grep Memory
Memory size: 32768 Megabytes
tells me there are 32 GB of RAM
In the case of SPARC based Sun hardware, (which disk.math is not) you can get a
good idea of the model too. For on 't2' we can see it's a T5240.
kirkby@t2:[~] $ uname -a
SunOS t2 5.10 Generic_141414-02 sun4v sparc SUNW,T5240
On my Sun Blade 1000, I can see it is a Sun Blade 1000.
drkirkby@redstart:~$ uname -a
SunOS redstart 5.10 Generic sun4u sparc SUNW,Sun-Blade-1000
However, that is not perfect, as sometimes the same motherboard is used in more
than one machine, and you can't distinguish them. A Sun Blade 2000 displays
itself as a Sun Blade 1000. The motherboards are interchangeable. (In fact,
apart from the Blade 2000 being supported with faster CPUs, and looking a bit
nicer, I don't think there are any differences in the hardware.)
When a system boots, that gets logged to /var/adm/messages, so some information
is given there. But the log files get cycled, so after some time it will get
moved to /var/adm/messages.0 and so on. I can see on machine of mine, in
/var/adm/messages.0 that:
Jul 2 13:11:55 redstart genunix: [ID 540533 kern.notice] ^MSunOS Release 5.10
Version Generic 64-bit
Jul 2 13:11:55 redstart genunix: [ID 943906 kern.notice] Copyright 1983-2005
Sun Microsystems, Inc. All rights reserved.
Jul 2 13:11:55 redstart Use is subject to license terms.
Jul 2 13:11:55 redstart genunix: [ID 678236 kern.info] Ethernet address =
8:0:20:fb:1d:49
Jul 2 13:11:55 redstart unix: [ID 673563 kern.info] NOTICE: Kernel Cage is ENABLED
Jul 2 13:11:55 redstart unix: [ID 389951 kern.info] mem = 2097152K (0x80000000)
Jul 2 13:11:55 redstart unix: [ID 930857 kern.info] avail mem = 2082398208
Jul 2 13:11:55 redstart rootnex: [ID 466748 kern.info] root nexus =
SUNW,Sun-Blade-1000 (2 X UltraSPARC-III+)
Jul 2 13:11:55 redstart rootnex: [ID 349649 kern.info] pseudo0 at root
If you have root access, you can find out what the disks are. If they are Sun
badged disks, they will say Sun here
# format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c1t0d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848>
/pci@400/pci@0/pci@8/scsi@0/sd@0,0
1. c1t1d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848>
/pci@400/pci@0/pci@8/scsi@0/sd@1,0
Specify disk (enter its number):
But on my own machine, there's a generic Seagate fibre channel disk
# /usr/sbin/format
Searching for disks...done.
AVAILABLE DISK SELECTIONS:
0. c1t1d0 <SEAGATE-ST3146807FC-MS06 cyl 49780 alt 2 hd 8 sec 720>
/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100000c50b0bd54,0
'zpool' can tell you a lot about how the disks are configured, if ZFS file
systems are used, as they are on t2.
kirkby@t2:[~] $ /usr/sbin/zpool status
pool: rootpool
state: ONLINE
scrub: scrub completed after 0h22m with 0 errors on Mon Jul 12 00:17:40 2010
config:
NAME STATE READ WRITE CKSUM
rootpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c1t0d0s3 ONLINE 0 0 0
c1t1d0s3 ONLINE 0 0 0
errors: No known data errors
pool: rootpool2
state: ONLINE
scrub: scrub completed after 0h31m with 0 errors on Mon Jul 12 00:21:29 2010
config:
NAME STATE READ WRITE CKSUM
rootpool2 ONLINE 0 0 0
mirror ONLINE 0 0 0
c1t0d0s7 ONLINE 0 0 0
c1t1d0s7 ONLINE 0 0 0
errors: No known data errors
You can find out a lot of information from /usr/sbin/prtconf -v
drkirkby@redstart:~$ /usr/sbin/prtconf -v | grep SPARC
SUNW,UltraSPARC-III+, instance #0
SUNW,UltraSPARC-III+, instance #1
value='/SUNW,UltraSPARC-III@*' +
'/SUNW,UltraSPARC-III+@*' + '/pci@8,700000' + '/upa@8,480000' +
'/pci@8,700000/firewire@5,2' + '/pci@8,700000/ebus@5/floppy@1,3023f0' +
'/pci@8,700000/scsi@6' + '/pci@8,600000/SUNW,qlc@4'
kirkby@t2:[~] $ /usr/sbin/prtdiag
System Configuration: Sun Microsystems sun4v T5240
Memory size: 32544 Megabytes
================================ Virtual CPUs ================================
CPU ID Frequency Implementation Status
------ --------- ---------------------- -------
0 1167 MHz SUNW,UltraSPARC-T2+ on-line
1 1167 MHz SUNW,UltraSPARC-T2+ on-line
2 1167 MHz SUNW,UltraSPARC-T2+ on-line
3 1167 MHz SUNW,UltraSPARC-T2+ on-line
4 1167 MHz SUNW,UltraSPARC-T2+ on-line
5 1167 MHz SUNW,UltraSPARC-T2+ on-line
6 1167 MHz SUNW,UltraSPARC-T2+ on-line
7 1167 MHz SUNW,UltraSPARC-T2+ on-line
8 1167 MHz SUNW,UltraSPARC-T2+ on-line
9 1167 MHz SUNW,UltraSPARC-T2+ on-line
10 1167 MHz SUNW,UltraSPARC-T2+ on-line
11 1167 MHz SUNW,UltraSPARC-T2+ on-line
12 1167 MHz SUNW,UltraSPARC-T2+ on-line
13 1167 MHz SUNW,UltraSPARC-T2+ on-line
14 1167 MHz SUNW,UltraSPARC-T2+ on-line
15 1167 MHz SUNW,UltraSPARC-T2+ on-line
16 1167 MHz SUNW,UltraSPARC-T2+ on-line
17 1167 MHz SUNW,UltraSPARC-T2+ on-line
18 1167 MHz SUNW,UltraSPARC-T2+ on-line
19 1167 MHz SUNW,UltraSPARC-T2+ on-line
20 1167 MHz SUNW,UltraSPARC-T2+ on-line
21 1167 MHz SUNW,UltraSPARC-T2+ on-line
22 1167 MHz SUNW,UltraSPARC-T2+ on-line
23 1167 MHz SUNW,UltraSPARC-T2+ on-line
24 1167 MHz SUNW,UltraSPARC-T2+ on-line
25 1167 MHz SUNW,UltraSPARC-T2+ on-line
26 1167 MHz SUNW,UltraSPARC-T2+ on-line
27 1167 MHz SUNW,UltraSPARC-T2+ on-line
28 1167 MHz SUNW,UltraSPARC-T2+ on-line
29 1167 MHz SUNW,UltraSPARC-T2+ on-line
30 1167 MHz SUNW,UltraSPARC-T2+ on-line
31 1167 MHz SUNW,UltraSPARC-T2+ on-line
32 1167 MHz SUNW,UltraSPARC-T2+ on-line
33 1167 MHz SUNW,UltraSPARC-T2+ on-line
34 1167 MHz SUNW,UltraSPARC-T2+ on-line
35 1167 MHz SUNW,UltraSPARC-T2+ on-line
36 1167 MHz SUNW,UltraSPARC-T2+ on-line
37 1167 MHz SUNW,UltraSPARC-T2+ on-line
38 1167 MHz SUNW,UltraSPARC-T2+ on-line
39 1167 MHz SUNW,UltraSPARC-T2+ on-line
40 1167 MHz SUNW,UltraSPARC-T2+ on-line
41 1167 MHz SUNW,UltraSPARC-T2+ on-line
42 1167 MHz SUNW,UltraSPARC-T2+ on-line
43 1167 MHz SUNW,UltraSPARC-T2+ on-line
44 1167 MHz SUNW,UltraSPARC-T2+ on-line
45 1167 MHz SUNW,UltraSPARC-T2+ on-line
46 1167 MHz SUNW,UltraSPARC-T2+ on-line
47 1167 MHz SUNW,UltraSPARC-T2+ on-line
48 1167 MHz SUNW,UltraSPARC-T2+ on-line
49 1167 MHz SUNW,UltraSPARC-T2+ on-line
50 1167 MHz SUNW,UltraSPARC-T2+ on-line
51 1167 MHz SUNW,UltraSPARC-T2+ on-line
52 1167 MHz SUNW,UltraSPARC-T2+ on-line
53 1167 MHz SUNW,UltraSPARC-T2+ on-line
54 1167 MHz SUNW,UltraSPARC-T2+ on-line
55 1167 MHz SUNW,UltraSPARC-T2+ on-line
56 1167 MHz SUNW,UltraSPARC-T2+ on-line
57 1167 MHz SUNW,UltraSPARC-T2+ on-line
58 1167 MHz SUNW,UltraSPARC-T2+ on-line
59 1167 MHz SUNW,UltraSPARC-T2+ on-line
60 1167 MHz SUNW,UltraSPARC-T2+ on-line
61 1167 MHz SUNW,UltraSPARC-T2+ on-line
62 1167 MHz SUNW,UltraSPARC-T2+ on-line
63 1167 MHz SUNW,UltraSPARC-T2+ on-line
64 1167 MHz SUNW,UltraSPARC-T2+ on-line
65 1167 MHz SUNW,UltraSPARC-T2+ on-line
66 1167 MHz SUNW,UltraSPARC-T2+ on-line
67 1167 MHz SUNW,UltraSPARC-T2+ on-line
68 1167 MHz SUNW,UltraSPARC-T2+ on-line
69 1167 MHz SUNW,UltraSPARC-T2+ on-line
70 1167 MHz SUNW,UltraSPARC-T2+ on-line
71 1167 MHz SUNW,UltraSPARC-T2+ on-line
72 1167 MHz SUNW,UltraSPARC-T2+ on-line
73 1167 MHz SUNW,UltraSPARC-T2+ on-line
74 1167 MHz SUNW,UltraSPARC-T2+ on-line
75 1167 MHz SUNW,UltraSPARC-T2+ on-line
76 1167 MHz SUNW,UltraSPARC-T2+ on-line
77 1167 MHz SUNW,UltraSPARC-T2+ on-line
78 1167 MHz SUNW,UltraSPARC-T2+ on-line
79 1167 MHz SUNW,UltraSPARC-T2+ on-line
80 1167 MHz SUNW,UltraSPARC-T2+ on-line
81 1167 MHz SUNW,UltraSPARC-T2+ on-line
82 1167 MHz SUNW,UltraSPARC-T2+ on-line
83 1167 MHz SUNW,UltraSPARC-T2+ on-line
84 1167 MHz SUNW,UltraSPARC-T2+ on-line
85 1167 MHz SUNW,UltraSPARC-T2+ on-line
86 1167 MHz SUNW,UltraSPARC-T2+ on-line
87 1167 MHz SUNW,UltraSPARC-T2+ on-line
88 1167 MHz SUNW,UltraSPARC-T2+ on-line
89 1167 MHz SUNW,UltraSPARC-T2+ on-line
90 1167 MHz SUNW,UltraSPARC-T2+ on-line
91 1167 MHz SUNW,UltraSPARC-T2+ on-line
92 1167 MHz SUNW,UltraSPARC-T2+ on-line
93 1167 MHz SUNW,UltraSPARC-T2+ on-line
94 1167 MHz SUNW,UltraSPARC-T2+ on-line
95 1167 MHz SUNW,UltraSPARC-T2+ on-line
96 1167 MHz SUNW,UltraSPARC-T2+ on-line
97 1167 MHz SUNW,UltraSPARC-T2+ on-line
98 1167 MHz SUNW,UltraSPARC-T2+ on-line
99 1167 MHz SUNW,UltraSPARC-T2+ on-line
100 1167 MHz SUNW,UltraSPARC-T2+ on-line
101 1167 MHz SUNW,UltraSPARC-T2+ on-line
102 1167 MHz SUNW,UltraSPARC-T2+ on-line
103 1167 MHz SUNW,UltraSPARC-T2+ on-line
104 1167 MHz SUNW,UltraSPARC-T2+ on-line
105 1167 MHz SUNW,UltraSPARC-T2+ on-line
106 1167 MHz SUNW,UltraSPARC-T2+ on-line
107 1167 MHz SUNW,UltraSPARC-T2+ on-line
108 1167 MHz SUNW,UltraSPARC-T2+ on-line
109 1167 MHz SUNW,UltraSPARC-T2+ on-line
110 1167 MHz SUNW,UltraSPARC-T2+ on-line
111 1167 MHz SUNW,UltraSPARC-T2+ on-line
112 1167 MHz SUNW,UltraSPARC-T2+ on-line
113 1167 MHz SUNW,UltraSPARC-T2+ on-line
114 1167 MHz SUNW,UltraSPARC-T2+ on-line
115 1167 MHz SUNW,UltraSPARC-T2+ on-line
116 1167 MHz SUNW,UltraSPARC-T2+ on-line
117 1167 MHz SUNW,UltraSPARC-T2+ on-line
118 1167 MHz SUNW,UltraSPARC-T2+ on-line
119 1167 MHz SUNW,UltraSPARC-T2+ on-line
120 1167 MHz SUNW,UltraSPARC-T2+ on-line
121 1167 MHz SUNW,UltraSPARC-T2+ on-line
122 1167 MHz SUNW,UltraSPARC-T2+ on-line
123 1167 MHz SUNW,UltraSPARC-T2+ on-line
124 1167 MHz SUNW,UltraSPARC-T2+ on-line
125 1167 MHz SUNW,UltraSPARC-T2+ on-line
126 1167 MHz SUNW,UltraSPARC-T2+ on-line
127 1167 MHz SUNW,UltraSPARC-T2+ on-line
======================= Physical Memory Configuration ========================
Segment Table:
--------------------------------------------------------------
Base Segment Interleave Bank Contains
Address Size Factor Size Modules
--------------------------------------------------------------
0x0 32 GB 8 4 GB MB/CMP0/BR0/CH0/D0
MB/CMP0/BR0/CH1/D0
4 GB MB/CMP0/BR1/CH0/D0
MB/CMP0/BR1/CH1/D0
4 GB MB/CMP1/BR0/CH0/D0
MB/CMP1/BR0/CH1/D0
4 GB MB/CMP1/BR1/CH0/D0
MB/CMP1/BR1/CH1/D0
4 GB MB/CMP0/BR0/CH0/D1
MB/CMP0/BR0/CH1/D1
4 GB MB/CMP0/BR1/CH0/D1
MB/CMP0/BR1/CH1/D1
4 GB MB/CMP1/BR0/CH0/D1
MB/CMP1/BR0/CH1/D1
4 GB MB/CMP1/BR1/CH0/D1
MB/CMP1/BR1/CH1/D1
================================ IO Devices ================================
Slot + Bus Name + Model
Status Type Path
----------------------------------------------------------------------------
MB PCIE scsi-pciex1000,58 LSI,1068E
/pci@400/pci@0/pci@8/scsi@0
MB/XAUI0 PCIE network-pciex108e,abcd SUNW,pcie-neptune
/pci@500/pci@0/pci@8/network@0
MB/NET1 PCIE network-pciex108e,abcd SUNW,pcie-neptune
/pci@500/pci@0/pci@8/network@0,1
MB/NET2 PCIE network-pciex108e,abcd SUNW,pcie-neptune
/pci@500/pci@0/pci@8/network@0,2
MB/NET3 PCIE network-pciex108e,abcd SUNW,pcie-neptune
/pci@500/pci@0/pci@8/network@0,3
MB/USB0 PCIE usb-pciclass,0c0310
/pci@400/pci@0/pci@1/pci@0/usb@0
MB/USB0 PCIE usb-pciclass,0c0310
/pci@400/pci@0/pci@1/pci@0/usb@0,1
MB/USB0 PCIE usb-pciclass,0c0320
/pci@400/pci@0/pci@1/pci@0/usb@0,2
============================ Environmental Status ============================
Fan sensors:
All fan sensors are OK.
Temperature sensors:
All temperature sensors are OK.
Current sensors:
All current sensors are OK.
Voltage sensors:
All voltage sensors are OK.
Voltage indicators:
All voltage indicators are OK.
============================ FRU Status ============================
All FRUs are enabled.
Another possible useful command is 'memconf'
http://www.4schmidts.com/memconf.html
but that is not part of Solaris
drkirkby@hawk:~$ ./memconf -v
memconf: V2.15 08-Jun-2010 http://www.4schmidts.com/unix.html
hostname: hawk
manufacturer: Sun Microsystems, Inc.
model: Ultra 27 (Quad-Core Hyper-Threaded Intel(R) Xeon(R) W3580 3325MHz)
OpenSolaris Development snv_134 X86, 64-bit kernel, SunOS 5.11
1 Quad-Core Hyper-Threaded Intel(R) Xeon(R) W3580 3325MHz cpu
CPU Units:
==== Processor Sockets ====================================
Version Location Tag
-------------------------------- --------------------------
Intel(R) Xeon(R) CPU W3580 @ 3.33GHz CPU 1
Memory Units:
socket DIMM0: Micron 2048MB 18JSF25672AZ-1G4F1 DIMM, BANK0
socket DIMM1: Nanya Technology 2048MB NT2GC72B8PA0NF-CG DIMM, BANK1
socket DIMM2: Micron 2048MB 18JSF25672AZ-1G4F1 DIMM, BANK2
socket DIMM3: Micron 2048MB 18JSF25672AZ-1G4F1 DIMM, BANK3
socket DIMM4: Micron 2048MB 18JSF25672AZ-1G4F1 DIMM, BANK4
socket DIMM5: Micron 2048MB 18JSF25672AZ-1G4F1 DIMM, BANK5
empty memory sockets: None
total memory = 12288MB (12GB)
On my Sun at home:
drkirkby@hawk:~$ kstat | grep Xeon
brand Intel(r) Xeon(r) CPU W3580 @ 3.33GHz
brand Intel(r) Xeon(r) CPU W3580 @ 3.33GHz
brand Intel(r) Xeon(r) CPU W3580 @ 3.33GHz
brand Intel(r) Xeon(r) CPU W3580 @ 3.33GHz
brand Intel(r) Xeon(r) CPU W3580 @ 3.33GHz
brand Intel(r) Xeon(r) CPU W3580 @ 3.33GHz
brand Intel(r) Xeon(r) CPU W3580 @ 3.33GHz
brand Intel(r) Xeon(r) CPU W3580 @ 3.33GHz
John H Palmieri
> On 07/23/10 04:02 PM, John H Palmieri wrote:
>
>
>
>
>
> > On Jul 22, 11:43 pm, "Dr. David Kirkby"<david.kir...@onetel.net>
> > wrote:
> >> On 07/23/10 06:18 AM, leif wrote:
>
> >>> Is there somewhere a table mapping skynet (and perhaps *.math) machine
> >>> names to operating system, processor etc.?
>
> >>> -Leif
>
> >> Hardware
>
> >> * disk.math.washington.edu x64 hardware of some sort.
> >> * OpenSolaris 2008.11 (snv_101b)
> >> * 32 GB RAM
> >> * 2 x quad core 2.3 GHz CPUs
>
> > How do you get this information?
>
> There are a number of commands I would use
>
> * $ uname
> * $ kstat
> * $ /usr/sbin/prtconf
> * $ /usr/sbin/psrinfo
> * $ cat /etc/release
> * # /usr/sbin/format (you need to be root).
> * $ /usr/sbin/zpool
> * Look at the contents of /var/adm/messages*
machines). I haven't tried the other machines; maybe they would work
on the solaris machines, but since Sage doesn't build on those yet,
that's not as helpful.
- uname works
- missing: format, kstat, prtconf, psrinfo, zpool (not in PATH, /usr/
sbin/, or /sbin/)
I found "lscpu", though.
$ uname -a
Linux eno 2.6.32.12-115.fc12.x86_64 #1 SMP Fri Apr 30 19:46:25 UTC
2010 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/redhat-release
Fedora release 12 (Constantine)
$ lscpu
Architecture: x86_64
CPU(s): 8
Thread(s) per core: 1
Core(s) per socket: 4
CPU socket(s): 2
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 15
Stepping: 7
CPU MHz: 2333.331
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 4096K
I'm not sure how to get RAM information. Maybe today I'll start
assembling some information about these machines if I have a chance.
--
John
Dr. David Kirkby
Most of these sorts of commands are very operating system specific. Those I gave
were for Solaris. You would no doubt use a different set for Linux. There's a
script on trac that gives system information on linux boxes
http://trac.sagemath.org/sage_trac/ticket/8048
I thought you were asking about disk.math - hence my answer was Solaris-specific.
Dave
John H Palmieri
<http://wiki.sagemath.org/skynet>
Of course feel free to edit it as you see fit. (This used to be a
page about building Sage 3.0.4 on skynet, so it was terribly
outdated.)
--
John
Mitesh Patel
> The following tests failed:
> [...]
> 3 sage -t -long ge/sage/geometry/toric_lattice_element.pyx # 1 doctests failed
> 4 sage -t -long ge/sage/geometry/cone.py # 1 doctests failed
These are now
http://trac.sagemath.org/sage_trac/ticket/9590
> 5 sage -t -long ge/sage/combinat/words/nfactor_enumerable_word.py # 2 doctests failed
This is now
http://trac.sagemath.org/sage_trac/ticket/9589
All blockers for Sage 4.5.2:
Mitesh Patel
> John Cremona wrote:
>>> 32-bit Suse test still running...
>
> On 32-bit Ubuntu 9.04 (P4 Prescott 3.2GHz, gcc 4.3.3, native code)
> I get nearly the same doctest errors as John gets (errors 2-5 are
> identical here, see rest of his post at bottom), except:
>
>
> sage -t -long
> "devel/sage/sage/schemes/elliptic_curves/ell_number_field.py"
> ***************************************************************
> File
> "/home/leif/sage-4.5.2.alpha0/devel/sage/sage/schemes/elliptic_curves/ell_number_field.py",
> line 444:
> sage: EK.regulator_of_points([P,T])
> Expected:
> -1.23259516440783e-32
> Got:
> -4.93038065763132e-32
> ***************************************************************
> 1 items had failures:
> 1 of 42 in __main__.example_5
> ***Test Failed*** 1 failures.
> For whitespace errors, see the file
> /home/leif/.sage//tmp/.doctest_ell_number_field.py
> [171.9 s]
Has anyone else seen this failure with 4.5.2.alpha0? Leif, if this is
reproducible, could you open a blocker ticket for milestone 4.5.2?
leif
> On 07/22/2010 09:44 AM, John Cremona wrote about 32-bit SUSE tests:
>> The following tests failed:
>> [...]
>> 3 sage -t -long ge/sage/geometry/toric_lattice_element.pyx # 1 doctests failed
>> 4 sage -t -long ge/sage/geometry/cone.py # 1 doctests failed
>
> These are now
>
> http://trac.sagemath.org/sage_trac/ticket/9590
I've positively reviewed that, but haven't (yet) changed its status.
>> 5 sage -t -long ge/sage/combinat/words/nfactor_enumerable_word.py # 2 doctests failed
>
> This is now
>
> http://trac.sagemath.org/sage_trac/ticket/9589
I've given that positive review.
-Leif
Carl Witty
> 1:
> sage -t -long "devel/sage/sage/graphs/generic_graph.py"
> **********************************************************************
> File "/local/jec/sage-4.5.2.alpha0/devel/sage/sage/graphs/generic_graph.py",
> line 11581:
> Expected:
> {0: [1.17..., -0.855...],
> 1: [1.81..., -0.0990...],
> 2: [1.35..., 0.184...],
> 3: [1.51..., 0.644...],
> 4: [2.00..., -0.507...],
> 5: [0.597..., -0.236...],
> 6: [2.04..., 0.687...],
> 7: [1.46..., -0.473...],
> 8: [0.902..., 0.773...],
> 9: [2.48..., -0.119...]}
> Got:
> {0: [1.1644236010005358, -0.83686858657215979], 1:
> [1.7943839700815074, -0.066920666682206337], 2: [1.2689961125613971,
> 0.14359096356381118], 3: [1.511860539628787, 0.59162048325984706], 4:
> [1.9941403734258905, -0.53845815492480542], 5: [0.59110867097474395,
> -0.2204272806589378], 6: [2.0144421480067041, 0.70158250822163282], 7:
> [1.4603696336476519, -0.46717593533332896], 8: [0.90427280509063312,
> 0.79073173670301911], 9: [2.4603584159299983, -0.097675067576871527]}
I suspect that this is due to #9593 -- the spring layout algorithm
does not converge at all on this graph; every iteration jerks all the
vertices around into a very different layout. Then my theory is that
this chaotic motion amplifies tiny floating-point differences (like
the difference between 80-bit floating point numbers used by default
on 32-bit x86 and 64-bit floating point used by default on 64-bit x86)
into large, visible differences.
Carl
Harald Schilly
> Please build, test, and report any issues.
builds fine for me on
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12)
Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz
ubuntu 8.10 32bit
failures with make ptestlong:
sage -t -long local/lib/python2.6/site-packages/sagenb-0.8.1-
py2.6.egg/sagenb/misc/sageinspect.py # 1 doctests failed
sage -t -long devel/sage/sage/graphs/generic_graph.py # 1 doctests
failed
sage -t -long devel/sage/sage/combinat/words/
nfactor_enumerable_word.py # 2 doctests failed
sage -t -long devel/sage/sage/geometry/cone.py # 1 doctests failed
sage -t -long devel/sage/sage/geometry/toric_lattice_element.pyx # 1
doctests failed
sage/geometry/toric_lattice_element.pyx", line 235:
sage: n.set_immutable()
Expected:
2528502973977326415
Got nothing
sage/geometry/cone.py", line 559:
sage: c = Cone([(1,0), (0,1)])
Expected:
4372618627376133801
Got nothing
local/lib/python2.6/site-packages/sagenb-0.8.1-py2.6.egg/sagenb/misc/
sageinspect.py", line 997:
sage: sage_getvariablename(A)
Expected:
['A', 'B']
Got:
['B', 'A']
/sage/graphs/generic_graph.py", line 11581:
sage: G.get_pos()
Expected:
{0: [1.17..., -0.855...],
1: [1.81..., -0.0990...],
2: [1.35..., 0.184...],
3: [1.51..., 0.644...],
4: [2.00..., -0.507...],
5: [0.597..., -0.236...],
6: [2.04..., 0.687...],
7: [1.46..., -0.473...],
8: [0.902..., 0.773...],
9: [2.48..., -0.119...]}
Got:
{0: [1.1644236010005358, -0.83686858657215979], 1:
[1.7943839700815074, -0.066920666682206337], 2: [1.2689961125613971,
0.14359096356381118], 3: [1.511860539628787, 0.59162048325984706], 4:
[1.9941403734258905, -0.53845815492480542], 5: [0.59110867097474395,
-0.2204272806589378], 6: [2.0144421480067041, 0.70158250822163282], 7:
[1.4603696336476519, -0.46717593533332896], 8: [0.90427280509063312,
0.79073173670301911], 9: [2.4603584159299983, -0.097675067576871527]}
**********************************************************************
File "/scratch/scratch/schilly/sage/sage-4.5.2.alpha0/devel/sage-main/
sage/combinat/words/nfactor_enumerable_word.py", line 612:
sage: for i in range(10):
for u in w.bispecial_factors_iterator(i):
print i,u
Expected:
0 word:
1 word: 1
1 word: 0
2 word: 10
2 word: 01
3 word: 101
3 word: 010
4 word: 0110
4 word: 1001
6 word: 100110
6 word: 011001
8 word: 10010110
Got:
0 word:
1 word: 1
1 word: 0
2 word: 10
2 word: 01
3 word: 101
3 word: 010
4 word: 0110
4 word: 1001
6 word: 011001
6 word: 100110
8 word: 10010110
sage/combinat/words/nfactor_enumerable_word.py", line 630:
sage: for u in w.bispecial_factors_iterator(): u
Expected:
word:
word: 1
word: 0
word: 10
word: 01
word: 101
word: 010
word: 0110
word: 1001
word: 100110
word: 011001
word: 10010110
Got:
word:
word: 1
word: 0
word: 10
word: 01
word: 101
word: 010
word: 0110
word: 1001
word: 011001
word: 100110
word: 10010110
**********************************************************************
Rob Beezer
exactly the same 5 failures John Cremona reported below.
Just coincidentally, this is a fresh install with almost nothing added
yet.
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
/proc/cpuinfo:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 2.00GHz
stepping : 8
cpu MHz : 800.000
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov
clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts est tm2
bogomips : 1596.02
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 32 bits virtual
power management:
On Jul 22, 7:44 am, John Cremona <john.crem...@gmail.com> wrote:
> > 32-bit Suse test still running...
>
>
> 1 sage -t -long ge/sage/graphs/generic_graph.py # 1 doctests failed
> 2 sage -t -long
> b/python2.6/site-packages/sagenb-0.8.1-py2.6.egg/sagenb/misc/sageinspect.py
> # 1 doctests failed
> 4 sage -t -long ge/sage/geometry/cone.py # 1 doctests failed
> doctests failed
>
>
> 3 and 4 look trivial to fix (typo in doctests?) but I am not sure. 5
> is an iterator whose output is in a different order than expected.
>
> John
> 1:
> sage -t -long "devel/sage/sage/graphs/generic_graph.py"
> **********************************************************************
> sage: G.get_pos()
> Expected:
> {0: [1.17..., -0.855...],
> 1: [1.81..., -0.0990...],
> 2: [1.35..., 0.184...],
> 3: [1.51..., 0.644...],
> 4: [2.00..., -0.507...],
> 5: [0.597..., -0.236...],
> 6: [2.04..., 0.687...],
> 7: [1.46..., -0.473...],
> 8: [0.902..., 0.773...],
> 9: [2.48..., -0.119...]}
> Got:
> {0: [1.1644236010005358, -0.83686858657215979], 1:
> [1.7943839700815074, -0.066920666682206337], 2: [1.2689961125613971,
> 0.14359096356381118], 3: [1.511860539628787, 0.59162048325984706], 4:
> [1.9941403734258905, -0.53845815492480542], 5: [0.59110867097474395,
> -0.2204272806589378], 6: [2.0144421480067041, 0.70158250822163282], 7:
> [1.4603696336476519, -0.46717593533332896], 8: [0.90427280509063312,
> 0.79073173670301911], 9: [2.4603584159299983, -0.097675067576871527]}
>
>
> 3:
> sage -t -long "devel/sage/sage/geometry/toric_lattice_element.pyx"
> **********************************************************************
> File "/local/jec/sage-4.5.2.alpha0/devel/sage/sage/geometry/toric_lattice_element.pyx",
> sage: n.set_immutable()
> Expected:
> 2528502973977326415
> Got nothing
>
> **********************************************************************
> File "/local/jec/sage-4.5.2.alpha0/devel/sage/sage/geometry/cone.py", line 559:
> Expected:
> 4372618627376133801
> Got nothing
>
>
> sage -t -long "devel/sage/sage/combinat/words/nfactor_enumerable_word.py"
> **********************************************************************
> File "/local/jec/sage-4.5.2.alpha0/devel/sage/sage/combinat/words/nfactor_enumerable_word.py",
> File "/local/jec/sage-4.5.2.alpha0/devel/sage/sage/combinat/words/nfactor_enumerable_word.py",
Samuel Lelievre
> Mitesh Patel and I have released Sage 4.5.2.alpha0. Source tarball is at
> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha0/sage-4...
I tried to build on a MacBook Pro with Mac OS X 10.5.8, but it failed.
Below are excerpts of the build session output, including the final
bit.
Samuel
[Sat 2010-07-24]
$ cd s452a0
$ export SAGE_CHECK="yes"
$ export MAKE="make -j2"
$ make
...
Starting prerequisite check.
Machine: Darwin Comp 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15
16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
...
/usr/bin/install -c ./install-sh /Users/name/s452a0/local/lib/
python2.6/config/install-sh
# Substitution happens here, as the completely-expanded BINDIR
# is not available in configure
sed -e "s,@EXENAME@,/Users/name/s452a0/local/bin/python2.6," < ./Misc/
python-config.in >python-config
/usr/bin/install -c python-config /Users/name/s452a0/local/bin/
python2.6-config
rm python-config
DYLD_LIBRARY_PATH=`pwd`:/Users/name/s452a0/local/lib/R/lib:/Users/name/
s452a0/local/lib/openmpi:/Users/name/s452a0/local/lib/:::/Users/name/
s452a0/local/lib/R/lib ./python.exe -E ./setup.py install \
--prefix=/Users/name/s452a0/local \
--install-scripts=/Users/name/s452a0/local/bin \
--install-platlib=/Users/name/s452a0/local/lib/python2.6/lib-dynload
\
--root=/
running install
running build
running build_ext
Failed to find the necessary bits to build these modules:
bsddb185 gdbm linuxaudiodev
ossaudiodev spwd sunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for
the module's name.
...
Successfully installed python-2.6.4.p9
Running the test suite.
Testing the Python package
running build
running build_ext
Failed to find the necessary bits to build these modules:
bsddb185 gdbm linuxaudiodev
ossaudiodev spwd sunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for
the module's name.
...
test test_asynchat produced unexpected output:
**********************************************************************
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x173e5a8> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x173e468> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x173e440> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x173e738> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x173e6e8> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x173e468> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x173e440> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x173e7d8> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x173e6e8> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x173e468> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x173e7b0> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x173e710> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x173e5a8> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x173e468> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x173e7b0> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x173e710> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
**********************************************************************
...
test_ctypes
test test_ctypes failed -- Traceback (most recent call last):
File "/Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/ctypes/
test/test_macholib.py", line 55, in test_find
self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError
...
test_distutils
test test_distutils failed -- errors occurred; run in verbose mode for
details
...
test_smtplib
test test_smtplib produced unexpected output:
**********************************************************************
error: uncaptured python exception, closing channel
<test.test_smtplib.SimSMTPChannel 127.0.0.1:52970 at 0x38e02b0>
(<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/name/
s452a0/spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/
Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|
handle_expt_event|441] [<string>|getsockopt|1] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_smtplib.SimSMTPChannel 127.0.0.1:52974 at 0x38e0300>
(<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/name/
s452a0/spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/
Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|
handle_expt_event|441] [<string>|getsockopt|1] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_smtplib.SimSMTPChannel 127.0.0.1:52978 at 0x38e0788>
(<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/name/
s452a0/spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/
Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|
handle_expt_event|441] [<string>|getsockopt|1] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/socket.py|_dummy|167])
**********************************************************************
...
test_socket
test test_socket failed -- Traceback (most recent call last):
File "/Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/test/
test_socket.py", line 474, in testSockName
my_ip_addr = socket.gethostbyname(socket.gethostname())
gaierror: [Errno 8] nodename nor servname provided, or not known
...
test_sundry
/Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/test/
test_sundry.py:66: DeprecationWarning: The posixfile module is
deprecated; fcntl.lockf() provides better locking
import posixfile
...
test_thread
Unhandled exception in thread started by <bound method
ThreadRunningTests.task of <test.test_thread.ThreadRunningTests
testMethod=test_starting_threads>>
Traceback (most recent call last):
File "/Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/test/
test_thread.py", line 51, in task
self.done_mutex.release()
thread.error: release unlocked lock
...
test_xmllib
/Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/test/
test_xmllib.py:24: DeprecationWarning: The xmllib module is obsolete.
Use xml.sax instead.
import xmllib
...
test_zlib
test test_zlib failed -- Traceback (most recent call last):
File "/Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/test/
test_zlib.py", line 84, in test_baddecompressobj
self.assertRaises(ValueError, zlib.decompressobj, 0)
AssertionError: ValueError not raised
323 tests OK.
6 tests failed:
test_asynchat test_ctypes test_distutils test_smtplib test_socket
test_zlib
36 tests skipped:
test_aepack test_al test_applesingle test_bsddb185 test_bsddb3
test_cd test_cl test_codecmaps_cn test_codecmaps_hk
test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
test_epoll test_gdbm test_gl test_imgfile test_largefile
test_linuxaudiodev test_macos test_macostools test_normalization
test_ossaudiodev test_pep277 test_py3kwarn test_scriptpackages
test_smtpnet test_socketserver test_startfile test_sunaudiodev
test_timeout test_urllib2net test_urllibnet test_winreg
test_winsound test_zipfile64
5 skips unexpected on darwin:
test_macos test_applesingle test_aepack test_scriptpackages
test_bsddb185
make[2]: [test] Error 1 (ignored)
DYLD_LIBRARY_PATH=`pwd`:/Users/name/s452a0/local/lib/R/lib:/Users/name/
s452a0/local/lib/openmpi:/Users/name/s452a0/local/lib/:::/Users/name/
s452a0/local/lib/R/lib ./python.exe -E -tt ./Lib/test/regrtest.py -l
test_grammar
test_opcodes
test_dict
test_builtin
test_exceptions
test_types
test_unittest
test_doctest
test_doctest2
test_MimeWriter
test_SimpleHTTPServer
test_StringIO
test___all__
test___future__
test__locale
test_abc
test_abstract_numbers
test_aepack
test_aepack skipped -- No module named _AE
test_aifc
test_al
test_al skipped -- No module named al
test_anydbm
test_applesingle
test_applesingle skipped -- No module named _Res
test_array
test_ast
test_asynchat
test test_asynchat produced unexpected output:
**********************************************************************
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x171a580> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x171a490> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x171a300> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x171a5f8> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x171a620> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x171a490> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x171a300> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x171a6e8> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x171a620> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x171a490> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x171a6c0> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x171a698> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x171a580> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x171a490> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x171a6c0> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_asynchat.echo_client at 0x171a738> (<class 'socket.error'>:
[Errno 9] Bad file descriptor [/Users/name/s452a0/spkg/build/
python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|handle_expt_event|441]
[<string>|getsockopt|1] [/Users/name/s452a0/spkg/build/python-2.6.4.p9/
src/Lib/socket.py|_dummy|167])
**********************************************************************
...
test_ctypes
test test_ctypes failed -- Traceback (most recent call last):
File "/Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/ctypes/
test/test_macholib.py", line 55, in test_find
self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError
...
test_macos
test_macos skipped -- No module named MacOS
test_macostools
test_macostools skipped -- No module named _Res
...
test_os
/Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/os.py:760:
DeprecationWarning: integer argument expected, got float
bs += read(_urandomfd, n - len(bs))
...
test_smtplib
test test_smtplib produced unexpected output:
**********************************************************************
error: uncaptured python exception, closing channel
<test.test_smtplib.SimSMTPChannel 127.0.0.1:53731 at 0x36567b0>
(<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/name/
s452a0/spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/
Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|
handle_expt_event|441] [<string>|getsockopt|1] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_smtplib.SimSMTPChannel 127.0.0.1:53735 at 0x2ea0c60>
(<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/name/
s452a0/spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/
Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|
handle_expt_event|441] [<string>|getsockopt|1] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/socket.py|_dummy|167])
error: uncaptured python exception, closing channel
<test.test_smtplib.SimSMTPChannel 127.0.0.1:53739 at 0x40f2d78>
(<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/name/
s452a0/spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|readwrite|107] [/
Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/asyncore.py|
handle_expt_event|441] [<string>|getsockopt|1] [/Users/name/s452a0/
spkg/build/python-2.6.4.p9/src/Lib/socket.py|_dummy|167])
**********************************************************************
...
test_socket
test test_socket failed -- Traceback (most recent call last):
File "/Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/test/
test_socket.py", line 474, in testSockName
my_ip_addr = socket.gethostbyname(socket.gethostname())
gaierror: [Errno 8] nodename nor servname provided, or not known
...
test_sundry
/Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/test/
test_sundry.py:66: DeprecationWarning: The posixfile module is
deprecated; fcntl.lockf() provides better locking
import posixfile
...
test_xmllib
/Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/test/
test_xmllib.py:24: DeprecationWarning: The xmllib module is obsolete.
Use xml.sax instead.
import xmllib
...
test_zlib
test test_zlib failed -- Traceback (most recent call last):
File "/Users/name/s452a0/spkg/build/python-2.6.4.p9/src/Lib/test/
test_zlib.py", line 84, in test_baddecompressobj
self.assertRaises(ValueError, zlib.decompressobj, 0)
AssertionError: ValueError not raised
...
323 tests OK.
6 tests failed:
test_asynchat test_ctypes test_distutils test_smtplib test_socket
test_zlib
36 tests skipped:
test_aepack test_al test_applesingle test_bsddb185 test_bsddb3
test_cd test_cl test_codecmaps_cn test_codecmaps_hk
test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
test_epoll test_gdbm test_gl test_imgfile test_largefile
test_linuxaudiodev test_macos test_macostools test_normalization
test_ossaudiodev test_pep277 test_py3kwarn test_scriptpackages
test_smtpnet test_socketserver test_startfile test_sunaudiodev
test_timeout test_urllib2net test_urllibnet test_winreg
test_winsound test_zipfile64
5 skips unexpected on darwin:
test_macos test_applesingle test_aepack test_scriptpackages
test_bsddb185
make[2]: *** [test] Error 1
An error occurred while testing Python
*************************************
Error testing package ** python-2.6.4.p9 **
*************************************
sage: An error occurred while testing python-2.6.4.p9
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of
of /Users/name/s452a0/install.log. Describe your computer, operating
system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/Users/name/s452a0/spkg/build/python-2.6.4.p9 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/name/s452a0/spkg/build/python-2.6.4.p9' && '/Users/name/
s452a0/sage' -sh)
When you are done debugging, you can type "exit" to leave the
subshell.
make[1]: *** [installed/python-2.6.4.p9] Error 1
real 22m22.395s
user 14m4.905s
sys 4m50.460s
Error building Sage.
./sage -docbuild all html 2>&1 | tee -a dochtml.log
python: can't open file '/Users/name/s452a0/devel/sage/doc/common/
builder.py': [Errno 2] No such file or directory
$
leif
> On Jul 22, 9:18 am, Dan Drake <dr...@kaist.edu> wrote:
>> Hello,
>> Mitesh Patel and I have released Sage 4.5.2.alpha0. Source tarball is at
>> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha0/sage-4...
>> Please build, test, and report any issues.
>
>
> Hello,
>
> I tried to build on a MacBook Pro with Mac OS X 10.5.8, but it failed.
> Below are excerpts of the build session output, including the final
> bit.
>
> Samuel
>
>
> [Sat 2010-07-24]
>
> $ cd s452a0
> $ export SAGE_CHECK="yes"
> $ export MAKE="make -j2"
> $ make
>
> ...
All I can tell is that - currently - building Sage (as opposed to
installing an spkg) with SAGE_CHECK=yes doesn't make sense on Linuces,
since at least Python's test suite will fail (and Sage unconditionally
treats that as a *build* error, stopping the build immediately).
I have no idea if that ever worked on MacOS X though.
I'd try to build Sage without SAGE_CHECK set and (if the build succeeds)
run Sage's "test suite", e.g. with one of:
- make test # runs only a subset of the doctests
- make ptest # same as above, runs tests in parallel
- make testlong # run nearly all doctests, takes of course longer
- make ptestlong # same as above, again runs tests in parallel
If you set MAKE as you did above, you should also set
SAGE_PARALLEL_SPKG_BUILD=yes (and of course export it, too).
-Leif
Dr. David Kirkby
> On Jul 22, 9:18 am, Dan Drake<dr...@kaist.edu> wrote:
>> Hello,
>> Mitesh Patel and I have released Sage 4.5.2.alpha0. Source tarball is at
>> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha0/sage-4...
>> Please build, test, and report any issues.
>
>
> Hello,
>
> I tried to build on a MacBook Pro with Mac OS X 10.5.8, but it failed.
> Below are excerpts of the build session output, including the final
> bit.
>
> Samuel
>
>
> [Sat 2010-07-24]
>
> $ cd s452a0
> $ export SAGE_CHECK="yes"
> $ export MAKE="make -j2"
> $ make
> 323 tests OK.
> 6 tests failed:
> test_asynchat test_ctypes test_distutils test_smtplib test_socket
> test_zlib
<SNIP>
> *************************************
> Error testing package ** python-2.6.4.p9 **
> *************************************
> sage: An error occurred while testing python-2.6.4.p9
I do not believe there is one platform where all of Python's test pass in Sage.
6 is a slightly high number of failures, but most people get a few.
I would re-run the python build with SAGE_CHECK unset, then set it again.
If you have time, it would be good to build Python outside of Sage to see if you
get any more/less test failures. But I would not lose sleep over some in Python,
as everyone reports some failures.
Dave
Jason Grout
> (like
> the difference between 80-bit floating point numbers used by default
> on 32-bit x86 and 64-bit floating point used by default on 64-bit x86)
> into large, visible differences.
>
I realize this is an old email, but I'm really curious about this
statement. Do 64-bit x86 registers not use extended precision (80-bit)
by default?
This:
http://stackoverflow.com/questions/2799684/x86-64-long-double-precision
seems to indicate that x86-64 uses 80-bit precision when you use long
double types, at least.
Thanks,
Jason
Dr. David Kirkby
only load 64-bit numbers, and can only read out 64-bit numbers. However, lets
say you perform the calculation
(a+b)*c
If a, b and c are all loaded into the floating point processor at the same time
(which they will be able to do), then the computation will be performed entirely
to 80-bit of precision. Then when the number is read out, it will be rounded to
64-bits.
Conversely, if you try to perform
(a+b)*c+(d+e)*(f+g)*h+i+j+k+l+m+n
then there are not enough registers in the FPU to hold all those variables at
once, so the whole computation can't be done in 80-bits, but some of it will be.
There used to be 8 floating point registers - I suspect that might have
increased a bit now. But whatever number there are, there's a limit to how many
numbers can be held in the floating point registers at the same time.
Also worth noting is that whilst the largest and smallest numbers that can be
represented in IEEE 754 format are of the order of 10^308 and 10^-308, the
80-bits used internally in the FPU allows intermediate calculations to go
outside that range (from memory its a bit over 10^4000 and bit less that
10^-4000). So the 80-bits gives you less chance of underflows and overflows on
intermediate calculations. But ultimately, if the final result is 10^309, then
it can't be read out of a 64-bit register in IEE 754 format so it will cause an
overflow.
I personally can't understand how this would be any relevance for a long double
(which I believe is 128 bits). At that point, there's no way the FPU can do any
of this, as 80 bits is no help if you want 128 bits. The only way I can see a
compiler can implement a 128 bit double is to use software systems like MPFR.
Not surprisingly then, when you build gcc it needs both the GMP and the MPIR
libraries. I assume gcc will just MPIR for the 128 bits code, but I don't know
that to be true.
I've not looked at the assembly code for any of the Intel/AMD processors in the
last 20 years, but that's how it used to be at least. Things may have moved on a
bit since then! But I'm not aware of any changes in CPU technology that would
change these conclusions.
Dave
Jason Grout
David Lay gives a good talk pointing out weird numerical issues that
sometimes arise. IIRC, one example he gives is of a matlab program that
ran fine until you added a print statement in the middle, and then the
program messes up a lot. In the end, the conclusion was that without
the print statement, computations were all done in 80-bit arithmetic,
but when the print statement was added, the registers were dumped and so
there was some 64-bit rounding occurring in the middle of the
calculation. Apparently it was very frustrating to debug.
>
> I personally can't understand how this would be any relevance for a long
> double (which I believe is 128 bits).
The stuff I read said long doubles were 80 bits (but I don't know how
accurate it was, or if it was for x87 or SSE2.)
Thanks for the education!
Jason
leif
long doubles are 128 bits *in memory* (for better alignment), but
usually only 96 bits are used: 80 bit mantissa, 16 bit exponent.
-Leif
Mitesh Patel
> On Jul 22, 6:52 pm, John H Palmieri <jhpalmier...@gmail.com> wrote:
>> skynet machine iras: the problem at #9456 comes up whenever I build on
>> this machine with parallel spkg building enabled, preventing the build
>> from completely successfully. Since that ticket has a patch with a
>> positive review, I've upgraded it to "blocker".
>
> On iras (ia64-Linux-suse), after continuing the build, one failure:
>
> sage -t -long "devel/sage/sage/graphs/genus.pyx"
> **********************************************************************
> File "/home/palmieri/iras/sage-4.5.2.alpha0/devel/sage/sage/graphs/
> genus.pyx", line 129:
> sage: get_memory_usage(t)
> Expected:
> 0.0
> Got:
> -0.28125
This is now