Sage 7.5.beta5 released

135 views
Skip to first unread message

Volker Braun

unread,
Dec 1, 2016, 6:15:57 PM12/1/16
to sage-release
As always, you can get the latest beta version from the "develop" git branch. Alternatively, the self-contained source tarball is at http://www.sagemath.org/download-latest.html

163489e Updated SageMath version to 7.5.beta5
d1d859d Trac #22000: The coding conventions for INPUT: blocks have periods
0d7c45d Trac #21805: Use psutil instead of various hacks
909d9e1 Trac #12402: Make a three.js backend for 3d plotting
df2adac Trac #8181: cannot convert residue field elements back to p-adic ring
f5afa90 Trac #21979: Wrong conversion from algebraic to interval
6d380f9 Trac #21947: Don't let "tightpage" in view cut tikz images
ee25e65 Trac #21647: Doctest continuation marker / combinat
4baf341 Trac #20692: Add sage-apply-patches helper script for use in spkg-install scripts
5944641 Trac #21988: Implement epimorphisms from finitely presented group.
21d920f Trac #21982: Py3: Unicode errors in docstrings
2306db0 Trac #21895: Better metaclass inference in dynamic classes
14b6fe7 Trac #21911: Docstring for IncidenceStructure.is_uniform has issues
d7e2d06 Trac #21949: some various typos
1490af2 Trac #21978: py3 richcmp in pyx files for finite rings
94b5b1d Trac #21970: py3 richcmp in function fields (pyx)
9acd3ad Trac #21967: little cleanup for universal cyclotomic field
20ea82e Trac #21964: py3 richcmp in 2 pyx files (in structure and symbolic folders)
8cc8ff5 Trac #21491: IndexError in integral_points_count of Polyhedron
056f5c6 Trac #21953: Chain complexes: implement shift (= translation = suspension)
f022846 Trac #21929: Make "tightpage=True" the default behavior for view
04deb1f Trac #21925: Remove some deprecated code
dc97fb2 Trac #21960: Get rid of six.itervalues in Cython
0da1c25 Trac #21701: Compiling sagelib with clang on OS X (Sierra): failure in cythonized sage/symbolic/expression.pyx
cbb59f1 Trac #21962: Don't import max from builtins
abd7ed7 Trac #21961: Get rid of six.moves.range in Cython files (step 4)
2068019 Trac #21958: py3 richcmp in Laurent and power series (pyx files)
113c7c2 Trac #21955: py3 get rid of cmp() in two pyx files in modular folder
68a5e5a Trac #21938: Problem in the documentation of block design
0cd8bb6 Trac #21930: Add rank for hypergraphs
649379c Trac #21926: Deprecate unused stuff from sage/misc/misc.py
f9af853 Trac #21919: documentation of FiniteSetMaps(n) says it is over {1, 2, ..., n}
e2729c8 Trac #21913: LatticePoset: Add certicate for is_vertically_decomposable
1ca5b30 Trac #21908: Fix _ascii_art_ for 0 in a CombinatorialFreeModule
1b2e37c Trac #21607: Posets: with_linear_extension() and wrong constructor
4c9e162 Trac #21513: Package rst2ipynb
c4df8bb Trac #17147: Overriding checks to generate poset and lattice faster
aa2bcc1 Updated SageMath version to 7.5.beta4

Paul Masson

unread,
Dec 1, 2016, 7:31:00 PM12/1/16
to sage-release
The develop branch now has two uncommitted files, both with the first line:

# This file is auto-generated by sage_setup/autogen/pari/generator.py

François Bissey

unread,
Dec 1, 2016, 8:06:29 PM12/1/16
to sage-r...@googlegroups.com
Can please people stop using files in SAGE_SRC at runtime and people
stop reviewing such things positively unless there is absolutely no
choices.

In sage/plot/plot3d/base.pyx we have line 410 and after:
from sage.env import SAGE_SRC
filename = os.path.join(SAGE_SRC, 'sage',
'plot', 'plot3d', 'threejs_template.html')
f = open(filename, 'r')
html = f.read()
f.close()

If you really need this at run time, ship it and access
it relative to SAGE_LIB instead of SAGE_SRC. Thank you #12402.

Francois
> --
> 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
> <mailto:sage-release...@googlegroups.com>.
> To post to this group, send email to sage-r...@googlegroups.com
> <mailto:sage-r...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/sage-release.
> For more options, visit https://groups.google.com/d/optout.

