Fix doctests #19

Open saraedum opened 6 years ago

It would be great to make sage -tp src pass. (And sage -tp --long src as well.)

A GitLab CI pipeline runs these doctests, the results of the latest run are:

227 failing individual doctests

No modules are failing entirely at the moment.

For reference, here are the corresponding numbers in Debian (for --long doctests.)

TODO:

[x] Package jmol - https://github.com/conda-forge/staged-recipes/pull/5996
[x] Package twisted - https://github.com/conda-forge/staged-recipes/pull/6003
[x] Add sphinx as a dependency to sage
[x] Add pillow as a dependency to sage
[x] Fix brial packaging - https://github.com/conda-forge/brial-feedstock/pull/9
[x] Install gcc in gitlab CI
[x] Patch glpk - https://github.com/conda-forge/glpk-feedstock/pull/29
[x] Make sage -tp --all work (instead of specifying the same directories explicitly.)
[x] the first pexpect call involving R hangs; this is causing the timeouts, please review https://trac.sagemath.org/ticket/25806 to fix this.
[x] dowgrade ecl, see https://github.com/conda-forge/sage-feedstock/pull/24
[x] apply https://trac.sagemath.org/ticket/26117 once it has been merged
[x] apply https://trac.sagemath.org/ticket/25344
[ ] apply https://trac.sagemath.org/ticket/26326 once it's ready
[x] apply https://trac.sagemath.org/ticket/25260
[x] apply https://trac.sagemath.org/ticket/26434 once it's ready
[x] apply https://trac.sagemath.org/ticket/26451 ~~once it's ready~~
[x] apply patches from recipe to source tree for testing
[ ] apply https://trac.sagemath.org/ticket/26454
[ ] apply https://trac.sagemath.org/ticket/26116 once it's ready
[ ] apply https://trac.sagemath.org/ticket/26457 once it's ready

We can see how we're doing once #20 has been merged.

I started to run doctests here: https://gitlab.com/saraedum/conda-sagelib-tests/pipelines

I want to wait for https://github.com/conda-forge/sage-feedstock/pull/15 before I continue with this.

Now that conda-forge/sage-feedstock#15 is merged, can you rerun?

Sure. Should be ready in two hours or so.

There was some HTTP error. I restarted the test.

Looks like it installed a previous version.

sage:                               8.1-py27_0                    conda-forge

So when I say conda create -n sagemath sage=8.1 then I get sage: 8.1-py27_0 conda-forge.

