sage-5.8.beta2 released

[Jeroen Demeyer]

Dear Sage lovers,

We're releasing Sage 5.8.beta2.

Source archive:

http://boxen.math.washington.edu/home/release/sage-5.8.beta2/sage-5.8.beta2.tar

Upgrade path:

http://boxen.math.washington.edu/home/release/sage-5.8.beta2/sage-5.8.beta2/

The source and upgrade path can also be found on the mirror network
(you might need to wait a while before the mirrors are synchronized):

http://www.sagemath.org/download-latest.html


Please build, test, and report! We'd love to hear about your
experiences with this release.

== Tickets ==

* We closed 99 tickets in this release. For details, see

http://boxen.math.washington.edu/home/release/sage-5.8.beta2/tickets.html

Closed tickets:

#12357: Make groupoids garbage collectable [Reviewed by Simon King,
Jean-Pierre Flori]
#13904: Better deletion of items of TripleDict [Reviewed by Simon King,
Jean-Pierre Flori]

Merged in sage-5.8.beta2:

#7886: Javier López Peña: Implement conjugacy classes [Reviewed by David
Joyner, Travis Scrimshaw]
#8920: Vincent Delecroix, Stepan Starosta: Factor code between words's
alphabets and sets/enumerated sets/ordered sets [Reviewed by Travis
Scrimshaw]
#11593: Kwankyu Lee: `quo_rem` for divisor of leading unit coefficient
[Reviewed by Frédéric Chapoton]
#12313: Simon King, Jean-Pierre Flori: Fix yet another memory leak
caused by caching of coercion data [Reviewed by Simon King, Jean-Pierre
Flori, John Perry, Nils Bruin]
#13054: Jeroen Demeyer: PARI polred() bug [Reviewed by David Roe]
#13387: Nils Bruin: Improve MonoDict and TripleDict data structures
[Reviewed by Simon King]
#13539: Julian Rueth: Add inverse_of_unit() for padics [Reviewed by
David Roe]
#13780: Kannappan Sampath: Typo in the docstring for
echelon_coordinate_vector in FreeModules Documentation [Reviewed by
Julian Rueth]
#13786: Michael Orlitzky: Fix remaining instances of ArithmeticError:
0^0 is undefined [Reviewed by Travis Scrimshaw]
#13895: Michael Orlitzky: Fix ArithmeticError: 0^0 in
rings/polynomial/polynomial_modn_dense_ntl.pyx [Reviewed by Travis
Scrimshaw]
#13897: Michael Orlitzky: Fix ArithmeticError: 0^0 in
rings/finite_rings/element_givaro.pyx [Reviewed by Travis Scrimshaw]
#13941: Michael Orlitzky: Fix ArithmeticError: 0^0 in
rings/padics/padic_capped_absolute_element.pyx [Reviewed by Travis
Scrimshaw]
#14000: Nathann Cohen: Speedup in GenericGraph.relabel() and two new
options [Reviewed by Anne Schilling]
#14040: Volker Braun: Configurable "tall list" output style [Reviewed by
Travis Scrimshaw]
#14063: Travis Scrimshaw: Remove CombinatorialClass from Compositions
[Reviewed by Vincent Delecroix]
#14085: Nicolas M. Thiéry: Ambient spaces for dual and affine root
systems [Reviewed by Dan Orr, Anne Schilling]
#14100: Simon King: Make raising attribute errors faster [Reviewed by
Volker Braun]
#14105: Alejandro Morales, Eric Rowland: all_graph_colorings should have
an option to use integer colors. [Reviewed by Chris Berg, Nathann Cohen]
#14120: Travis Scrimshaw: Add constant_coefficient method for Laurent
polynomials [Reviewed by Kannappan Sampath]
#14142: Travis Scrimshaw: Making mutable copies of simplicial complexes
[Reviewed by John Palmieri]
#14150: Jeroen Demeyer: Fix wait() in @parallel [Reviewed by David Roe]
#14156: John Palmieri: New docbuilder always rebuilds everything
[Reviewed by Volker Braun]
#14158: Jeroen Demeyer: _is_Field() ignores exceptions [Reviewed by
David Roe]
#14166: John Palmieri: Use "tar", not "cp -pr", to copy files in
spkg-install [Reviewed by Jeroen Demeyer]
#14173: Nathann Cohen: Stopgap warning in Graph.modular_decomposition
[Reviewed by Luis Felipe Tabera Alonso]
#14174: Nicolas M. Thiéry: Remove coxeter matrix implementation for type
H (the generic implementation is just as good) [Reviewed by Anne Schilling]
#14176: Nicolas M. Thiéry: Use standard Python operators for
intersection of polyhedrons and membership testing [Reviewed by Volker
Braun]
#14177: Nicolas M. Thiéry: More uniform handling of color_by_labels for
graph plot, plot3d, graphviz, and reference fix [Reviewed by Nathann Cohen]
#14182: Jeroen Demeyer: Fix whitespace in coercion_and_categories.rst
[Reviewed by Simon King]
#14185: Nathann Cohen: Stopgap warning in Poset.relabel [Reviewed by
Luis Felipe Tabera Alonso]

