Built 8.3.beta1 from scratch (after make distclean at least after
previously reported pip version issues). Two failing files both
complaining that lrslib is not found:
sage -t --long src/sage/game_theory/normal_form_game.py # 2 doctests failed
sage -t --long
On Ubuntu 16.04 x86_64 Xeon E5-2623 + 16 GB RAM, from a fresh git clone +
pull develop, parallel (-j16) build OK and make ptestlong failed with 4
transient doctests. 3 of them are due to "Jmol failed to create file", as
usual on this computer (race error?), but the 4th one is a different type:
On Tuesday, May 15, 2018 at 9:24:26 PM UTC+2, Sébastien Labbé wrote:
>
> On Ubuntu 16.04, the command `./sage -t -p --all --long
> --optional=sage,optional,external` finishes with:
>
> --
> sage -t --long
On 16 May 2018 at 22:15, Jeroen Demeyer wrote:
> On 2018-05-16 17:26, Erik Bray wrote:
>
>> I'm not sure, but I think this might be pip-related. I think Jeroen
>> mentioned something about this to me a couple weeks ago. Is it
>> possible you upgraded the pip in your Sage
On 15/05/2018 21:24, Sébastien Labbé wrote:
On Ubuntu 16.04, the command `./sage -t -p --all --long
--optional=sage,optional,external` finishes with:
sage -t --long src/sage/coding/code_constructions.py
**
File
On 2018-05-16 17:26, Erik Bray wrote:
I'm not sure, but I think this might be pip-related. I think Jeroen
mentioned something about this to me a couple weeks ago. Is it
possible you upgraded the pip in your Sage install?
Indeed, I guess you are using pip 10 by accident.
It might be a good
pip should be able to uninstall itself so
sage -pip uninstall pip
sage -i pip
should give you the standard sage version of pip back. I did not test this,
so use at your own risk.
On Wednesday, 16 May 2018 17:33:50 UTC+2, John Cremona wrote:
>
>
>
> On Wed, 16 May 2018, 16:26 Erik Bray,
On Wed, May 16, 2018 at 9:56 AM, John Cremona wrote:
> I started to build this yesterday after pulling from trac into a place where
> beta0 had already built OK. This morning I find the lines
>
> [scipy-0.19.1] Skipping scipy as it is not installed.
> [scipy-0.19.1]
I started to build this yesterday after pulling from trac into a place
where beta0 had already built OK. This morning I find the lines
[scipy-0.19.1] Skipping scipy as it is not installed.
[scipy-0.19.1] Skipping scipy as it is not installed.
[scipy-0.19.1] Skipping scipy as it is not installed.
Bionic 18.04 AMD x8 64 bits, compile perfect. I started from fresh git
sage because upgrading from 8.2 failed. It couldn't find many libs. By
the way I found my crash problem while compiling : I had to config the
bios allowing warmer processing.
Le 15/05/2018 à 21:24, Sébastien Labbé a écrit
Under macOS 10.10.5, after downloading the cysignals patch
https://github.com/sagemath/cysignals
/commit/daef81e2fc111378ccc58b3f572eb18c70753a30.patch
into
build/pkgs/cysignals/patches
both the build+docbuild of Python2-based Sage
and the build+nodocbuild of Python3-based Sage
were
On Ubuntu 16.04, the command `./sage -t -p --all --long
--optional=sage,optional,external` finishes with:
--
sage -t --long src/sage/coding/code_constructions.py # 1 doctest failed
this is already fixed in https://trac.sagemath.org/ticket/25323
please review :-)
On Tuesday, May 15, 2018 at 4:44:03 PM UTC+1, John H Palmieri wrote:
>
> For me on OS X, I get the same failures as in earlier versions (which may
> be related somehow to my system). But if I then do "sage -i
On Tuesday, May 15, 2018 at 4:44:03 PM UTC+1, John H Palmieri wrote:
>
> For me on OS X, I get the same failures as in earlier versions (which may
> be related somehow to my system). But if I then do "sage -i database_gap"
> and run tests again, I get failures in permgroup.py and
For me on OS X, I get the same failures as in earlier versions (which may
be related somehow to my system). But if I then do "sage -i database_gap"
and run tests again, I get failures in permgroup.py and features/gap.py.
For example:
sage -t --long src/sage/features/gap.py
Thanks for the release.
On Ubuntu 14.04 I get LOTS of test timeouts that I didn't get
previously. It's possible though that the system is just uder heavy
load, but even re-running the tests with --failed keeps giving me
timeouts for some modules. So I'm concerned about a real performance
FWIW : on Debian testing running on Core i7 + 16 GB RAM, same results as
for 8.3.beta0, i. e. one transient and two permanent errors (the same as
before) :
--
sage -t --long src/sage/rings/padics/padic_lattice_element.py #
17 matches
Mail list logo