Re: [sage-devel] Re: Sage development norms and procedures

On Monday, September 29, 2025 at 3:34:44 PM UTC-5 Nils Bruin wrote: It seems to me there are two things that arise in conflict here: - some people who see, unannounced, big changes and failures happen. - developers who see certain changes as necessary to keep their maintenance burden manageab

Re: [sage-devel] Re: Sage development norms and procedures

On Monday, September 29, 2025 at 11:12:49 AM UTC-5 John H Palmieri wrote: On Monday, September 29, 2025 at 8:01:58 AM UTC-7 dim...@gmail.com wrote: On Sun, Sep 28, 2025 at 10:52 AM Kwankyu Lee wrote: > > On Friday, September 26, 2025 at 7:47:25 AM UTC+9 John H Palmieri wrote: > > Here are

Re: [sage-devel] Re: Sage development norms and procedures

On Mon, Sep 29, 2025 at 1:39 PM William Stein wrote: > On Mon, Sep 29, 2025 at 9:12 AM John H Palmieri > wrote: > > On Monday, September 29, 2025 at 8:01:58 AM UTC-7 dim...@gmail.com > wrote: > > > Previously "make" built doc. Now it doesn't. This change affects all > developers using sage-the-d

[sage-devel] Re: Sage development norms and procedures

On Friday, September 26, 2025 at 7:47:25 AM UTC+9 John H Palmieri wrote: Here are some recent occurrences in Sage development: 1. The documentation is not built by default. Previously "make" built doc. Now it doesn't. This change affects all developers using sage-the-distro. As such, It shoul

[sage-devel] Re: Sage development norms and procedures

On Friday, September 26, 2025 at 6:47:25 AM UTC+8 John H Palmieri wrote: 3. Kwankyu has brought up some issues about github release creation. 4. ... Item 3 arose, and some other issues arose, because code was removed without carefully thinking about the consequences. As can be seen in https://

Re: [sage-devel] Re: strategy question about method name uniformity

Hello, I think it will be hard to achieve consistency on this matter. Unless of course somebody wants to spent the next few years doing that. Any volunteer ? (0) I think we should allow "n*" and "n_*" and "number_of_*" only. I have a preference for "n_*". (1) My current proposal is to use "n_

Re: [sage-devel] Re: strategy question about method name uniformity

On 2025-09-24 12:23 p.m., 'Martin R' via sage-devel wrote: There are about 100 distinct methods named `number_of_xxx`.  I'm a bit sceptical that changing or aliasing these to `num_xxx` is a good idea - mostly because of tab completion. If that's the naming scheme that's already established in

Re: [sage-devel] Re: strategy question about method name uniformity

There are about 100 distinct methods named `number_of_xxx`. I'm a bit sceptical that changing or aliasing these to `num_xxx` is a good idea - mostly because of tab completion. Martin On Wednesday, 24 September 2025 at 16:39:57 UTC+2 Vincent Macri wrote: > I agree that consistency is good. I p

[sage-devel] Re: Did something become more strict about circular imports?

El miércoles, 24 de septiembre de 2025 a las 16:51:32 UTC+2, Michael Orlitzky escribió: Has anything else changed? Is it just me? (This requires sagelib to be installed as a python package via pip, meson, or a package manager; it works fine from within a sage prompt.) Can reproduce as far ba

Re: [sage-devel] Re: The built documentation location

On Tue, Sep 9, 2025 at 9:47 AM 'tobia...@gmx.de' via sage-devel wrote: > > > As of 10.8.beta2 (perhaps also earlier releases), the built documentation is > found in build/sage-distro/src/doc/html/en/reference. The standard location > was local/share/doc/sage/html/en/reference. > > Is this intend

Re: [sage-devel] Re: Make boost a prerequisite specifically on macOS (gh-40689)

On Fri, Sep 12, 2025 at 11:20 AM Volker Braun wrote: > > > BTW, Conda is already the recommended approach for compiling from source. > > Is it? I mean thats great but I'm not aware of it > > Our documentation https://doc.sagemath.org/html/en/installation/source.html > curiously only explains how

