This project is mirrored from https://gitlab.com/sagemath/sage.git.
Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
 15 Jan, 2019 1 commit


Volker Braun authored

 12 Jan, 2019 1 commit


Volker Braun authored

 10 Jan, 2019 3 commits


Release Manager authored
A recent fix in Singular makes computing a certain invariant of modular cohomology rings of finite groups faster, but another recent fix in Singular makes the p_group_cohomology package fail. The new version p_group_cohomology3.0.1 is supposed to cope with the changes in Singular. I suggest to base it on top of #24735 and make it a dependency for #25993 (which contains the above mentioned changes in Singular). While I was at it, I also improved more features of the package. Hence, I propose to upgrade to p_group_cohomology3.1. [https://users.fmi.unijena.de/cohomology/p_group_cohomology3.1.tar.xz Upstream tarball v3.1] URL: https://trac.sagemath.org/26001 Reported by: SimonKing Ticket author(s): Simon King Reviewer(s): Travis Scrimshaw, Dima Pasechnik

Release Manager authored
Note that self tests require `nose` which is optional only. Also, the random seeds are not passed as integers, but as `random.Random` instances, see https://networkx.github.io/documentation/ stable/release/release_2.2.html#improvements Zipball: https://files.pythonhosted.org/packages/f3/f4/7e20ef40b11847819 1cec0b58c3192f822cace858c19505c7670961b76b2/networkx2.2.zip URL: https://trac.sagemath.org/26326 Reported by: tmonteil Ticket author(s): Thierry Monteil, Dima Pasechnik Reviewer(s): Volker Braun, Dima Pasechnik

Dima Pasechnik authored

 06 Jan, 2019 2 commits


Thierry Monteil authored

Thierry Monteil authored
#26326 : reorder creation of random graphs to avoid creating an empty one by bad luck on 32bit systems.

 05 Jan, 2019 1 commit


Thierry Monteil authored

 03 Jan, 2019 1 commit


Volker Braun authored

 02 Jan, 2019 8 commits


