Re: [sage-devel] "Copy" vs "Refactor"

On Sat, 2022-04-23 at 08:28 -0400, ph h wrote: > Dear All, > > If the three files: > >1. sage/sage >2. sage/src/bin/sage >3. sage/src/bin/sage-env > > are to be factored out into > >1. sage/resolvelinks.in >2. sage/sage.sage.in >3. sage/sage.src.bin.sage.in >4.

Re: [sage-devel] Re: [sage-release] Re: Sage 9.5 released

On Fri, 2022-04-22 at 08:16 -0700, seb@gmail.com wrote: > > (./sage -i should be deprecated and removed…) > > — or just have ‘sage -i xyz’ do whatever ‘make xyz’ now does, perhaps. > > +1 > This only works if you don't ever want to e.g. rename sage to sage.in to fix the copy & paste from

Re: [sage-devel] "Copy" vs "Refactor"

On Fri, 2022-04-22 at 01:03 -0400, ph h wrote: > > Is this use case scenario, (running a script before building anything) > documented or undocumented? > I'm not sure if it still is, but running things like "sage -b" and "sage -i" was for 15+ years the documented way to build parts of sage.

Re: [sage-devel] "Copy" vs "Refactor"

On Thu, 2022-04-21 at 14:28 -0700, ph h wrote: > Dear All, > > While waiting for advice on the questions on the thread "Copy" > > """ > BTW, is symlink a solution for "Copy & Paste"? > By another way, are there reasons that "Copy & Paste & Symlinks" is better > than just symlinks. > """ > >

Re: [sage-devel] Copy & Paste

On Wed, 2022-04-13 at 19:36 -0700, ph h wrote: > Dear All, > > At the top of 'sage/src/bin/sage' script: > > > # WARNING: this function is copy/pasted from both src/bin/sage-env and > # the top-level "sage" script. Please keep them synchronized. > resolvelinks() { > > > Is there any other way

Re: [sage-devel] Proposal: make Jupyterlab a standard package

On Tue, 2022-03-22 at 13:47 +, Thierry wrote: > > "Standard" also means "be shipped within the source tarball" that is > self-contained and does not require network connexion to be installed. > True, but it would be just as easy to ship the tarballs for packages that are optional and

Re: [sage-devel] Proposal: make Jupyterlab a standard package

On Tue, 2022-03-22 at 03:44 -0700, Eric Gourgoulhon wrote: > > Maybe it is time to make it a standard package in Sage. > If so, please make it optional via a --disable-jupyterlab flag. (We already have one for the standard notebook, --disable-notebook.) Hijack, sorry: with these flags

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

On Wed, 2022-03-16 at 11:34 -0700, Matthias Koeppe wrote: > Reviving this old thread... > Another option is https://github.com/puppeteer/puppeteer, which is > used by > screenshotting tools such > as https://github.com/marketplace/actions/screenshots-ci-action > > I've opened

Re: [sage-devel] Question about some Sage scripts

On Wed, 2022-02-23 at 14:21 -0800, John H Palmieri wrote: > >- sage-cachegrind, sage-callgrind, sage-massif, sage-omega, >sage-valgrind — do people use these? Not really, but they do have /some/ value. At the useful end, the sage- valgrind script, 1. Tries to guess where the python3

Re: [sage-devel] Re: Using Both Induced Volume and Lrs Engine

On Wed, 2022-02-23 at 10:34 -0800, Advay Goel wrote: > For example, I currently have a 10-dimensional polytope that is located in > QQ^18. How would I bring this polytope into 10-dimensional space so that I > can use LRS to calculate its volume? If you have a ten-dimensional polytope, there

Re: [sage-devel] Moving SAGE_TMP to the system location

On Sun, 2022-02-13 at 09:57 -0500, Michael Orlitzky wrote: > > If not, I'm proposing we, > > 1. Replace all direct uses of SAGE_TMP in library/doctest code with  > python's tempfile module. > 2. Drop SAGE_TMP from tmp_filename() and tmp_dir(); this will revert

Re: [sage-devel] Re: Moving SAGE_TMP to the system location

On Sun, 2022-02-13 at 09:18 -0800, Volker Braun wrote: > Are we talking about /tmp or /var/tmp? Short answer: /tmp. Long answer: The python tempfile functions use a directory that, "is chosen from a platform-dependent list, but the user of the  application can control the directory

