Sage 8.1.rc0 released

[Volker Braun]

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

b707ce9348 (tag: 8.1.rc0, trac/develop) Updated SageMath version to 8.1.rc0

0542f0a7fb Trac #19517: Graphs: canonical_label() and several errors

c73b0be317 Trac #24143: zeromq: don't use -Werror

06dbe2327a Trac #24154: Fix equation handling of Polyhedron.to_linear_program() and thus integral_points_count(preprocess=True)

23c060c581 Trac #24062: Upgrade to SymPy-1.1.1

a89800b2e0 Trac #16801: Conversion of psi(x,y) to/from SymPy

dc9be1b424 Trac #20204: Fix problems with constructing or converting to SymPy expressions

8ad8826519 Trac #23954: Mass change of docstring: from "-" to "--", variables with underscores

82666c4788 Trac #24095: Part 2, "Posets.*" to "posets.*"

780f69dd4d Trac #24076: Pep8-compliance, lattices.py as an example

e33beaf80a Trac #24069: let our required header be pep8 compliant

ca925431c8 Trac #24048: Unify selfdual and self_dual

071c1bf918 Trac #18536: Solvers for constant sum games

5c90df6193 Trac #24133: py3 : get rid of im_func again

13d7a570cb Trac #24132: py3: some care for items() and values()

3897c7f864 Trac #24126: py3: some more care for keys()[...]

63273442d6 Trac #24119: Create an assuming() context manager

701897ecc3 Trac #24114: prefer list(K) over K.list() for syndrom decoder

4d82659aaa Trac #24104: Merge the code of ex.solve(...) and solve(...)

004a326306 Trac #23991: Update curl to 7.56.1

4ddb4717bd Trac #23787: py3: richcmp for ideals

b78794f137 Trac #23112: Repair math-readline script for interactive use, mathematica_console and make Mathematica pexpect work without helper script

c59a1adb5b Trac #20439: eigenmatrix_right gives the conjugate of what it should

a181bc24e8 Trac #24081: Use system curl if possible

4398274f52 Trac #24061: Slightly faster test for semiorder

7c6371b16d Trac #11541: Add example with solution_dict and substituting in a matrix

9d1fdaa3c0 Trac #24127: py3: adding hash for complex fields

7ec526c44c Trac #24124: lazy import hecke algebras

75e5ef97f6 Trac #24120: Implement the q-Pochhammer symbol

20f0073693 Trac #24116: Fix Cython warnings in finite_rings

9896ca2282 Trac #24113: Add test for cactus graph

326106ee54 Trac #24110: Upgrade to Cython 0.27.2

7b3992b637 Trac #24109: Always enable debug.bad_parent_warnings

02cebd0016 Trac #24105: Deprecate Sage-specific Cython pragmas like #clib

e738d859cb Trac #24103: Remove a lot of deprecated code

b8686f64dd Trac #24026: Upgrade R to 3.4.2

75506c95b1 Trac #23982: perfect matchings and containment

a62930e0e7 Trac #23919: Sage library: standardize on C99 and C++11

c646a6d7a7 Trac #22566: SymPy's ceiling() is not translated to Sage

79be5d5a7b Trac #24099: Use PPL by default for Fractional Chromatic Index

6c101056ac Trac #24017: Add sdh_die helper function--report an error message and exit

acdd015032 Trac #23923: Interface cases function with SymPy's piecewise

0d0a98582f Trac #23830: Add SBox Instance: DBlock cipher

72ccc417e4 Trac #23804: gap_eval: move libgap_enter() inside sig_on()

d0950542cf Trac #21303: Make hecke operators not blow up the memory

1df89a43aa Trac #10950: The hash function for matrices suffers from many collisions

10d2434878 Trac #24097: Broken paths in cython()'d modules

2b602e263f Trac #24090: Clean up matrix hashing

ac85d0d147 Trac #24068: py3: some care for .values()[...]

1493886987 Trac #24029: Force -std=gnu++11 for Linbox

a9dc63f072 Trac #24021: Checking if a graph is cograph

0ee8241017 Trac #24006: SymPy --> Sage conversion completely inside Sage

8785904f43 Trac #23967: Coercion pushout for FGP_modules

d396f15a96 Trac #23939: Link from IntegerVectors documentation to IntegerListsLex documentation

7138bd107c Trac #23861: Doctest: Make Expression normalization work with symbolic powers