[sage-devel] Re: Discussion list for Sage governance

Dear all, There is another governance discussion tomorrow (Friday). See the message below for the time and the Zoom link. Regards, John On Monday, September 15, 2025 at 3:14:08 PM UTC-7 John H Palmieri wrote: Dear all, A reminder: there are two scheduled Zoom discussions to discuss governa

[sage-devel] Re: Make boost a prerequisite specifically on macOS (gh-40689)

> BTW, Conda is already the recommended approach for compiling from source. Is it? I mean thats great but I'm not aware of it Our documentation https://doc.sagemath.org/html/en/installation/source.html curiously only explains how to *NOT* use conda in case you happen to be in an activated cond

[sage-devel] Re: Github release creation stopped working

I manually created "releases" for 10.8.beta2 and 10.8.beta3. The workflow is not working. -- 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...@g

[sage-devel] Re: Github release creation stopped working

I manually created "releases" for 10.8.beta2 and 10.8.beta3. The github workflow is not working. -- 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+unsubs

[sage-devel] Re: Discussion list for Sage governance

Dear all, A reminder: there are two scheduled Zoom discussions to discuss governance ideas for Sage: Tuesday (tomorrow!) and Friday. Please follow the links in the message below to RSVP and get an invitation to the meeting. Regards, John On Sunday, September 7, 2025 at 7:20:15 PM UTC-7 David

Re: [sage-devel] Re: Make boost a prerequisite specifically on macOS (gh-40689)

On September 13, 2025 4:31:51 AM CDT, Volker Braun wrote: >> cannot support a mix with the standard install >(./boostrap+./configure+make) pulling some deps from Conda and some from >elsewhere > >Why not? Specifically, why do we support that for homebrew and cannot for >conda? OK, maybe i

[sage-devel] Re: Github release creation stopped working

This message was delivered to me, but somehow not posted here: ("---" inserted by me) > Kwankyu, > > we love your attitude too. You disappear from the project for a solid half a year or so, and then come back as it was yesterday and start sw---ring at people who continued working on it. > > Dim

Re: [sage-devel] Re: Make boost a prerequisite specifically on macOS (gh-40689)

> cannot support a mix with the standard install (./boostrap+./configure+make) pulling some deps from Conda and some from elsewhere Why not? Specifically, why do we support that for homebrew and cannot for conda? You at least implied on the PR that boost could be installed from conda, so is

[sage-devel] Re: Github release creation stopped working

On Saturday, September 13, 2025 at 11:19:25 AM UTC+9 tobia...@gmx.de wrote: Concerning " workflow step "Create release"." was removed: no it was replaced by using the softprops/action-gh-release to create the release notes at the same time as uploading the release assets. Since adding the asset

Re: [sage-devel] Re: The built documentation location

On Thursday, September 11, 2025 at 10:02:48 AM UTC+8 François Bissey wrote: These days, I set it at build time in the file that becomes: sage/config.py which defines all those things that are different in gentoo compared to some other environments. Hopefully, we can improve the meson setup a

[sage-devel] Re: Github release creation stopped working

At https://github.com/sagemath/sage/actions/runs/17527169457/job/49779204920 you can see that the workflow fails in the "release_dist" step with the error " sage_bootstrap.tarball.FileNotMirroredError: tarball does not exist on mirror network". I have no idea what this step is checking in detai

[sage-devel] Re: Make boost a prerequisite specifically on macOS (gh-40689)

The documentation was changed in the 10.7 release cycle but the published docs are still for 10.6. In the updated docs: - https://doc-develop--sagemath.netlify.app/html/en/developer/walkthrough uses conda to setup the dev env for new developers - https://doc-develop--sagemath.netlify.app/html/en

Re: [sage-devel] Re: The built documentation location

On Wednesday, September 10, 2025 at 12:17:27 PM UTC+8 Kwankyu Lee wrote: We really should just remove all those SAGE_xyz variables. Why? Do you assume that sage-the-distro is dead? I do think it's close to dead, but that's not the point. The reason why SAGE_xyz should not be used is bec

