[sage-devel] Re: SingularError in rational_parameterization

Works fine with system singular 4.3.2.p16 too, so this may be a bug in that particular Singular version. El jueves, 18 de abril de 2024 a las 6:02:53 UTC+2, Kwankyu Lee escribió: > No problem with Singular 4.3.2 included in sage (on mac). -- You received this message because you are

[sage-devel] Re: Something is up with normaliz

El jueves, 13 de julio de 2023 a las 8:21:34 UTC+2, Max Kölbl escribió: Does anyone else have that problem? I installed updates this morning and now there seems to be an issue with normaliz. I can't really tell what's going on, but before today, normaliz worked just fine. Maybe other arch /

[sage-devel] %display latex in Sage command line

Hi all, In older versions of sage/ipython, one could use '%display latex' or '%display typeset' to force all output to be formatted in latex. This is used by some third party GUIs (such as Cantor [1]) to typeset the output in their UI. In recent versions of Sage (at least since 9.5), this

[sage-devel] Test failures in R interface

Hi, I've been seeing these failures for a while when running the doctests. It is not reproducible when testing the file standalone, only when testing the full sage library, which makes it really hard to debug. Has anybody seen this or has any idea how to fix it?

[sage-devel] Re: why is sagemath 9.8 rc1 still running old maxima build?

El martes, 7 de febrero de 2023 a las 9:35:53 UTC+1, Nasser M. Abbasi escribió: Any chance that 9.8 will use the latest version instead? No. Upgrading maxima needs work, https://github.com/sagemath/sage/issues/33718 -- You received this message because you are subscribed to the Google

[sage-devel] Re: sagelib fails to build (9.8.beta5)

That's the singular 4.3.1.p3 update. The patch [1] fixes the build, but there are some regressions in the asymptotics ring that need looked into. [1] https://github.com/archlinux/svntogit-community/blob/packages/sagemath/trunk/sagemath-singular-4.3.1.p3.patch El miércoles, 14 de diciembre de

Re: [sage-devel] VOTE: move Sage development to Github

+1 for GitHub El jueves, 22 de septiembre de 2022 a las 18:43:02 UTC+2, martinr...@googlemail.com escribió: > +1 for GitHub > > On Wed, Sep 21 2022, David Roe wrote: > > Dear Sage developers, > > Following extensive discussion, both recently > >

[sage-devel] Re: PARI/GP upgrade to 2.15

Specifically, help is needed from someone who understands genus2reduction code in order to solve the (almost) last remaining issue. El jueves, 15 de septiembre de 2022 a las 20:58:19 UTC+2, vdelecroix escribió: > Dear all, > > The PARI/GP team is about to release a new version. I opened a

[sage-devel] Re: System upgrades breaking sage frequently

