[sage-devel] Re: Packaging Sage?

As far as I'm aware, everyone's current solution to packaging sage is to more or less completely ignore its own build system and do everything manually in whatever specification format your package manager uses. You will need to make sure it keeps working once the dependencies change. The test

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

Am Freitag, 17. Januar 2020 16:07:08 UTC+1 schrieb E. Madison Bray: > > On Wed, Jan 15, 2020 at 2:37 AM Matthias Koeppe > > wrote: > > > > On Tuesday, January 14, 2020 at 12:01:42 PM UTC-5, Frédéric Chapoton > wrote: > >> > >> So here is my proposal. > >> > >> * Starting from now, we

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

Am Montag, 13. Januar 2020 17:33:56 UTC+1 schrieb E. Madison Bray: > > On Sat, Jan 11, 2020 at 9:24 AM Antonio Rojas > wrote: > > > > 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

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

I have said this before, but I feel like the point was dropped out of the discussion so I'll stress it again. The major issue here is *not* the compatibility of sage's own codebase. A few "from __future__ import"'s are not so bad. The issue is that python2 compatibility forces us to use

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

+1 for dropping python 2.7 compatibility It is unfortunate that the wiki makes that promise. But it is a community wiki, and as such I wouldn't consider it an authorative source. Keeping python2 support will be a *lot* of effort, either for the sage project or (if it just refuses to deal with

[sage-devel] Re: Buiding sage on a Raspberry Pi 4B

Am Dienstag, 31. Dezember 2019 11:50:08 UTC+1 schrieb Volker Braun: > > Which hardware are you using, and how long does it take to bulid and run > the tests? > > On Tuesday, December 31, 2019 at 12:14:28 AM UTC+1, Timo Kaufmann wrote: >> >> For what it's worth, I re

[sage-devel] Re: Buiding sage on a Raspberry Pi 4B

For what it's worth, I regularly build and test sage-on-nixos on aarch64. The testsuite shows no issues, except some transient timeouts which may or may not be caused by the architecture. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To

Re: [Debian-science-sagemath] [sage-devel] Sage Crash Report - Debian testing - amd64