9898df4172 Trac #23793: Doctest: Bug in symbolic GCD computations involving complex I

af44562d9f Trac #23742: Check for overflow in matrix_mod2_dense

14d3ce4969 Trac #23707: More competitive and comprehensive finite dimensional algebras

7c41260607 Trac #23400: Cleanup of matrix_gfpn_dense

4879c7f48a Trac #22391: Always use PPL for facet normals of lattice polytopes

35f930c0fc Trac #22073: Surprising matrix solve error message

d6f7f9e5bd Trac #18970: Log function and documentation revamp

e7f6e8fede Trac #10035: Hold context

88b3fbff89 Trac #24072: Disallow positive characteristic in the symbolic ring

3e7031cef8 Trac #14305: Doctest: Immediate simplifications of symbolic powers

4dd39c0de8 Trac #24092: Make brial depend on pip

a90b25ebf7 Trac #23898: Upgrade to gcc 7.2.0 (gcc 5.4.0 does not build with Xcode 9.0)

8418fd787f Trac #24074: cleanup of words/words.py

78b5f627f1 Trac #23988: another collection of typos

5a9a622251 Trac #23916: Pretty printing and latex for Genera of quadratic forms

9392bc7845 Trac #24077: Fix is_integral() for quadratic order elements

e0668d49c1 Trac #24042: Upgrade fplll and fpylll

e07d641b30 Trac #23781: python2/3: split spkg-install to spkg-build; fix various build issues

7db5a8af9a Trac #24088: build hangs on ipykernel

9b80346b3a Trac #24075: doctest failure in  schemes/elliptic_curves/heegner.py

bc45dab36e (tag: 8.1.beta9) Updated SageMath version to 8.1.beta9

[John H Palmieri]