Re: [sage-devel] Re: The built documentation location

https://github.com/sagemath/sage/pull/40807 needs review. -- 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 dis

Re: [sage-devel] Re: The built documentation location

... SAGE_SHARE: Also doesn't make sense outside of sage-the-distro. Instead of looking for stuff there at runtime, you should try to find your resources at build time. They all make sense in sage-the-distro. ... so you have to set SAGE_DOC after you build the docs to tell sagelib where

[sage-devel] Re: Make boost a prerequisite specifically on macOS (gh-40689)

It's important to have the overall situation for this in mind: - Dima is the main maintainer nowadays for updating packages in sage-the-distro. One should perhaps say the only maintainer. In fact, he has trouble to even find reviewers for package update PRs. - The maintenance burden is way to hi

Re: [sage-devel] Re: The built documentation location

On 10/09/2025 20:51, 'tobia...@gmx.de' via sage-devel wrote: meson setup build meson compile -C build doc-html cp -r build/src/doc/html usr/share/doc/sage-$VERSION As for example done on arch: https://github.com/gripped/archpkgbuilds/blob/master/extra/sagemath-doc/PKGBUILD How do you currentl

Re: [sage-devel] Re: The built documentation location

On Wed, Sep 10, 2025 at 4:28 AM Kwankyu Lee wrote: > > ... > SAGE_SHARE: Also doesn't make sense outside of sage-the-distro. Instead of > looking for stuff there at runtime, you should try to find your resources at > build time. > > > They all make sense in sage-the-distro. > > > ... so you hav

Re: [sage-devel] Re: The built documentation location

On 2025-09-10 16:30:09, François Bissey wrote: > Even if sage-the-distro was dead, those variables are useful. > And if we say it is dead, well, it should go in a more standard > location, which at minimum would be $prefix/share/doc and configurable. > In Gentoo we want stuff in /usr/share/doc/pk

Re: [sage-devel] Re: The built documentation location

On Tue, Sep 9, 2025 at 10:31 PM 'tobia...@gmx.de' via sage-devel wrote: > > +export SAGE_DOC="$SAGE_ROOT/build/sage-distro/src/doc" > > > This fixes it only for sage-the-distro, not for anyone else. We really should > just remove all those SAGE_xyz variables. For SAGE_DOC this should be > relati

Re: [sage-devel] Re: The built documentation location

On 10/09/2025 16:17, Kwankyu Lee wrote:  We really should just remove all those SAGE_xyz variables. Why? Do you assume that sage-the-distro is dead? Even if sage-the-distro was dead, those variables are useful. And if we say it is dead, well, it should go in a more standard location,

Re: [sage-devel] Re: The built documentation location

We really should just remove all those SAGE_xyz variables. Why? Do you assume that sage-the-distro is dead? | doc is built after sage is built. Why not just put SAGE_DOC under '-o'? It's already falling back to SAGE_DOC if you don't specify '-o'. But that doesn't solve the question wh

Re: [sage-devel] Re: The built documentation location

+export SAGE_DOC="$SAGE_ROOT/build/sage-distro/src/doc" This fixes it only for sage-the-distro, not for anyone else. We really should just remove all those SAGE_xyz variables. For SAGE_DOC this should be relatively simple, since it's essentially only used in src\sage\misc\sagedoc.py and the

Re: [sage-devel] Re: The built documentation location

On Tue, Sep 9, 2025 at 6:27 PM Kwankyu Lee wrote: > > > > On Tuesday, September 9, 2025 at 11:47:50 PM UTC+9 tobia...@gmx.de wrote: > > In the case of `reference`, is there a good reason this is not simply > opening https://doc.sagemath.org/ in case SAGE_DOC doesn't point to an > existing folde

[sage-devel] Re: The built documentation location