For what it's worth, if you don't mind installing a secondary package manager (https://nixos.org/nix/download.html) you can also use the nix package on debian. Using the unstable channel (rolling release) you can already use sagemath 8.9. You can use pre-build binaries or build from source. I

[sage-devel] Re: [gentoo) insufficient memory for the JRE to continue.

It's been a while, but now we are seeing a similar issue here[1]. In our case it fails the doctests, seems to be jmol running out of memory. [1] https://github.com/NixOS/nixpkgs/pull/65802 Am Dienstag, 14. Mai 2019 09:12:12 UTC schrieb Dima Pasechnik: > > Lately I get this error a lot on a

[sage-devel] Grepping Trac

Hi! As part of my packaging workflow, I find myself pasting error messages into the trac search pretty frequently to discover if something is a known issue or due to packaging complications. Trac search isn't very helpful here though, since it will try to split words and look for them

[sage-devel] Re: Equivalent of "git diff" in trac

Am Montag, 8. Juli 2019 16:05:56 UTC schrieb Chaman Agrawal: > > Hi folks, > > I wanted to compare the net changes in ticket > https://trac.sagemath.org/ticket/27852 in previous commits. On clicking > on a particular commit, trac shows the changes in that commit but I wanted > to see the

Re: [sage-devel] updating README.md

Am Montag, 20. Mai 2019 10:21:05 UTC schrieb Dima Pasechnik: > * what is the status of Nix(OS) support for building/installing Sage? Sage builds and passes its test suite. It uses system dependencies and is patched to work with newer versions where necessary. These patches are listed here[1]

Re: [sage-devel] What to do with the sys.path security patch?

There is some previous discussion here: https://trac.sagemath.org/ticket/26457 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [sage-devel] What to do with the sys.path security patch?

> > I suggest a middle ground: I don't believe this behavior should be > tested in Sage's test suite, because this is a question about the > Python interpreter's behavior, not Sage. > [...] > Otherwise, I don't think the Sage test suite has any business testing > this. > +1, I agree with

Re: [sage-devel] Is there a way to force Sage to use system's openblas ?

Am Sonntag, 17. Februar 2019 12:48:52 UTC+1 schrieb Emmanuel Charpentier: > > > > Le dimanche 17 février 2019 09:34:10 UTC+1, Dima Pasechnik a écrit : >> >> Our plan is to enable the use of the system R install in Sage - for this >> we need to understand whether there would be any problems for

[sage-devel] Re: python3 status report

Am Sonntag, 27. Januar 2019 14:32:16 UTC+1 schrieb Simon King: > > *STATEMENT *: I would to advocate that **every developer switch to > python3 > > NOW**. > > How? > Git worktrees would be a solution. Essentially you keep one git repository, but check out two branches at the same time in

[sage-devel] Re: Startup time improvement in 8.6

Am Donnerstag, 17. Januar 2019 21:31:35 UTC+1 schrieb John H Palmieri: > > > > On Thursday, January 17, 2019 at 12:11:03 PM UTC-8, Timo Kaufmann wrote: >> >> When packaging sage 8.6, I noticed that startup felt unusually fast. So I >> averaged the startup time ove

[sage-devel] Startup time improvement in 8.6

When packaging sage 8.6, I noticed that startup felt unusually fast. So I averaged the startup time over 100 runs: ``` for i in {1..100}; do "sage-8.5/bin/sage" --startuptime | grep 'Total time' | awk '{ print $7 }' >> 8.6.log "sage-8.6/bin/sage" --startuptime | grep 'Total time' | awk '{ print

[sage-devel] cgit update

I just encountered a bug when trying to generate a patch file using `https://git.sagemath.org/sage.git/rawdiff`. It generated a malformed patch. I wanted to report that upstream to cgit, but then I noticed that our cgit installation is 3 years old. We are using 1.0.1 while the latest version

[sage-devel] Re: Single instance of R only

Am Mittwoch, 26. Dezember 2018 01:25:59 UTC+1 schrieb Simon King: > > Hi Timo. > > On 2018-12-25, Timo Kaufmann > wrote: > > I don't really see a reason to rename it. The old name doesn't suggest > that > > it is implemented with pexpect. > > No, it

Re: [sage-devel] Single instance of R only

: > > > > On Tuesday, 25 December 2018 14:55:02 UTC-7, Timo Kaufmann wrote: >> >> Am Dienstag, 25. Dezember 2018 22:46:22 UTC+1 schrieb Nils Bruin: >>> >>> Perhaps for reference, maxima_lib can only be instantiated once and, >>> since sage.inter

Re: [sage-devel] Single instance of R only

Am Dienstag, 25. Dezember 2018 22:46:22 UTC+1 schrieb Nils Bruin: > > Perhaps for reference, maxima_lib can only be instantiated once and, since > sage.interfaces.maxima_lib is only referenced at start-up via lazy_import > (which has its own problems), the instantiation happens upon import of >

Re: [sage-devel] Single instance of R only

Am Dienstag, 25. Dezember 2018 22:04:06 UTC+1 schrieb Andrey Novoseltsev: > > On Tuesday, 25 December 2018 13:53:07 UTC-7, Timo Kaufmann wrote: >> >> Am Dienstag, 25. Dezember 2018 16:32:10 UTC+1 schrieb Andrey Novoseltsev: >>> >>> It does not affect me perso

Re: [sage-devel] Single instance of R only

Am Dienstag, 25. Dezember 2018 16:32:10 UTC+1 schrieb Andrey Novoseltsev: > > On Tuesday, 25 December 2018 03:55:13 UTC-7, vdelecroix wrote: >> >> Since there is only one process, there should be a single instance of >> the R object in Sage. Isn't that a trivial fix? >> >> Disallowing multiple

Re: [sage-devel] Single instance of R only

Am Dienstag, 25. Dezember 2018 11:55:13 UTC+1 schrieb vdelecroix: > > Le 25/12/2018 à 11:01, Timo Kaufmann a écrit : > > > > Am Dienstag, 25. Dezember 2018 00:25:40 UTC+1 schrieb William: > > > >> Just to be clear, I fully support your ch

Re: [sage-devel] Single instance of R only

Am Dienstag, 25. Dezember 2018 00:25:40 UTC+1 schrieb William: > Just to be clear, I fully support your choice. Glad to hear that :) > By "both should be > supported, since they have complementary functionality (pros and cons > to each)... Oh well." I mean "I personally think both should