The problem is not that the dependencies of the _1 build are not satisfiable anymore: conda create -n sagemath sage=8.1 'alabaster>=0.7.8' 'arb>=2.11.1,<3' 'backports.shutil_get_terminal_size>=1.0.0,<2' 'backports_abc>=0.5' 'bdw-gc>=7.2f,<8' 'boost-cpp>=1.61.0,<2' 'brial>=1.0.1,<2' 'cddlib>=0.94g' 'certifi>=2016.2.28' 'cliquer>=1.21,<2' 'configparser>=3.5.0,<4' 'cvxopt>=1.1.8,<2' 'cycler>=0.10.0' 'cysignals>=1.6.5,<2' 'decorator>=4.0.6,<5' 'docutils>=0.13.1' 'ecl>=16.1.2,<17' 'eclib>=20171002' 'ecm>=7.0.4,<8' 'entrypoints>=0.2.2' 'fflas-ffpack>=2.2.2,<2.3.0' 'flintqs>=1.0,<2' 'fplll>=5.2.0,<6' 'fpylll>=0.3.0dev' 'freetype>=2.6.3,<3' 'functools32>=3.2.3,<4' 'future>=0.15.2' 'gap>=4.8.6,<5' 'gf2x>=1.2,<2' 'gfan>=0.5' 'giac>=1.2.3,<2' 'givaro=4.0.2' 'glpk>=4.63,<5' 'gmp>=6.1.2,<7' 'gsl>=2.3,<3' 'iml>=1.0.4,<2' 'ipykernel>=4.6.1,<5' 'ipython>=5.1.0,<6' 'ipython_genutils>=0.2.0' 'ipywidgets>=6.0.0,<7' 'jinja2>=2.8,<3' 'jsonschema>=2.5.1,<3' 'jupyter_client>=5.1.0,<6' 'jupyter_core>=4.3.0,<5' 'lcalc>=1.23,<2' 'libflint>=2.5.2,<3' 'libgap>=4.8.6,<5' 'libgd>=2.1.1.1,<3' 'libiconv>=1.14,<2' 'libpng>=1.6.29,<2' 'linbox>=1.4.2,<1.5' 'lrcalc>=1.2,<2' 'm4ri>=20140914' 'm4rie>=20150908' 'matplotlib>=1.5.1,<2' 'maxima>=5.39.0,<6' 'mistune>=0.7.3' 'mpc>=1.0.3,<2' 'mpfi>=1.5.1,<2' 'mpfr>=3.1.5,<4' 'mpmath>=0.19' 'nauty>=2.6r7,<3' 'nbconvert>=4.2.0,<5' 'nbformat>=4.4.0,<5' 'ncurses>=5.9,<7' 'networkx>=1.11,<2' 'notebook>=4.4.1,<5' 'ntl>=10.3.0,<11' 'numpy>=1.13.3,<2' 'openblas>=0.2.20' 'palp>=2.1,<3' 'pari>=2.9,<3' 'path.py>=7.1,<8' 'pathlib2>=2.1.0,<3' 'pexpect>=4.1.0,<5' 'pickleshare>=0.7.2' 'planarity>=3.0.0.5,<4' 'ppl>=1.2,<2' 'prompt_toolkit>=1.0.9,<2' 'psutil>=5.2.0,<6' 'ptyprocess>=0.5.1' 'pycrypto>=2.6.1,<3' 'pygments>=2.2.0,<3' 'pynac>=0.7.12' 'pyparsing>=2.1.5,<3' 'python=2.7*' 'python-dateutil>=2.5.3,<3' 'pytz>=2016.4' 'pyzmq>=16.0.0,<17' 'ratpoints>=2.1.3,<3' 'readline=6.2*' 'rpy2>=2.8.2,<3' 'rubiks>=20070912' 'rw>=0.7' 'sagelib=8.1' 'sagemath-db-combinatorial-designs>=20140630' 'sagemath-db-conway-polynomials>=0.5.*' 'sagemath-db-elliptic-curves>=0.8' 'sagemath-db-graphs>=20161026' 'sagemath-db-polytopes>=20170220' 'scipy>=0.19.1' 'simplegeneric>=0.8.1' 'singledispatch>=3.4.0.3,<4' 'singular>=4.1.0p3,<5' 'six>=1.11.0,<2' 'sqlite>=3.17,<4' 'ssl_match_hostname>=3.5.0.1,<4' 'symmetrica>=2.0,<3' 'sympow>=1.018.1,<2' 'sympy>=1.1.1,<2' 'terminado>=0.6' 'tornado>=4.3,<5' 'traitlets>=4.3.1,<5' 'wcwidth>=0.1.7' 'widgetsnbextension>=2.0.0,<3' 'zeromq>=4.0.5,<5' 'zlib>=1.2.11,<2' 'zn_poly>=0.9' actually works and installs _1.

I guess this is just a "bug" in conda. It doesn't give the latest build of what I actually asked for high enough priority over some other choices it can make it seems.

Is there anything we can do other than removing the _0 build?

I'll move the _0 build to a different label

Done. Can you restart?

Ok. Let's see what it says in a couple of hours.

Added a TODO

I have not tried to find out yet what's the issue…

UnsatisfiableError: The following specifications were found to be in conflict:
  - gcc
  - sage 8.2*

Probably mpfr.

True. gcc does not come from conda-forge. Any workaround?

Use the system package manager?

Haha, sorry, for asking such dumb questions ;)

One killed and one timeout less. And a few thousand fewer doctests failing.

Did you have jmol installed? Does jmol work in a headless image?

Newest build https://gitlab.com/isuruf/conda-sagelib-tests/-/jobs/75426947

@isuruf: I just gave you access to my gitlab repo so we can work on the same fork.

I just pushed to your repo. Here's the latest build. https://isuruf.gitlab.io/-/conda-sagelib-tests/-/jobs/76387946/artifacts/sagemath/doctest.txt

There are some issues with cddlib

The output of cddlib has changed in a recent version. I just released 0.94j which together with https://trac.sagemath.org/ticket/25344 should fix these.

Or let's just pin it to the right version rather ;) see https://github.com/conda-forge/sage-feedstock/pull/19.

We can not pin to 0.94g because it's not in conda-forge. So should we patch Sage's parser or backport the uppgrade to 0.94j?

Debian's debian/patches/u1-version-cddlib-094h.patch should do the trick. I'll create a PR.

That worked. Down to 123 failures

Unfortunately, we know hit the 3h limit on gitlab.

Let's use some private runners then…