On Tuesday, September 9, 2025 at 11:47:50 PM UTC+9 tobia...@gmx.de wrote: In the case of `reference`, is there a good reason this is not simply opening https://doc.sagemath.org/ in case SAGE_DOC doesn't point to an existing folder? SAGE_DOC should point to an existing folder if doc was buil

[sage-devel] Re: The built documentation location

The docs are placed in whatever folder you pass under `-o` to the sage_docbuild script. In the case of `make doc-html` this is indeed some folder under build/sage-distro, but it could be also a completely different directory. doc is built after sage is built. Why not just put SAGE_DOC unde

[sage-devel] Re: The built documentation location

As of 10.8.beta2 (perhaps also earlier releases), the built documentation is found in build/sage-distro/src/doc/html/en/reference. The standard location was local/share/doc/sage/html/en/reference. Is this intended or a bug? The docs are placed in whatever folder you pass under `-o` to the s

[sage-devel] Re: The built documentation location

On Tuesday, September 9, 2025 at 9:58:57 AM UTC+9 Kwankyu Lee wrote: ... in src/sage/misc/sagedoc.py. But as you see, the "not tested" tag makes it useless. Why a doctest is "not tested"? To prevent undesirable side effects, such as opening an web browser. OK. -- You received this messa

[sage-devel] Re: How to depend on sagemath as pip installable third party package

On Monday, 8 September 2025 at 08:35:49 UTC+2 tobia...@gmx.de wrote: Thanks for bringing this up! > what will be the recommended way to depend on sagemath in a pip package As with any other python dependency: If you compile against sage (eg using cython), you should specify `sagemath` under

[sage-devel] Re: How to depend on sagemath as pip installable third party package

Thanks for bringing this up! > what will be the recommended way to depend on sagemath in a pip package As with any other python dependency: If you compile against sage (eg using cython), you should specify `sagemath` under `build-system > requires` in the pyproject.toml of your project. If sag

[sage-devel] Re: Discussion list for Sage governance

Hi Sage developers, There was some discussion shortly after this discussion list was created, but not much has been happening for many months. In an effort to make some progress we're organizing Zoom discussions, starting with * Tuesday September 16 at 12pm

Re: [sage-devel] Re: Documentation and state of Sage CI