Re: [sage-devel] Single instance of R only

> > When I last looked, I think the rpy2 interface happens entirely at the C > library level, and there is only one process involved. > Yes, that is true. Working at the C level has a lot of advantages, but there is only one process involved. It may be possible to work around this either by

[sage-devel] Re: Python 3 startup time speedup

Thank you for working on this! Startup time is the biggest pain point for casual sage usage and half a second for python2 is huge. Am Montag, 17. Dezember 2018 16:01:08 UTC+1 schrieb E. Madison Bray: > > Hi all, > > For those of you interested in following the Python 3 port of Sage, > you'll

[sage-devel] Re: Accidentally merged and pushed other tickets branch

Another (more destructive) way is to use `git reset --hard ` to reset the current branch to a particular commit and then `git push --force` it to trac. Another option is `git rebase --interactive`. Am Samstag, 24. November 2018 12:41:36 UTC+1 schrieb Friedrich Wiemer: > > In

Re: [sage-devel] Jupyterhub kernel and SAGE_ROOT

> I think the one "new" point I'm making here is that `import sage` should *just work* without having to set any special environment variables :/ I very much agree On Tue, Nov 6, 2018 at 1:12 PM Erik Bray wrote: > On Tue, Nov 6, 2018 at 1:00 PM Timo Kaufmann wrote: > >

Re: [sage-devel] Jupyterhub kernel and SAGE_ROOT

I've had similar thoughts for a while. Replacing sage-env with a dumb config file that can be parsed from within python would go a long way. I'm not too familiar with the native sage-env however, it might do some clever stuff that a dumb config file couldn't do. Am Dienstag, 6. November 2018

Re: [sage-devel] Re: Error building sage-8.4 on Ubuntu

d (configure check) > gdb-8.2 > gf2x-1.2.p0 > gfan-0.6.2.p0 > gfortran-7.2.0 not installed (configure check) > ... > > If so it should not build gfortran (unless you have SAGE_INSTALL_GCC > set to yes for some reason...) > > On Tue, Oct 30, 2018 at 4:39 PM T

Re: [sage-devel] Re: Error building sage-8.4 on Ubuntu

/Filesystem_Hierarchy_Standard [1] https://nixos.org/nixpkgs/manual/#sec-fhs-environments Am Dienstag, 30. Oktober 2018 16:34:47 UTC+1 schrieb Dima Pasechnik: > > On Tue, Oct 30, 2018 at 4:29 PM Timo Kaufmann > wrote: > > > > Its a bit of a complicated case, but I'm not using anacond

Re: [sage-devel] Re: Error building sage-8.4 on Ubuntu

natively on nixos. Am Dienstag, 30. Oktober 2018 16:08:24 UTC+1 schrieb Dima Pasechnik: > > On Tue, Oct 30, 2018 at 4:01 PM Timo Kaufmann > wrote: > > > > I just had the same issue. Why do you think "several versions of > gfortran guts" are the issue? How

[sage-devel] Re: Error building sage-8.4 on Ubuntu

I just had the same issue. Why do you think "several versions of gfortran guts" are the issue? How does sage find gfortran / why does it get confused? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop

[sage-devel] Re: NTL 11.3.1

Just pushed the nix update without any issues. Thank you for the heads up. For your information, the sage ntl package is still quite outdated: https://trac.sagemath.org/ticket/25532 Am Samstag, 20. Oktober 2018 17:45:04 UTC+2 schrieb Victor Shoup: > > I just release NTL 11.3.1, which fixes a

[sage-devel] Re: Remove sagenb documentation from the reference manual?

I'm also in favor. Besides being more complicated, I think doing something different here for python2 and python3 would be a bad idea. Am Mittwoch, 10. Oktober 2018 07:27:59 UTC+2 schrieb John H Palmieri: > > At https://trac.sagemath.org/ticket/25382, it is being proposed to remove > the

Re: [sage-devel] zn_poly status?

Great! Please let us know on sage-packaging once you put out a new release and switch sage over. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [sage-devel] Re: zn_poly status?

Am Freitag, 7. September 2018 17:56:04 UTC+2 schrieb Erik Bray: > > On Fri, Sep 7, 2018 at 5:29 PM Timo Kaufmann > wrote: > > > > For what its worth, we currently don't apply any patches in nix and at > least the sage doctests pass. A more standard build would

[sage-devel] Re: zn_poly status?

For what its worth, we currently don't apply any patches in nix and at least the sage doctests pass. A more standard build would still be nice though. And since upstream is officially dead, I think giving it a new home would be very good. +1 from me. Am Freitag, 7. September 2018 15:53:43

Re: [sage-devel] Re: Enabling Merge Requests from GitLab

The unfamiliar trac workflow was a barrier of entry for me, definitely delaying my first contribution. It has some advantages but having gitlab as an option for newcomers would be nice. +1 from me. -- You received this message because you are subscribed to the Google Groups "sage-devel"

Re: [sage-devel] Meaning of --optional=sage in doctests

Also see the solutions I and jhpalmieri proposed in #26159[1]. I like those better because they still makes it possible to run optional doctests without running all of sages doctests. I think that is very valuable. The current example that started the discussion (very limited in scope) in

Re: [sage-devel] installation fortran

Is sage not included in ubuntus repos? Alternatively if it is a hardware detection problem you could try building with SAGE_FAT_BINARY=1 or, as a bit of self promotion, install sage through nix. Am Sonntag, 19. August 2018 20:06:55 UTC+2 schrieb Mathieu Roux: > > aie aie aie > > but i have

Re: [sage-devel] Status of the legacy Sage notebook

See https://trac.sagemath.org/ticket/25837 for discussion about deprecation. I think the documentation ticket is much smaller in scope and independent of deprecation. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this

Re: [sage-devel] Re: talk

