Sage 3.3.alpha3 released
mabshoff
here goes alpha3 which is still rather large. It is mostly the mop up
of patches from Sage Days 12 which went rather well :)
There will be another alpha4 in the near future since we need to
switch to ecls and also do a couple more invasive things. Also another
bunch of essential build fixes did not make it into this release yet,
but delaying it won't do any good since we are starting to see rejects
for existing patches, so it was important to release this. As usual
sources, a sage.math only binary as well as the upgrade files can be
found in
http://sage.math.washington.edu/home/mabshoff/release-cycles-3.3/
The toy_d_basis doctest will still fail as well as some potential
numerical noise in the root finding code. Other than that things
should go smooth and I did a full build and test round on sage.math,
i.e. if you have been either in IRC or watching the usual place you
would know that the alpha3 has been sitting there for about eight
hours now.
Please build, doctest and report all issues.
Cheers,
Michael
PS: So far we have closed 224 tickets against 3.3 and judging by the
work left to be done we will surpass the 3.1.2 release with 252 closed
tickets before the end of the 3.3 release. So we will set another
record for the most tickets closed in a release in 3.3.
Merged in Sage 3.3.alpha3:
#773: William Stein: SAGE drops . from path [Reviewed by Robert
Miller, Michael Abshoff]
#791: David Roe: ugly absprec parameter in Polynomial constructor
[Reviewed by Alex Ghitza]
#1367: Nick Alexaner: weird bug creating fractional ideal in relative
number field [Reviewed by David Roe]
#1619: Sebastien Barthelemy: update cddlib to 0.94f [Reviewed by
Michael Abshoff]
#1847: Robert Miller: add nice print method for Sha(Elliptic curve)
[Reviewed by Alex Ghitza]
#1867: William Stein: factoring multivariate polynomials over finite
fields is broken in Singular [Reviewed by Kiran Kedlaya]
#2404: Alex Ghitza: subs_expr claims to take a dictionary, but doesn't
[Reviewed by Mike Hansen]
#2601: William Stein: problem with _mpoly_dict_recursive() [Reviewed
by Alex Ghitza]
#2858: William Stein: parametric_plot3d throws an error when the sum
of the components cancels a variable [Reviewed by Mike Hansen]
#2950: Dan Shumow: point3d misinterpret arguments [Reviewed by Mike
Hansen]
#2957: Martin Albrecht: Singular multivariate polynomials are buggy on
exponent overflow [Reviewed by Burcin Erocal]
#3201: Mike Hansen: notebook -- bug in parsing \ at end of line in
%latex mode [Reviewed by Jason Grout]
#3326: Mike Hansen: trailing question marks in %html blocks are
mistreated [Reviewed by John Palmieri]
#3547: Arnaud Bergeron: create a polygon3d function [Reviewed by Dan
Shumow]
#3704: Robert Miller: make diagonal_matrix accept much more general
arguments [Reviewed by Jason Grout]
#3762: Robert Bradshaw: deprecate quaddouble, switch the number of
partitions code to use MPFR all the way [Reviewed by William Stein]
#3890: David Roe: exact division syntax in finite fields of prime
order [Reviewed by Kiran Kedlaya]
#3933: Robert Miller: Set iteration is broken over sets created with
iterators [Reviewed by Arnaud Bergeron]
#3938: Robert Bradshaw, David Roe, Carl Witty: coercion framework
converts built-in types to Sage types when it should not [Reviewed by
Craig Citro]
#4364: Martin Albrecht: major bug in singular polynomial GCD [Reviewed
by William Stein]
#4440: Alexander Hupfer, Tom Boothby: Automatic Indentation [Reviewed
by Jason Grout]
#4560: David Roe: SR and containment broken [Reviewed by Burcin
Erocal]
#4697: Karl-Dieter Crisman: change integration error message [Reviewed
by Michael Abshoff]
#4727: Nick Alexaner: list method on relative number field elements is
broken -- it doesn't satisfy the most basic consistency check
[Reviewed by David Roe]
#4728: Nick Alexander: .roots() is inconsistent between polynomials
and symbolic polynomials [Reviewed by Martin Albrecht, Jason Grout]
#4770: Martin Albrecht: implement maxima.cputime() [Reviewed by Simon
King]
#4813: Dan Drake: add code from arxiv_0812_2725 to the tests/
directory [Reviewed by Mike Hansen]
#4827: Harald Schilly: add L-BFGS-B bound constraint solver to
minimize_constraint [Reviewed by Jason Grout]
#4859: Dan Gordon: basic covering design module [Reviewed by William
Stein, David Joyner]
#4860: Robert Miller: upgrade networkx to 0.99 upstream release
[Reviewed by Michael Abshoff, Minh Van Nguyen]
#4869: Nick Alexaner: make element of relative number field from
polynomial [Reviewed by David Roe]
#4891: William Stein: make a command that installs all optional spkg's
and reports the ones that don't work [Reviewed by Martin Albrecht]
#4892: Robert Miller: Changing precision of a Complex can convert it
to a real [Reviewed by Alex Ghitza]
#4937: John Cremona: bug in _p_primary_torsion_basis() for elliptic
curves [Reviewed by David Roe]
#4957: Craig Citro: inconsistent integer hashing [Reviewed by Robert
Bradshaw]
#4978: Michael Abshoff: fix NTL tuning issue on Linux/ppc64 [Reviewed
by Carl Witty]
#5009: Robert Miller: elementary_divisors for integer matrices: fix
doc string [Reviewed by Mike Hansen]
#5021: John Palmieri: add some jsMath extensions [Reviewed by Jason
Grout]
#5025: Jason Grout: tinymce: tinymce: fix creation of text cells to
not cause duplicate ids and not be considered compute cells [Reviewed
by Mike Hansen, Tom Boothby, Karl-Dieter Crisman]
#5040: Michael Abshoff: NTL's DoConfig errors out when NTL is build
with dependencies in a directory containing [-h|help|-help|--help]
[Reviewed by Carl Witty]
#5044: William Stein: on some systems mwrank dumps core and crashes on
exit when run under pexpect [Reviewed by Michael Abshoff]
#5052: Dan Drake: preparser does not respect leading space in front of
"load foo.sage" [Reviewed by Tom Boothby]
#5053: Simon King: If the hostname of the computer has a "-" in it,
then no tempfiles will ever be deleted from $DOT_SAGE/temp [Reviewed
by Michael Abshoff]
#5055: Karl-Dieter Crisman: Trivial typo in interact documentation
[Reviewed by Martin Albrecht]
#5066: Nick Alexander: break out relative number fields into separate
file [Reviewed by David Roe]
#5095: Mike Hansen: AJAX requests don't work from the worksheet
listing page [Reviewed by John Palmieri]
#5097: Alex Ghitza: doctest failures in 3.3.alpha2 due to lack of
#optional tag [Reviewed by Michael Abshoff]
#5109: Blair Sutton, Mike Hansen: add support for Bell polynomials in
Sage [Reviewed by David Joyner]
#5113: Robert Bradshaw: elliptic curve construction from weierstrass
equation [Reviewed by Jason Grout]
#5115: Dan Drake: documentation for IterableFunctionCall is poor
[Reviewed by Michael Abshoff]
#5121: Jason Grout: major bug in plot command [Reviewed by William
Stein]
Jaap Spies
> Hello folks,
>
> here goes alpha3 which is still rather large. It is mostly the mop up
> of patches from Sage Days 12 which went rather well :)
>
> There will be another alpha4 in the near future since we need to
> switch to ecls and also do a couple more invasive things. Also another
> bunch of essential build fixes did not make it into this release yet,
> but delaying it won't do any good since we are starting to see rejects
> for existing patches, so it was important to release this. As usual
> sources, a sage.math only binary as well as the upgrade files can be
> found in
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.3/
>
> The toy_d_basis doctest will still fail as well as some potential
> numerical noise in the root finding code. Other than that things
> should go smooth and I did a full build and test round on sage.math,
> i.e. if you have been either in IRC or watching the usual place you
> would know that the alpha3 has been sitting there for about eight
> hours now.
>
> Please build, doctest and report all issues.
>
On Fedora 10, 32 bits numerical noise:
[jaap@peace sage-3.3.alpha0]$ ./sage -t "devel/sage/sage/calculus/calculus.py"
sage -t "devel/sage/sage/calculus/calculus.py"
**********************************************************************
File "/home/jaap/Download/sage-3.3.alpha0/devel/sage/sage/calculus/calculus.py",
line 3206:
sage: f.roots(ring=CC)
Expected:
[(-0.0588115223184495, 1), (1.36050567903502 + 1.51880872209965*I,
1), (-1.33109991787579 + 1.52241655183732*I, 1), (1.36050567903502 -
1.51880872209965*I, 1), (-1.33109991787580 - 1.52241655183732*I, 1)]
Got:
[(-0.0588115223184495, 1), (1.36050567903502 + 1.51880872209965*I,
1), (-1.33109991787580 + 1.52241655183732*I, 1), (1.36050567903502 -
1.51880872209965*I, 1), (-1.33109991787580 - 1.52241655183732*I, 1)]
**********************************************************************
File "/home/jaap/Download/sage-3.3.alpha0/devel/sage/sage/calculus/calculus.py",
line 3208:
sage: (2.5*f).roots(ring=RR)
Expected:
[(-0.0588115223184494, 1)]
Got:
[(-0.0588115223184495, 1)]
**********************************************************************
File "/home/jaap/Download/sage-3.3.alpha0/devel/sage/sage/calculus/calculus.py",
line 3210:
sage: f.roots(ring=CC, multiplicities=False)
Expected:
[-0.0588115223184495, 1.36050567903502 + 1.51880872209965*I,
-1.33109991787579 + 1.52241655183732*I, 1.36050567903502 -
1.51880872209965*I, -1.33109991787580 - 1.52241655183732*I]
Got:
[-0.0588115223184495, 1.36050567903502 + 1.51880872209965*I,
-1.33109991787580 + 1.52241655183732*I, 1.36050567903502 -
1.51880872209965*I, -1.33109991787580 - 1.52241655183732*I]
**********************************************************************
1 items had failures:
3 of 29 in __main__.example_81
***Test Failed*** 3 failures.
For whitespace errors, see the file
/home/jaap/Download/sage-3.3.alpha0/tmp/.doctest_calculus.py
[243.9 s]
exit code: 1024
Jaap
Nick Alexander
> calculus.py"
> sage -t "devel/sage/sage/calculus/calculus.py"
> **********************************************************************
> File "/home/jaap/Download/sage-3.3.alpha0/devel/sage/sage/calculus/
> calculus.py",
> line 3206:
> sage: f.roots(ring=CC)
> Expected:
> [(-0.0588115223184495, 1), (1.36050567903502 + 1.51880872209965*I,
> 1), (-1.33109991787579 + 1.52241655183732*I, 1), (1.36050567903502 -
> 1.51880872209965*I, 1), (-1.33109991787580 - 1.52241655183732*I, 1)]
> Got:
> [(-0.0588115223184495, 1), (1.36050567903502 + 1.51880872209965*I,
> 1), (-1.33109991787580 + 1.52241655183732*I, 1), (1.36050567903502 -
> 1.51880872209965*I, 1), (-1.33109991787580 - 1.52241655183732*I, 1)]
Just the use numerical noise... sorry, I wrote this code and I only
ran the tests on sage.math.
Nick
mabshoff
Jaap: please open a ticket for this one since AFAIK there is no such
ticket in trac yet.
> Nick
Cheers,
Michael
Alex Ghitza
Best,
Alex
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne -- Australia -- http://www.ms.unimelb.edu.au/~aghitza/
William Stein
> On Archlinux 32-bit, built and doctested with only the numerical noise issue
> in calculus.py, and the tod_d_basis problem.
>
> Best,
> Alex
Failed to build on:
* centos32 -- atlas, system too loaded
* mandriva32, mandriva64 -- fails to build python; possible compiler bug
* opensuse64 -- readline (known problem)
Built but failed doctests (here's the output):
* all other test systems on the vmware box. I've copied the ends
of the test logs.
Built and fails spectacularly:
* Fedora 64 bit, with dozens of failures like this (about 1 in 6
doctest files):
sage -t "devel/sage/sage/misc/all.py"
A mysterious error (perphaps a memory error?) occurred, which may have
crashed doctest.
I think this related to the issues a little birdy told me about,
where Fedora does something involving randomly moving around libraries
in memory or something. He said Allan Steel had to work very hard to
come up with a hack to get around this problem for Magma. Said birdy
didn't give any further details when asked.
For complete details, see
http://sage.math.washington.edu/home/was/farm/out/3.3.alpha2/
==> centos32.out <==
subshell.)
make[1]: *** [installed/atlas-3.8.2.p1] Error 1
make[1]: Leaving directory `/space/wstein/farm/sage-3.3.alpha2/spkg'
real 52m58.973s
user 22m31.941s
sys 26m21.553s
. local/bin/sage-env && sage-starts && sage-maketest
Testing that Sage starts...
Sage failed to startup.
==> centos64.out <==
[1.4 s]
----------------------------------------------------------------------
The following tests failed:
sage -t "devel/sage/sage/interfaces/octave.py"
sage -t "devel/sage/sage/interfaces/maple.py"
Total time for all tests: 3269.8 seconds
Please see /space/wstein/farm/sage-3.3.alpha2/tmp/test.log for the
complete log from this test.
==> debian32.out <==
----------------------------------------------------------------------
The following tests failed:
sage -t "devel/sage/sage/rings/polynomial/toy_d_basis.py"
sage -t "devel/sage/sage/interfaces/octave.py"
sage -t "devel/sage/sage/interfaces/maple.py"
Total time for all tests: 3771.4 seconds
Please see /space/wstein/farm/sage-3.3.alpha2/tmp/test.log for the
complete log from this test.
==> debian64.out <==
[1.4 s]
----------------------------------------------------------------------
The following tests failed:
sage -t "devel/sage/sage/interfaces/octave.py"
sage -t "devel/sage/sage/interfaces/maple.py"
Total time for all tests: 3640.1 seconds
Please see /space/wstein/farm/sage-3.3.alpha2/tmp/test.log for the
complete log from this test.
==> farm.out <==
==> fedora32.out <==
----------------------------------------------------------------------
The following tests failed:
sage -t "devel/sage/sage/rings/polynomial/toy_d_basis.py"
sage -t "devel/sage/sage/interfaces/octave.py"
sage -t "devel/sage/sage/interfaces/maple.py"
sage -t "devel/sage/sage/interfaces/gp.py"
Total time for all tests: 3520.2 seconds
Please see /space/wstein/farm/sage-3.3.alpha2/tmp/test.log for the
complete log from this test.
==> fedora64.out <==
sage -t "devel/sage/sage/structure/sage_object.pyx"
sage -t "devel/sage/sage/structure/coerce_dict.pyx"
sage -t "devel/sage/sage/algebras/algebra.py"
sage -t "devel/sage/sage/algebras/algebra_element.py"
sage -t "devel/sage/sage/algebras/steenrod_milnor_multiplication_odd.py"
sage -t "devel/sage/sage/algebras/steenrod_algebra_element.py"
sage -t "devel/sage/sage/algebras/quaternion_algebra_element.py"
sage -t "devel/sage/sage/algebras/quaternion_order_element.py"
Total time for all tests: 3338.1 seconds
Please see /space/wstein/farm/sage-3.3.alpha2/tmp/test.log for the
complete log from this test.
==> mandriva32.out <==
/space/wstein/farm/sage-3.3.alpha2/spkg/build/python-2.5.2.p8
(When you are done debugging, you can type "exit" to leave the
subshell.)
make[1]: *** [installed/python-2.5.2.p8] Error 1
make[1]: Leaving directory `/space/wstein/farm/sage-3.3.alpha2/spkg'
Command exited with non-zero status 2
979.35user 646.44system 31:35.81elapsed 85%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+720584outputs (0major+45069597minor)pagefaults 0swaps
. local/bin/sage-env && sage-starts && sage-maketest
Problem with sage location or flags.
==> mandriva64.out <==
/space/wstein/farm/sage-3.3.alpha2/spkg/build/python-2.5.2.p8
(When you are done debugging, you can type "exit" to leave the
subshell.)
make[1]: *** [installed/python-2.5.2.p8] Error 1
make[1]: Leaving directory `/space/wstein/farm/sage-3.3.alpha2/spkg'
Command exited with non-zero status 2
958.69user 561.70system 28:45.65elapsed 88%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+724488outputs (0major+54490961minor)pagefaults 0swaps
. local/bin/sage-env && sage-starts && sage-maketest
Problem with sage location or flags.
==> opensuse32.out <==
----------------------------------------------------------------------
The following tests failed:
sage -t "devel/sage/sage/rings/polynomial/toy_d_basis.py"
sage -t "devel/sage/sage/interfaces/octave.py"
sage -t "devel/sage/sage/interfaces/maple.py"
Total time for all tests: 5620.8 seconds
Please see /space/wstein/farm/sage-3.3.alpha2/tmp/test.log for the
complete log from this test.
==> opensuse64.out <==
(When you are done debugging, you can type "exit" to leave the
subshell.)
make[1]: *** [installed/readline-5.2.p5] Error 1
make[1]: Leaving directory `/space/wstein/farm/sage-3.3.alpha2/spkg'
real 9m22.068s
user 1m28.382s
sys 2m55.627s
. local/bin/sage-env && sage-starts && sage-maketest
Problem with sage location or flags.
==> ubuntu32.out <==
----------------------------------------------------------------------
The following tests failed:
sage -t "devel/sage/sage/rings/polynomial/toy_d_basis.py"
sage -t "devel/sage/sage/interfaces/octave.py"
sage -t "devel/sage/sage/interfaces/maple.py"
Total time for all tests: 4034.0 seconds
Please see /space/wstein/farm/sage-3.3.alpha2/tmp/test.log for the
complete log from this test.
==> ubuntu64.out <==
[1.5 s]
----------------------------------------------------------------------
The following tests failed:
sage -t "devel/sage/sage/interfaces/octave.py"
sage -t "devel/sage/sage/interfaces/maple.py"
Total time for all tests: 3535.4 seconds
Please see /space/wstein/farm/sage-3.3.alpha2/tmp/test.log for the
complete log from this test.
mabshoff
On Jan 29, 3:17 pm, William Stein <wst...@gmail.com> wrote:
> > On Archlinux 32-bit, built and doctested with only the numerical noise issue
> > in calculus.py, and the tod_d_basis problem.
>
> > Best,
> > Alex
>
> Failed to build on:
> * centos32 -- atlas, system too loaded
> * mandriva32, mandriva64 -- fails to build python; possible compiler bug
> * opensuse64 -- readline (known problem)
>
> Built but failed doctests (here's the output):
> * all other test systems on the vmware box. I've copied the ends
> of the test logs.
>
> Built and fails spectacularly:
> * Fedora 64 bit, with dozens of failures like this (about 1 in 6
> doctest files):
> sage -t "devel/sage/sage/misc/all.py"
> A mysterious error (perphaps a memory error?) occurred, which may have
> crashed doctest.
>
> I think this related to the issues a little birdy told me about,
> where Fedora does something involving randomly moving around libraries
> in memory or something. He said Allan Steel had to work very hard to
> come up with a hack to get around this problem for Magma. Said birdy
> didn't give any further details when asked.
<SNIP>
Most of the failures below are from alpha2. Are you sure you build
alpha3?
Cheers,
Michael
William Stein
Crap! I just posted all the logs from alpha2. Oops. Alpha3 is
actually builiding or done for most of my machines. I just looked in
the wrong directory.
So far, only mandriva32 and 64 are totally done, and both failed with
that compiler bug when building python (?). Oh, opensuse64 also still
fails because of readline.
William
mabshoff
> Built and fails spectacularly:
> * Fedora 64 bit, with dozens of failures like this (about 1 in 6
> doctest files):
> sage -t "devel/sage/sage/misc/all.py"
> A mysterious error (perphaps a memory error?) occurred, which may have
> crashed doctest.
http://bugs.gentoo.org/show_bug.cgi?id=218378
which leads to
https://bugzilla.redhat.com/show_bug.cgi?id=451494
and then
http://bugs.python.org/issue3115
It fits the problem well:
* open in Python 2.5.2 which we ship
* it only happens on 64 bits since Jaap [our endless 32 bit Fedora
tester - thank $DEITY we have him :)] has never seen it on 32 bit
Fedora 8/9/10 in the last couple years
* we have seen it on Fedora 9 64 bit boxen - it went away by
downgrading the kernel to some FC8 kernel
I meant to update to Python 2.5.4 in alpha4 anyway, so I will see if
the problem cannot be made to go away.
Cheers,
Michael
mabshoff
On Jan 29, 5:15 pm, mabshoff <mabsh...@googlemail.com> wrote:
> On Jan 29, 3:17 pm, William Stein <wst...@gmail.com> wrote:
>
> <SNIP>
>
> > Built and fails spectacularly:
> > * Fedora 64 bit, with dozens of failures like this (about 1 in 6
> > doctest files):
> > sage -t "devel/sage/sage/misc/all.py"
> > A mysterious error (perphaps a memory error?) occurred, which may have
> > crashed doctest.
>
> I think I tracked this down to
>
> http://bugs.gentoo.org/show_bug.cgi?id=218378
>
> which leads to
>
> https://bugzilla.redhat.com/show_bug.cgi?id=451494
>
> and then
>
> http://bugs.python.org/issue3115
>
> It fits the problem well:
>
> * open in Python 2.5.2 which we ship
> * it only happens on 64 bits since Jaap [our endless 32 bit Fedora
> tester - thank $DEITY we have him :)] has never seen it on 32 bit
> Fedora 8/9/10 in the last couple years
> * we have seen it on Fedora 9 64 bit boxen - it went away by
> downgrading the kernel to some FC8 kernel
using malloc instead of mmap it all blows up on exit every time with a
double free since we end up calling the wrong dtor in a bunch of
cases. The same problem exists on OSX in 64 bit mode (where we are
forced to use --with-malloc=system for libSingular to even work), so
this bug needs to b e fixed either way. Unfortunately I have no clue
how to approach this at this point.
> I meant to update to Python 2.5.4 in alpha4 anyway, so I will see if
> the problem cannot be made to go away.
above issues I also suspect prelinking, but have not tried to disable
it. Either way, if the issue goes away with disabling prelinking it
isn't very useful anyway since disabling it requires root priviledges
and I have been unable so far to find a way to disable it on a per
program basis.
> Cheers,
>
> Michael
Cheers,
Michael
Justin C. Walker
On Jan 29, 2009, at 11:19 , mabshoff wrote:
> There will be another alpha4 in the near future since we need to
> switch to ecls and also do a couple more invasive things. Also another
> bunch of essential build fixes did not make it into this release yet,
> but delaying it won't do any good since we are starting to see rejects
> for existing patches, so it was important to release this. As usual
> sources, a sage.math only binary as well as the upgrade files can be
> found in
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.3/
Built w/o problems as an upgrade from alpha2 (Mac OS X, 10.5.6, Dual
Quad Xeon). Two tests had failures:
sage -t "devel/sage/sage/calculus/calculus.py"
sage -t "devel/sage/sage/rings/polynomial/toy_d_basis.py"
The 'toy_d_basis' failure is known. Don't know about the calculus
failure (below). It doesn't look like noise; rather, order of the
output values differs from the expected order in all three failures.
Justin
sage -t "devel/sage/sage/calculus/calculus.py"
**********************************************************************
File "/Users/tmp/sage-3.3.alpha0/devel/sage/sage/calculus/
calculus.py", line 3206:
sage: f.roots(ring=CC)
Expected:
[(-0.0588115223184495, 1), (1.36050567903502 +
1.51880872209965*I, 1), (-1.33109991787579 + 1.52241655183732*I, 1),
(1.36050567903502 - 1.51880872209965*I, 1), (-1.33109991787580 -
1.52241655183732*I, 1)]
Got:
[(-0.0588115223184495, 1), (-1.33109991787579 +
1.52241655183732*I, 1), (1.36050567903502 + 1.51880872209965*I, 1),
(-1.33109991787579 - 1.52241655183732*I, 1), (1.36050567903502 -
1.51880872209965*I, 1)]
**********************************************************************
File "/Users/tmp/sage-3.3.alpha0/devel/sage/sage/calculus/
calculus.py", line 3210:
sage: f.roots(ring=CC, multiplicities=False)
Expected:
[-0.0588115223184495, 1.36050567903502 + 1.51880872209965*I,
-1.33109991787579 + 1.52241655183732*I, 1.36050567903502 -
1.51880872209965*I, -1.33109991787580 - 1.52241655183732*I]
Got:
[-0.0588115223184495, -1.33109991787579 + 1.52241655183732*I,
1.36050567903502 + 1.51880872209965*I, -1.33109991787579 -
1.52241655183732*I, 1.36050567903502 - 1.51880872209965*I]
**********************************************************************
File "/Users/tmp/sage-3.3.alpha0/devel/sage/sage/calculus/
calculus.py", line 3214:
sage: f.roots(ring=QQbar, multiplicities=False)
Expected:
[-0.05881152231844944?, 1.360505679035020? + 1.518808722099650?
*I, -1.331099917875796? + 1.522416551837318?*I, 1.360505679035020? -
1.518808722099650?*I, -1.331099917875796? - 1.522416551837318?*I]
Got:
[-0.05881152231844944?, -1.331099917875796? + 1.522416551837318?
*I, 1.360505679035020? + 1.518808722099650?*I, -1.331099917875796? -
1.522416551837318?*I, 1.360505679035020? - 1.518808722099650?*I]
**********************************************************************
1 items had failures:
3 of 29 in __main__.example_81
***Test Failed*** 3 failures.
--
Justin C. Walker, Curmudgeon at Large
Director
Institute for the Enhancement of the Director's income
-----------
--
They said it couldn't be done, but sometimes,
it doesn't work out that way.
- Casey Stengel
--
mabshoff
brk, sbrk and omalloc :) This is joint debugging work with cwitty!
If the import fails it always fails after importing:
sage.rings.polynomial.all -- sage/rings/all.py:93
with
error: no more memory
System 0k:0k Appl 0k/0k Malloc 0k/0k Valloc 0k/0k Pages 0/0 Regions
0:0
strace reveals:
working version is pid 30120
failure is pid 30195
[pid 30120] stat("/space/wstein/farm/sage-3.3.alpha3/local/lib/
python2.5/site-packages/sage/rings/polynomial/
multi_polynomial_libsingular", 0x7fff39631240) = -1 ENOENT (No such
file or directory)
[pid 30195] stat("/space/wstein/farm/sage-3.3.alpha3/local/lib/
python2.5/site-packages/sage/rings/polynomial/
multi_polynomial_libsingular", 0x7fff51e26a30) = -1 ENOENT (No such
file or directory)
[pid 30120] open("/space/wstein/farm/sage-3.3.alpha3/local/lib/
python2.5/site-packages/sage/rings/polynomial/
multi_polynomial_libsingular.so", O_RDONLY) = 7
[pid 30195] open("/space/wstein/farm/sage-3.3.alpha3/local/lib/
python2.5/site-packages/sage/rings/polynomial/
multi_polynomial_libsingular.so", O_RDONLY) = 7
[pid 30120] fstat(7, {st_mode=S_IFREG|0755, st_size=1629513, ...}) = 0
[pid 30195] fstat(7, {st_mode=S_IFREG|0755, st_size=1629513, ...}) = 0
[pid 30120] open("/space/wstein/farm/sage-3.3.alpha3/local/lib/
python2.5/site-packages/sage/rings/polynomial/
multi_polynomial_libsingular.so", O_RDONLY) = 8
[pid 30195] open("/space/wstein/farm/sage-3.3.alpha3/local/lib/
python2.5/site-packages/sage/rings/polynomial/
multi_polynomial_libsingular.so", O_RDONLY) = 8
[pid 30120] read(8, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>
\0\1\0\0\0\360\366\0\0\0\0\0\0@"..., 832) = 832
[pid 30195] read(8, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>
\0\1\0\0\0\360\366\0\0\0\0\0\0@"..., 832) = 832
[pid 30120] fstat(8, {st_mode=S_IFREG|0755, st_size=1629513, ...}) = 0
[pid 30195] fstat(8, {st_mode=S_IFREG|0755, st_size=1629513, ...}) = 0
[pid 30120] mmap(NULL, 2685464, PROT_READ|PROT_EXEC, MAP_PRIVATE|
MAP_DENYWRITE, 8, 0) = 0x7f1114b6d000
[pid 30195] mmap(NULL, 2685464, PROT_READ|PROT_EXEC, MAP_PRIVATE|
MAP_DENYWRITE, 8, 0) = 0x7f492e6ed000
[pid 30120] mprotect(0x7f1114be4000, 2093056, PROT_NONE) = 0
[pid 30195] mprotect(0x7f492e764000, 2093056, PROT_NONE) = 0
[pid 30120] mmap(0x7f1114de3000, 102400, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 8, 0x76000) = 0x7f1114de3000
[pid 30195] mmap(0x7f492e963000, 102400, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 8, 0x76000) = 0x7f492e963000
[pid 30120] mmap(0x7f1114dfc000, 2584, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f1114dfc000
[pid 30195] mmap(0x7f492e97c000, 2584, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f492e97c000
[pid 30120] close(8) = 0
[pid 30195] close(8) = 0
[pid 30120] open("/space/wstein/farm/sage-3.3.alpha3/local/lib/
libsingular.so", O_RDONLY) = 8
[pid 30195] open("/space/wstein/farm/sage-3.3.alpha3/local/lib/
libsingular.so", O_RDONLY) = 8
[pid 30120] read(8, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>
\0\1\0\0\0000\201\7\0\0\0\0\0@"..., 832) = 832
[pid 30195] read(8, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>
\0\1\0\0\0000\201\7\0\0\0\0\0@"..., 832) = 832
[pid 30120] fstat(8, {st_mode=S_IFREG|0755, st_size=14065013, ...}) =
0
[pid 30195] fstat(8, {st_mode=S_IFREG|0755, st_size=14065013, ...}) =
0
[pid 30120] mmap(NULL, 5775120, PROT_READ|PROT_EXEC, MAP_PRIVATE|
MAP_DENYWRITE, 8, 0) = 0x7f11145eb000
[pid 30195] mmap(NULL, 5775120, PROT_READ|PROT_EXEC, MAP_PRIVATE|
MAP_DENYWRITE, 8, 0) = 0x7f492e16b000
[pid 30120] mprotect(0x7f111495e000, 2097152, PROT_NONE) = 0
[pid 30195] mprotect(0x7f492e4de000, 2097152, PROT_NONE) = 0
[pid 30120] mmap(0x7f1114b5e000, 57344, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 8, 0x373000) = 0x7f1114b5e000
[pid 30195] mmap(0x7f492e6de000, 57344, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 8, 0x373000) = 0x7f492e6de000
[pid 30120] mmap(0x7f1114b6c000, 3856, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f1114b6c000
[pid 30195] mmap(0x7f492e6ec000, 3856, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f492e6ec000
[pid 30120] close(8) = 0
[pid 30195] close(8) = 0
[pid 30120] gettimeofday({1233289115, 517188}, NULL) = 0
[pid 30195] gettimeofday({1233289330, 751145}, NULL) = 0
[pid 30120] brk(0x1b6a030) = 0x1b6a030
[pid 30195] brk(0x2617030) = 0x2611000
[pid 30120] brk(0x1b6b000) = 0x1b6b000
[pid 30195] brk(0x2617030) = 0x2611000
*boom* - note that brk(0x2617030) is identical in two subsequent
calls!
Linux Notes
The return value described above for brk() is the behavior
provided by the glibc wrapper function for the Linux brk() system
call. (On
most other implementations, the return value from brk() is
the same; this return value was also specified in SUSv2.) However,
the actual
Linux system call returns the new program break on success. On
failure, the system call returns the current break. The glibc
wrapper
function does some work (i.e., checks whether the new break is
less than addr) to provide the 0 and -1 return values described above.
On Linux, sbrk() is implemented as a library function that
uses the brk() system call, and does some internal bookkeeping so that
it can
return the old break value.
[pid 30120] mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x7f1131638000
[pid 30120] stat("/space/wstein/farm/sage-3.3.alpha3/local/lib/
python2.5/site-packages/sage/rings/finite_field_ntl_gf2e",
0x7fff3962ee60) = -1 ENOENT (No such file or directory)
[pid 30120] open("/space/wstein/farm/sage-3.3.alpha3/local/lib/
python2.5/site-packages/sage/rings/finite_field_ntl_gf2e.so",
O_RDONLY) = 8
[pid 30120] fstat(8, {st_mode=S_IFREG|0755, st_size=582890, ...}) = 0
[pid 30120] open("/space/wstein/farm/sage-3.3.alpha3/local/lib/
python2.5/site-packages/sage/rings/finite_field_ntl_gf2e.so",
O_RDONLY) = 9
[pid 30120] read(9, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0r
\0\0\0\0\0\0@"..., 832) = 832
[pid 30120] fstat(9, {st_mode=S_IFREG|0755, st_size=582890, ...}) = 0
[pid 30120] mmap(NULL, 2303864, PROT_READ|PROT_EXEC, MAP_PRIVATE|
MAP_DENYWRITE, 9, 0) = 0x7f11143b8000
[pid 30120] mprotect(0x7f11143e1000, 2097152, PROT_NONE) = 0
[pid 30120] mmap(0x7f11145e1000, 36864, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 9, 0x29000) = 0x7f11145e1000
[pid 30120] mmap(0x7f11145ea000, 1912, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f11145ea000
[pid 30120] close(9) = 0
[pid 30195] write(2, "\nerror: no more memory\n"..., 23) = 23
[pid 30195] write(2, "System 0k:0k Appl 0k/0k Malloc 0k"..., 72) = 72
[pid 30195] write(1, "eric -- sage/rings/padics/padic_r"..., 3848) =
3848
[pid 30195] exit_group(14) = ?
Process 30195 detached
daveloeffler
fix for the fractional ideals in relative number fields problem seems
to have introduced a new bug:
sage: K.<a> = QuadraticField(-23)
sage: L.<b> = K.extension(x^3 - x - 1)
sage: OL = L.ring_of_integers()
It seems to get stuck in an infinite loop; it's just sitting there
consuming 98.5% of my CPU, and resisting all attempts to stop it with
Ctrl-C. All I can do is kill the entire Sage process.
I'm not sure one could actually do much with rings of integers in
relative extensions before this -- e.g. membership testing has been
broken for a while (#4193) -- but at least one could create them.
David
Alex Ghitza
Dan Drake
> Hello folks,
>
> here goes alpha3 which is still rather large. It is mostly the mop up
> of patches from Sage Days 12 which went rather well :)
> Please build, doctest and report all issues.
I've done multiple runs of 'make test', 'make ptest', and 'make
ptestlong', and don't get any persistent failures -- Ubuntu 8.10 amd64.
I still get a bit of the lisp hangs in calculus.py and am eager to see
the new Lisp in alpha4!
Dan
--
--- Dan Drake <dr...@kaist.edu>
----- KAIST Department of Mathematical Sciences
------- http://mathsci.kaist.ac.kr/~drake
Jaap Spies
>
>
> On Jan 29, 3:17 pm, William Stein <wst...@gmail.com> wrote:
>
> <SNIP>
>
>> Built and fails spectacularly:
>> * Fedora 64 bit, with dozens of failures like this (about 1 in 6
>> doctest files):
>> sage -t "devel/sage/sage/misc/all.py"
>> A mysterious error (perphaps a memory error?) occurred, which may have
>> crashed doctest.
>
>
>
> * open in Python 2.5.2 which we ship
> * it only happens on 64 bits since Jaap [our endless 32 bit Fedora
> tester - thank $DEITY we have him :)] has never seen it on 32 bit
> Fedora 8/9/10 in the last couple years
This is not quite true:
>> On 01/19/2009 I wrote, testing alpha0:
>> On Fedora 9, 32 bits:
>>
>> ----------------------------------------------------------------------
>> The following tests failed:
>>
>>
>> sage -t "devel/sage/sage/matrix/misc.pyx"
>> sage -t "devel/sage/sage/rings/polynomial/term_order.py"
>> sage -t "devel/sage/sage/rings/polynomial/toy_d_basis.py"
>> sage -t "devel/sage/sage/rings/number_field/small_primes_of_degree_one.py"
>> sage -t "devel/sage/sage/rings/finite_field_ext_pari.py"
>> sage -t "devel/sage/sage/rings/padics/padic_printing.pyx"
>> sage -t "devel/sage/sage/rings/integral_domain.py"
>> sage -t "devel/sage/sage/algebras/algebra_order_ideal.py"
>> sage -t "devel/sage/sage/monoids/free_abelian_monoid.py"
>> sage -t "devel/sage/sage/schemes/generic/glue.py"
>> Total time for all tests: 5864.7 seconds
>> Please see /home/jaap/downloads/sage-3.2.2/tmp/test.log for the complete log from this test.
>>
>> Mostly of the type:
>> sage -t "devel/sage/sage/matrix/misc.pyx"
>> A mysterious error (perphaps a memory error?) occurred, which may have crashed doctest.
>> [1.0 s]
Jaap
Jaap Spies
mabshoff wrote:
> Hello folks,
>
> here goes alpha3 which is still rather large. It is mostly the mop up
> of patches from Sage Days 12 which went rather well :)
>
>
> Please build, doctest and report all issues.
>
On Fedora 9, 32 bits in a fresh build:
The following tests failed:
sage -t "devel/sage/sage/libs/linbox/linbox.pyx"
sage -t "devel/sage/sage/matrix/matrix_dense.pyx"
sage -t "devel/sage/sage/calculus/calculus.py"
sage -t "devel/sage/sage/rings/polynomial/toy_d_basis.py"
sage -t "devel/sage/sage/rings/number_field/totallyreal_data.pyx"
sage -t "devel/sage/sage/structure/coerce_maps.pyx"
sage -t "devel/sage/sage/algebras/quaternion_algebra.py"
sage -t "devel/sage/sage/tests/arxiv_0812_2725.py"
sage -t "devel/sage/sage/server/wiki/moin.py"
sage -t "devel/sage/sage/schemes/elliptic_curves/padics.py"
Total time for all tests: 5450.3 seconds
8 out of 10 are from the form:
A mysterious error (perphaps a memory error?) occurred, which may have
crashed doctest.
Now running this eight tests in a loop.
Until now:
[jaap@paix sage-3.3.alpha3]$ grep passed t.log | wc -l
493
[jaap@paix sage-3.3.alpha3]$ grep fail t.log | wc -l
2
Jaap
mabshoff
The problem is likely the same as Carl Witty and I tracked down above,
i.e. brk() does not extend the heap and Singular goes boom even though
it did get the memory. Note that in case of failure the amount
allocated seems to be sub-page in size, but that is only speculation
at this point if that is really a contributing factor.
> Jaap
Cheers,
Michael
Jaap Spies
>> Now running this eight tests in a loop.
>>
>> Until now:
>> [jaap@paix sage-3.3.alpha3]$ grep passed t.log | wc -l
>> 493
>> [jaap@paix sage-3.3.alpha3]$ grep fail t.log | wc -l
>> 2
>
[jaap@paix sage-3.3.alpha3]$ grep passed t.log | wc -l
857
[jaap@paix sage-3.3.alpha3]$ grep fail t.log | wc -l
6
[...]
>
> The problem is likely the same as Carl Witty and I tracked down above,
> i.e. brk() does not extend the heap and Singular goes boom even though
> it did get the memory. Note that in case of failure the amount
> allocated seems to be sub-page in size, but that is only speculation
> at this point if that is really a contributing factor.
>
Great job! I see this behaviour only on Fedora 9, not on Fedora 10.
Jaap
mabshoff
On Jan 30, 6:25 am, Jaap Spies <j.sp...@hccnet.nl> wrote:
> mabshoff wrote:
<SNIP>
> > The problem is likely the same as Carl Witty and I tracked down above,
> > i.e. brk() does not extend the heap and Singular goes boom even though
> > it did get the memory. Note that in case of failure the amount
> > allocated seems to be sub-page in size, but that is only speculation
> > at this point if that is really a contributing factor.
>
> Great job! I see this behaviour only on Fedora 9, not on Fedora 10.
and higher since the way brk randomization is done has changed in the
kernel. It is only a question of time until we will hit the same issue
with other distributions. There is still a remote chance the Fedora's
glibc is buggy, but I would not bet money on that one :)
A trivial workaround for that problem would be to make Singular use
malloc instead of mmap or sbrk, but that causes an unrelated bug to
surface that needs to be fixed anyway, but I am clueless about that
one, too, since it seems to involve scoping issues with Cython/
Python.
> Jaap
Cheers,
Michael
Jaap Spies
>> Great job! I see this behaviour only on Fedora 9, not on Fedora 10.
>
> Well, it isn't fixed yet, but my guess is that it only happens on FC9
> and higher since the way brk randomization is done has changed in the
> kernel.
I didn't see it in Fedora 10. Maybe I was lucky :)!
Jaap
Georg S. Weber
for Sage 3.3.alpha3 I got a strange build failure with the new
cddlib-094f.spkg on my Intel Core2Duo MacBook / Mac OS X 10.4.11,
XCode 2.5:
The make run (acually MAKE='make -j2' ) won't extract this spkg (see
log posted below).
After changing the name to "cddlib-04f.tar.bz2", unpacking it (by
double-cklicking), and then repacking it with:
sage -pkg cddlib-094f
(where the "sage" command is the sage3.3.alpha3 from the incomplete
install ...) I get a new spkg which is fine for the build process.
Weird. Another MAKE now made the build continue (still running).
It seems to be some deficiency of the "tar" of my system (Mac OS X
10.4.11), "tar --version" gives:
tar (GNU tar) 1.14 +CVE-2006-0300 +CVE-2006-6097
Copyright (C) 2004 Free Software Foundation, Inc.
This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute it under the terms of the GNU General Public
License;
see the file named COPYING for details.
Written by John Gilmore and Jay Fenlason.
Modified to support extended attributes.
The log output with the failure in question follows below; the
original tar file seems to contain "obsolescent base-64 headers".
Is that worth a trac ticket?
Cheers,
gsw
...
Finished installing sympow-1.018.1.p6.spkg
sage-spkg cddlib-094f 2>&1
You must set the SAGE_ROOT environment variable or
run this script from the SAGE_ROOT or
SAGE_ROOT/local/bin/ directory.
cddlib-094f
Machine:
Darwin webers-computer.local 8.11.1 Darwin Kernel Version 8.11.1: Wed
Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386
Deleting directories from past builds of previous/current versions of
cddlib-094f
Extracting package /Users/georgweber/Public/sage/sage-3.3.alpha3/spkg/
standard/cddlib-094f.spkg ...
-rw-r--r-- 1 georgweb georgweb 328531 Jan 29 07:01 /Users/
georgweber/Public/sage/sage-3.3.alpha3/spkg/standard/cddlib-094f.spkg
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: Read 851 bytes from /Users/georgweber/Public/sage/sage-3.3.alpha3/
spkg/standard/cddlib-094f.spkg
tar: Error exit delayed from previous errors
Finished extraction
sage: After decompressing the directory cddlib-094f does not exist
This means that the corresponding .spkg needs to be downloaded
again.
...
Georg S. Weber
On 31 Jan., 22:09, "Georg S. Weber" <GeorgSWe...@googlemail.com>
wrote:
There is another issue revealed by this build failure reported above.
I always run on the command line "MAKE && MAKE testlong" so after some
hours/overnight/etc. the end result is there without further
interaction of mine.
Now the second "MAKE testlong" also tried to continue with the build,
of course failed building cddlib --- but then the doctesting started
nevertheless?!
IMHO this is not OK, doctesting does not make sense if the build
itself errors out.
(Poke me if you need the log, but they don't seem to contain
enlightening details about that --- and this behaviour should be
easily reproducible.)
Same questionagain: Do we open a trac ticket?
Cheers,
gsw
mabshoff
On Jan 31, 1:09 pm, "Georg S. Weber" <GeorgSWe...@googlemail.com>
wrote:
>
> for Sage 3.3.alpha3 I got a strange build failure with the new
> cddlib-094f.spkg on my Intel Core2Duo MacBook / Mac OS X 10.4.11,
> XCode 2.5:
>
> The make run (acually MAKE='make -j2' ) won't extract this spkg (see
> log posted below).
> After changing the name to "cddlib-04f.tar.bz2", unpacking it (by
> double-cklicking), and then repacking it with:
>
> sage -pkg cddlib-094f
compressed one. Recompressing it as bzip2 gets rid of the problem.
> Is that worth a trac ticket?
> Cheers,
> gsw
>
Cheers,
Michael
mabshoff
On Jan 31, 1:20 pm, "Georg S. Weber" <GeorgSWe...@googlemail.com>
wrote:
<SNIP>
> P.S.:
> There is another issue revealed by this build failure reported above.
> I always run on the command line "MAKE && MAKE testlong" so after some
> hours/overnight/etc. the end result is there without further
> interaction of mine.
>
> Now the second "MAKE testlong" also tried to continue with the build,
> of course failed building cddlib --- but then the doctesting started
> nevertheless?!
> IMHO this is not OK, doctesting does not make sense if the build
> itself errors out.
> (Poke me if you need the log, but they don't seem to contain
> enlightening details about that --- and this behaviour should be
> easily reproducible.)
>
> Same questionagain: Do we open a trac ticket?
properly return a non-zero status to make and then the testing blows
up. It even happens with a simple "make testlong"
if the build phase breaks.
> Cheers,
> gsw
Cheers,
Michael