[leif]

Jeroen Demeyer wrote:
> Dear Sage lovers,
>
> We're releasing Sage 5.8.beta2.
>
> Source archive:
>
> http://boxen.math.washington.edu/home/release/sage-5.8.beta2/sage-5.8.beta2.tar
>
> Upgrade path:
>
> http://boxen.math.washington.edu/home/release/sage-5.8.beta2/sage-5.8.beta2/

Built w/o problems on Ubuntu 10.04.4 x86_64 (GCC 4.7.0), and all tests
passed (ptestlong), except for

devel/sage/sage/combinat/sf/k_dual.py

which initially timed out.

This is a major regression: It now doesn't only use more than 1 GB RAM
(resident), but also takes about 10 (ten!) times longer than it took
with Sage 5.7.beta4 on the same machine, with the same compiler, and the
same flags. [Don't know when exactly the regression went in.]


There are also other files like e.g.
sage/quadratic_forms/quadratic_form__automorphisms.py which meanwhile
eat up more than 1 GB (resident, at least 1.8 GB virtual) when tested
with '--long'. I remember being able to run all long tests without any
swapping on a GUI-enabled Linux box with just 512 MB RAM a while ago,
where the greediest tests were those in schemes/elliptic_curves, taking
less than 300 MB IIRC.


-leif

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[Jean-Pierre Flori]

Builds and passes "make ptestlong" (without rebuilding the doc! nice) with #10508 and #13351 added on 64 bits Ubuntu 12.04.1.
Now trying a debug build.

[John Cremona]

Is there a reason why start-up time should be getting worse?
Immediately after building + make ptestlong I start sage-5.8.beta2 and
quit:
(CPU time 0m0.06s, Wall time 0m26.71s)

John

> --
> You received this message because you are subscribed to the Google Groups
> "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-release...@googlegroups.com.
> To post to this group, send email to sage-r...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-release?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Jean-Pierre Flori]

With a debug build "make ptestlong" passes except for matrix_group.py which still times out as I reported with a previous beta.

[Justin C. Walker]

On Feb 28, 2013, at 06:36 , Jeroen Demeyer wrote:

> Dear Sage lovers,
>
> We're releasing Sage 5.8.beta2.
>
> Source archive:
>
> http://boxen.math.washington.edu/home/release/sage-5.8.beta2/sage-5.8.beta2.tar

Full build on two Mac OS X systems: 10.6.8 (Dual 6-core Xeons) and 10.8.2 (Quad-core Core i7). No problems on either system and all tests ('ptestlong') passed!

Justin

--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Enhancement of the Director's Income
--------
Experience is what you get
when you don't get what you want.
--------

[Justin C. Walker]

On Mar 1, 2013, at 05:11 , John Cremona wrote:

> Is there a reason why start-up time should be getting worse?
> Immediately after building + make ptestlong I start sage-5.8.beta2 and
> quit:
> (CPU time 0m0.06s, Wall time 0m26.71s)

I don't see this on Mac OS X. At least, between 5.8-b1 and 5.8-b2, I see no appreciable difference between the two for startup times. For "warm" starts, both versions have essentially the same times. On 10.6.8, for b2, I get

real 0m3.139s
user 0m1.104s
sys 0m0.807s