[sage-devel] Moving SAGE_TMP to the system location

tl;dr I think we should forego SAGE_TMP and use whatever the system's temporary location is. The first-order benefits of that are, 1. No need to maintain SAGE_TMP code ourselves. 2. The system temporary location is often optimized for temporary  access (e.g. is mounted in RAM), and is

Re: [sage-devel] sage -t: sorting sources by runtime

On Tue, 2022-02-08 at 22:40 -0500, David Roe wrote: > This is for when you're running in parallel, so that you don't start a file > that takes a long time at the end of the run. And here I thought it was using the Hardy-Littlewood-Polya approach to slow down testing as much as possible. That

[sage-devel] sage -t: sorting sources by runtime

> Sorting sources by runtime so that slower doctests are run first > Doctesting 4320 files... Why? Does anyone know what this is supposed to do? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop

Re: [sage-devel] Re: docbuild aborting on warnings

On Tue, 2022-02-01 at 16:10 -0800, Matthias Koeppe wrote: > +1 on this as a new default if we add a flag for the current strict > behavior, for use by Release Manager, patchbot, and GH Actions. > We could also explicitly list the warnings that can cause a failure, but that might get annoying

Re: [sage-devel] Re: [sage-release] Re: Sage 9.5 released

On 2022-01-31 20:13:12, John Cremona wrote: > > > > (./sage -i should be deprecated and removed...) > > -- or just have 'sage -i xyz' do whatever 'make xyz' now does, perhaps. > The main philosophical issue with this is that "make" is a build-time tool, and that "sage" is the thing that "make"

Re: [sage-devel] turning on warnings during a recompile?

On Sat, 2022-01-22 at 14:09 -0800, Randall wrote: > [sagelib-9.5.rc3] Executing 1 command (using 1 thread) > [sagelib-9.5.rc3] [1/1] Time to execute 1 command: 9.62 seconds. Between these two lines, the C or C++ compilation takes place. If you don't see any warnings, there weren't any. It's a

Re: [sage-devel] trouble pushing to a ticket

On Wed, 2022-01-19 at 21:04 -0800, Steven Trogdon wrote: > I'm having difficulty pushing to a ticket, which I've done many times > previously. When I push, i.e. > > OpenSSH 8.8 (recently stable on Gentoo) disables RSA with SHA-1. You can work around it, but probably the best long-term solution

Re: [sage-devel] Re: 32768

On Tue, 2022-01-18 at 07:53 -0800, William Stein wrote: > > One of the difficulties for them is lack of support for 32-bit Linux > distros. E.g., if you click > Nobody has the hardware any more. Debian is your best bet for ongoing i686 support. -- You received this message because you are

Re: [sage-devel] asking for setting up cythonizing compiling

On Mon, 2022-01-17 at 18:35 -0800, Matthias Koeppe wrote: > On Monday, January 17, 2022 at 5:14:30 PM UTC-8 Michael Orlitzky wrote: > > > Dark magic is relative, but for someone new [...] > > > > (rant deleted) > > 1) "make build" just works > 2) &

Re: [sage-devel] asking for setting up cythonizing compiling

On Mon, 2022-01-17 at 17:02 -0800, William Stein wrote: > > > When I wrote this, the steps were: > > (1) build sage > (2) edit the pyx/pxd file you want to change, or really anything in > SAGE_ROOT/src/sage > (3) type "sage -br" to build any changes and start sage. > > Doing "sage -br" should

Re: [sage-devel] asking for setting up cythonizing compiling

On Mon, 2022-01-17 at 15:27 -0800, Randall wrote: > I would like to find some developer who is willing to show me how to set up > the cythonizing part of the compile for the Sage build. I did fix 371 > warnings in 110 code units, but have to push these changes back up into the > cython code.

Re: [sage-devel] sagemath 9.5rc0 still not compiling on opensuse tumbleweed

On Wed, 2022-01-12 at 13:27 +, Dima Pasechnik wrote: > > to see if it can be overridden. But it would be nice to track down the > > source of the -Werror so that it can be fixed for others. > > I have found it - it's absense of return statement in an inline > function in an fflas-ffpack

Re: [sage-devel] sagemath 9.5rc0 still not compiling on opensuse tumbleweed