WIth OS X 10.12.6, Xcode (and the same happens when building with clang, #12426):

sage -t --long --warn-long 64.0 src/sage/matrix/matrix_mod2_dense.pyx  # Killed due to kill signal

**********************************************************************
Tests run before process (pid=12556) failed:
sage: a = matrix(GF(2),3,range(9),sparse=False); a ## line 8 ##
[0 1 0]
[1 0 1]
[0 1 0]
sage: a.rank() ## line 12 ##
2
sage: type(a) ## line 14 ##
<type 'sage.matrix.matrix_mod2_dense.Matrix_mod2_dense'>
sage: a[0,0] = 1 ## line 16 ##
sage: a.rank() ## line 17 ##
3
sage: parent(a) ## line 19 ##
Full MatrixSpace of 3 by 3 dense matrices over Finite Field of size 2
sage: a^2 ## line 22 ##
[0 1 1]
[1 0 0]
[1 0 1]
sage: a+a ## line 26 ##
[0 0 0]
[0 0 0]
[0 0 0]
sage: b = a.new_matrix(2,3,range(6)); b ## line 31 ##
[0 1 0]
[1 0 1]
sage: a*b ## line 35 ##
sage: b*a ## line 39 ##
[1 0 1]
[1 0 0]
sage: TestSuite(a).run() ## line 43 ##
sage: TestSuite(b).run() ## line 44 ##
sage: a.echelonize(); a ## line 46 ##
[1 0 0]
[0 1 0]
[0 0 1]
sage: b.echelonize(); b ## line 50 ##
[1 0 1]
[0 1 0]
sage: FF = FiniteField(2) ## line 56 ##
sage: V = VectorSpace(FF,2) ## line 57 ##
sage: v = V([0,1]); v ## line 58 ##
(0, 1)
sage: W = V.subspace([v]) ## line 60 ##
sage: W ## line 61 ##
Vector space of degree 2 and dimension 1 over Finite Field of size 2
Basis matrix:
[0 1]
sage: v in W ## line 65 ##
True
sage: M = Matrix(GF(2), [[1,1,0],[0,1,0]]) ## line 68 ##
sage: M.row_space() ## line 69 ##
Vector space of degree 3 and dimension 2 over Finite Field of size 2
Basis matrix:
[1 0 0]
[0 1 0]
sage: M = Matrix(GF(2), [[1,1,0],[0,0,1]]) ## line 75 ##
sage: M.row_space() ## line 76 ##
Vector space of degree 3 and dimension 2 over Finite Field of size 2
Basis matrix:
[1 1 0]
[0 0 1]
sage: sig_on_count() # check sig_on/off pairings (virtual doctest) ## line 90 ##
0
sage: type(random_matrix(GF(2),2,2)) ## line 165 ##
<type 'sage.matrix.matrix_mod2_dense.Matrix_mod2_dense'>
sage: Matrix(GF(2),3,3,1) # indirect doctest ## line 168 ##
[1 0 0]
[0 1 0]
[0 0 1]
sage: matrix(GF(2),0,[]) * vector(GF(2),0,[]) ## line 177 ##
()
sage: MatrixSpace(GF(2), 2^30)(1) ## line 182 ##

**********************************************************************

[John H Palmieri]

Sorry, I sent too early. This is with Xcode 9.1 (the most recent version).

[François Bissey]

Smells like https://trac.sagemath.org/ticket/23742

[Emmanuel Charpentier]

On Debian testing 8.1.rc0 + Trac#24121 in its current state passes ptestlong without error whatsoever.

HTH,

--
Emmanuel Charpentier

[Eric Gourgoulhon]

On Ubuntu 16.04 x86_64 Xeon E5-2623 + 16 GB RAM, from a fresh git clone + pull develop, parallel (-j16) build OK and ptestlong failed with one doctest:

sage -t --long --warn-long 45.7 src/sage/geometry/riemannian_manifolds/surface3d_generators.py  # 1 doctest failed

As usual on this computer since a few betas, this is due to the failure of Jmol to create some file in ~/.sage/temp/  . But the doctest is passed when run standalone.

Best wishes,

Eric.

[Volker Braun]

Can somebody open a ticket for that issue?

[Maarten Derickx]

Scipy fails to build on the sage4 patchbot  (4.4.26-gentoo). Relevant part of the log:

[scipy-0.19.1]     getarrdims:warning: assumed shape array, using 0 instead of '*'
[scipy-0.19.1]     getarrdims:warning: assumed shape array, using 0 instead of '*'
[scipy-0.19.1]     		  x,y = zrot(x,y,c,s,[n,offx,incx,offy,incy,overwrite_x,overwrite_y])
[scipy-0.19.1]     		Constructing wrapper function "ilaver"...
[scipy-0.19.1]     		  major,minor,patch = ilaver()
[scipy-0.19.1]     	Wrote C/API module "_flapack" to file "build/src.linux-x86_64-2.7/build/src.linux-x86_64-2.7/scipy/linalg/_flapackmodule.c"
[scipy-0.19.1]     	Fortran 77 wrappers are saved to "build/src.linux-x86_64-2.7/build/src.linux-x86_64-2.7/scipy/linalg/_flapack-f2pywrappers.f"
[scipy-0.19.1]       adding 'build/src.linux-x86_64-2.7/build/src.linux-x86_64-2.7/build/src.linux-x86_64-2.7/scipy/linalg/fortranobject.c' to sources.
[scipy-0.19.1]       adding 'build/src.linux-x86_64-2.7/build/src.linux-x86_64-2.7/build/src.linux-x86_64-2.7/scipy/linalg' to include_dirs.
[scipy-0.19.1]       adding 'build/src.linux-x86_64-2.7/build/src.linux-x86_64-2.7/scipy/linalg/_flapack-f2pywrappers.f' to sources.
[scipy-0.19.1]     building extension "scipy.linalg._flinalg" sources
[scipy-0.19.1]     f2py options: []
[scipy-0.19.1]     f2py:> build/src.linux-x86_64-2.7/scipy/linalg/_flinalgmodule.c
[scipy-0.19.1]     IOError: [Errno 2] No such file or directory: 'scipy/linalg/src/det.f'. Skipping file "scipy/linalg/src/det.f".
[scipy-0.19.1]     IOError: [Errno 2] No such file or directory: 'scipy/linalg/src/lu.f'. Skipping file "scipy/linalg/src/lu.f".
[scipy-0.19.1]     Reading fortran codes...
[scipy-0.19.1]     Post-processing...
[scipy-0.19.1]     Post-processing (stage 2)...
[scipy-0.19.1]     Building modules...
[scipy-0.19.1]     error: f2py target file 'build/src.linux-x86_64-2.7/scipy/linalg/_flinalgmodule.c' not generated
[scipy-0.19.1]     Running setup.py install for scipy: finished with status 'error

I created https://trac.sagemath.org/ticket/24187#ticket for this.

[Eric Gourgoulhon]

On the same computer as above (Ubuntu 16/04),
./sage -n
as well as any of the equivalent commands
./sage --notebook
./sage -n export
./sage --notebook export

fails with the following error message:

[C 14:35:42.400 NotebookApp] Bad config encountered during initialization:
[C 14:35:42.400 NotebookApp] The 'nbserver_extensions' trait of a NotebookApp instance must be a dict, but a value of type 'list' (i.e. ['sagenb_export.nbextension']) was specified.

On the same machine, it is OK for Sage 8.1beta8 and all previous betas. Moreover
./sage -n jupyter
./sage -n sagenb
both work perfectly with 8.1.rc0.

Eric.

[Maarten Derickx]

CBC causes doctest failures because of linking with incompatible liblapack on the quasar patchbot:

See [https://patchbot.sagemath.org/log/0/Ubuntu/16.04/x86_64/4.4.0-98-generic/quasar/2017-11-10%2009:54:32?short the logs of quasar]:

Relevant part of the logs:

File "src/sage/numerical/backends/coin_backend.pyx", line 1628, in sage.numerical.backends.coin_backend.CoinBackend.get_row_price

Failed example:

    p = get_solver(solver = "Coin")                  # optional - cbc

Exception raised:

    Traceback (most recent call last):

      File "/home/vdelecro/sage_patchbot/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 515, in _run

        self.compile_and_execute(example, compiler, test.globs)

      File "/home/vdelecro/sage_patchbot/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 885, in compile_and_execute

        exec(compiled, globs)

      File "<doctest sage.numerical.backends.coin_backend.CoinBackend.get_row_price[1]>", line 1, in <module>

        p = get_solver(solver = "Coin")                  # optional - cbc

      File "sage/numerical/backends/generic_backend.pyx", line 1650, in sage.numerical.backends.generic_backend.get_solver (build/cythonized/sage/numerical/backends/generic_backend.c:21055)

        cpdef GenericBackend get_solver(constraint_generation = False, solver = None, base_ring = None):

      File "sage/numerical/backends/generic_backend.pyx", line 1785, in sage.numerical.backends.generic_backend.get_solver (build/cythonized/sage/numerical/backends/generic_backend.c:20378)

        from sage.numerical.backends.coin_backend import CoinBackend

    ImportError: /usr/lib/liblapack.so.3: undefined symbol: sgetrs_N_parallel

I created https://trac.sagemath.org/ticket/24188#ticket for this.

On Wednesday, 8 November 2017 22:30:44 UTC+1, Volker Braun wrote:

[Maarten Derickx]

I created https://trac.sagemath.org/ticket/24190 for the issue.

[Justin C. Walker]

> On Nov 8, 2017, at 13:30 , 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 a fresh clone of the developer branch, on macOS 10.11.6 (Quad-core Core i7), w/o problems.

Testing (‘ptestlong’) showed the same failure as others on macOS have seen:

sage -t --long --warn-long 76.1 src/sage/matrix/matrix_mod2_dense.pyx

Killed due to kill signal

I am using an out-of-rev Xcode 3.2.6, with this for gcc:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.6.0
Thread model: posix

The build of Sage installed gcc 7.2.0.

The error indicates that SIGKILL was sent to the process, but Trac #23742 (mentioned by François) seems to implicate a Seg Fault (SIGSEGV).

Anyone know what agent would KILL the process? The kernel can do this under resource starvation, but I am sufficiently out of touch with this stuff to know where to look (and I see no indication that the kernel did this in the system logs).

Justin

--
Justin C. Walker
Curmudgeon-at-large
Director
Institute for the Absorption of Federal Funds
----
186,000 Miles per Second
Not just a good idea:
it's the law!
----

[Henri Girard]

I am a bit in future : Bionic beaver 18.04 with AMD 64 16 RAM,
everything ok.
I have a problem with my computer, at the end of compiling my computer
halt in a bad way !  (this was already from sage-8.0 and with other
flavor of ubuntu, 17.04,17.10) maybe my RAM or my SSD ?

[Eric Gourgoulhon]

Le vendredi 10 novembre 2017 14:42:44 UTC+1, Eric Gourgoulhon a écrit :

On the same computer as above (Ubuntu 16/04),
./sage -n

fails with the following error message:

[C 14:35:42.400 NotebookApp] Bad config encountered during initialization:
[C 14:35:42.400 NotebookApp] The 'nbserver_extensions' trait of a NotebookApp instance must be a dict, but a value of type 'list' (i.e. ['sagenb_export.nbextension']) was specified.

Confirmed on another computer (still running Ubuntu 16.04 though). So I opened the ticket

https://trac.sagemath.org/ticket/24198

and set it to "blocker".

Eric.

[Kwankyu Lee]

Hi, 

Does this release support Xcode 9.1 on mac?

I built this release with Xcode 9.1, and the Sage built shows strange behaviors. Is this because of Xcode 9.1?

[François Bissey]

Define strange behaviours?

[Kwankyu Lee]

I get the following just after "make",

Hera:sage$ sage -t src/sage/rings/function_field/*

Running doctests with ID 2017-11-16-15-36-55-9cd5f354.

Git branch: develop

Using --optional=mpir,python2,sage

Doctesting 8 files.

Traceback (most recent call last):

  File "/Users/Kwankyu/GitHub/sage/src/bin/sage-runtests", line 125, in <module>

    err = DC.run()

  File "/Users/Kwankyu/GitHub/sage/local/lib/python2.7/site-packages/sage/doctest/control.py", line 1144, in run

    self.run_doctests()

  File "/Users/Kwankyu/GitHub/sage/local/lib/python2.7/site-packages/sage/doctest/control.py", line 867, in run_doctests

    self.dispatcher = DocTestDispatcher(self)

  File "/Users/Kwankyu/GitHub/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 1403, in __init__

    init_sage()

  File "/Users/Kwankyu/GitHub/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 134, in init_sage

    from sympy.printing.pretty.stringpict import stringPict

ImportError: No module named sympy.printing.pretty.stringpict

Hera:sage$

[Kwankyu Lee]

So I ran

sage -i sympy

and Sage installed sympy. Then now this works fine.

$ sage -t src/sage/rings/function_field/*

[Kwankyu Lee]

Then I created a new directory at SAGE_ROOT/src/ext/directory and put a file "test.txt" 

$ ls -l src/ext/

total 0

drwxr-xr-x  3 Kwankyu  staff  102 Nov 16 15:42 directory

drwxr-xr-x  4 Kwankyu  staff  136 Apr 15  2015 doctest

drwxr-xr-x  5 Kwankyu  staff  170 Apr 14  2016 gap

drwxr-xr-x  3 Kwankyu  staff  102 Mar  4  2016 graphs

drwxr-xr-x  7 Kwankyu  staff  238 Jun 11  2015 images

drwxr-xr-x  7 Kwankyu  staff  238 Jul 26 23:26 kenzo

drwxr-xr-x  5 Kwankyu  staff  170 Jun 11  2015 magma

drwxr-xr-x  3 Kwankyu  staff  102 Jun 11  2015 mwrank

drwxr-xr-x  4 Kwankyu  staff  136 Jun 11  2015 notebook-ipython

drwxr-xr-x  5 Kwankyu  staff  170 Apr 15  2015 pari

drwxr-xr-x  3 Kwankyu  staff  102 Jun 11  2015 pickle_jar

drwxr-xr-x  3 Kwankyu  staff  102 Jul 26 23:26 threejs

drwxr-xr-x  5 Kwankyu  staff  170 Apr 13  2016 valgrind

$

and then I ran

$ sage -br 

and I expected the new directory "directory" is created at "local/share/sage/ext/", but I get:

$ ls -l local/share/sage/ext/

total 0

drwxr-xr-x  4 Kwankyu  staff  136 Nov 15 19:19 doctest

drwxr-xr-x  5 Kwankyu  staff  170 Nov 15 19:19 gap

drwxr-xr-x  3 Kwankyu  staff  102 Nov 15 19:19 graphs

drwxr-xr-x  7 Kwankyu  staff  238 Nov 15 19:19 images

drwxr-xr-x  7 Kwankyu  staff  238 Nov 15 19:19 kenzo

drwxr-xr-x  5 Kwankyu  staff  170 Nov 15 19:19 magma

drwxr-xr-x  3 Kwankyu  staff  102 Nov 15 19:19 mwrank

drwxr-xr-x  4 Kwankyu  staff  136 Nov 15 19:19 notebook-ipython

drwxr-xr-x  5 Kwankyu  staff  170 Nov 15 19:19 pari

drwxr-xr-x  3 Kwankyu  staff  102 Nov 15 19:19 pickle_jar

drwxr-xr-x  3 Kwankyu  staff  102 Nov 15 19:19 threejs

drwxr-xr-x  7 Kwankyu  staff  238 Nov 15 19:19 valgrind

$

According to the developer guide,

Non-Python Sage source code and supporting files should be placed in appropriate subdirectories of SAGE_ROOT/src/ext/. They will then be automatically copied to the corresponding subdirectories of SAGE_ROOT/local/share/sage/ext/ during the build process and can be accessed at runtime using SAGE_EXTCODE. 

[Jeroen Demeyer]

On 2017-11-16 07:38, Kwankyu Lee wrote:
> I get the following just after "make",

Sorry to ask a silly question, but are you sure that

(1) You actually ran "make"
(2) That run of "make" succeeded without errors

It seems that sympy simply wasn't built. I am not aware of any bug in
the build system (especially not specific to OS X) which could cause that.

[Kwankyu Lee]

Sorry to ask a silly question, but are you sure that

(1) You actually ran "make"

Yes. But this was not a fresh one. I ran "make distclean", and then "make".

 

(2) That run of "make" succeeded without errors

There was an error in building doc. I ignored this as there was no problem in running Sage.

 

It seems that sympy simply wasn't built. I am not aware of any bug in
the build system (especially not specific to OS X) which could cause that.

Ok. Then I will try a fresh build from source, and report the result. Thank you for your attention.

[Kwankyu Lee]

On Thursday, November 16, 2017 at 8:38:52 PM UTC+9, Jeroen Demeyer wrote:

It seems that sympy simply wasn't built. I am not aware of any bug in
the build system (especially not specific to OS X) which could cause that.

The fresh build (of actually Sage 8.1rc1) finished with no problem. Also the strange behaviour reported above does not appear with the fresh Sage.

Perhaps my previous Sage installation was somehow corrupted. I don't know why...

Sorry for the noise. Thank you! 

[Dima Pasechnik]

It might be that a dependency is missing somewhere. While building rc1, I had to start make for the 2nd time for no apparent reason.

[Jeroen Demeyer]

On 2017-11-17 02:05, Kwankyu Lee wrote:
> There was an error in building doc.

There you have it! The build didn't succeed.

[Thierry]

Hi,

On Thu, Nov 16, 2017 at 05:05:11PM -0800, Kwankyu Lee wrote:
[...]

> There was an error in building doc. I ignored this as there was no problem
> in running Sage.
>

How much available RAM do you have ? Builging the documentation is no
longer the last step, hence if that fails, everything after that is not
built. If you do not have enough RAM to build the doc, you can compile the
rest of Sage with:

make build

Ciao,
Thierry

[Kwankyu Lee]

On Friday, November 17, 2017 at 6:53:41 PM UTC+9, Thierry wrote:

How much available RAM do you have ? Building the documentation is no

longer the last step, hence if that fails, everything after that is not
built.

Ah, I didn't know that. This (building the documentation is no longer the last step) sounds a big change to me. I wonder when that change was made.

 

If you do not have enough RAM to build the doc, you can compile the
rest of Sage with:

        make build 

It is Mac Pro with 32GB RAM. I never suspected that  the Sage build on the machine could fail because of not enough RAM. 

Ok. Thank you guys for enlightening me :-)

Kwankyu

 

[Kwankyu Lee]

I noticed this:

$ sage -t src/sage/rings/finite_rings/*

Running doctests with ID 2017-11-17-23-04-49-f065787a.

Git branch: finite_field_extension_trac24195_dev

Using --optional=mpir,python2,sage

Traceback (most recent call last):

  File "/Users/Kwankyu/GitHub/sage/src/bin/sage-runtests", line 125, in <module>

    err = DC.run()

  File "/Users/Kwankyu/GitHub/sage/local/lib/python2.7/site-packages/sage/doctest/control.py", line 1141, in run

    self.expand_files_into_sources()

  File "/Users/Kwankyu/GitHub/sage/local/lib/python2.7/site-packages/sage/doctest/control.py", line 751, in expand_files_into_sources

    self.sources = [FileDocTestSource(path, self.options) for path in expand()]

  File "/Users/Kwankyu/GitHub/sage/local/lib/python2.7/site-packages/sage/doctest/sources.py", line 525, in __init__

    raise ValueError("unknown file extension %r"%ext)

ValueError: unknown file extension '.h'

$

The problematic file is

$ ls -l src/sage/rings/finite_rings/*.h

-rw-r--r--  1 Kwankyu  staff  311 Nov 17 10:13 src/sage/rings/finite_rings/integer_mod_limits.h

$ 

Is this normal situation? This betrays my belief that a command like

$ sage -t src/sage/rings/finite_rings/*

always works fine.

[Eric Gourgoulhon]

Hi,

Le vendredi 17 novembre 2017 15:15:13 UTC+1, Kwankyu Lee a écrit :

Is this normal situation? This betrays my belief that a command like

$ sage -t src/sage/rings/finite_rings/*

always works fine.

You should use instead

sage -t src/sage/rings/finite_rings/

(skip the *)

Best wishes,

Eric.

[Thierry]

On Fri, Nov 17, 2017 at 05:51:18AM -0800, Kwankyu Lee wrote:
[...]

> It is Mac Pro with 32GB RAM. I never suspected that the Sage build on the
> machine could fail because of not enough RAM.

This is more than enough (unless you run a very greedy program
simultaneously). I personally have problems on my laptop with 5G of RAM,
as well a on my 32bit patchbot running in a VM.

Ciao,
Thierry

[Simon King]

On 2017-11-17, Kwankyu Lee <ekwa...@gmail.com> wrote:
> Ah, I didn't know that. This (building the documentation is no longer the
> last step) sounds a big change to me. I wonder when that change was made.

And WHY that change was made!

Is it still possible to build SageMath without documentation ("make start")?

Cheers,
Simon

[Thierry]

On Fri, Nov 17, 2017 at 02:37:37PM +0000, Simon King wrote:

> Is it still possible to build SageMath without documentation ("make start")?

make build

Ciao,
Thierry

[Simon King]

Thanks!

[John H Palmieri]

On Friday, November 17, 2017 at 6:37:54 AM UTC-8, Simon King wrote:

On 2017-11-17, Kwankyu Lee <ekwa...@gmail.com> wrote:
> Ah, I didn't know that. This (building the documentation is no longer the
> last step) sounds a big change to me. I wonder when that change was made.

And WHY that change was made!

If it takes a while to build the documentation, better to start as soon as possible, rather than to wait until the last possible time, right?

[Jeroen Demeyer]

On 2017-11-17 14:51, Kwankyu Lee wrote:
> This (building the documentation is no longer
> the last step) sounds a big change to me. I wonder when that change was
> made.

In Sage 6.8, see https://trac.sagemath.org/ticket/18710

[Simon King]

Hi John,

On 2017-11-17, John H Palmieri <jhpalm...@gmail.com> wrote:
>> And WHY that change was made!
>>
>
> If it takes a while to build the documentation, better to start as soon as
> possible, rather than to wait until the last possible time, right?

If the user's purpose is to use Sage, better make it usable as soon as
possible.

Moreover: Have the for-years-frequently-occurring "sporadic" doc build
failures been fixed at last? Otherwise: Better build as soon as possible
what does reliably build (i.e., sage/src), rather than frustrating the user.

Best regards,
Simon

[John H Palmieri]

For the first paragraph, we have to deal with the definition of "usable". The philosophy for some time has been that Sage without documentation is not fully usable. (Plus having the documentation build in parallel with some Sage packages may not slow down the build of Sage-minus-the-documentation that much. I don't really know.)

For the second paragraph, there has been some progress made, yes. Also, there is the question of to what extent the default build process should be tailored toward developers, who are more likely to run into problems with the documentation (because the problems have occurred in the past when changing branches, for example), vs. toward users who are not developers. My opinion is that developers should come low on the priority list; we can always use "make build" to skip the documentation build, if we want, or use "make doc-html-no-plot" to skip the plots (which can take a while), etc. For users who are not developers, having the Sage build process end (fully, including the documentation) more quickly is better.

  John

[Simon King]

Hi John,

On 2017-11-17, John H Palmieri <jhpalm...@gmail.com> wrote:
> For the first paragraph, we have to deal with the definition of "usable".
> The philosophy for some time has been that Sage without documentation is
> not fully usable.

OK, you got a point here.

> For the second paragraph, there has been some progress made, yes. Also,
> there is the question of to what extent the default build process should be
> tailored toward developers, who are more likely to run into problems with
> the documentation (because the problems have occurred in the past when
> changing branches, for example), vs. toward users who are not developers.

Is that so? I wasn't aware and thought that the build errors can also happen
when building the docs for the first time.

Now I understand the rationale behind the change of build order.

Best regards,
Simon