Am Mittwoch, 25. Juli 2018 01:32:38 UTC+2 schrieb William: > > On Tue, Jul 24, 2018 at 5:49 PM, Timo Kaufmann > wrote: > > I really like your wishlist! The all-or-nothing nature of sage and the > slow > > startup time > > (although it's actually more like

[sage-devel] Re: talk

I really like your wishlist! The all-or-nothing nature of sage and the slow startup time (although it's actually more like 1.3 seconds with a warm cache on my machine) are my biggest pain points. I'm not sure if its a good idea to separate user and developer error messages. I'm also not

Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)

As one small data point I can say that I already upgraded cysignals in nixpkgs (tested Linux, although it could technically be used on other platforms too). I didn't run into any obvious issues. I also think we should merge that upgrade for 8.3. Erik put in a lot of work to make that platform

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

Yes that is exactly https://bugs.python.org/issue33374 and can be fixed by either switching to the develop branch (building 8.3rc0 instead of 8.2) where python is already upgraded

Re: [sage-devel] Patching policy

To be clear I am not advocating to create a fork of every dependency. That would probably only worsen the problem (making it even easier to pull the "patch trigger" and harder to find the patches for distributions). -- You received this message because you are subscribed to the Google Groups

Re: [sage-devel] Patching policy

2018-06-07 15:06 GMT+02:00 Jeroen Demeyer : > And I'm not saying there should be absolutely no patches, just that they >> should be the very last resort. >> > > I mostly agree with this, it's what I'm already doing. It just depends > where you put the borderline of "very last resort" and there we

Re: [sage-devel] Patching policy

2018-06-07 14:16 GMT+02:00 Jeroen Demeyer : > On 2018-06-07 13:24, Timo Kaufmann wrote: > >> I don't really agree but even if that was the case, the PARI stackwarn >> patch could have been handled through filtering within sage instead >> (which I proposed in that tick

Re: [sage-devel] Patching policy

2018-06-07 11:12 GMT+02:00 Jeroen Demeyer : > I think that your post is focusing too much on tests, as if the only > purpose of Sage is to pass its testsuite. It's actually the other way > around: the purpose of the testsuite is to ensure that Sage functions > correctly. Of course. But the

[sage-devel] Patching policy

I have recently re-written the nixpkgs sage package to use system packages[1] (not merged yet). While doing that I noticed that while sage patches a lot of its dependencies (81 out of 276 packages have a `patches` folder). There are more or less 3 categories of patches: 1.

[sage-devel] Re: Interrupting pari hangs sage

Thanks! That version in the repo "just" rebuilds everything using sage spkgs. It probably fails lots of tests, although I never really tried. The one I'm working on now uses system packages and passes the testsuite. Its not quite correct to list nix under linux distributions: While there is the

Re: [sage-devel] Interrupting pari hangs sage

>Was cysignals compiled with PARI support? Can you provide the cysignals >build log? It was not and I think that fixed the problem! At least I couldn't reproduce it yet (not reliably reproducible bugs are annoying). I mainly looked into recent dependency changes for potential causes, although

[sage-devel] Interrupting pari hangs sage

Hi, I'm currently in the process of upgrading nixos's sage package to 8.2. While doing that, https://trac.sagemath.org/ticket/18919 resurfaced: ``` alarm(9/11); (2^100).binomial(2^22, algorithm='pari') ``` sometimes hangs. "sometimes" seems to be whenever the system is under load. This

Re: [sage-devel] Giac fails to build

I am essentially building like this: ``` autoreconf --install --force --verbose ./configure --disable-dependency-tracking --prefix=${out} make -j4 -l4 SHELL="$(which bash)" ``` And yes, in the failing builds texlive was present (in an minimal configuration). Do you think texlives presence also

Re: [sage-devel] Giac fails to build

After adding one more depencency (hevea) the compilation succeeds. Thank you for your help. It needs quite some dependencies that are not mentioned on the README's instructions though (like hevea and texlive). Are those just undocumented or does it depend on some build options? -- You

Re: [sage-devel] Giac fails to build

Okay, I've added automake-1.11 and a full texlive install to the deps. I'll rerun the build and see how it turns out. So do you think that sed command actually fixed the first error? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To

Re: [sage-devel] Giac fails to build

With that change the build still fails, just for a different reason: ``` Making install in doc make[1]: Entering directory '/home/timo/nix/shell/sage-8.0/local/var/tmp/sage/build/giac-1.2.3.47.p0/src/doc' Making install in en make[2]: Entering directory

Re: [sage-devel] Giac fails to build

No, the build started from https://github.com/sagemath/sage/archive/8.0.tar.gz The weird looking path names are normal in nixos[1], since it writes every package under a path containing the hash of its build inputs. [1]: https://nixos.org/ Am Donnerstag, 19. Oktober 2017 15:18:56 UTC-5

Re: [sage-devel] Giac fails to build

> The line that makes me curious is "sed: can't read input_parser.cc: No > such file or directory” > and you are failing on that file. I cannot find a sed line in spkg-install > on github for sage-8.0 > (or the current beta) so this is very curious. > > François &