For some reason R hangs at the first invocation from Sage, i.e., the expect interface hangs. I run the following from both an upstream Sage and conda's Sage:

sage: %r

  --> Switching to R Interpreter <--

r: 1+1

Internally, conda's R produces:

> 1+519502659;
[1] 519502660
<R__PROMPT__> ", width=100,pager="cat",device="png")
__SAGE__R__PROMPT__> __SAGE__R__PROMPT__> 
__SAGE__R__PROMPT__>

whereas Sage's R produces:

> 1+695904367;
[1] 695904368
<SAGE__R__PROMPT__> ", width=100,pager="cat",device="png")                   
__SAGE__R__PROMPT__> 1+378998609;
[1] 378998610
__SAGE__R__PROMPT__> options(repos="http://cran.r-project.org/")
__SAGE__R__PROMPT__> 1+152632009;
[1] 152632010
__SAGE__R__PROMPT__> options(CRAN="http://cran.r-project.org/")
__SAGE__R__PROMPT__> 1+586856521;
[1] 586856522
__SAGE__R__PROMPT__> options(error = expression(NULL))
__SAGE__R__PROMPT__> 1+1334779490;
[1] 1334779491
__SAGE__R__PROMPT__> set.seed(428099105)
__SAGE__R__PROMPT__> 1+1
[1] 2
__SAGE__R__PROMPT__>

Any ideas what could be the issue?

what does conda list | grep r-base give you?

❯ conda list |grep r-base
r-base                    3.4.1                         4    conda-forge

It appears that pexpect is making the difference. Sage uses 4.1.0, conda has 4.6.0. Strangely everything appears to work if I shorten sage's R prompt from __SAGE_R_PROMPT> to __SAGE__>.

There is an upstream ticket about the 4.6.0 upgrade: https://trac.sagemath.org/ticket/25700

Have you ever adopted this patch originally from debian? https://github.com/cschwan/sage-on-gentoo/blob/master/sci-mathematics/sage/files/dt-r-no-readline.patch

Interesting. Thanks, I was not aware of that one.

It helped me with readline 7.0 but I am wondering if it would help here as well. Haven't looked at pexpect 4.6.0 in gentoo yet. Mostly because it isn't in the main tree.

And it actually makes things work. See https://trac.sagemath.org/ticket/25806 for upstreaming this.

@isuruf why did you install numpy 1.13 in 0b2f6d3b05d7bfb767a2e385a2d916ab5f5bcac9? This seems to cause errors, see CI

ImportError: numpy.core.multiarray failed to import

Locally with 1.14 these imports work fine.

This is now https://github.com/conda-forge/sage-feedstock/pull/23.

I installed 1.13 because the printing of arrays changed and there were doctests failing. I guess the new sage versions fixed the doctests

I see. Do you mean these?

Expected:
    array([[[ 1.,  1.,  1.],
            [ 1.,  1.,  1.],
            [ 1.,  1.,  1.]],
    <BLANKLINE>
           [[ 1.,  1.,  1.],
            [ 0.,  0.,  0.],
            [ 1.,  1.,  1.]],
    <BLANKLINE>
           [[ 1.,  1.,  1.],
            [ 1.,  1.,  1.],
            [ 1.,  1.,  1.]]])
Got:
    array([[[1., 1., 1.],
            [1., 1., 1.],
            [1., 1., 1.]],
    <BLANKLINE>
           [[1., 1., 1.],
            [0., 0., 0.],
            [1., 1., 1.]],
    <BLANKLINE>
           [[1., 1., 1.],
            [1., 1., 1.],
            [1., 1., 1.]]])

If so, let me try to make the tests less strict upstream.

~~Seems like a NORMALIZE_WHITESPACE would fix these.~~ No, actually not.

Yes, doctests like that failed

Nice, numpy has a legacy printing mode to print like 1.13 :)

@isuruf: Any idea where these floating point errors that crash Sage could come from?

Also needs https://github.com/sagemath/sagenb/pull/450 and https://trac.sagemath.org/ticket/26117

@isuruf: We are now having trouble with maxima not being run with the same ecl that it was built with: RuntimeError: ECL says: Module error: Don't know how to REQUIRE MAXIMA. Apparently we need to pin exactly when building something with ecl.

That error occurs when ecl can't find maxima.fas. You could try explicitly setting the MAXIMA_FAS environment variable to the correct location. Maybe that'll work without rebuilding ecl.

With https://github.com/conda-forge/maxima-feedstock/pull/10 we are now down to 8 modules timing out and 340 failing tests.

conda-forge / sagelib-feedstock

Fix doctests #19