On Wed, 2022-01-12 at 10:19 +, Dima Pasechnik wrote: > > Basically, your C++ compiler is too strict. I think it's just the CFLAGS that are too strict: error: Command "gcc-10 -Wno-unused-result -Wsign-compare -DNDEBUG -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong

Re: [sage-devel] Python-level error messages don't give the source file name

On Sat, 2022-01-08 at 23:27 -0800, Jonathan Thornburg wrote: > what's the idiomatic way for some other piece of Sage source code to > execute the contents of all of those files? What I've been doing is > to create another file (say 'setup.sage') which contains the lines > load('foo.sage') >

Re: [sage-devel] Python-level error messages don't give the source file name

On 2022-01-08 18:56:21, Jonathan Thornburg wrote: > I've noticed that some (many) Python-level error messages (e.g., syntax > errors) from Sage 9.5.beta8 fail to give the name of the source file > in which the error occured. For example, a few minutes ago I got this > error message from a Sage

Re: [sage-devel] Whats the plan for random doctests with floating point numbers?

On Wed, 2021-12-29 at 13:35 -0800, Volker Braun wrote: > There are doctests of the form > > sage: x = random_value() > sage: abs(floating_point_computation(x) - exact_value(x)) < tolerance > True > > but every floating point computation has SOME values where it is >

Re: [sage-devel] Add more-itertools as a standard package

On Mon, 2021-12-20 at 14:29 +, Dima Pasechnik wrote: > a pypi package without a version constraint in requirements.txt is not much > of burden, maintenance-wise, until it starts breaking things. > It still needs to be upgraded forever, and added to every distro, and upgraded in every distro

Re: [sage-devel] Add more-itertools as a standard package

On Thu, 2021-12-16 at 00:38 +0100, Samuel Lelièvre wrote: > Dear sage-devel, > > The "more-itertools" Python package extends the "itertools" > module with extra useful iteration tools such as `pairwise`, > `triplewise`, `unique_justseen`, etc. > > Would anyone else support adding this package? >

Re: [sage-devel] Re: Demote SageTeX to an optional package?

On Mon, 2021-12-06 at 19:34 -0800, Nathan Dunfield wrote: > On Monday, December 6, 2021 at 8:39:23 AM UTC-6 Michael Orlitzky wrote: > > > > > Does "sage -i" not work either? (Is there a ticket for fixing it?) > > > > It doesn't with the recommend ma

Re: [sage-devel] Re: Demote SageTeX to an optional package?

On Mon, 2021-12-06 at 01:55 -0800, Emmanuel Charpentier wrote: > > Having a *standard* way to integrate Sage’s results in a document is > **crucial*. > > So -1. Modulo the binary package issue, I'm only suggesting that we change the word "standard" in build/pkgs/sagetex/type to "optional", not

Re: [sage-devel] Re: Demote SageTeX to an optional package?

On Sun, 2021-12-05 at 20:03 -0800, Nathan Dunfield wrote: > I'd be extremely hesitant to remove something that's been a standard > package for over a decade unless it was causing major headaches. I could > be wrong, but isn't SageTeX just a couple files totaling under 25K? > > The vast

[sage-devel] Demote SageTeX to an optional package?

SageTeX was added to sage as a standard package in https://trac.sagemath.org/ticket/7617 It's closely tied to sage (can't be used on its own), but is also not used by any other part of sage. Can we demote it to an optional package? Realistically this amounts to adding "first, run `make

Re: [sage-devel] Problem with testim...png while building sphinx

On Sat, 2021-11-06 at 09:58 -0700, Fr Morain wrote: > I cannot compile sphinx for version 9.3 due to a problem in the name of a > file, namely > testimäge.png > in ../var/tmp/sage/build/sphinx-3.1.2.p0/src/tests/roots/test-images > that cannot be listed, (re)moved and copied. > Any hint? >

Re: [sage-devel] Re: singular crash

On Fri, 2021-11-12 at 14:59 -0800, Volker Braun wrote: > I'm seeing these fail regularly (and randomly) > > Are these system (i.e. non-SPKG) installs of Singular? We're accepting anything newer than v4.1.0, but if some particular version is buggy we should exclude it. -- You received this

[sage-devel] Re: RFC: zn_poly removal