and essentially the same numbers for b1. I see similar behavior on 10.8.2.

Justin

--
Justin C. Walker
Director

Institute for the Enhancement of the Director's Income
--

Fame is fleeting, but obscurity
just drags on and on. F&E

[Volker Braun]

On Friday, March 1, 2013 3:11:32 AM UTC-10, John Cremona wrote:

Is there a reason why start-up time should be getting worse?
Immediately after building + make ptestlong I start sage-5.8.beta2 and
quit:
(CPU time 0m0.06s, Wall time 0m26.71s)

Sounds like most of the time was spent waiting for the disk. Its possible that the last doctest used a lot of ram, which pushed the unused parts of the Sage library out of the disk cache.

 

[John Cremona]

Brilliant diagnosis! In fact his was several hours after the build &
test had finished, and the machine has 64 gb of RAM and 24 processors,
but... 3 magma processes were using up about 60gb between them, so you
are right (and I'll yet again have to warn my colleagues to keep an
eye on their magmas).

John

[leif]

leif wrote:
> Jeroen Demeyer wrote:
>> Dear Sage lovers,
>>
>> We're releasing Sage 5.8.beta2.
>

> Built w/o problems on Ubuntu 10.04.4 x86_64 (GCC 4.7.0), and all tests
> passed (ptestlong), except for
>
> devel/sage/sage/combinat/sf/k_dual.py
>
> which initially timed out.
>
> This is a major regression: It now doesn't only use more than 1 GB RAM
> (resident), but also takes about 10 (ten!) times longer than it took
> with Sage 5.7.beta4 on the same machine, with the same compiler, and the
> same flags. [Don't know when exactly the regression went in.]

This is apparently http://trac.sagemath.org/sage_trac/ticket/13991
("Mitigate speed regressions in symmetric function related code due to
#12313").


-leif

[David Kirkby]

On 28 February 2013 14:36, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> Dear Sage lovers,
>
> We're releasing Sage 5.8.beta2.
>
> Source archive:
>
> http://boxen.math.washington.edu/home/release/sage-5.8.beta2/sage-5.8.beta2.tar

Here's two results from building on a Sun Blade 2000.

1) Using the gcc 4.5.0 I built a long time ago, R would not build.
2) Using the Sun supplied gcc 3.4.3, that compiler was used to build
the gcc package in Sage, and the build completed.

There were 3 doctest failures:

The following tests failed:

sage -t --long -force_lib devel/sage/sage/crypto/mq/sr.py # 1 doctests failed
sage -t --long -force_lib
devel/sage/sage/matrix/matrix_modn_dense.pyx # 5 doctests failed
sage -t --long -force_lib
devel/sage/sage/matrix/matrix_modn_dense_template.pxi # 5 doctests
failed
----------------------------------------------------------------------
Total time for all tests: 26899.3 seconds

A log of the test results can be seen at:

http://boxen.math.washington.edu/home/kirkby/ptestlong.log.gz

If anyone feels able/willing to sort the issus out, I can create an
account on the machine.

I know I should really upgrade this machine to Solaris 11, but it is
working and I use it for real work, and so are reluctant to fix
something that is doing me a fine job.

Dave

[Jeroen Demeyer]

On 2013-03-02 20:31, David Kirkby wrote:
> The following tests failed:
>
> sage -t --long -force_lib devel/sage/sage/crypto/mq/sr.py # 1 doctests failed
> sage -t --long -force_lib
> devel/sage/sage/matrix/matrix_modn_dense.pyx # 5 doctests failed
> sage -t --long -force_lib
> devel/sage/sage/matrix/matrix_modn_dense_template.pxi # 5 doctests
> failed
> ----------------------------------------------------------------------
> Total time for all tests: 26899.3 seconds

There already is a ticket:
http://trac.sagemath.org/sage_trac/ticket/13151

[Jean-Pierre Flori]

On Saturday, March 2, 2013 8:31:31 PM UTC+1, David Kirkby wrote:

On 28 February 2013 14:36, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> Dear Sage lovers,
>
> We're releasing Sage 5.8.beta2.
>
> Source archive:
>
> http://boxen.math.washington.edu/home/release/sage-5.8.beta2/sage-5.8.beta2.tar

Here's two results from building on a Sun Blade 2000.