Release Manager authored
Starting from somewhere around 8.5.beta the canonical labels given by Sage and bliss are different on some instances {{{ sage: G1 = Graph("Cr") sage: G2 = Graph("C]") sage: G1 == G2 False sage: G1.is_isomorphic(G2) and G2.is_isomorphic(G1) True sage: G1.canonical_label(algorithm='bliss') == G1 True sage: G1.canonical_label(algorithm='sage') == G2 True }}} That is `Cr` is canonical for bliss while `C]` is canonical for Sage... More examples:  4 vertices: {{{C`}}} vs {{{CK}}}, {{{CR}}} vs {{{CL}}} and {{{Cr}}} vs {{{C]}}}  5 vertices: {{{DGC}}} vs {{{D@O}}}, {{{DAK}}} vs {{{D@S}}}, {{{DC[}}} vs {{{D@s}}}, {{{DIK}}} vs {{{DBW}}}, {{{DD[}}} vs {{{DBk}}}, {{{DDW}}} vs {{{DBg}}}, {{{D`{}}} vs {{{DK{}}}, {{{DqK}}} vs {{{DLo}}}, {{{DMk}}} vs {{{Dbk}}}, {{{DR{}}} vs {{{DL{}}}, {{{DR[}}} vs {{{DJk}}}, {{{Dr{}}} vs {{{D]{}}} As a consequence, when bliss is installed, we have the two following doctest failures in `databases/sql_db.py`. {{{ sage t long src/sage/databases/sql_db.py ********************************************************************** File "src/sage/databases/sql_db.py", line 956, in sage.databases.sql_db.SQLDatabase.__init__ Failed example: D.show('simon') Expected: graph6 vertices edges  ? 0 0 @ 1 0 A? 2 0 A_ 2 1 B? 3 0 BG 3 1 BW 3 2 Bw 3 3 C? 4 0 C@ 4 1 CB 4 2 CF 4 3 CJ 4 3 CK 4 2 CL 4 3 CN 4 4 C] 4 4 C^ 4 5 C~ 4 6 Got: graph6 vertices edges  ? 0 0 @ 1 0 A? 2 0 A_ 2 1 B? 3 0 BG 3 1 BW 3 2 Bw 3 3 C? 4 0 C@ 4 1 CB 4 2 CF 4 3 CJ 4 3 C` 4 2 CR 4 3 CN 4 4 Cr 4 4 C^ 4 5 C~ 4 6 ********************************************************************** File "src/sage/databases/sql_db.py", line 1004, in sage.databases.sql_db.SQLDatabase.__init__ Failed example: E.show('simon') Expected: graph6 vertices edges  ? 0 0 @ 1 0 A? 2 0 A_ 2 1 B? 3 0 BG 3 1 BW 3 2 Bw 3 3 C? 4 0 C@ 4 1 CB 4 2 CF 4 3 CJ 4 3 CK 4 2 CL 4 3 CN 4 4 C] 4 4 C^ 4 5 C~ 4 6 Got: graph6 vertices edges  ? 0 0 @ 1 0 A? 2 0 A_ 2 1 B? 3 0 BG 3 1 BW 3 2 Bw 3 3 C? 4 0 C@ 4 1 CB 4 2 CF 4 3 CJ 4 3 C` 4 2 CR 4 3 CN 4 4 Cr 4 4 C^ 4 5 C~ 4 6 ********************************************************************** 1 item had failures: 2 of 26 in sage.databases.sql_db.SQLDatabase.__init__ [288 tests, 2 failures, 1.59 s] }}} URL: https://trac.sagemath.org/26994 Reported by: vdelecroix Ticket author(s): David Coudert Reviewer(s): Volker Braun

Release Manager authored
On some patchbots, I see this: {{{ sage t long src/sage/interfaces/gap.py ********************************************************************** File "src/sage/interfaces/gap.py", line 1351, in sage.interfaces.gap.Gap.help Failed example: print(gap.help('SymmetricGroup', pager=False)) Expected: <BLANKLINE> 50.1... SymmetricGroup <BLANKLINE> ‣ SymmetricGroup( [filt, ]deg ) ─────────────────────────────────── function ... <BLANKLINE> Got: <BLANKLINE> <BLANKLINE> 50.110 SymmetricGroup <BLANKLINE> > SymmetricGroup( [filt, ]deg )  function [..many more lines..] }}} This seems to be a matter of unicode output or not. URL: https://trac.sagemath.org/26987 Reported by: jdemeyer Ticket author(s): Erik Bray Reviewer(s): Volker Braun

Release Manager authored
Trac #26676: Fix var() method for cryptominisat and picosat, which breaks solve_sat for boolean polynomial systems When I used Sage7.2, I could easily solve my boolean equations with solve_sat commands, and it's results were verified by the papers and other tools, but when I upgraded my sage to version 8 (or later version) I found that the new solve_sat solver (especially when we use CryptoMiniSat as the SAT solver) doesn't work as correct as before. For example, when I solve a system of equations via solve_sat which used CryptoMiniSat as a SAT solver, I get different number of solutions in different version of SageMath. I believe that there is something wrong in newer version of SageMath because my previous experiences shows that the older version's results were verified by the other tools and papers. I hope someone could solve this problem. See also the following thread on sagedevel: https://groups.google.com/forum/?fromgroups#!topic/sage devel/2EhgHzGgUnQ URL: https://trac.sagemath.org/26676 Reported by: ghhadipourh Ticket author(s): Thierry Monteil Reviewer(s): Frédéric Chapoton

David Coudert authored

E. Madison Bray authored

E. Madison Bray authored
otherwise the output may be inconsistent on nonUTF8 locales

E. Madison Bray authored

Release Manager authored
See https://groups.google.com/d/msg/sagerelease/MX SnQJh8EE/2vNChwf_CQAJ. ~~It looks like rpy2 picks up the systems R.~~ When a symbol has been overloaded, R's {{{help}}} doesn't pick the right symbol. URL: https://trac.sagemath.org/26791 Reported by: ghtimokau Ticket author(s): Timo Kaufmann Reviewer(s): Emmanuel Charpentier

 01 Jan, 2019 5 commits


Release Manager authored
As reported on [https://groups.google.com/d/msg/sage release/l635YEuT7Hs/WkHCnmWhAQAJ sagerelease 8.3.beta3], {{{ sage tp optional=sage,internet logfile=logs/25501.log src/sage/symbolic/integration/integral.py src/sage/symbolic/integration/external.py }}} gives {{{ ********************************************************************** File "src/sage/symbolic/integration/external.py", line 65, in sage.symbolic.integration.external.mma_free_integrator Failed example: mma_free_integrator(sin(x), x) # optional  internet Exception raised: Traceback (most recent call last): File "/home/slabbe/GitBox/sage/local/lib/python2.7/site packages/sage/doctest/forker.py", line 572, in _run self.compile_and_execute(example, compiler, test.globs) File "/home/slabbe/GitBox/sage/local/lib/python2.7/site packages/sage/doctest/forker.py", line 982, in compile_and_execute exec(compiled, globs) File "<doctest sage.symbolic.integration.external.mma_free_integrator[1]>", line 1, in <module> mma_free_integrator(sin(x), x) # optional  internet File "/home/slabbe/GitBox/sage/local/lib/python2.7/site packages/sage/symbolic/integration/external.py", line 97, in mma_free_integrator page = page[page.index('"inputForm"'):page.index('"outputForm"')] ValueError: substring not found ********************************************************************** ...  sage t src/sage/symbolic/integration/external.py # 3 doctests failed sage t src/sage/symbolic/integration/integral.py # 1 doctest failed  }}} It can be reproduced with: {{{ sage: from sage.symbolic.integration.external import mma_free_integrator sage: mma_free_integrator(sin(x), x) ... ValueError: substring not found }}} URL: https://trac.sagemath.org/25501 Reported by: slabbe Ticket author(s): Sébastien Labbé, Amaury Pouly Reviewer(s): Frédéric Chapoton

Release Manager authored
URL: https://trac.sagemath.org/24562 Reported by: embray Ticket author(s): Erik Bray Reviewer(s): Frédéric Chapoton

Simon King authored

Simon King authored
* develop: (73 commits) Updated SageMath version to 8.6.beta1 Fix tox testsuite for sage_bootstrap trac 26980 fix script for python3 trac 26978 remove module finite_class from doc a little firework of typos remove FiniteCombinatorialClass after #13552 remove some deprecated thing in combinat/partition remove deprecated things in combinat/integer_vector remove deprecated argument handling in symbolic integration remove deprecated interact decorator trac #26973: avoid .vertices() in graph_plot.py py3: fix doctests in Laurent polynomials py3: some minor fix fox traveling salesman trac 26953 : fallback for systems having only python3 command fix some fricas doctests for conversions of rings disable doctesting of these modules followup to #22626: adds a prerm script to the gap SPKG suppress "#I.." warnings Add the generic InfoWarning info class to the 'standard' GAP globals explicitly calling libgap.set_seed(0) for these tests allows consistent results for them ...

Volker Braun authored

 31 Dec, 2018 14 commits


Release Manager authored
{{{ Traceback (most recent call last): File "/var/lib/buildbot/slave/sage_git/build/build/bin/sagedownload file", line 28, in <module> run_safe() File "/var/lib/buildbot/slave/sage_git/build/build/bin/../sage_bootstr ap/download/cmdline.py", line 119, in run_safe except StandardError as error: NameError: name 'StandardError' is not defined }}} URL: https://trac.sagemath.org/26980 Reported by: vbraun Ticket author(s): Frédéric Chapoton Reviewer(s): Volker Braun

Release Manager authored
URL: https://trac.sagemath.org/26979 Reported by: chapoton Ticket author(s): Frédéric Chapoton Reviewer(s): Travis Scrimshaw

Release Manager authored
after #13552 URL: https://trac.sagemath.org/26978 Reported by: chapoton Ticket author(s): Frédéric Chapoton Reviewer(s): Travis Scrimshaw

Release Manager authored
after #13072 URL: https://trac.sagemath.org/26977 Reported by: chapoton Ticket author(s): Frédéric Chapoton Reviewer(s): Travis Scrimshaw

Release Manager authored
after #12453 URL: https://trac.sagemath.org/26976 Reported by: chapoton Ticket author(s): Frédéric Chapoton Reviewer(s): Travis Scrimshaw

Release Manager authored
after #12438 URL: https://trac.sagemath.org/26975 Reported by: chapoton Ticket author(s): Frédéric Chapoton Reviewer(s): Travis Scrimshaw

Release Manager authored
after #22636 URL: https://trac.sagemath.org/26974 Reported by: chapoton Ticket author(s): Frédéric Chapoton Reviewer(s): Travis Scrimshaw

Release Manager authored
URL: https://trac.sagemath.org/26973 Reported by: dcoudert Ticket author(s): David Coudert Reviewer(s): Frédéric Chapoton

Release Manager authored
URL: https://trac.sagemath.org/26972 Reported by: chapoton Ticket author(s): Frédéric Chapoton Reviewer(s): Travis Scrimshaw

Release Manager authored
by not sorting the connected components URL: https://trac.sagemath.org/26971 Reported by: chapoton Ticket author(s): Frédéric Chapoton Reviewer(s): David Coudert

Release Manager authored
`QQbar` and `AA` are very slow, to the point of often being unusable. There are many reasons to that (see #18333), including computations being triggered when they shouldn't, internal operations that construct elements of large degree, and incomplete of caching in some places. Yet the most visible issue by far is that, each time a new extension is constructed internally, we try to optimize its representation using PARI's `polredbest()`. This is bad, since `polredbest()` can easily take days for moderately large extensions, and only made worse by other issues that lead to lots of large extensions being created. The reasons I can see to call `polredbest()` are: * to limit the creation of isomorphic number fields (but with no guarantee that we'll avoid it completely), * to speed up subsequent computations in these number fields, * and perhaps also, in simple cases, to make the elements more readable. None of these is worth letting simple computations hang forever. This ticket restricts the optimization step using `polredbest()` to cases where (based on the size of the defining polynomial) it can be expected to finish in reasonable time. URL: https://trac.sagemath.org/15600 Reported by: mmezzarobba Ticket author(s): Marc Mezzarobba Reviewer(s): Vincent Delecroix

Sébastien Labbé authored

Volker Braun authored

Frédéric Chapoton authored

 30 Dec, 2018 4 commits


Frédéric Chapoton authored

Frédéric Chapoton authored

Frédéric Chapoton authored

Frédéric Chapoton authored