On 2021-11-11 11:18:03, Alex J Best wrote: > Right, that seems like a fair benchmark to me, does zn_poly (falling back > to ntl) run faster than the force ntl = 1 version in enough ranges of > variables to justify its continued existence? > Knowing whether it failed and fell back (and hence was

Re: [sage-devel] Re: RFC: zn_poly removal

On Tue, 2021-11-09 at 10:58 -0800, Alex J Best wrote: > I must correct myself: the interval products code via NTL is not used for > cyclic covers as the force NTL flag is set to true there (thanks David Roe!) Unless I misread commit 54e89297, you've set force_ntl=1 yourself inside the exposed

Re: [sage-devel] Re: RFC: zn_poly removal

On Tue, 2021-11-09 at 10:54 -0800, Alex J Best wrote: > I agree the situation with zn_poly is a mess, but I think it would be good > to do some actual benchmarks to check if the NTL code is faster or > comparable to the zn_poly version, I don't see any data in the ticket but > you do say "The

[sage-devel] RFC: zn_poly removal

Trac: https://trac.sagemath.org/ticket/32841 In short, zn_poly is one of "those" packages. Abandoned in 2008, and kept on life support by sage developers ever since. Despite our efforts, the build system remains crazy and it would take a good bit of time to re-do the whole thing using autotools

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

On Mon, 2021-11-01 at 09:58 -0700, Sébastien Labbé wrote: > Also, this used to work, but does not work currently: > > $ sage -tp --memlimit=4000 > usage: sage -t [options] filenames > sage-runtests: error: unrecognized arguments: --memlimit=4000 > The --memlimit option and the default memlimit

Re: [sage-devel] Trac emails

On 2021-10-10 04:41:19, Antonio Rojas wrote: > 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%) Is anybody else experiencing this? I think these are all relayed through

Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

On Thu, 2021-09-23 at 21:57 -0700, Matthias Koeppe wrote: > On Thursday, September 23, 2021 at 9:09:45 PM UTC-7 Michael Orlitzky wrote: > > > Item #2 happened, incidentally, only because we've copy & pasted so > > many packages into sage pretending to be a linux distribu

Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

On Thu, 2021-09-23 at 21:18 -0700, Matthias Koeppe wrote: > On Thursday, September 23, 2021 at 7:48:35 PM UTC-7 Michael Orlitzky wrote: > > > You could tar up an entire Gentoo system with > > sage installed and it would probably take up less space than our >

Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

On Thu, 2021-09-23 at 21:10 -0700, Matthias Koeppe wrote: > On Thursday, September 23, 2021 at 7:48:35 PM UTC-7 Michael Orlitzky wrote: > > > 2, 4, 6, and 7 are addressed by Conda, Nix, Guix, Homebrew, or even > > Gentoo Prefix. > > > > Item 7 of my list, pip

Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

On Thu, 2021-09-23 at 20:51 -0700, Matthias Koeppe wrote: > On Thursday, September 23, 2021 at 7:48:35 PM UTC-7 Michael Orlitzky wrote: > > > Whoever is building the binary images could install a compiler into > > SAGE_LOCAL with "dpkg-deb -x" or whatever before they

Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

On Thu, 2021-09-23 at 20:32 -0700, John H Palmieri wrote: > Item #2 actually happened. Can you cite posts from people successfully > using the tools you mention to get around it? People who solve the unnecessary problem in the obvious and reliable way don't post about it. If you really doubt

Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

On Thu, 2021-09-23 at 18:12 -0700, Matthias Koeppe wrote: > I repeat my strong objections to the proposed change -- which does not > solve any problems and only creates new ones. > 2, 4, 6, and 7 are addressed by Conda, Nix, Guix, Homebrew, or even Gentoo Prefix. These projects *want* to build

Re: [sage-devel] #32532 - removing gcc and gfortran spkgs

On Thu, 2021-09-23 at 23:17 +0100, Dima Pasechnik wrote: > https://trac.sagemath.org/ticket/32532 > proposes to remove > these packages as not needed, and a huge time sink for everyone involved. > I'm sure this list changes every time I make it

Re: [sage-devel] minimize_constrained is not consistent with different variable names

On Thu, 2021-09-16 at 01:28 -0700, Pol del Aguila Pla wrote: > How would one go about contributing a fix to this? It should be easy. I > would be happy to try. Could you provide some links on how to do it? The documentation can be found at  https://doc.sagemath.org/html/en/developer/ The

Re: [sage-devel] minimize_constrained is not consistent with different variable names