Paul Masson

unread,
Dec 1, 2016, 8:47:03 PM12/1/16
to sage-release
François, I'm responsible for this but need more information. It was recommended by one of my reviewers that I keep an HTML template for Three.js support separate from the Python code and the template must be accessible at runtime. For this first version it's sitting in the source code next to the other 3d plotting files.

Where should it actually go in the source so that it's accessible at runtime, both for developers and end users?

I see many instances of SAGE_SRC in the source code but not so many of SAGE_LIB. I'm also not finding any documentation for SAGE_LIB. How are people supposed to know what is considered the proper use of the two locations?

François Bissey

unread,
Dec 1, 2016, 8:57:11 PM12/1/16
to sage-r...@googlegroups.com
I am testing a patch. Basically you really want the html file
to be installed like the other python files. Then you can use
SAGE_LIB which really is the top level of "site-packages" instead of
SAGE_SRC. This is what I am testing right now
diff --git a/src/sage/plot/plot3d/base.pyx b/src/sage/plot/plot3d/base.pyx
index 0ca1c71..6bb89e5 100644
--- a/src/sage/plot/plot3d/base.pyx
+++ b/src/sage/plot/plot3d/base.pyx
@@ -407,8 +407,8 @@ cdef class Graphics3d(SageObject):
surfaces = flatten_list(surfaces)
surfaces = '[' + ','.join(surfaces) + ']'

- from sage.env import SAGE_SRC
- filename = os.path.join(SAGE_SRC, 'sage',
+ from sage.env import SAGE_LIB
+ filename = os.path.join(SAGE_LIB, 'sage',
'plot', 'plot3d', 'threejs_template.html')
f = open(filename, 'r')
html = f.read()
diff --git a/src/setup.py b/src/setup.py
index 7451519..7b96378 100755
--- a/src/setup.py
+++ b/src/setup.py
@@ -666,7 +666,7 @@ class sage_build_ext(build_ext):
dist = self.distribution
from sage_setup.find import find_extra_files
self.cythonized_files = find_extra_files(dist.packages,
- ".", SAGE_CYTHONIZED, ["ntlwrap.cpp"])
+ ".", SAGE_CYTHONIZED, ["ntlwrap.cpp", "threejs_template.html"])

for (dst_dir, src_files) in self.cythonized_files:
dst = os.path.join(self.build_lib, dst_dir)
> > an email to sage-release...@googlegroups.com <javascript:>
> > <mailto:sage-release...@googlegroups.com <javascript:>>.
> > To post to this group, send email to sage-r...@googlegroups.com
> <javascript:>
> > <mailto:sage-r...@googlegroups.com <javascript:>>.
> <https://groups.google.com/group/sage-release>.
> > For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
> --
> 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
> <mailto:sage-release...@googlegroups.com>.

François Bissey

unread,
Dec 1, 2016, 9:06:13 PM12/1/16
to sage-r...@googlegroups.com
Re-reading your answer again, if you don't want it along side the .py
files you'll have to install it in something like local/share/sage.
You could put it in its own folder under src/ext/ and it would installed
automatically by the current mechanic. But you would have to change
SAGE_SRC to something like SAGE_EXTCODE.
Supposing you put it under src/ext/threejs you would use
os.path.join(SAGE_EXTCODE, 'threejs', 'threejs_template.html')

Francois

On 02/12/16 14:47, Paul Masson wrote:
> > an email to sage-release...@googlegroups.com <javascript:>
> > <mailto:sage-release...@googlegroups.com <javascript:>>.
> > To post to this group, send email to sage-r...@googlegroups.com
> <javascript:>
> > <mailto:sage-r...@googlegroups.com <javascript:>>.
> <https://groups.google.com/group/sage-release>.
> > For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
> --
> 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
> <mailto:sage-release...@googlegroups.com>.

François Bissey

unread,
Dec 1, 2016, 9:32:12 PM12/1/16
to sage-r...@googlegroups.com
On 02/12/16 14:47, Paul Masson wrote:
> I see many instances of SAGE_SRC in the source code but not so many of
> SAGE_LIB. I'm also not finding any documentation for SAGE_LIB. How are
> people supposed to know what is considered the proper use of the two
> locations?