1) Using the gcc 4.5.0 I built a long time ago, R would not build.
2) Using the Sun supplied gcc 3.4.3, that compiler was used to build
the gcc package in Sage, and the build completed.

I continued experiments on a Ultrasparc T2+  and could finally begin the build: under my usual shell the GNU tar was picked up, but not in Sage's shell... strange.
Because of that the prereq install script failed to untar the prereq tarball and failed... before the test for  GNU tar were made at the end of the script.

I'm using gcc 3.43 which is the default compiler found on the system (there might be another one somewhere, not sure), so that GCC 4.6.3 build is triggered.
But, then iconv which is a prereq for MPIR failed to build with Sun gcc 3.4.3, it seems it does not get the -Wl,... -Wl,... syntax.
So I'm building MPIR without having built iconv and let's see what happens.

[Jean-Pierre Flori]

And it fails with a similar problem.

Should I build GCC first in another way?
Are the instructions at http://wiki.sagemath.org/Solaris-on-SPARC still of any use? 
Any advice, Dave?

[Jean-Pierre Flori]

Think I got it.
Its the autotools macro which looks broken if I got the same problem as reported there: http://lists.gnu.org/archive/html/libtool/2007-08/msg00039.html
The configure script finds the GNU linker which is installed and first in PATH, so libtool thinks it will be used, but its not the one GCC calls by default.

I worked around this by setting LD_ALTEXEC to point to the GNU linker and at least iconv was built, now going through MPIR.

[leif]

I think that's a rather common problem on Solaris (having a different
linker first in PATH than GCC was configured to use).

AFAIK setting LD to the one GCC actually uses (or modifying your PATH)
suffices.

[Jeroen Demeyer]

On 2013-03-05 14:30, Jean-Pierre Flori wrote:
> Are the instructions at http://wiki.sagemath.org/Solaris-on-SPARC still
> of any use?
> Any advice, Dave?

Not sure, in any case it dates back to older (pre-GCC) versions of Sage.

With the GCC spkg, it's not even required to have GCC, you could try
building with CC=/usr/bin/suncc (or whatever the path to the Sun C
compiler).

[Jeroen Demeyer]

On 2013-03-05 14:43, Jean-Pierre Flori wrote:
> I worked around this by setting LD_ALTEXEC to point to the GNU linker
> and at least iconv was built, now going through MPIR.

In my experience, building Sage on Solaris with the GNU linker doesn't
work, you need the Solaris linker. But go ahead and see what happens.

[Jean-Pierre Flori]

It built (correctly?) iconv and MPIR, then failed with MPFR because the first (GNU) makeinfo in PATH was too old and did not recognize "--enable-encoding".
Fortunately there was another more recent makeinfo and MPFR and MPC were build (still with the GNU linker, correctly?).

The GCC build began and failed at some point because it assumes by default (i.e. unless you pass --with-gnu-ld) that the linker is the Sun's one and the GNU linker did not understand some generated libgcc.map file.
So I've unset LD_ALTEXEC and set LD to the Sun's one now and GCC seems happy (it surely "bad" to mix linker, but whatever, I'll go on like this until something bad happens).

[Jean-Pierre Flori]

But ultimately failed because stage 2 and 3 diffeR.

[Jean-Pierre Flori]

I'm trying gcc 4.7.2 now.

[Jean-Pierre Flori]

Same problem.
Many object files in stage 2 and 3 differ.

[Jeroen Demeyer]

On 2013-03-06 13:21, Jean-Pierre Flori wrote:
> Same problem.
> Many object files in stage 2 and 3 differ.

Try to enable this fix (in gcc spkg-install) for Cygwin and see it if helps:

# Disable bootstrap-debug on Darwin, since it doesn't work on an
# OS X 10.4 PPC machine. bootstrap-debug only does additional checks,
# so it is safe not to use it.
if [ "$UNAME" = "Darwin" ]; then
MAKE="$MAKE BUILD_CONFIG="
fi

[Jean-Pierre Flori]

It worked! (with GCC 4.6.3, did nt try 4.7.2)
I got some "spkg/bin/sage: line 825: exec: sage-location: not found" error in the end after the "Finished installing..." message, but I'm not convinced its related.