On Fri, 2021-09-03 at 02:25 -0700, Pol del Aguila Pla wrote: > I've encountered a bug in minimize_constrained where it seems that the > variable name has an effect on the result. My guess is that this happens > somewhere along the translation from symbolic to numerical function. > Attached is a

Re: [sage-devel] Update of system python

On Tue, 2021-08-31 at 10:42 +0530, Niranjana K M wrote: > Hi, > If sage is built with system python (default behavior) any future > update of system python makes sage non-functioning. This is natural. > > ... > > PS: I use Gentoo. Though it doesn't matter. > > This is true of any software you

Re: [sage-devel] **WARNING** /var/cache/sympow/datafiles/le64 yields insufficient permissions

On Sat, 2021-08-28 at 14:45 -0700, Jaap Spies wrote: > On Fedora 34 on an i7 running ptestlong I get some failures all related to > subject. > Never seen this before. A chmod 0777 /var/cache/sympow/datafiles/le64 > 'solved' the problem, but is it a solution? > Fedora should patch sympow to hide

Re: [sage-devel] Singular rpm packages on Fedora

On Wed, 2021-08-18 at 17:34 +0900, Kazuyoshi Furutaka wrote: > > But there exists no fedora.txt file in sage pkgs directory. > > $ ls build/pkgs/singular/distros/ > > conda.txt freebsd.txt macports.txt repology.txt > > debian.txt homebrew.txt nix.txt > > > > Isn't it possible to use

Re: [sage-devel] Re: Vector spaces with immutable vectors by default

I like the idea proposed in https://trac.sagemath.org/ticket/29101 (as posted by Matthias). Namely, introducing the option mutable=False for the element constructor. Then your code could be rewritten to sum( D[V(v0+w, mutable=False)] for w in W) which should be fine, I guess. Travis Scrimshaw

Re: [sage-devel] printing polynomials with matrix coefficients

On Mon, 2021-08-02 at 05:14 -0700, 'Martin R' via sage-devel wrote: > is currently rather awkward: > > > sage: M = MatrixSpace(QQ, 2) > sage: L. = PolynomialRing(M) > sage: 1-x > ([-1 0] > [ 0 -1])*x + [1 0] > [0 1] > > Is there a cure? > This also happens with CombinatorialFreeModule, where

[sage-devel] Re: How to use generic quotients?

e able to implement the quotients > in #32249. Does anyone see any reason not to implement such an error? Or at > least a warning? > > On Tuesday, July 27, 2021 at 8:33:13 AM UTC-5 Michael Jung wrote: > >> Thank you Trevor! This was extremely helpful! >> Trevor Karn schrieb am Di

[sage-devel] Re: How to use generic quotients?

he graded commutative > algebras. I opened a ticket https://trac.sagemath.org/ticket/32249 to > start doing this but in the meantime got pulled toward other tasks for my > GSoC project. > > On Monday, July 26, 2021 at 1:43:33 PM UTC-5 Michael Jung wrote: > >> Sorry, the last exam

[sage-devel] Re: How to use generic quotients?

Sorry, the last example is of course sage: from sage.algebras.commutative_graded_algebra_finite import FiniteGCAlgebra sage: A. = FiniteGCAlgebra(QQ, degrees=(1,2,3), max_degree=6) sage: I = A.ideal(y^2) sage: Q = A.quotient(I) sage: Q.gen(1)^2 ybar^2 Michael Jung schrieb am Montag, 26. Juli

[sage-devel] How to use generic quotients?

Hello everyone, In https://trac.sagemath.org/ticket/32272, I am trying to implement graded algebras with finite degree. I have troubles constructing a (generic) quotient. Here is what happens without a ngens method: sage: from sage.algebras.commutative_graded_algebra_finite import

Re: [sage-devel] Unexpected result when substituting expression with minus

On Thu, 2021-07-22 at 10:08 -0700, Marcus A. wrote: > Hi all, > > I think I found a bug when substituting "-a == 0" into "a". The result is > not "0" but "a". This also happens when I assume that "a" is real. (see > below) > > sage: var('a') > a > sage: a.substitute(a == 0) > 0 > sage:

Re: [sage-devel] String literals and the line continuation character