How many of the package that you have installed on your computer rely
on the source being available?
As far as I am concerned SAGE_SRC should not be used at runtime.
One of the current problem with sage is it is not testable before being
installed. This is the only reason, in my opinion SAGE_SRC can still
sometimes being used in things that are installed. If it is needed for
doctesting. And sometimes for stuff the dev thinks are nice for
themselves but add not much value to an end user, and when there is
value, an alternative way could be pursued at low cost.

But functionality should not rely on anything under SAGE_SRC this is
a broken design.

In a standard sage install SAGE_LIB will default to
SAGE_LOCAL/lib/python2.7/site-packages.
Since all the python files under SAGE_SRC/sage will be installed
under SAGE_LIB/sage the substitution should be one to one.

Francois

Sébastien Labbé

unread,
Dec 2, 2016, 2:11:48 AM12/2/16
to sage-release
On OS X 10.10.2, make ptestlong creates two sage.png file due to #21947 (I will create a ticket to fix this shortly) and finishes with:

----------------------------------------------------------------------
sage -t --long --warn-long 264.4 src/sage/modular/modform/element.py  # Timed out
sage -t --long --warn-long 264.4 src/sage/interfaces/singular.py  # 1 doctest failed
----------------------------------------------------------------------

The singular issue is the same as reported for 7.5.beta4 and earlier threads. Here is where the doctest timed out for element.py (I can't reproduce) :

sage -t --long --warn-long 264.4 src/sage/modular/modform/element.py
    Timed out
**********************************************************************
Tests run before process (pid=23593) timed out:
sage: from sage.modular.modform.element import is_ModularFormElement ## line 40 ##
sage: is_ModularFormElement(5) ## line 41 ##
False
...
sage: eps = DirichletGroup(3).0 ## line 1730 ##
sage: eps.parent() ## line 1731 ##
Group of Dirichlet characters modulo 3 with values in Cyclotomic Field of order 2 and degree 1
sage: f_eps = f.twist(eps) ## line 1733 ##
**********************************************************************

Everything else is okay!

Sébastien

Sébastien Labbé

unread,
Dec 2, 2016, 2:33:13 AM12/2/16
to sage-release
 
make ptestlong creates two sage.png file due to #21947 (I will create a ticket to fix this shortly)

Erik Bray

unread,
Dec 2, 2016, 5:38:50 AM12/2/16
to sage-r...@googlegroups.com
On Fri, Dec 2, 2016 at 2:06 AM, François Bissey
<francoi...@canterbury.ac.nz> wrote:
> Can please people stop using files in SAGE_SRC at runtime and people
> stop reviewing such things positively unless there is absolutely no
> choices.
>
> In sage/plot/plot3d/base.pyx we have line 410 and after:
> from sage.env import SAGE_SRC
> filename = os.path.join(SAGE_SRC, 'sage',
> 'plot', 'plot3d', 'threejs_template.html')
> f = open(filename, 'r')
> html = f.read()
> f.close()
>
> If you really need this at run time, ship it and access
> it relative to SAGE_LIB instead of SAGE_SRC. Thank you #12402.

I agree. Runtime dependencies on SAGE_SRC have really been a pain in
trying to package Sage. It's basically impossible to package without
the source code and that's not really how to do this...
> email to sage-release...@googlegroups.com.
> To post to this group, send email to sage-r...@googlegroups.com.

Emmanuel Charpentier

unread,
Dec 2, 2016, 6:14:25 AM12/2/16
to sage-release


Le vendredi 2 décembre 2016 02:06:29 UTC+1, François a écrit :
Can please people stop using files in SAGE_SRC at runtime and people
stop reviewing such things positively unless there is absolutely no
choices.

Indeed. Reading the rest of the thread so far show that it's important.

But people coming to Sage are not necessarily seasoned developers/packagers/maintainers. They are ordinary matemathicians/engeneers/students, with no previous knowledge of these problems.

Therefore, this (and other analogous issues) should be should be explained and discussed in the right place (i. e. the place where people turn to when learning how to package their ideas for Sage) : the Sage Developer's guide. One can hardly expect newcomers to consult every rant on sage-devel and sage-release

Would you consider writing a patch for this guide ?

In sage/plot/plot3d/base.pyx we have line 410 and after:
         from sage.env import SAGE_SRC
         filename = os.path.join(SAGE_SRC, 'sage',
                                 'plot', 'plot3d', 'threejs_template.html')
         f = open(filename, 'r')
         html = f.read()
         f.close()

If you really need this at run time, ship it and access
it relative to SAGE_LIB instead of SAGE_SRC. Thank you #12402.

Dumb dentist's idea : the spkg-install script might *move* the relevant file in some appropriate location under SAGE_LIB and symlink it in the source tree, thus more or less transparently ensuring availability at runtime and at compile time. Of course, if the source code explicitly references its own source tree, that won't be sufficient, and heavier patching will be required.

That should work at least on unices, Macs, and probably on cygwin IIRC...

What do you think ?

--
Emmanuel Charpentier

Thierry

unread,
Dec 2, 2016, 7:04:21 AM12/2/16
to sage-r...@googlegroups.com
On Fri, Dec 02, 2016 at 03:14:24AM -0800, Emmanuel Charpentier wrote:
[...]
> Dumb dentist's idea : the spkg-install script might *move* the relevant
> file in some appropriate location under SAGE_LIB and symlink it in the
> source tree, thus more or less transparently ensuring availability at
> runtime and at compile time. Of course, if the source code explicitly
> references its own source tree, that won't be sufficient, and heavier
> patching will be required.
>

The issue is not related to any package, so there is no spkg-install to
use. Also, removing things from the src directory will not be transparent
at development time, git will complain that things changed without being
commited.

I guess an appropriate solution which is widely used already, and that
Francois already mentioned would be to put the templates files in
SAGE_ROOT/src/ext/blah so that they are automatically copied in
SAGE_ROOT/local/share/sage/ext/blah and accessed from SAGE_EXT/blah
without any additional script. See also:

https://trac.sagemath.org/ticket/12402#comment:125

Ciao,
Thierry
> > > an email to sage-release...@googlegroups.com <javascript:>
> > > <mailto:sage-release...@googlegroups.com <javascript:>>.
> > > To post to this group, send email to sage-r...@googlegroups.com
> > <javascript:>
> > > <mailto:sage-r...@googlegroups.com <javascript:>>.
> > > Visit this group at https://groups.google.com/group/sage-release.
> > > For more options, visit https://groups.google.com/d/optout.
> >
> >
>
> --
> 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.

John H Palmieri

unread,
Dec 2, 2016, 10:22:05 AM12/2/16
to sage-release
Just for kicks, I tried building with SAGE_CHECK=yes. (Do any of the buildbots do this?)

On two different OS X machines, 10.11 and 10.12, two :

Error building Sage.

The following package(s) may have failed to build (not necessarily during this run of 'make all'):

* package: cython-0.25.1.p0
* package: gf2x-1.1.p1


On Thursday, December 1, 2016 at 3:15:57 PM UTC-8, Volker Braun wrote:

John H Palmieri

unread,
Dec 2, 2016, 10:26:55 AM12/2/16
to sage-release


On Friday, December 2, 2016 at 7:22:05 AM UTC-8, John H Palmieri wrote:
Just for kicks, I tried building with SAGE_CHECK=yes. (Do any of the buildbots do this?)

On two different OS X machines, 10.11 and 10.12, two :

The end of this should have said "two packages failed their self-tests".

 

Justin C. Walker

unread,
Dec 2, 2016, 7:20:19 PM12/2/16
to sage-r...@googlegroups.com

> On Dec 1, 2016, at 15:15 , Volker Braun <vbrau...@gmail.com> wrote:
>
> As always, you can get the latest beta version from the "develop" git branch. Alternatively, the self-contained source tarball is at http://www.sagemath.org/download-latest.html

Built from tarball on macOS 10.11.6 w/o problems. Testing (‘ptestlong’) turned up two failures, the usual Singular problem (“sagexxx not defined”), and a new one in "src/sage/modular/modform/find_generators.py” [*]. I ran the latter by and it again timed out (after ~30 minutes). It left some information for the curious, which I’m attaching below.

Justin

[*]At least, I haven’t seen it before, or seen it discussed (and I don’t see fingerprints on the last couple of betas).

test.out

Eric Gourgoulhon

unread,
Dec 5, 2016, 7:15:34 AM12/5/16
to sage-release
From a fresh git clone + pull develop, build OK + make ptestlong passed on Ubuntu 16.04 x86_64 Xeon E5-2623 + 16 GB RAM.

Eric.

Paul Masson

unread,
Dec 5, 2016, 3:18:33 PM12/5/16
to sage-release
These files have been removed from the develop branch, but I've just noticed they also appear in the master branch.
Reply all
Reply to author
Forward
Message has been deleted
0 new messages