El jueves, 21 de julio de 2022 a las 7:32:59 UTC+2, Nils Bruin escribió: > In that case, shouldn't sagemath be linking to libflint.so instead of > libflint.so.16 then? That's the thing that seems to be available between > the different versions. Are they not ABI compatible? (or at least in

[sage-devel] Re: Memory Leak in canonical_label with bliss?

El lunes, 16 de mayo de 2022 a las 17:34:14 UTC+2, Ricardo Buring escribió: > Specifically bliss::AbstractGraph::canonical_form calls > bliss::AbstractGraph::search, which sometimes calls > bliss::Partition::cr_init without calling bliss::Partition::cr_free, due > to a (conditional) early

[sage-devel] docbuild aborting on warnings

Sage doc build currently aborts by default whenever sphinx emits a warning, and keeps a hardcoded whitelist of "admissible" warnings that needs to be kept up to date. This is very inconvenient for distros building Sage with system Sphinx, as every new version introduces new warnings: a fix was

[sage-devel] Re: `sage -t --log=file.log` broken in 9.5.beta5

El lunes, 1 de noviembre de 2021 a las 17:36:18 UTC+1, Sébastien Labbé escribió: > Bonjour, > > I just noticed that providing a log file to the `sage -t` command is > currently broken with the most recent version: > > This is caused by https://trac.sagemath.org/ticket/32332. All arguments must

[sage-devel] Re: BUG: Si(pi).n() throws error in sage 9.2-2

This is not a Sage problem, it's a mpmath 1.2 issue, which broke Sage detection when using distro packages. You either need to revert commit [1] or set the MPMATH_SAGE env variable. [1] https://github.com/fredrik-johansson/mpmath/commit/84ca137f El domingo, 17 de octubre de 2021 a las 0:26:16

Re: [sage-devel] Trac emails

I had already checked, but after a closer look it might have something to do. I had disabled automatic notifications for the tickets I have commented on, assuming that setting it would simply stop automatically adding me to the notification list of those tickets. But apparently what it does is

[sage-devel] Trac emails

Hi all, I'm having an issue for a long time where many of the email notifications I should be receiving from trac are getting lost (many being over 50%). I thougt it might be a problem with my mail provider, but the same thing happens after changing to a different address. Is anybody else

[sage-devel] Pushing to trac with openssh 8.8

Hi all, I'm unable to push to git-trac since updating to openssh 8.8, getting a permission denied error. This version disables RSA/SHA1 signatures by default [1], is it possible that the server is using that to chack the keys? [1] https://www.openssh.com/txt/release-8.8 -- You received this

[sage-devel] Re: Proposal: Making cmake a standard package

El viernes, 16 de julio de 2021 a las 22:44:22 UTC+2, Matthias Koeppe escribió: > cmake is an advanced build system and currently an optional package, as it > is only used for building optional or experimental packages. > I propose to make cmake a standard package ( >

[sage-devel] Re: Loading all GAP packages

El viernes, 30 de abril de 2021 a las 9:05:41 UTC+2, Antonio Rojas escribió: > Hi, > On a fresh run of the GAP interface, Sage caches a GAP workspace which > loads every single GAP package on the system. While this might be OK with > Sage's trimmed-down version of gap_packag

Re: [sage-devel] Loading all GAP packages

El viernes, 30 de abril de 2021 a las 9:21:11 UTC+2, vdelecroix escribió: > > Does your remark applies to both the pexpect GAP interface and libgap? > > AFAIK this only affects the pexpect interface https://git.sagemath.org/sage.git/tree/src/sage/interfaces/gap.py#n1549 -- You received this

[sage-devel] Loading all GAP packages

Hi, On a fresh run of the GAP interface, Sage caches a GAP workspace which loads every single GAP package on the system. While this might be OK with Sage's trimmed-down version of gap_packages, if using a system GAP install with all optional packages installed this can take a massive amount of

[sage-devel] Re: Memory leak in integer multiplication in sage?

On Arch, using system libraries: 0 0 memory usage 10k: 10.69921875 0 memory usage 20k: 21.40234375 El jueves, 18 de marzo de 2021 a las 11:56:33 UTC+1, m.derick...@gmail.com escribió: > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To

[sage-devel] Re: Status of modularization and packaging in Sage 9.3.beta9

El lunes, 15 de marzo de 2021 a las 1:44:19 UTC+1, Matthias Koeppe escribió: > A quick overview of the status of the modularization effort of Meta-ticket > #29705 in Sage 9.3.beta9. > What are the plans for the top-level setup.py? I noticed that it no

Re: [sage-devel] distro packaging, docbuilding and modularisation

El miércoles, 10 de marzo de 2021 a las 21:13:15 UTC+1, François Bissey escribió: > I’d like to talk to you on another channel, I have to do a small > patch currently. It may reflect different packaging strategy or > something I could improve. > Here is my current PKGBUILD (after some

[sage-devel] Re: distro packaging, docbuilding and modularisation

El miércoles, 10 de marzo de 2021 a las 10:21:07 UTC+1, François Bissey escribió: > Instead of trying to fix the problem that you should be building the > documentation > before installing, the push to modularisation is currently used to > enshrine the > current situation. #30010 actually

[sage-devel] Re: Making the package jmol optional

El lunes, 7 de diciembre de 2020 a las 6:11:31 UTC+1, Matthias Koeppe escribió: > In https://trac.sagemath.org/ticket/30315 I propose to make jmol > optional. To my understanding it has been replaced by generally better > options such as threejs and jsmol. But it's possible that I'm missing >

Re: [sage-devel] Re: configure fails to find some packages (archlinux)

> There is also something funny with Flint 2.6 build using cmake - not > sure if it's the case on your system, but it seems > that in this case there is no way to specify whether you want GC > support or not. > I guess it ends up without GC support (or, perhaps, with GC support, > no

Re: [sage-devel] 9.1.beta0 build failure on Arch

That's osx, not Arch El martes, 14 de abril de 2020, 15:38:27 (UTC+2), Dima Pasechnik escribió: > > On Tue, Apr 14, 2020 at 9:28 PM Antonio Rojas > wrote: > > > > I'm missing some context here... flint does certainly link to ntl > already, i don't see how it could wo

Re: [sage-devel] 9.1.beta0 build failure on Arch

I'm missing some context here... flint does certainly link to ntl already, i don't see how it could work otherwise. El martes, 14 de abril de 2020, 15:23:08 (UTC+2), Dima Pasechnik escribió: > > Hi Antonio, > can Arch's Flint be fixed so that it links against NTL, like in Sage? > Then we

[sage-devel] Re: archlinux: some system package not recognized

El jueves, 19 de marzo de 2020, 14:52:46 (UTC+1), vdelecroix escribió: > > Dear all, > > Thanks to hard work it is now possible to use some package from > the system! That is great! But on my archlinux computer that also > has sage installed from the package manager the following > packages

[sage-devel] sagenb dependencies

sagenb was made optional, but its dependencies (such as flask-* packages) are still standard and installed by default as of 9.1.beta7. Shouldn't they be made optional too? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this

Re: [sage-devel] 9.1.beta0 build failure on Arch

El jueves, 23 de enero de 2020, 18:11:51 (UTC+1), Dima Pasechnik escribió: > > On Wed, Jan 22, 2020 at 5:20 PM Isuru Fernando > wrote: > > > > [root@50586643ff22 /]# pkg-config --modversion blas > > 0.3.7 > > [root@50586643ff22 /]# pkg-config --modversion cblas > > 3.9.0 > >

Re: [sage-devel] 9.1.beta0 build failure on Arch

rom fflas-ffpack flags ? > >> see https://trac.sagemath.org/ticket/27444#comment:34 > >> > >> On Sat, Jan 11, 2020 at 7:53 AM Antonio Rojas > wrote: > >> > > >> > Build fails at fflas-ffpack, log attached. Seems related to FS#27870 > >>

Re: [sage-devel] 9.1.beta0 build failure on Arch

t; see https://trac.sagemath.org/ticket/27444#comment:34 > > On Sat, Jan 11, 2020 at 7:53 AM Antonio Rojas > wrote: > > > > Build fails at fflas-ffpack, log attached. Seems related to FS#27870 > > > > -- > > You received this message because you are su

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

El viernes, 10 de enero de 2020, 14:54:24 (UTC+1), E. Madison Bray escribió: > > That seems like the obvious approach to me. As it is I've long felt > that Sage should be more flexible in its dependencies where > possible/necessary. With most Python packages it's easy as most have > a

[sage-devel] Re: drop python2 compatibility in 9.1 ?

El lunes, 6 de enero de 2020, 8:43:14 (UTC+1), Nils Bruin escribió: > > > You could say: there is such a way: just check out 9.0 and build that with > py2. Perhaps that's enough. However, I would err at the side of caution and > make a slightly bigger gesture here and still include 9.1 as well

Re: [sage-devel] Adopting orphaned math packages

El miércoles, 18 de diciembre de 2019, 11:19:54 (UTC+1), E. Madison Bray escribió: > > > Looking in the latest source tarball for SYMMETRICA there are > absolutely zero license or copyright notifications. And if the author > is deceased, does that mean it's public domain? I don't know. > >

Re: [sage-devel] Re: error building barvinok (sage 8.9.beta8 + system NTL)

El jueves, 5 de septiembre de 2019, 15:51:34 (UTC+2), Victor Shoup escribió: > > We seem to be talking past each other. > Unfortunately it seems so. It is also true that when I run ldd on libntl.so, I do not see anything > related to pthread. > From the comments I'm reading in

Re: [sage-devel] Re: error building barvinok (sage 8.9.beta8 + system NTL)

El jueves, 5 de septiembre de 2019, 6:07:13 (UTC+2), Victor Shoup escribió: > So, based on that comment, it seems that there is no problem if you link > with g++ > rather than libtool. But who or what uses libtool to link? > I would never have thought of doing that, as I thought libtool was

[sage-devel] Re: [sage-packaging] About python2 vs python3 package versions

El sábado, 13 de julio de 2019, 19:33:50 (UTC+2), Samuel Lelievre escribió: > > One thing we could do for a start, given that for now we build > both Python 2 and Python 3 in any case, would be to transition > the Jupyter part of Sage-the-distribution to be python3-based, > allowing us to

Re: [sage-devel] Re: error building barvinok (sage 8.9.beta8 + system NTL)

El jueves, 29 de agosto de 2019, 0:06:49 (UTC+2), Dima Pasechnik escribió: > > > > Relying on patched bundled copies of dependencies is very much frowned > upon by distros. It would be much preferable to make this work with > unmodified libtool, which may be provided by the distribution. > >

Re: [sage-devel] Re: error building barvinok (sage 8.9.beta8 + system NTL)

El miércoles, 28 de agosto de 2019, 23:47:43 (UTC+2), Dima Pasechnik escribió: > > Victor, > as you ship libtool, you can just patch it, essentially as in > https://lists.gnu.org/archive/html/libtool-patches/2013-11/msg00015.html > It needs to be moved to a slightly different place, but it

[sage-devel] Re: error building barvinok (sage 8.9.beta8 + system NTL)

El miércoles, 28 de agosto de 2019, 15:15:18 (UTC+2), Victor Shoup escribió: > > Thanks. I guess what I'm asking for is a solution. From what you say > here, and what is said in the links, the problem seems to be a bug in > libtool, not NTL. So a solution would be, either: > 1) a patch other

[sage-devel] Re: error building barvinok (sage 8.9.beta8 + system NTL)

El martes, 27 de agosto de 2019, 16:25:12 (UTC+2), Victor Shoup escribió: > > I reviewed some comments which mentioned a problem with ntl and threads. > I’m happy to fix that, but I don’t think I understand what the issue is. > Can anyone explain? Thanks. Hi Victor, IIRC I reported this to

[sage-devel] Re: maxima 5.43.0

El jueves, 1 de agosto de 2019, 2:00:02 (UTC+2), François Bissey escribió: > > Hi all, > > I am giving a shot at getting maxima-5.43.0 working for sage-on-gentoo > and it looks good overall but there are couple of things that needs > attention. >

[sage-devel] Re: [Debian-science-sagemath] name of arb library in Debian and adjustments needed

El lunes, 15 de julio de 2019, 14:49:54 (UTC+2), Dima Pasechnik escribió: > > > > A quick way would be to create src/sage/env.py.in, with a template for, > say, > `aliases["ARB_LIBRARIES"]` in `cython_aliases` > filled in by a call to AC_CONFIG_FILES. > > This would be setting a precedent

[sage-devel] About python2 vs python3 package versions

Hi all, Today I tested building Sage on Arch against our python3 packages. Not surprisingly, it failed to even start. This is due to our python3 ipython package being at version 7 already, with includes some API changes that require some porting in Sage. More and more python modules are

[sage-devel] Re: Gap pexpect error when most Gap packages are installed

I just noticed this yesterday after updating GAP to 4.10.2 in Arch. SymmetricGroup(n).conjugacy_classes_subgroups() works fine for n<=4, and fails for n>=5. Same as you, it works after removing all additional GAP packages. Additionally, after the update (and with all GAP packages installed)

[sage-devel] Re: Delaying 8.5 or fast-tracking 8.6?

El martes, 18 de diciembre de 2018, 12:50:44 (UTC+1), E. Madison Bray escribió: > > As pointed out by Samuel last month [1] the transition freeze (i.e. > new package versions) for the next major Debian release (buster) is > coming up January 12 [2]. This is important for Sage and those >

[sage-devel] Re: zn_poly status?

El viernes, 7 de septiembre de 2018, 15:53:43 (UTC+2), Erik Bray escribió: > > Hi all, > > Does anyone know what that current status is of the upstream zn_poly > package? According to its website > http://cims.nyu.edu/~harvey/zn_poly/ it is "no longer maintained", > though it has been

[sage-devel] Re: Arch: error building Sage, rpy2 fails

El viernes, 17 de agosto de 2018, 17:31:13 (UTC+2), Nicolás Sirolli escribió: > > Hello, > > I'm trying to build Sage 8.4.beta1 (following the develop branch from git) > on Arch Linux, and it fails when trying to build the rpy2-2.8.2.p0 package. > I'm attaching the corresponding log file. > >

Re: [sage-devel] Re: Sage fails to build on Arch linux, possible recurrence of an old bug

El martes, 10 de julio de 2018, 14:21:03 (UTC+2), Amit Wolecki escribió: > > I see, thanks Antonio for the fix! To make sure I get the big picture - > distro package will use system services (e.g. python and especially pip) > whereas the built from source installation has it's own compiled

[sage-devel] Re: Sage fails to build on Arch linux, possible recurrence of an old bug

El lunes, 9 de julio de 2018, 21:35:04 (UTC+2), Amit Wolecki escribió: > > Thank you all for the useful comments! > Antonio, I wasn't aware of the somewhat limiting way a repo installation > works, this remark made me try to stick to building from source. > >> >> Actually, scratch that. 'sage

Re: [sage-devel] Sage fails to build on Arch linux, possible recurrence of an old bug

El domingo, 8 de julio de 2018 10:39:34 (CEST), Amit Wolecki escribió: Replying to the repo package issues: As for the packaged installation problem, two examples are: 1. sage --testall fails to start, returning: File "/usr/lib/python2.7/site-packages/sage/doctest/control.py", line 696, in

[sage-devel] Re: Sage fails to build on Arch linux, possible recurrence of an old bug

Replying to the repo package issues: El domingo, 8 de julio de 2018, 11:10:01 (UTC+2), Amit Wolecki escribió: > > As for the packaged installation problem, two examples are: > 1. sage --testall fails to start, returning: > > File "/usr/lib/python2.7/site-packages/sage/doctest/control.py",

Re: [sage-devel] Re: executable referenced in sagemath jupyter kernel

:22 AM UTC-7, Antonio Rojas wrote: >> >> >> >>> OK, so how do we see whether the $SAGE_ROOT/sage script needs to be >>> used? Can we just see if $SAGE_ROOT/sage is present and executable and if >>> not, use $SAGE_LOCAL/bin/sage? The remark by François

Re: [sage-devel] Re: executable referenced in sagemath jupyter kernel

> > OK, so how do we see whether the $SAGE_ROOT/sage script needs to be used? > Can we just see if $SAGE_ROOT/sage is present and executable and if not, > use $SAGE_LOCAL/bin/sage? The remark by François seems quite to the point: > if sage is installed system-wide as a package of python2,

Re: [sage-devel] Re: executable referenced in sagemath jupyter kernel

El sábado, 19 de mayo de 2018, 8:30:12 (UTC+2), Nils Bruin escribió: > > so, am I right in concluding that distribution packages patch this anyway > and that we can therefore safely put $SAGE_ROOT/sage in kernel.json by > default? > No - this does "the right thing" out of the box currently.

[sage-devel] Re: executable referenced in sagemath jupyter kernel

El jueves, 17 de mayo de 2018, 6:46:11 (UTC+2), Nils Bruin escribió: > > > Are there good reasons to refer to .../local/bin/sage rather than the > .../sage script? If not, then it might be more flexible to change it. > > This would break distribution packages, where SAGE_LOCAL is generally set

[sage-devel] Re: networkx BipartiteGraph

El Thu, 14 Dec 2017 11:09:17 +, Vincent Delecroix escribió: > What about > > sage: A = networkx.complete_bipartite_graph(2r, 3r) That works correctly: sage: A=networkx.complete_bipartite_graph(2r,3r) sage: list(A.edges()) [(0, 2), (0, 3), (0, 4), (1, 2), (1, 3), (1, 4)] -- You received

[sage-devel] networkx BipartiteGraph

Hi all, In Arch we have upgraded networkx to version 2. This comes with major API changes that affect Sage's interface, and I'm currently trying to fix these issues. I'm struggling with a particular issue with bipartite graphs. In pure ipython, this code gives: In [1]: import networkx In [2]:

[sage-devel] Re: Re: Re: notebook does not work

Sándor Czirbusz wrote: > Ah, sorry > #!/usr/bin/python2 > > That looks OK. Are you sure you don't have any other 'twistd' executable lying around on your system? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group

[sage-devel] Re: Re: notebook does not work

Sándor Czirbusz wrote: > This is the answer > > # Copyright (c) Twisted Matrix Laboratories. > # See LICENSE for details. > import os, sys > > try: > import _preamble > except ImportError: > try: > sys.exc_clear() > except AttributeError: > # exc_clear() (and the

[sage-devel] Re: notebook does not work

Dima Pasechnik wrote: > Is your Sage built from source, or you downloaded a binary installation? > > Anyway, I see what happens. For some strange reason it picks up wrong > Twisted, the one for Python 3. > You can see it from the log below, and the error message is the one you > get by trying to

[sage-devel] Re: Making Sage-7.1 Fails

Antonio Rojas wrote: > Adetokunbo Arogbonlo wrote: > >> Cleaning out old PolyBoRi and BRiAl installations >> patching file Makefile.am >> patching file Makefile.in >> patching file groebner/src/Makefile.am >> patching file groebner/src/Makefile.in >&

[sage-devel] Re: Making Sage-7.1 Fails

Adetokunbo Arogbonlo wrote: > Cleaning out old PolyBoRi and BRiAl installations > patching file Makefile.am > patching file Makefile.in > patching file groebner/src/Makefile.am > patching file groebner/src/Makefile.in > checking for a BSD-compatible install... /usr/bin/install -c The patch

[sage-devel] Duplicate folders in docs

Hi, The Sage docs ship 22(!) almost identical copies of the _static dir, the only difference being the translations.js files. This adds almost 200MB to the Sage installation. Any chance that these could be replaced by symlinks on supported platforms? -- You received this message because you

[sage-devel] Re: Build failure on Arch Linux: conway_polynomials fails to build

Perl 5.22 throws warnings for unescaped '{', and pari treats warnings as errors by default. I'm using this patch for system-wide pari: https://projects.archlinux.org/svntogit/community.git/tree/trunk/no_warnings_fatal.patch?h=packages/pari-sage Joshua Hunt wrote: Hi, Perl is v5.22.0.

[sage-devel] Re: Sage 6.7 build failure

François Bissey wrote: Are you really really certain about the bisection? Which version of Cython (system or with Sage patches?) I'll have to add, because I have no such problems in sage-on-gentoo, which version of ntl? ntl-8 and 9 will certainly lead to some failures. Francois

[sage-devel] Re: Sage 6.7 build failure

Jeroen Demeyer wrote: On 2015-05-18 23:19, Antonio Rojas wrote: I've bisected and it is caused by this commit: https://github.com/sagemath/sage/commit/01432cf19605c9534a6063d1d66f55d7b96a50d1 Are you really really certain about the bisection? Which version of Cython (system or with Sage

[sage-devel] Sage 6.7 build failure

Hi, I'm getting this error when trying to build sage-the-library 6.7 (against system NTL), with both GCC 4.9 and GCC 5: build/cythonized/sage/rings/polynomial/pbori.cpp:1931:3: error: reference to 'WrappedPtr' is ambiguous WrappedPtrFGLMStrategy _strat; ^ In file included from

[sage-devel] Re: Issues with GCC 5.x

leif wrote: * Sage library -- modules using Lcalc headers won't build for the same reason (build with '-fpermissive' in CFLAGS; distutils ignores CXXFLAGS) sage/libs/coxeter3 also fails: In file included from /usr/include/coxeter/coxgroup.h:67:0,

[sage-devel] Re: cached methods in cython

Simon King wrote: In two experiments with Sage-6.5.beta4, I can not replicate the problem. Hi, I tried with a downloaded binary package to make sure it's not caused by our packaging, and can still reproduce: - Remove src/sage/rings/finite_rings/finite_field_base.pyx - Run: sage:

[sage-devel] Re: cached methods in cython

Vincent Delecroix wrote: Which Sage version are you using? The following code is ok for me on sage-6.6.beta0 sage: K=GF(5) sage: K.factored_order() 5 Vincent Version 6.5. Note the if the cython source is not available part, it works OK if the .pyx source is installed (we currently

[sage-devel] cached methods in cython

Hi, Cached methods in cython modules don't work if the cython source is not available: sage: K=GF(5) sage: K.factored_order() --- AttributeErrorTraceback (most recent call last) [...]

[sage-devel] Where is sage/tests/parallel.pyx?

Hi, In module_list.py there is reference to a sage/tests/parallel.pyx extension, but there is no such file in the sources. This breaks compiling the Sage library with cython 0.22, which seems to be stricter than previous versions in dealing with missing sources. -- You received this message