On 2025-08-28 20:46:47, 'tobia...@gmx.de' via sage-devel wrote: > Lines annotated with "known bug" are always skipped. What do you think > about the following: > 1. Introduce a new "random failure" tag and use that to annotate doctests > that are known to fail sometimes (either with segfaults, ti

Re: [sage-devel] Re: Documentation and state of Sage CI

What do you think about the following: 1. Introduce a new "random failure" tag and use that to annotate doctests that are known to fail sometimes (either with segfaults, timeouts, or differing output) 2. Normally on CI, skip the execution of such tests. 3. In one special run after a release (or

[sage-devel] Re: External cython packages broken

Marc Mezzarobba wrote: > It looks like Sage 10.8.beta0 broke the installation of external > packages that include Cython modules. Update: I just noticed that 10.8.beta1 is out. The issue is still present. -- Marc -- You received this message because you are subscribed to the Google Groups "sa

Re: [sage-devel] Re: Documentation and state of Sage CI

Lines annotated with "known bug" are always skipped. What do you think about the following: 1. Introduce a new "random failure" tag and use that to annotate doctests that are known to fail sometimes (either with segfaults, timeouts, or differing output) 2. Normally on CI, skip the execution of s

Re: [sage-devel] Re: Documentation and state of Sage CI

On 2025-08-27 6:42 p.m., 'tobia...@gmx.de' via sage-devel wrote: I don't think tests need to be disabled, but rather the CI should not report a PR as failing if the same failure occurs on develop. So still run the failing tests, but don't report the workflow as failing if the

Re: [sage-devel] Re: "Undefined symbol" revealed by 'make ptestlong'

yes, this is exactly the problem. no-build-isolation is the last resort which can potentially lead to this sort of trouble. it's probably fixed in , but there are versions shenanigans there, stemming from our rather outdated way to deal with Python p

Re: [sage-devel] Re: Documentation and state of Sage CI

I don't think tests need to be disabled, but rather the CI should not report a PR as failing if the same failure occurs on develop. So still run the failing tests, but don't report the workflow as failing if the same test fails on develop. I think we already have something like this for the f

[sage-devel] Re: "Undefined symbol" revealed by 'make ptestlong'

Could the error be related to this message near the end of matplotlib-3.10.1.log? "[spkg-install] Warning: Wheel building needed to use "--no-isolation --skip-dependency-check" to succeed. This means that a dependencies file in build/pkgs/ needs to be updated. Please report this to sage-devel@

Re: [sage-devel] Re: Documentation and state of Sage CI

To slightly expand on the above: We do have tests with fixed (build.yml) and with variable random seed (ci-meson.yml). I was not aware that only meson used a random seed. That's good to know and explains why meson seems to fail more often in CI. As a reviewer/developer it's helpful to know whi

[sage-devel] Re: "Undefined symbol" revealed by 'make ptestlong'

On many systems, GCC14 should be fine: Recent linux distributions have now moved to GCC15, which is a problem. But then changing the build options to use gcc14 works fine (see https://groups.google.com/g/sage-devel/c/tJCbTnelvSg/m/IfzQF0HGBQAJ ). On those same distributions, sagemath is running

[sage-devel] Re: "Undefined symbol" revealed by 'make ptestlong'

Nils - It's always possible, but I don't see any obvious culprits in my path. OTOH, I do see is that readme calls for "GCC versions from 8.4.0 to 13.x" whereas I'm running gcc 14.3.0. (Has anyone else tested gcc 14.x?) I also see that readme calls for python3 versions "3.9.x to 3.12.x" whereas

Re: [sage-devel] Re: Documentation and state of Sage CI

On August 26, 2025 9:30:28 PM CDT, Kwankyu Lee wrote: > > >- Sometimes PRs introduce reproducible build errors on a small subset of >systems ... then after some time disable the failing system > > >I think we should not drop support of a system (platform) failing because >of bugs introduced b

Re: [sage-devel] Re: Documentation and state of Sage CI

To slightly expand on the above: We do have tests with fixed (build.yml) and with variable random seed (ci-meson.yml). But even with a fixed seed you do get sometimes, often non-reproducible, failures. Some of these issues are known for a long time (eg https://github.com/sagemath/sage/issues/29

Re: [sage-devel] Re: Documentation and state of Sage CI

I took a look at the "sage -t" in "test-long (src/sage[a-f]*)" of a few recent PRs (going back to June), and it looks to me like they all used the same random seed: 286735480429121101562228604801325644303. Where are you seeing a different seed? On Tuesday, August 26, 2025 at 11:28:15 PM UTC-4

Re: [sage-devel] Re: Documentation and state of Sage CI

* My understanding is that all CI runs now use the same random seed We do use random seeds, and we should. https://github.com/sagemath/sage/issues/40632 was found because we have a test that generates a random input to a function and 0 is not valid input for that function. For some seeds, lik

[sage-devel] Re: Documentation and state of Sage CI

- Sometimes PRs introduce reproducible build errors on a small subset of systems ... then after some time disable the failing system I think we should not drop support of a system (platform) failing because of bugs introduced by PRs. Similarly "Sometimes a PR introduces a bug that breaks exi

[sage-devel] Re: "Undefined symbol" revealed by 'make ptestlong'

A loader symbol lookup error probably means that the dynamic library loaded during runtime differs from the one that was assumed during compile time. "agg" is a component of matplotlib, so it could be that the inconsistency lies within matplotlib itself. Could it be the case that an old version

[sage-devel] Re: Documentation and state of Sage CI

> The biggest issue with the reliability of the CI is a deep design decision in the way the tests are setup. > Many doctests have an inherent random element, and this is mostly on purpose to increase the surface > of code paths that are tested and thereby discover new bugs. The disadvantage is

[sage-devel] Re: "Undefined symbol" revealed by 'make ptestlong'

1) Sorry, I forgot to mention, I am building sage-10.7 from source on openSUSE-15.6. 2) It turns out not to matter whether sage builds matplotlib or if it is installed from the OS repository. Suggestions welcome. On Tuesday, August 26, 2025 at 8:35:04 AM UTC-7 Richard_L wrote: > All(?) tests i

Re: [sage-devel] Re: Documentation and state of Sage CI

On 2025-08-25 6:56 p.m., Kwankyu Lee wrote: Perhaps this helps you understand the current pitiful state of the CI infrastructure.  Since the CI infrastructure  itself is broken and unstable, I think that documenting it now is premature. Even if formal documentation isn't possible, I still think

Re: [sage-devel] Re: Documentation and state of Sage CI

On Tue, Aug 26, 2025 at 06:55:28AM -0700, 'tobia...@gmx.de' via sage-devel wrote: > The biggest issue with the reliability of the CI is a deep design > decision in the way the tests are setup. Many doctests have an > inherent random element, and this is mostly on purpose to increase > the surface

[sage-devel] Re: Documentation and state of Sage CI

The biggest issue with the reliability of the CI is a deep design decision in the way the tests are setup. Many doctests have an inherent random element, and this is mostly on purpose to increase the surface of code paths that are tested and thereby discover new bugs. The disadvantage is that u

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

Hello, Le lun. 18 août 2025 à 18:45, seb@gmail.com a écrit : > > > A big thanks, Marc. > > +1 > > > I am looking forward to testing it with my colleagues, students and > > friends, especially those on Windows. > > BTW: Eight months ago, we reactivated the sage-windows repository, which was

Re: [sage-devel] Re: Error when using sage --doucbuild -D

There is https://github.com/sagemath/sage/pull/40588 for the issue. -- 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 vie

[sage-devel] Re: Documentation and state of Sage CI

A brief history: 1. Aa far as I know, Matthias (currently off duty) did the most work in setting up the original CI infrastructure. This is based on traditional tools: make and docker. 2. Recently Tobias made (and is making) changes to the CI infrastructure, based on meson, with which he inten

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

Le lundi 25 août 2025 à 16:08:53 UTC+2, marc@gmail.com a écrit : Hi Eric, You can install ipympl by running `%pip install ipympl` at a sage prompt. It will do a "--user" install in your .local directory. (Ubuntu 24.04 does not allow --user installs, but the AppImage does.) Thanks for the

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

Hi Eric, You can install ipympl by running `%pip install ipympl` at a sage prompt. It will do a "--user" install in your .local directory. (Ubuntu 24.04 does not allow --user installs, but the AppImage does.) Nominally an AppImage is read-only, but that is not strictly true. You can unpack an A

[sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

I gave it a try on a Ubuntu 24.04 computer: it works like a charm! In particular, I've run this test notebook: https://nbviewer.org/github/egourgoulhon/SageMathTest/blob/master/Notebooks/test_display.ipynb and everything was OK, except for the %matplotlib widget magic in cell 22. But the latter re

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

Hi, Would you mind to re-post your question - it's nowhere to be seen in our forum. Dima On August 23, 2025 6:52:54 PM CDT, Tessa Weinstein wrote: >Sorry! I posted a question and I thought this was a response to my >question! Ignore me. My apologies. > > >***

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

Sorry! I posted a question and I thought this was a response to my question! Ignore me. My apologies. * Tessa F. Weinstein, Ph.D. www.tessatutors.com * On Sat, Aug 23, 2025 at 4:49 PM Tessa Weinstein wrote:

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

I'm not using it in a course. I don't work at a university. There is no IT department. I'm it. It's for me and my personal use. I'm a professional math tutor who makes content for her students and wants to automate using it with LaTeX, that's all. * Tes

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

On Sat, Aug 23, 2025 at 1:59 AM Jesus Martinez Garcia wrote: > > When it's for me, for research, we're allowed to get an admin account (after > jumping a number of admin approval hoops). I still found it difficult because > the VPN is installed by deffect and cannot be turned off even by admin a

Re: [sage-devel] Re: Error when using sage --doucbuild -D

with #39030 this should be obsolete, so let's not dwell on fixing stuff which is about to be gone for good. On August 23, 2025 5:51:39 PM CDT, John H Palmieri wrote: >This was broken in PR #39973. I don't what motivated that change, but it >needs to be fixed. > > >On Saturday, August 23, 2025

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

On Friday, 22 August 2025 at 23:59:52 UTC-7 aska...@gmail.com wrote: In any case, that's beyond the point. Sure, one can "demand" but the actual nature of the power relationship at many unis is a different one. I'm sure our CS department would prefer Linux running in the computers that their st

[sage-devel] Re: Error when using sage --doucbuild -D

This was broken in PR #39973. I don't what motivated that change, but it needs to be fixed. On Saturday, August 23, 2025 at 11:13:46 AM UTC-7 yuand...@gmail.com wrote: > Dear all, > I build > SageMath version 10.8.beta0, Release Date: 2025-08-16 > on my Macbook Air M2, with macOS 15.6. > > I tr

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

Thank you for this useful feedback! aska...@gmail.com schrieb am Samstag, 23. August 2025 um 08:59:52 UTC+2: > Hi, > > When it's for me, for research, we're allowed to get an admin account > (after jumping a number of admin approval hoops). I still found it > difficult because the VPN is insta

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

Hi, When it's for me, for research, we're allowed to get an admin account (after jumping a number of admin approval hoops). I still found it difficult because the VPN is installed by deffect and cannot be turned off even by admin and it blocks a number of things (on top of my head package install,

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

On Thu, Aug 21, 2025 at 10:29 AM aska...@gmail.com wrote: > I use Sagemath on Windows (essentially because my university only supports > Windows, but also because I prefer Windows to other systems and I cannot > really deal with having separate machines for programming and everything > else). M

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

> *If I understand correctly from your link, approach D may get close to this?* Yes, that's true. But I don't know the timeline for that. I find it unfortunate that your university is withholding WSL from you, as I consider it the best thing Microsoft has produced in the last decade. Neverthel

Re: [sage-devel] Re: conflicting semantics of rank

Hi, Thanks for raising this issue. For good and bad, rank and unrank are indeed the standard names in enumerative combinatorics, which is why we had chosen these names back then in MuPAD-Combinat, before the code got ported to Sage-Combinat. I agree that the conflict with widely used seman

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

Hi, I use Sagemath on Windows (essentially because my university only supports Windows, but also because I prefer Windows to other systems and I cannot really deal with having separate machines for programming and everything else). My university provides Sagemath on version 9.1 on the old Windo

Re: [sage-devel] Re: conflicting semantics of rank

On Wednesday, 20 August 2025 at 17:35:20 UTC-7 tcsc...@gmail.com wrote: Let me also point out that this is for *enumerated* sets, which means there is a special total order on the objects. So I might not call it arbitrary. However, that is somewhat of a digression. And that order is indeed rel

[sage-devel] Re: base_ring not a ring?

Yes, that's a bug. It is passing the residue to the base class, which doesn't handle it. So I simply removed it from the super().__init__() call in https://github.com/sagemath/sage/pull/40651. Best, Travis On Wednesday, August 20, 2025 at 4:16:36 PM UTC+9 axio...@yahoo.de wrote: > I am guessin

Re: [sage-devel] Re: conflicting semantics of rank

A common tool used to resolve such name clashes is to use an underscored name. So you'd end up with ordinal_rank or enumeration_rank then. I still like enumeration_index better in that context. In my original post I proposed `total_order_rank` and `total_order_unrank`. I think it would be

Re: [sage-devel] Re: conflicting semantics of rank

I think that the main use for rank and unrank is to have an arbitrary, but deterministic total order on the elements, and to be able to create elements at random. Let me also point out that this is for *enumerated* sets, which means there is a special total order on the objects. So I might n

Re: [sage-devel] Re: conflicting semantics of rank

On Wednesday, 20 August 2025 at 13:55:04 UTC-7 axio...@yahoo.de wrote: In my original post I proposed `total_order_rank` and `total_order_unrank`. I think it would be good to have the same prefix, in order not to further clutter the already long list of method names you get by tab completio

Re: [sage-devel] Re: conflicting semantics of rank

Dear Nils, On Wednesday, 20 August 2025 at 18:00:15 UTC+2 Nils Bruin wrote: On Wednesday, 20 August 2025 at 02:57:36 UTC-7 axio...@yahoo.de wrote: Well, rank is really the standard term in computational combinatorics. But, as you note, it doesn't play nicely with terminology from other areas

Re: [sage-devel] Re: conflicting semantics of rank

On Wednesday, 20 August 2025 at 02:57:36 UTC-7 axio...@yahoo.de wrote: Well, rank is really the standard term in computational combinatorics. But, as you note, it doesn't play nicely with terminology from other areas of mathematics -- the meaning of "rank" as for a matrix and for (free) rank o

Re: [sage-devel] Re: conflicting semantics of rank

Well, rank is really the standard term in computational combinatorics. It seems to me that index is already quite overloaded: for example, `CombinatorialObject` defines it. I cannot find `index` as an alias for `rank`, where did you see that? I think that the main use for rank and unrank is to

Re: [sage-devel] Re: conflicting semantics of rank

The name index follows Python convention >>> [1, 2, 5, -2, 3].index(-2) 3 sounds like a much better name than rank. Note that rank could also refer to the dimension of a vector space/free module or the number of generators of a free group. On Tue, 19 Aug 2025 at 22:32, Nils Bruin wrote: > > Ag

[sage-devel] Re: conflicting semantics of rank

Agreed! In fact, looking at the docstring, it seems like "rank" is just an alias for "index". Of course, "index" is going to be a similarly overloaded term, but at least "rank" can be freed up by just dropping it as an alias of "index". You can then solve the problems of "index" separately. For

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

Thanks Marc and everyone involved in this work! I second that it should be mentioned in the install section. And, to keep the appimage up-to-date, the build scripts and CI should be perhaps included in the main repo as well (similar to the existing docker build). On Tuesday, August 19, 2025 at

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

On Monday, August 18, 2025 at 3:52:38 PM UTC-5 Nils Bruin wrote: Would "%cython" code work in it? Yes, it seems to work. I tested using %%cython as a decorator for a simple factorial function. The resulting function got the right answer, although it was a bit slower than the pure python vers

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

If we can keep these AppImages up-to-date then a mention in https://doc.sagemath.org/html/en/installation/index.html (in the linux section) would certainly seem appropriate. These pages: https://doc.sagemath.org/html/en/installation/linux.html https://doc.sagemath.org/html/en/installation/binary.

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

On Mon, Aug 18, 2025 at 11:45 AM seb@gmail.com wrote: > There are currently four approaches to obtaining installers for Sage on > Windows, again. At least the approach marked with "C" still works for all > Sage releases available on DockerHub >

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

> *A big thanks, Marc.* +1 > *I am looking forward to testing it with my colleagues, students and friends, especially those on Windows.* BTW: Eight months ago, we reactivated the sage-windows repository , which was once used to provide Windows install

[sage-devel] Re: Meson build

El viernes, 15 de agosto de 2025 a las 18:33:14 UTC+2, tobia...@gmx.de escribió: Thanks a lot for giving this a try! Thanks to all of you for your really hard work. Before starting, if one copies the instructions in html, it is OK when in the rst the instruction is written in the file but

Re: [sage-devel] Re: ANNOUNCEMENT: SageMath as an AppImage

A big thanks, Marc. I am looking forward to testing it with my colleagues, students and friends, especially those on Windows. Best, Guillermo On Sat, 16 Aug 2025 at 10:56, Eric Gourgoulhon wrote: > This is great news! > Thank you very much for making this possible! > > Eric. > > Le vendredi 1

  1   2   3   4   5   6   7   8   9   10   >