On Wed, 2021-07-21 at 16:42 -0700, Evan O'Dorney wrote: > It seems to work, but not quite: > > sage: "abc\ > : 23" > 'abcInteger(23)' > > What version of Sage? Your example works for me after these two fixes: * https://trac.sagemath.org/ticket/30417 *

[sage-devel] (RFC) New standard package: GNU Info

On https://trac.sagemath.org/ticket/32242 I propose adding the standalone GNU "info" reader as a new standard package. In sage/interfaces/singular.py, we currently manually parse Singular's Info file to obtain docstrings for Singular's functions. This is not great: 1. We're maintaining an

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

On 2021-07-16 13:44:21, Matthias Koeppe wrote: > I propose to make cmake a standard package We're going to have to do it sooner or later. Might as well be sooner. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and

Re: [sage-devel] spoken languages and banner translations

On Sun, 2021-07-04 at 18:12 -0700, Kwankyu Lee wrote: > > +1 for designing the logo anew. I never liked the amateurish logo. Now Sage > deserves a better logo! > > There's a lot of low-hanging fruit to be had. If you start with Harald's logo from https://github.com/sagemath/artwork and

Re: [sage-devel] Re: proposal - remove gcc, gfortran, python building/spkgs

On Thu, 2021-06-24 at 18:59 -0700, Matthias Koeppe wrote: > On Thursday, June 24, 2021 at 4:24:10 PM UTC-7 Michael Orlitzky wrote: > > > On Thu, 2021-06-24 at 15:54 -0700, Volker Braun wrote: > > > What about replacing gcc with a script that installs the conda toolchain

Re: [sage-devel] Re: proposal - remove gcc, gfortran, python building/spkgs

On Thu, 2021-06-24 at 15:54 -0700, Volker Braun wrote: > What about replacing gcc with a script that installs the conda toolchain > automatically. The distro gcc currently does not work for me, so its not > THAT rare to get into problems. On the other hard, installing conda is more > likely to

Re: [sage-devel] Re: extend with list vs extend with iterator

On Thu, 2021-06-10 at 09:47 -0700, 'Martin R' via sage-devel wrote: > The question is, whether we can rely on behaviour of the reference > implementation of python which contradicts its documentation: > The cynic's take: you can't rely on anything in a language that has no specification. Can

[sage-devel] Re: taylor expansion and heap overflow

eap overflow caused by a >> sagemath taylor expansion? >> Culprits are functions of this form: >> 'Product(1+x^m)^A001511(m)' or 'zeta(s)zeta(2s)zeta(3s)/zeta(6s)'. >> >> In kind regards, >> Michael >> > -- You received this message because you are subscribed

[sage-devel] taylor expansion and heap overflow

)'. In kind regards, Michael -- 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 sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web vi

Re: [sage-devel] problem building maxima

On Fri, 2021-05-14 at 12:12 +0100, Dima Pasechnik wrote: > > > > The other possibility is that the linker is told not to look for > > system-wide libffi - can this be achieved with -L and -Wl,-rpath ? > > > > On the other hand, it's a bug in maxima, which does not try to check > > for presense

Re: [sage-devel] lcalc upstream

On Wed, 2021-05-05 at 11:26 +1200, François Bissey wrote: > Hi all, > > Do we have a fork and repo for lcalc to add our changes? > Some lcalc headers are currently preventing sage to compile with gcc-11 > and rather than just adding some more patch to lcalc I was wondering > if we had made

Re: [sage-devel] QQbar benchmarks

On Sun, 2021-04-25 at 15:07 +0200, Fredrik Johansson wrote: > Hi all, > > I'm looking for benchmark problems for QQbar/AA arithmetic. Ideally such a > problem will: > > * Be reducible to a short program that, apart from using QQbar/AA > operations, is reasonably self-contained. > * Reflect

[sage-devel] Unification of generic ring methods

where it is already nailed. Suggestions and feedback are highly welcome. Best, Michael -- 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 sage-deve

[sage-devel] Unification of generic ring methods

Hello everyone, I have encountered some inconsistencies in the code involving rings. Some implementations use R.is_field() To check whether a ring R is a ring whereas other implementations prefer R in Fields() I propose to unify this behavior. A first approach and discussion can be found

[sage-devel] Graded algebra with finite degree

but providing what I need? Otherwise, I would start working on it. Best, Michael -- 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 sage-devel+unsubscr...@google

[sage-devel] Re: Possible bug in gen_legendre_P (associated Legendre polynomials)

fix. As for resolving the convention conflicts in a rigorous manner I propose a follow-up ticket: https://trac.sagemath.org/ticket/31637. Best, Michael Eric Gourgoulhon schrieb am Sonntag, 8. April 2018 um 18:07:56 UTC+2: > Hi, > > > Le mardi 27 mars 2018 14:46:52 UTC+2, Ralf Ste

[sage-devel] Re: spherical harmonics still broken in 9.3.rc2

I changed priority to "critical". This feature is obviously highly demanded among the community (cf. https://trac.sagemath.org/ticket/25034#comment:6). Best, Michael Jonathan Thornburg schrieb am Donnerstag, 8. April 2021 um 20:12:19 UTC+2: > There have been longstanding issues w

Re: [sage-devel] Error when running doctests.

On Mon, 2021-04-05 at 21:43 +0100, Dima Pasechnik wrote: > internet says it might have to do with wrong permissions to /tmp or > TMPDIR pointing to a directory with wrong permissions. > My guess: https://trac.sagemath.org/ticket/31395 -- You received this message because you are subscribed

[sage-devel] Re: https://wiki.sagemath.org/ReleaseTours/sage-9.3

P.S. Same for the ticket links I didn't provide since I assumed they will be added automatically similar to the Sage trac server. Michael Jung schrieb am Montag, 5. April 2021 um 10:40:01 UTC+2: > Thank you. But also sorry, I spotted a mistake: > > "under the weaker assumption of

[sage-devel] Re: https://wiki.sagemath.org/ReleaseTours/sage-9.3

for simplicity since I am not familiar to the Wiki's syntax (is that the same as for Wikipedia?). Best, Michael Matthias Koeppe schrieb am Montag, 5. April 2021 um 03:53:28 UTC+2: > Thanks! I've added it > -- You received this message because you are subscribed to the Goog

[sage-devel] Re: https://wiki.sagemath.org/ReleaseTours/sage-9.3

Here we go. Thanks for taking care of it, Matthias! Michael Jung schrieb am Montag, 5. April 2021 um 00:29:07 UTC+2: > Meaning, I will post it here. > > Michael Jung schrieb am Montag, 5. April 2021 um 00:28:24 UTC+2: > >> Alright, thanks. For now then, I'll post my proposal

[sage-devel] Re: https://wiki.sagemath.org/ReleaseTours/sage-9.3

Meaning, I will post it here. Michael Jung schrieb am Montag, 5. April 2021 um 00:28:24 UTC+2: > Alright, thanks. For now then, I'll post my proposal the upcoming days. Is > markdown format fine? > Matthias Koeppe schrieb am Sonntag, 4. April 2021 um 21:59:53 UTC+2: > >> I t

[sage-devel] Re: https://wiki.sagemath.org/ReleaseTours/sage-9.3

gt; https://trac.sagemath.org/wiki/WikiStart#legacy-account-request > > On Sunday, April 4, 2021 at 12:06:50 PM UTC-7 Michael Jung wrote: > >> Is there a way I can get access though? There is a bit more worth to add: >> - https://trac.sagemath.org/ticket/18416 >> - h

[sage-devel] Re: https://wiki.sagemath.org/ReleaseTours/sage-9.3

. April 2021 um 18:49:31 UTC+2: > Just post the text here that you want added and I can add it. > > On Sunday, April 4, 2021 at 9:29:08 AM UTC-7 Michael Jung wrote: > >> >> It might also worth to mention that the Pfaffian of a matrix can now be >> computed wi

[sage-devel] Re: https://wiki.sagemath.org/ReleaseTours/sage-9.3

It might also worth to mention that the Pfaffian of a matrix can now be computed with a much way faster algorithm: https://trac.sagemath.org/ticket/30681. I would add an example to the Release tour but I don't know how or I don't have access... Samuel Lelievre schrieb am Montag, 22. März 2021

Re: [sage-devel] sagetex and tcb

Here's the issue: https://github.com/sagemath/sagetex/issues/54 I've provided a minimal example of the tcolorbox environment. Perhaps that is something that can be added to sagetex if we get it to work? Michael Jung schrieb am Sonntag, 4. April 2021 um 11:54:02 UTC+2: > Anyway, I will appro

Re: [sage-devel] sagetex and tcb

Anyway, I will approach this on the GitHub page. This problem is more suited there than here. Thanks Dima! Best, Michael Michael Jung schrieb am Sonntag, 4. April 2021 um 11:39:46 UTC+2: > There is no bug or something. I just want to use sagetex beyond its > current capabilities. Long

Re: [sage-devel] sagetex and tcb

example yet. dim...@gmail.com schrieb am Sonntag, 4. April 2021 um 10:36:34 UTC+2: > Hi, > could you file an issue in https://github.com/sagemath/sagetex - > with an example, showing what doesn't currently work. > Thanks > Dima > > On Sat, Apr 3, 2021 at 9:49 PM Michael Jung wro

[sage-devel] sagetex and tcb

I am not familiar how sagetex even works internally. Some explanation or optimally a solution is pretty much appreciated. Thanks a lot. Best, Michael -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group

Re: [sage-devel] Re: Doctest memory limit

On Tue, 2021-03-23 at 17:16 -0700, Volker Braun wrote: > I don't understand what the big pain point is, if Steve doesn't like the > limit it he can just pick a different value no? You can, but "make ptestlong" no longer works. And the correct number to use is not obvious. The "optional -

[sage-devel] Doctest memory limit

Is anyone very much in love with the --memlimit (default: 3300MB) option to the sage -t command? Once again it has completely broken testing on some systems. We could try to guess a new, higher limit... or just admit that maybe it's not a great idea after all and delete the thing. The latter is

Re: [sage-devel] Linking libraries with spkg-install.in

On Fri, 2021-03-19 at 09:57 -0700, Matthias Koeppe wrote: > > > FWIW, latte_int 1.7.6 has eliminated these bad tests (for presence of > header files) > in > https://github.com/latte-int/latte/commit/2011c2ec0bda70b6f7e02bdd3ed02176d427927b > The "with" options that allow you to specify a

Re: [sage-devel] Could we remove "SR.symbols"?

On Sun, 2021-03-14 at 04:42 -0700, Diego Sejas wrote: > 2.If one defined "var('foo')", then overwrites it with "foo = 2", and for > some reason needs the symbol "foo" again, is there any meaningful advantage > in retrieving it from the cache "SR.symbols" instead of redefining it again? I think

Re: [sage-devel] Could we remove "SR.symbols"?

On Sat, 2021-03-13 at 14:00 -0800, Diego Sejas wrote: > Any symbolic ring in Sage has a dictionary called "symbols". (I'll refer > specifically to "SR" for the following.) "SR.symbols" contains all the > previously defined variables through "SR.var()" and/or "SR.symbol()". > However, this

Re: [sage-devel] Re: Downgrade R to optional? See #31409.

On Mon, 2021-03-08 at 21:04 -0800, William Stein wrote: > Hi, > > One related question: we tend to have a 1-year deprecation policy with > Sage, and some could argue that removing R will break use of Sage that uses > the R interface. Should removing the R package from standard be subject to >

Re: [sage-devel] Cached methods of Cartesian products

On Sat, 2021-02-20 at 09:31 -0500, Michael Orlitzky wrote: > On Sat, 2021-02-20 at 08:21 -0500, Michael Orlitzky wrote: > > @cached_method > > def cartesian_embedding(self, i): > > E = super().cartesian_projection(i) > > return "Ju

Re: [sage-devel] Cached methods of Cartesian products

On Sat, 2021-02-20 at 08:21 -0500, Michael Orlitzky wrote: > @cached_method > def cartesian_embedding(self, i): > E = super().cartesian_projection(i) > return "Just kidding" (The copy/paste error in that method is not the problem) -- You

[sage-devel] Cached methods of Cartesian products

I'm fighting with a strange bug. I have an algebraic structure that is subclassed from CombinatorialFreeModule, and its Cartesian product class is thus subclassed from CombinatorialFreeModule_CartesianProduct. There's not much in that class, but It Would Be Nice if I could reuse the code for e.g.

Re: [sage-devel] documentation of external packages

On Tue, 2021-02-16 at 19:43 +0100, Vincent Delecroix wrote: > Dear all, > > I think we reached a consensus that we should have more and more > of the sage source code made as independent Python packages. This > effort has already started with cysignals, cypari2, pplpy and > gappy. > > However,

<    1   2   3   4   5   6   7   8   9   10   >