Re: [sage-devel] Re: Cannot build sage 10.4.beta6 [fflas_ffpack-2.5.0]

[Dima Pasechnik]

On Wed, May 22, 2024 at 4:48 AM Edgar Costa  wrote:
>
> I ended up only needing the first combined with `--with-system-flint=no`

can you skip `--with-system-flint=no` with your latest Homebrew's flint 3.1.3 ?

>
> On Tuesday, May 21, 2024 at 9:53:07 AM UTC-4 Kwankyu Lee wrote:
>>
>> You need
>>
>> https://github.com/sagemath/sage/pull/38025
>>
>> and possibly also
>>
>> https://github.com/sagemath/sage/pull/38021
>>
>> On Tuesday, May 21, 2024 at 9:44:30 PM UTC+9 Edgar Costa wrote:
>>>
>>> Hello,
>>>
>>> Does someone has insights how t fix this?
>>> I already told ./configure --with-system-givaro=no and removed my installed 
>>> givaro via homebrew.
>>>
>>> You can find the logs here: 
>>> https://gist.github.com/edgarcosta/32a8dd533cf88b937fa54194da7efe8d
>>> But the main issue is here:
>>> [fflas_ffpack-2.5.0] [spkg-install]   "Givaro::Integer::operator-(long 
>>> long) const", referenced from:
>>> [fflas_ffpack-2.5.0] [spkg-install]   double 
>>> FFLAS::Protected::computeFactorClassic 
>>> >(Givaro::ModularBalanced const&) in ffpack_inst.o
>>> [fflas_ffpack-2.5.0] [spkg-install]   double 
>>> FFLAS::Protected::computeFactorClassic 
>>> >(Givaro::ModularBalanced const&) in ffpack_inst.o
>>> [fflas_ffpack-2.5.0] [spkg-install]   double 
>>> FFLAS::Protected::computeFactorClassic>> void> >(Givaro::Modular const&) in ffpack_inst.o
>>> [fflas_ffpack-2.5.0] [spkg-install]   double 
>>> FFLAS::Protected::computeFactorClassic 
>>> >(Givaro::Modular const&) in ffpack_inst.o
>>> [fflas_ffpack-2.5.0] [spkg-install]   "Givaro::Integer::operator>>(int) 
>>> const", referenced from:
>>> [fflas_ffpack-2.5.0] [spkg-install]   double 
>>> FFLAS::Protected::computeFactorClassic 
>>> >(Givaro::ModularBalanced const&) in ffpack_inst.o
>>> [fflas_ffpack-2.5.0] [spkg-install]   double 
>>> FFLAS::Protected::computeFactorClassic 
>>> >(Givaro::ModularBalanced const&) in ffpack_inst.o
>>> [fflas_ffpack-2.5.0] [spkg-install] ld: symbol(s) not found for 
>>> architecture x86_64
>>>
>>>
>>> Thank you,
>>> Edgar
>>>
>>>
> --
> 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 visit 
> https://groups.google.com/d/msgid/sage-devel/d1f6b536-4312-4e72-92c2-5ad6d38b5f13n%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3mE%3D01K5Rt69b%2BOTwrtg8WGoKduS5uNHfdVfpa5M5vAw%40mail.gmail.com.

Re: [sage-devel] Re: Standard/Recommended practices for adding codes with third-party libraries into Sage codebase?

[Dima Pasechnik]

On Mon, May 20, 2024 at 3:43 AM Matthias Koeppe
 wrote:
>
> On Sunday, May 19, 2024 at 12:53:25 PM UTC-7 Jing Guo wrote:
>
> In the past few months I have been working on a Sage library for counting 
> graph homomorphisms: https://github.com/guojing0/count-graph-homs (It's still 
> updating, hence not 100% complete)
>
> In `concurrent_hom_count.py`, I use third-party libraries, such as `numba`, 
> `dask`, and `numpy`. For numpy, I think it's already in Sage. So I was 
> wondering what would be the standard/best/recommended practices if I want to 
> contribute this code to Sage, which I suppose does not support either `numba` 
> or `dask` (searching in the codebase returns nothing)?
>
>
> It depends on the intended degree of integration into Sage.
> The loosest integration: Prepare it as a pip-installable package (which 
> declares its dependencies using the standard Python packaging practices);  
> then add it as an optional "pip" package to the Sage disitribution.

How exactly is this code using Sage - what are graph Sage-specific
functions used?
Tight integration with Sage would need, in the present Sage distro
model, numbda and dask as its packages, and in particular numba would
be very tricky, as it needs LLVM.

> See Meta-ticket: Add external user packages as optional/experimental packages 
> (https://github.com/sagemath/sage/issues/31164) for examples and pointers to 
> documentation.
>
> --
> 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 visit 
> https://groups.google.com/d/msgid/sage-devel/d29caf89-d6b5-4896-94b1-b4703218e857n%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2ZLpQ-s8eDmwcZUtAccN42UJOYWt_%2B_qJ_v20d8fka4g%40mail.gmail.com.

Re: [sage-devel] Re: approve github actions

[Dima Pasechnik]

On 15 May 2024 02:14:05 BST, David Roe  wrote:
>On Tue, May 14, 2024 at 9:13 PM Dima Pasechnik  wrote:
>
>>
>>
>> On 14 May 2024 22:55:01 BST, "julian...@fsfe.org" 
>> wrote:
>> >I granted "write" permissions to you. That seems to be the required
>> >permission to approve workflow runs.
>>
>> IIRC, such permissions are automatic for the members of triage team.
>>
>
>That's incorrect.  Triage is a lower permission level than Write; see here
><https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization>
>for more details.



"Write" has commit rights beyond doing PRs.
I don't think such permissions are needed to authorise CI runs. AFAIK, any 
member of "triage" can do the latter - unless this recently changed.







>David
>
>Could you check that Martin is there?
>> >
>> >Can you check that it works now?
>> >
>> >julian
>> >
>> >PS: If this should be done differently, please let me know and I'll
>> revoke
>> >that permission again :)
>> >
>> >On Tuesday, May 14, 2024 at 11:55:53 PM UTC+3 axio...@yahoo.de wrote:
>> >
>> >> Could I have the right to approve github actions?
>> >>
>> >> Otherwise, mentoring the GSOC student over github is a pain.
>> >>
>> >> Best wishes,
>> >>
>> >> Martin (mantepse)
>> >>
>> >
>>
>> --
>> 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 visit
>> https://groups.google.com/d/msgid/sage-devel/0F49C387-A1D9-4517-A840-14DFD2A84BA9%40gmail.com
>> .
>>
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/6B1DD841-1773-4E9F-9080-F47340B1B09C%40gmail.com.

Re: [sage-devel] Re: approve github actions

[Dima Pasechnik]

On 14 May 2024 22:55:01 BST, "julian...@fsfe.org"  wrote:
>I granted "write" permissions to you. That seems to be the required 
>permission to approve workflow runs.

IIRC, such permissions are automatic for the members of triage team.
Could you check that Martin is there?
>
>Can you check that it works now?
>
>julian
>
>PS: If this should be done differently, please let me know and I'll revoke 
>that permission again :)
>
>On Tuesday, May 14, 2024 at 11:55:53 PM UTC+3 axio...@yahoo.de wrote:
>
>> Could I have the right to approve github actions?
>>
>> Otherwise, mentoring the GSOC student over github is a pain.
>>
>> Best wishes,
>>
>> Martin (mantepse)
>>
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/0F49C387-A1D9-4517-A840-14DFD2A84BA9%40gmail.com.

Re: [sage-devel] Re: New labels v: mimimal, v: small ... on pull requests

[Dima Pasechnik]

On Tue, May 14, 2024 at 1:48 AM Matthias Koeppe
 wrote:
>
> On Sunday, May 12, 2024 at 6:50:05 PM UTC-7 Travis Scrimshaw wrote:
>
> That model is not how we have worked as a community, nor do I think it is a 
> productive way to run a smaller developer community such as ours.
>
>
> I'm not sure what your reference point may be for this description, but in my 
> experience it has not been remotely like this ever since I started 
> contributing to Sage (2015). The project's infrastructure (in the past, for 
> example Trac or the patchbot) has been run by volunteer administrators; the 
> wiki page https://github.com/sagemath/sage/wiki/Infrastructure is intended to 
> keep track of it (though much info is likely outdated), and there is a closed 
> mailing list "sagemath-admins" for those involved.
>
> Perhaps a good reference: 
> https://www.redhat.com/en/blog/understanding-open-source-governance-models

It does not look Sage clearly fits into one of their types. Anyhow,
RedHat (wholly owned by IBM nowadays) is known to be subverting open
source in general,
and GPL in particular, for years. I would take whatever they write on
this topic with a very big grain of salt, as it might be merely
creating more open-source FUD.
Cf. https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis/

Dima
>
> --
> 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 visit 
> https://groups.google.com/d/msgid/sage-devel/e0c30573-7e4b-4991-a70f-53659d268571n%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3WY66LofuVrA11POVCM7e2E3%2B3JgdLK7D8yzz0dXYt9g%40mail.gmail.com.

Re: [sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On Sunday, May 12, 2024 at 4:42:42 PM UTC+1 Matthias Koeppe wrote:


On Friday, May 10, 2024 at 4:19:14 PM UTC-7 julian...@fsfe.org wrote:

If I read your proposal correctly, it is about removing review from changes 
made by "maintainers" [...]


That's right -- for the specified files.

Mostly, I am opposed to this because changes to the files you list are not 
automatically uncontroversial, see the disputed 
https://github.com/sagemath/sage/pull/37740, 
https://github.com/sagemath/sage/pull/37387, 
https://github.com/sagemath/sage/pull/37351, 
https://github.com/sagemath/sage/pull/36726, 
https://github.com/sagemath/sage/pull/36697, 
https://github.com/sagemath/sage/pull/36694, 
https://github.com/sagemath/sage/pull/36678, (there's probably more.)


Well, my proposal only generally noted that "waiting for reviewers to 
approve a PR and waiting for the Release Manager to merge it adds too much 
delay and friction." But yes, these "disputes" are certainly part of the 
friction that my proposal seeks to eliminate by establishing proper 
governance.

But since you bring it up and list these examples, yes, we can certainly 
have this conversation in more detail.

[...] In general, I am not sure about changing the review requirements. I 
know that having to do several rounds of review can be frustrating. At the 
same time, I like the idea of having somebody double check things. (I 
consider waiting for the first round of review a necessary annoyance. What 
can be really frustrating is waiting for the second round of review. Maybe, 
there are other ways to improve this, e.g., by encouraging people to set 
things to "feel free to set to positive review yourself once you addressed 
these tiny things I brought up in my review.")


I have to note that this description would not be a good starting point for 
a conversation. First of all, it makes me uncomfortable that you are 
sharing generalities about the PR review process, perhaps as if I needed 
advice on this from you; what could be the possible purpose of doing so? 
The topic here is much more specific: namely PRs that make changes to the 
CI. 
But more importantly, you are writing this after having just brought up PRs 
such as "CI Linux: Replace use of pkill" (
https://github.com/sagemath/sage/pull/36726) -- which you as member of the 
sage-conduct committee are familiar with in detail. In this context, 
mentioning something like "waiting for the second round of review" as 
"really frustrating" furthers a mischaracterization of the problem, 
trivializing a very serious matter.


"CI Linux: Replace use of pkill" (
https://github.com/sagemath/sage/pull/36726), more precisely, the 
discussion (the non-flamewar part of it) which went on there,
is an excellent example of CI importance blown out of proportion.

It was argued there that certain "minimal configurations" of packages are 
crucial for Sage development, where in reality no sane users would build 
Sage on such a super-minimal set of packages. These "minimal 
configurations" are kept as an excuse for not slimming down Sage the distro 
to a  more meaningful set of packages, e.g. not including largely useless 
parts such as the gcc compiler.

If, as proposed, the governance of the CI part of the Sage the distro is 
getting split off from Sage the distro, but kept inside Sage proper,
it will only make CI more dominant, not less, and lead to more disputes, 
not less. The CI should be, basically, a downstream 
quality assurance tool, not the means in itself. It should not dictate what 
packages Sage should or should not vendor, and what versions
of Python etc Sage must support.

Dima
  


 


-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/206a5801-dda8-4857-b0ff-3fc915490847n%40googlegroups.com.

Re: [sage-devel] Re: New labels v: mimimal, v: small ... on pull requests

[Dima Pasechnik]

On 9 May 2024 22:46:17 BST, Travis Scrimshaw  wrote:
>I am *very* strongly opposed to these tags. Their cutoffs are arbitrary nor 
>they serve no useful purpose as far as I can tell. To this point, they do 
>not reflect the difficulty of a review; in fact, they are at best 
>counterproductive to finding reviewers because it might deter people from 
>reviewing "large" or "huge" changes as they can include lots of trivial 
>doctest changes. At best it is just additional clutter in all of the 
>information for PRs.

It's also discouraging word, "minimal" - you do a "minimal" PR like 

- which potentially implies that we have thousands of missing "volatile" 
declarations in Cython code interfacing libgap, libsingular, and other 
libraries using setjmp/longjmp mechanics to gracefully process errors.


>
>From a community perspective, I feel such changes should have been brought 
>to the attention of sage-devel once the PR was at a positive review. 
>Specifically, *before* the PR was merged. Not everyone has time to read 
>every PR, and a small consensus of developers might not reflect the 
>development community at-large when making changes like this.
>
>Best,
>Travis
>
>
>On Tuesday, May 7, 2024 at 3:12:27 PM UTC+9 seb@gmail.com wrote:
>
>> Dear Sage developers,
>>
>> You may have noticed that since yesterday a new type of labels with the 
>> `v:` prefix has appeared on our PRs. These are automatically set to 
>> classify PRs based on their size. For more information, see #37262 
>> .
>>
>> Sebastian
>>
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/A5AA8226-A33F-46DA-AE56-4B66A014930F%40gmail.com.

Re: [sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

I've already said while the previous version of this was discussed, is
that it's a huge mess to have different commit rights for different
parts of the tree, and I proposed to spin the CI into a separate
repository, as an alternative which simplifies a lot of things.

Dima


On Wed, May 8, 2024 at 7:25 PM Matthias Koeppe  wrote:
>
> On Monday, May 6, 2024 at 10:49:07 PM UTC-7 Kwankyu Lee wrote:
>
> I propose a governance change for a small part of the main Sage repository:
> 1. The directories .ci, .devcontainer, .github/workflows. [...]
> 2. The file tox.ini. [...]
>
> 3. The file src/doc/en/developer/portability_platform_table.rst (which I 
> update using "tox -e update_docker_platforms").
>
>
> I think we should restrict the scope to the files and directories strictly in 
> the CI infrastructure.  Anything under `src/` should be excluded.
>
>
> This file src/doc/en/developer/portability_platform_table.rst is part of the 
> documentation of the CI infrastructure and needs to be updated (by script) 
> whenever I make changes to the tested platforms.
>
>
>
> Proposed change: All changes to these files are made through PRs. When the PR 
> is ready, a developer in the Maintainer role directly merges the PR into the 
> "develop" branch. In other words, switch to the "Show" model for these 
> changes.
>
>
> I fear that developers in the Maintainer role could conflict in making 
> changes to the CI-related files, as we suffered in the disputed PRs.
>
>
> I don't share this concern.
>
> By the way, I documented who is currently in the Maintainer role when I 
> prepared the NumFOCUS application last month, see 
> https://github.com/sagemath/sage/wiki/NumFOCUS#q13new-please-list-your-projects-maintainers-ie-anyone-with-write-access-to-the-repository
> (I haven't checked if it has changed since.)
>
> There's certainly a broader governance discussion that we should have at some 
> point (regarding duties and appointment procedures for the Maintainer role, 
> the Triage team, and other functions in the project), but I would suggest to 
> do this in a separate thread.
>
> So I suggest to have only one Maintainer for those files. As we acknowledge a 
> certain dictatorship of the release manager, we may have a vote to elect the 
> CI manager and give him/her a restricted dictatorship and responsibility.
>
>
> This model would also work for me, but I think it's unnecessarily specific.
>
> --
> 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 visit 
> https://groups.google.com/d/msgid/sage-devel/e955c1d9-96f5-495d-85a9-9267f5414d3dn%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3h3f0G4JFxwFt02A%3D55xOLeDcNggWkjfUhWH8SRC3PPA%40mail.gmail.com.

[sage-devel] Re: testing optional packages

[Dima Pasechnik]

As I already told Marc, one should use "pytest" rather than "sage -t" - for 
obvious reasons: Sage has very own testing system,
and one should not expect it to be able to test non-Sage code. 

On Monday, April 29, 2024 at 1:08:01 PM UTC+1 Marc Culler wrote:

> I don't know what the expectations are for testing optional packages, but 
> in 10.4.beta4 when I run:
>
> ./sage -t venv/lib/python3.11/site-packages/symengine
>
> I get the exception:
>
> NameError: name 'test_sage_conversions' is not defined
>
> - Marc
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/2b7b37d7-df3c-4288-91f6-0f055c5d3b25n%40googlegroups.com.

Re: [sage-devel] Re: wasm

[Dima Pasechnik]

It's interesting to compare this with the development by cocalc people, cowasm 


Perhaps William can explain the differences.


On 30 April 2024 18:00:26 BST, Matthias Koeppe  wrote:
>Hi Doris,
>porting Sage to pyodide is in progress, see 
>https://github.com/sagemath/sage/issues/34539, but it's not ready to be 
>used for what you have in mind. 
>I second Oscar's suggestion to look into using *sympy* and/or *python-flint*
>.
>
>The current status of the Sage pyodide port:
>- Some key dependencies of Sage will be shipped with the next pyodide 
>release (0.26): *ipython*, *cysignals*, *ppl*/*pplpy*, *flint*, 
>*memory_allocator*
>- https://github.com/pyodide/pyodide/pull/4438 provides the fundamental 
>modularized distribution packages *sagemath-objects*, *sagemath-categories*, 
>*sagemath-environment*, *sagemath-repl*
>
>The current bottlenecks / next steps:
>- *pari*, *cypari2* (https://github.com/pyodide/pyodide/pull/4430; help 
>wanted)
>- Adding the modularized distribution packages that provide more parts of 
>Sage, in particular *sagemath-pari* and *sagemath-flint*: 
>https://github.com/sagemath/sage/pull/37900, 
>https://github.com/sagemath/sage/pull/37901 
>(needs review)
>
>Matthias
>
>On Tuesday, April 30, 2024 at 12:29:35 AM UTC-7 Doris Behrendt wrote:
>
>> Hi all,
>>
>> My team is about to develop a webapp where we want to factor polynomials 
>> with coefficients in ZZ.
>> We want to offer a dropdown menu where the user can select the base ring 
>> and then the factorisation changes interactively. We use React and 
>> JavaScript and also Web Assembly, e.g. for our Web-OpenSSL here: 
>> https://www.cryptool.org/en/cto/openssl/
>>
>> Sage offers the command change_ring, we did not find a JavaScript Library 
>> that has this functionality. So I thought, perhaps we could look for 
>> solutions where Sage is used together with web assembly.
>>
>> After some research I have the impression that there are some proofs of 
>> concept, but there is nothing actively developed?
>>
>> Since I am not a programmer and nobody in my team is a mathematician (so 
>> my developers don't know Sage), I kindly ask on this list for any hints how 
>> we could proceed?
>>
>> Thanks in advance
>> Doris
>
>-- 
>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 visit 
>https://groups.google.com/d/msgid/sage-devel/91eec8d3-9173-46f7-9d64-4362598ee8f8n%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/1E6E3EC4-78B2-46AA-A624-3EAB823A022E%40gmail.com.

Re: [sage-devel] Incorrect result for `sum(1/factorial(n**2),n,1,oo)`

[Dima Pasechnik]

On Fri, Apr 26, 2024 at 2:24 PM Georgi Guninski  wrote:
>
> On Thu, Feb 15, 2024 at 2:27 AM Dima Pasechnik  wrote:
> >
> > I've filed https://sourceforge.net/p/maxima/bugs/4262/
> >
>
> Is maxima supported?
> There is no progress on their bug system for more than 2 months.

not many people are involved, and some bugs stay open for years there.


> SEGV is not pleasant, but incorrect symbolic result casts doubts about
> all symbolic sage computations, especially those that can't be
> verified numerically.
>
> --
> 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 visit 
> https://groups.google.com/d/msgid/sage-devel/CAGUWgD_MWht0_wBwXXsH-c%3DpKGSXUCgNBEbKq4PyLRc3g5k%3D_Q%40mail.gmail.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0mzJCU2MOhgGFKZCfwNtMU0J3cuOmddWxGY6dEqqi9PA%40mail.gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Dima Pasechnik]

On Thu, Apr 25, 2024 at 4:36 PM  wrote:
>
> On Thu, Apr 25, 2024 at 07:03:29AM -0700, Marc Culler wrote:
> > On Thursday, April 25, 2024 at 8:28:48 AM UTC-5 Dima Pasechnik wrote:
> >
> > Essential components of sagelib such as GAP, Singular, don't run on
> > native Windows
> >
> >
> > I was amused to find the following statement on the GAP forum
> > <https://www.gap-system.org/ForumArchive2/2005/000999.html> from 2005:

you might also like to know that in 2000 I asked whether we can have libgap :P
https://www.gap-system.org/ForumArchive/Pasechni.1/Dmitrii.1/using_GA.1/1.html

my 1st message to GAP Forum was sent in 1993:
https://www.gap-system.org/ForumArchive/Pasechni.1/Dmitrii.1/Re__brea.1/1.html


> >
> >   >  While porting GAP to use native Win32 calls is doable, basically
> > src/system.c is the only place
> >> that needs lots of changes, it is certainly a nontrivial and
> > time-consuming task. (and one needs
> >> to be a bit of an expert in programming to do this, IMHO)
> >
> > The author was someone from the Netherlands by the name of *Dima
> > Pasechnik.  :^)*
>
> It was me, yes. And I used to know from what end
> you have to approach a Windows machine. :-)
> But not to the point of knowing exactly how to change fork() and sbrk(),
> (and mmap()) into whatever functions with 15 arguments you have to use
> on Win32 as their replacements (they already have about 10 versions of
> spawn to use in place of fork).
>
> Note that since 2005 GAP has changed quite a bit, too.
> They made a go at making it multithreaded (HPC GAP), and that made code
> harder to deal with (HPC GAP is still beta).
> Instead of GAP's native GC (with its sbrk/mmap), HPC GAP uses Boehm GC, which 
> does run on native
> Windows. But it's a beta...
>
> Oh, and someone died porting GAP to Windows, some years ago.
>
> Dima
>
>
> >
> > - Marc
> >
> > --
> > 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 visit 
> > https://groups.google.com/d/msgid/sage-devel/b0784b4b-ab38-4ff7-b5f7-d9cc47472b95n%40googlegroups.com.
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq04q_KqiW_qEvPFRrqaHyC1Bf-a%3D1r1_bN3Lt0G61DqiA%40mail.gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Dima Pasechnik]

On 25 April 2024 14:47:35 BST, Marc Culler  wrote:
>On Thu, Apr 25, 2024 at 8:28 AM Dima Pasechnik  wrote:
>
>> On Thu, Apr 25, 2024 at 1:28 PM Nathan Dunfield 
>> wrote:
>> >
>> > On Wednesday, April 24, 2024 at 10:14:09 PM UTC-5 Matthias Koeppe wrote:
>> >
>> > Yes, native Windows would clearly be a very important target.
>> >
>> >
>> > As a data point, downloads of our stand-alone SnapPy app, which is about
>> as high level pure math as it gets, are 60% higher for Windows than macOS.
>>
>> That's not for native Windows, that's for WSL, right?
>>
>
>Wrong!  SnapPy runs as a native Windows app.
>
>We build Pari with msys2 and mingw on a CI runner.
>
>Essential components of sagelib such as GAP, Singular, don't run on
>> native Windows (on Cygwin, yes, but
>> we know by now, Cygwin is too flaky for Sage to work) and I don't
>> think anyone is keen on
>> doing the hard work to port it.
>>
>
>Msys2 and mingw are not so flaky, and use more or less the same toolchain
>as Cygwin.  There are many ports of gnu libraries to msys2 which can be
>installed with their package manage (pacman).  I am not convinced that GAP,
>Singuler, etc. could not be built with mingw.

E.g. GAP uses sbrk, fork (which are not in msys2/mingw), you'll need to port 
their GC too.
Doable, but very, very far from easy.



>
>- Marc
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/E442AC03-90B9-4167-81F4-AB0E9E3C20AE%40gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Dima Pasechnik]

On Thu, Apr 25, 2024 at 1:28 PM Nathan Dunfield  wrote:
>
> On Wednesday, April 24, 2024 at 10:14:09 PM UTC-5 Matthias Koeppe wrote:
>
> Yes, native Windows would clearly be a very important target.
>
>
> As a data point, downloads of our stand-alone SnapPy app, which is about as 
> high level pure math as it gets, are 60% higher for Windows than macOS.

That's not for native Windows, that's for WSL, right?

Essential components of sagelib such as GAP, Singular, don't run on
native Windows (on Cygwin, yes, but
we know by now, Cygwin is too flaky for Sage to work) and I don't
think anyone is keen on
doing the hard work to port it.

This puts native  Windows  support into the area of wishful thinking.

 Dima

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3P-zGuoT%2B2x96oFBNeDCh%3DEzqmn9WgTGhPmH2akPp%3DcA%40mail.gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Dima Pasechnik]

On Wed, Apr 24, 2024 at 9:29 PM Nathan Dunfield  wrote:
>
> On Wednesday, April 24, 2024 at 2:26:37 PM UTC-5 Oscar Benjamin wrote:
>
> Thanks Marc. This seems like a good example of a useful part of Sage
> that can be extracted to something much smaller than Sage.
>
> Presumably though a hypothetical person who wants CyPari2 but not all
> of Sage can already just use CyPari so that person is already well
> served.
>
>
> Correct.
>
>
> Is the plan that CyPari2 would effectively replace CyPari? Then the benefit 
> is not needing to maintain CyPari separately from
> sagelib's CyPari2 dependency?
>
>
> No, rather CyPari is an example of the sort of free-standing Python package 
> that could be extracted from Sage.  Modularization would create more of 
> these, in varying sizes and levels of granularity.
>
> Some level of modularization is necessary to address what William Stein 
> described last year as:
>
> The fundamental and massive problem that I think SageMath has is that it is 
> not part of the  Python ecosystem,
> by which I mean that there is no good way to do "pip install sagemath-[foo]", 
> in sufficient generality.
>
> PROBLEM: SageMath is not part of the Python ecosystem.
>
> DEFINITION: A piece of software is part of the Python ecosystem, if you can 
> do "pip install " on
> basically the same platforms as the intersection of where you can install 
> scipy/numpy/matplotlib/pandas,
> and with somewhat comparable resource usage (i.e., installing Sagemath can't 
> use 100x of the time/space of
> the above, as that would be unfair).
>
> On a related note, the reason that CyPari2 and CyPari are still separate 
> relates to what Marc mentioned earlier about tension between two models of 
> installing software: the "Linux distro way" using a system-level package 
> manager (where there is typically only one version of any given library on 
> the system) and the "Python pip" way (where all needed libraries are 
> statically linked into the wheel).  CyPari2 follows the first, CyPari the 
> second.  (This story is further complicated by the fact that, from a user's 
> perspective, conda is like "Python pip" in that it is orthogonal to any 
> system libraries, but developing packages for conda is akin to building them 
> for a Linux distro.)

There isn't a big problem to set up a GitHub wheel builder for
CyPari2, so  there is not really a sea of difference here in this
sense.

Also, probably it should be mentioned that linux distro way/pip way
can be very nicely combined  using a python venv.
So one can use system packages, but add up more packages, and, if
needed, override system packages with other versions.


>
> Of course, most projects in the scientific Python community support both 
> models, but there is technical overhead in doing so, which I believe is the 
> root of some of the current conflict.
>
> Best,
>
> Nathan
>
> --
> 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 visit 
> https://groups.google.com/d/msgid/sage-devel/60a60056-f8e9-417e-b03a-1dcfcbc3c6ebn%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0oqXa1J4pJM78Mk8pb0YCyKMQfmFyp-NdpXQS6Yy_dRA%40mail.gmail.com.

Re: [sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

[Dima Pasechnik]

On Wed, Apr 24, 2024 at 2:11 PM Marc Culler  wrote:
>
> On Wednesday, April 24, 2024 at 8:05:15 AM UTC-5 Dima Pasechnik wrote:
>
> running Cython in sage prompt or in Sage Jupyter notebook has nothing
> to do with -i option.
>
>
> I realize that.  But it looked to me like those variables are being set in 
> the sage-env script *primarily* to support sage -i.  Perhaps you are right 
> that it is *primarily* to support compiling cython, but it doesn't look like 
> it to me.  In any case, on macOS the default vaues work fine.

sage -i actually calls make, on a makefile where everything is already
set up. So no, it's not for sage -i.
>
> - Marc
>
> --
> 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 visit 
> https://groups.google.com/d/msgid/sage-devel/9d670ddb-ba2d-4c60-9fc2-5b0c1c209e3cn%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3dEnrcBWkzii%3DLh82%3DA0h85oYaUeO%3DDxQPu89An6F94g%40mail.gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Dima Pasechnik]

On Wed, Apr 24, 2024 at 3:37 PM Marc Culler  wrote:
>
> I think that CyPari ;and CyPari2 provide a relevant example.
>
> Some background ... CyPari is a PyPi package with binary wheels which 
> predates and was the starting point for Sage's cypari2 (hence the 2 in the 
> name).   The basis for CyPari was Sage's pari module.  That module was 
> modified to make it independent from the rest of Sage so that Sage's Pari 
> support could be provided as a component of SnapPy. Binary wheels for CyPari 
> are available for Windows, macOS and manylinux.  The current versions of 
> those wheels are statically linked against Pari 2.15.4
>
> The binary wheel for CyPari weighs in at 7MB.  Sage's CyPari2 is available as 
> a binay wheel for macOS and manylinux and the size is of the same order of 
> magnitude.  When they are unpacked and installed the sizes of these python 
> packages are respectively 19MB and 7.5MB (cypari2 is linked against the 
> dynamic libraries libgmp and libpari, which together are about 12MB and which 
> are external to the python package).  A full Sage installation is about 5 
> gigabytes.  With some significant omissions and compression of the 
> documentation, the macOS app squeezes that down to 3.4GB.
>
> So the size of this one significant self-contained component of sage is about 
> 200 times smaller than the full sage installation and it could be made 
> installable on Windows with some additional work which has already been done 
> for a very closely related package.

cypari2 is indeed self-contained (with libpari and libgmp added to the
count), and provides a Pari-Python interface.
This full installation takes about 35 Mb. But it's not a relevant
example, cause it's a very limited functionality.

This is unlike sagemath-graphs, etc, which are, as I wrote, very far
from being self-contained. Many of them, with all of its dependencies
installed, will be blow up to a good half of the whole Sage, if not
more.
So there are no 1%  savings on bandwidth here, more like 30%-50%, or less.

Dima
>
> - Marc
>
>
> On Wed, Apr 24, 2024 at 8:48 AM Oscar Benjamin  
> wrote:
>>
>> On Tue, 23 Apr 2024 at 15:27, Marc Culler  wrote:
>> >
>> > The projects that will really benefit from modularization will be those 
>> > that provide their own limited mathematical context.  Developers of such 
>> > projects will be able to choose which parts of Sage are relevant to their 
>> > specific context.  Those parts of Sage can be provided for their users 
>> > without having to embed a huge monolithic environment into a relatively 
>> > small project.
>>
>> Is the benefit in this case mainly about reduced disk/network usage?
>>
>> I could imagine other theoretical benefits like maybe some parts could
>> be installed natively on Windows or some parts might be easier to
>> provide binaries for etc.
>>
>> Are there any indicative numbers for what the size would be when
>> installing some useful portion of Sage vs installing the whole of
>> Sage?
>>
>> --
>> Oscar
>>
>> --
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "sage-devel" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/sage-devel/mqgtkLr2gXY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> sage-devel+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/CAHVvXxQUanPY%3D1svhf7Q8xDFD5BroD9wTLRc1-wmFC3vQhBMRg%40mail.gmail.com.
>
> --
> 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 visit 
> https://groups.google.com/d/msgid/sage-devel/CALcZXREFctqVF8Hr1B%2Bmz9WfhV9Dspop5EmWN7Q%2BsYdJLvnh4w%40mail.gmail.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2PGYDXTUP-1uCsSefDTKr45QFNbLQOk9%3Dgsx6EBzF9QQ%40mail.gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Dima Pasechnik]

On Wed, Apr 24, 2024 at 2:08 PM Kwankyu Lee  wrote:
>
> Wouldn't people in the python world who need a serious amount of math know of 
> sage anyway, and then, if they cannot rely on all of sage because that is too 
> large, use, for example, `citation.get_systems` to see whether they can do 
> without some dependencies?
>
>
>  I think they would do `pip install sagemath-graphs` if they need graphs 
> functionality.
"Too large" is relative. What was "too large" few years ago is normal
now, and RAM only gets cheaper, and 32-bit systems
get irrelevant.

And they'd be often quite unhappy, as e.g. basically nothing in
src/sage/graphs/generators/classical_geometries.py
will work without sage.rings or GAP.
Many other parts of sage.graphs use things in sage.combinat, as well
as cliquer, bliss/nauty, etc.

Dima

>
> --
> 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 visit 
> https://groups.google.com/d/msgid/sage-devel/8dd2c1ce-7811-4ada-94cc-075d5b6ab93bn%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2sRJSntR33W5%3DQOo4rZH_AN0aOkTC%2BoKwAuHY1t6htOQ%40mail.gmail.com.

Re: [sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

[Dima Pasechnik]

On Wed, Apr 24, 2024 at 4:45 AM Marc Culler  wrote:
>
> That was it!
>
> Thank you Gonzalo; indeed, it helps a lot.  And your workaround is fine, 
> since we don't support the -i option,

running Cython in sage prompt or in Sage Jupyter notebook has nothing
to do with -i option. One can call cythonize
in a regular Sage session (see, it builds a .so in /tmp):

sage: from sage.misc.cython import compile_and_load
sage: module = compile_and_load("def f(int n):\nreturn n*n")
sage: module.f(10)
100
sage: module




> Even if we did, the default names for as, ld and ar are correct whenever the 
> command line tools are installed.  So that block of code is completely 
> irrelevant for the macOS platform.  This solves the problem.

Anyway, instead of calling these all the time (this was done in
https://github.com/sagemath/sage/issues/14296)
we can let ./configure to fill in @AS@, @LD@, etc templates in
build/bin/sage-build-env-config.in, and having the corresponding env.
vars.
initialised in build/bin/sage-build-env-config(.in).

Dima

>
> - Marc
>
>
>
> On Tuesday, April 23, 2024 at 8:59:12 PM UTC-5 Gonzalo Tornaría wrote:
>>
>> https://github.com/sagemath/sage/blob/develop/src/bin/sage-env#L482 and L494
>>
>> See: https://github.com/sagemath/sage/issues/14296 and 
>> https://github.com/sagemath/sage/commit/69213d74ead4e93687cf61f214b0d96dd3f9885a
>>
>> Maybe you can workaround this by setting AS=as and LD=ld in sage-env-config.
>>
>> HTH,
>> Gonzalo
>>
>>
>> On Tuesday, April 23, 2024 at 3:48:18 PM UTC-3 Marc Culler wrote:
>>>
>>> I discovered, by installing the Sage_macOS app on a pristine macOS system, 
>>> that somehow, somewhere, in Sage's startup sequence there is a call to gcc. 
>>>  This is true whether Sage is being started from a command line or a 
>>> notebook.
>>>
>>> On such a macOS system /usr/bin/gcc exists, but calling it causes a dialog 
>>> to be posted which asks whether to download and install the Xcode "command 
>>> line tools".
>>>
>>> There is no need for a user to install, or be prompted to install, a C 
>>> compiler in order to run Sage.  If we want to verify whether a C compiler 
>>> is installed on the host system then we should check the return value of 
>>> xcode-select -p rather than calling /usr/bin/gcc.
>>>
>>> I am unable to find where this call occurs.  Do any of the Sage developers 
>>> know which component of Sage could be calling /usr/bin/gcc on start up?
>>>
>>> - Marc
>
> --
> 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 visit 
> https://groups.google.com/d/msgid/sage-devel/1fe1fca2-f228-45eb-9f43-a1d1be5d5895n%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2mdRtbkp4FKPob2eKn-tXku0AV99mLPNvtD31Lg-0JHw%40mail.gmail.com.

Re: [sage-devel] Question: why does /usr/bin/gcc get called during Sage startup?

[Dima Pasechnik]

On 23 April 2024 19:48:18 BST, Marc Culler  wrote:
>I discovered, by installing the Sage_macOS app on a pristine macOS system, 
>that somehow, somewhere, in Sage's startup sequence there is a call to 
>gcc.  This is true whether Sage is being started from a command line or a 
>notebook.
>
>On such a macOS system /usr/bin/gcc exists, but calling it causes a dialog 
>to be posted which asks whether to download and install the Xcode "command 
>line tools".
>
>There is no need for a user to install, or be prompted to install, a C 
>compiler in order to run Sage.  If we want to verify whether a C compiler 
>is installed on the host system then we should check the return value of 
>xcode-select 
>-p rather than calling /usr/bin/gcc.
>
>I am unable to find where this call occurs.  Do any of the Sage developers 
>know which component of Sage could be calling /usr/bin/gcc on start up?

It's not quite correct to say that a C, or other, compiler is not required to 
run Sage. Sage allows you to define, build, load, and run Cython extensions 
without leaving Sage, thus, it needs to call a compiler after cythonisation 
step.

It's another question why it's called on startup.
Might be macOS - only ?

Dima

>
>- Marc
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/196ECB9F-6E79-4FEB-A928-9C20BCF7F673%40gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Dima Pasechnik]

On 23 April 2024 19:13:44 BST, Matthias Koeppe  wrote:
>On Tuesday, April 23, 2024 at 11:06:12 AM UTC-7 Dima Pasechnik wrote:
>
>
>
>On 23 April 2024 18:41:34 BST, Matthias Koeppe  
>wrote: 
>>*$ git blame src/sage/combinat//designs/block_design.py* 
>> 
>>fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 65) 
>>lazy_import('sage.libs.gap.libgap', 'libgap') 
>>fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 66) 
>>lazy_import('sage.matrix.matrix_space', 'MatrixSpace') 
>>fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 67) 
>>lazy_import('sage.modules.free_module', 'VectorSpace') 
>>fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 68) 
>>lazy_import('sage.rings.finite_rings.finite_field_constructor', 
>>'FiniteField') 
>> 
>>What you see there is the result of work in the modularization project, 
>>using one of the techniques documented 
>>in 
>https://doc.sagemath.org/html/en/developer/packaging_sage_library.html#dependencies-and-distribution-packages
> 
>>("Reducing module-level run-time dependencies:") to reduce dependencies or 
>>to make dependencies milder. 
>
>The problem is that without these imports, lazy or not, this module is 
>basically useless.
>
>
>That's correct, but that's not a "problem". 

It is a problem, because such a module doesn't do what is says on the label.
Basically such a module is a semi-random part of sagelib, and it would not be 
fully functional until one installs a good chunk, probably well over half, of 
sagelib.

I am not saying it is totally useless, this sort of partition, but I don't see 
the point of distributing such  pieces, as Python wheels, as something useful 
on their own.

Application builders - who, according to Marc, are the only ones to get 
benefits from this design - can just as well build the needed part of sagelib 
from source, they don't need these barely useful wheels.



>
>It's part of a deliberate design, explained in detail in my 2023-06 
>sage-devel posts. 
>
>From "*Modularization project: IV. The rules*" 
>(https://groups.google.com/g/sage-devel/c/ozh-7ZZ848s):
>*3.* Distribution packages declare build dependencies and runtime 
>dependencies 
><https://sagemath-tobias.netlify.app/developer/packaging_sage_library.html#dependencies-and-distribution-packages>
> (on 
>other Python distribution packages). These two can be entirely unrelated to 
>each other. In addition to the runtime dependencies, it is possible to 
>declare extra dependencies – either those necessary for running tests 
><https://sagemath-tobias.netlify.app/developer/packaging_sage_library.html#doctest-only-dependencies>
> or 
>for providing advertised  
><https://sagemath-tobias.netlify.app/developer/packaging_sage_library.html#other-runtime-dependencies>
>extra  
><https://sagemath-tobias.netlify.app/developer/packaging_sage_library.html#other-runtime-dependencies>
>features 
><https://sagemath-tobias.netlify.app/developer/packaging_sage_library.html#other-runtime-dependencies>.
> 
>But there is no such thing as an "optional build dependency" or 
>"conditional compilation". The set of modules that form a distribution 
>package is static. There is no place in the name (or metadata) of a wheel 
>package that could indicate different "configurations".
>
>*4. *As a result of 3, it is possible to create distributions that contain 
>some modules that cannot be imported because some of their dependencies are 
>missing. That's OK; they can become importable simply by the presence of 
>other distributions, in particular those declared as extra dependencies. 
>All of this is discovered at the time of importing a module; there is no 
>ahead-of-time linking step of any sort.
>
>From "*Modularization project: V. The blocs*" 
>(https://groups.google.com/g/sage-devel/c/kiB32zP3xD4):
>*We should not attempt to define a distribution package for every possible 
>community or subfield of mathematics that Sage supports.*
>The proposed design instead introduces 3 types of distribution packages: 
>[...]
>Each of the distribution packages can define a list of extras (nicknames 
>for sets of other distribution packages that provide additional advertised 
>features). When using pip to install a distribution, users can use square 
>bracket notation to add (adjoin?) these extras.
>
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/6AAFD6C9-15B8-4ED2-AE2E-C1CFAE675165%40gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Dima Pasechnik]

On 23 April 2024 18:41:34 BST, Matthias Koeppe  wrote:
>On Tuesday, April 23, 2024 at 10:32:22 AM UTC-7 Dima Pasechnik wrote:
>
>in 
>src/sage/combinat//designs/block_design.py 
>
>you can see 
>
>lazy_import('sage.libs.gap.libgap', 'libgap') 
>lazy_import('sage.rings.finite_rings.finite_field_constructor', 
>'FiniteField')
>
>
>*$ git blame src/sage/combinat//designs/block_design.py*
>
>fdbe7f7e3348 (Matthias Koeppe2023-07-12 10:53:08 -0700   65) 
>lazy_import('sage.libs.gap.libgap', 'libgap')
>fdbe7f7e3348 (Matthias Koeppe2023-07-12 10:53:08 -0700   66) 
>lazy_import('sage.matrix.matrix_space', 'MatrixSpace')
>fdbe7f7e3348 (Matthias Koeppe2023-07-12 10:53:08 -0700   67) 
>lazy_import('sage.modules.free_module', 'VectorSpace')
>fdbe7f7e3348 (Matthias Koeppe2023-07-12 10:53:08 -0700   68) 
>lazy_import('sage.rings.finite_rings.finite_field_constructor', 
>'FiniteField')
>
>What you see there is the result of work in the modularization project, 
>using one of the techniques documented 
>in 
>https://doc.sagemath.org/html/en/developer/packaging_sage_library.html#dependencies-and-distribution-packages
> 
>("Reducing module-level run-time dependencies:") to reduce dependencies or 
>to make dependencies milder.


The problem is that without these imports, lazy or not, this module is 
basically useless.


>
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/1EA68E6E-0DC2-4D94-8C6A-39ABF3203436%40gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Dima Pasechnik]

On Tue, Apr 23, 2024 at 3:31 PM Matthias Koeppe
 wrote:
>
> On Tuesday, April 23, 2024 at 6:14:05 AM UTC-7 Dima Pasechnik wrote:
>
> On Sun, Apr 21, 2024 at 10:42 PM Matthias Koeppe  wrote:
>
> Let's just go through the list of distribution packages and their 
> dependencies for concreteness. (All depend on sagemath-categories and thus on 
> the basic arithmetic libraries gmp, mpc, mpfr, gmpy2)
>
>
> these are seemingly incomplete:
>
>
> What makes that seem to you?
>
>
> sagemath-combinat
> - non-Python dependency: symmetrica 
> (https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-combinat/pyproject.toml.m4#L65)
>
> non-python: depends on GAP, givaro, too
>
>
> No. Your source?
in

src/sage/combinat//designs/block_design.py

you can see

lazy_import('sage.libs.gap.libgap', 'libgap')
lazy_import('sage.rings.finite_rings.finite_field_constructor', 'FiniteField')


>
>
>
>
> sagemath-graphs
> - non-Python dependency: boost 
> (https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-graphs/pyproject.toml.m4#L73)
>
>
> non-python:  depends on GAP, givaro, too
>
>
> No. Source?

similar to the above

>
>
> sagemath-modules
> - non-Python dependency: gsl 
> (https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-modules/pyproject.toml.m4#L109)
> - Python build requirement: numpy
>
>
> non-python: linbox, flas_ffpac, too ?
>
>
> No. Source?

same as above, basically

These modules don't function in any meaningful way without
dependencies I listed.

Dima
>
> --
> 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 visit 
> https://groups.google.com/d/msgid/sage-devel/f54a1d55-b7c2-47a8-9245-d470a63091fan%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2AzRpc-fvxSki%3Dg8P%3D%2B%3DExWqidb%3Dtcm7DrzLmY2W89Qw%40mail.gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Dima Pasechnik]

On Sun, Apr 21, 2024 at 10:42 PM Matthias Koeppe 
wrote:

> On Sunday, April 21, 2024 at 2:30:15 AM UTC-7 Martin R wrote:
>
> Why would you separate mathematics into packages that have no more
> external dependencies from others, which at the same time may grow internal
> dependencies over time?
>
>
> Let's just go through the list of distribution packages and their
> dependencies for concreteness. (All depend on *sagemath-categories* and
> thus on the basic arithmetic libraries gmp, mpc, mpfr, gmpy2)
>

these are seemingly incomplete:

>
> *sagemath-combinat*
> - non-Python dependency: *symmetrica* (
> https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-combinat/pyproject.toml.m4#L65
> )
>
> non-python: depends on GAP, givaro, too


> *sagemath-graphs*
> - non-Python dependency: *boost *(
> https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-graphs/pyproject.toml.m4#L73
> )
>

non-python:  depends on GAP, givaro, too


>
> *sagemath-modules*
> - non-Python dependency: *gsl* (
> https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-modules/pyproject.toml.m4#L109
> )
> - Python build requirement: *numpy*
>

non-python: linbox, flas_ffpac, too ?


> *sagemath-groups*
> - non-Python dependency (via *sagemath-gap*): *gap* (
> https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-gap/pyproject.toml.m4#L52
> *)*
> - non-Python dependency (via *sagemath-modules*): *gsl* (see above)
>
> *sagemath-polyhedra*
> - non-Python dependency (via *sagemath-glpk*): *glpk*
> - non-Python dependency (via *sagemath-modules*): *gsl* (see above)
> - Python runtime dependency: *pplpy*
>
> *sagemath-schemes*
> - non-Python dependency (via *sagemath-modules*): *gsl* (see above)
> - non-Python dependencies (via *sagemath-singular*, *sagemath-flint*,
> *sagemath-ntl*, *sagemath-pari*): singular, flint, ntl, pari (
> https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-pari/pyproject.toml.m4#L61
> )
> - Python dependency (via *sagemath-singular*, *sagemath-flint*,
> *sagemath-pari*): *cypari2*
> - Python dependency: *scipy*
>
> *sagemath-symbolics*
> - non-Python dependencies: *ecl*, *maxima*, *singular*
> https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-symbolics/pyproject.toml.m4#L89
> - non-Python dependencies (via *sagemath-flint*, *sagemath-ntl*,
> *sagemath-modules*): *flint*, *ntl*, *pari*, *gsl*
> - Python dependencies: *mpmath*, *sympy*, *cypari2, numpy*
>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/41d11d3f-d5e5-4bf5-9629-2ef17ce4d6b1n%40googlegroups.com
> 
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2NxJYaqQBfVrZTkUproapZNH7_Ci%3DZjnZVV0vXFCBdqw%40mail.gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Dima Pasechnik]

On 20 April 2024 19:34:49 BST, Matthias Koeppe  wrote:
>On Saturday, April 20, 2024 at 12:56:30 AM UTC-7 Martin R wrote:
>
>do I understand correctly that common lisp (via maxima) is the main 
>dependency that prevents sagemath from being pip-installable?
>
>
>No.
>
>For one, SageMath is already pip-installable. 
>That was one of the first deliverables of the modularization project, 
>completed in 2021.
>See 
>https://wiki.sagemath.org/ReleaseTours/sage-9.4#Alternative_installation_methods_using_pip
>
>It's documented in our README: 
>https://github.com/sagemath/sage/blob/develop/README.md#alternative-installation-using-pypi
>
>However, installing Sage in this way is equivalent to installing the full 
>Sage distribution from source in the normal way.

No, it is not equivalent, far from it. One can read on


 Building sagemath-standard has a large number ofsystem packages as 
prerequisites. See 
https://doc.sagemath.org/html/en/installation/source.html#linux-recommended-installation
 for partial lists for various systems.

That is, many packages are not built. What's being built is not a Sage 
distribution, it is sagelib.


> (This is 
>what https://pypi.org/project/sage-conf/ does.)
>It takes very long. This alone makes it simply not suitable as a dependency 
>of other pip-installable projects.
>
>
>In another message, you asked:
>> 1.) Is there an example for someone who did not want to use sage because 
>of some dependency of the math library?  Or at least a possible reason? 
>[...] But this begs the question: who profits from cutting the math library 
>into pieces (which look very arbitrary to me and have a curious emphasis on 
>discrete math topics)?
>
>If you do allow me another example from discrete math: Sage has a lot of 
>very good code in "sage.graphs" that provides functionality that is not 
>available from other Python libraries. 
>
>But to potential projects that would need this functionality, the 
>proposition to have to depend on the monolithic project SageMath, with 
>hours of compilation time and/or dependencies on system packages that are 
>obviously unrelated to the needed functionality (boost, brial, ecl, eclib, 
>ecm, fflas_ffpack, flint, libgd, gap, giac, givaro, glpk, gmp, gsl, iml, 
>lcalc, libbraiding, libhomfly, libpng, linbox, m4ri, m4rie, mpc, mpfi, 
>mpfr, ntl, pari, rw, singular, symmetrica), is simply a showstopper.
>

This is not true, either. First, a lot of these packages that you list are 
available on systems, and thus there is no need to build them.
(To "but macOS?" I have a reply: "ask Apple to provide you a package manager, 
it's the best OS, right, you pay for it a lot of money, or learn to use 
Homebrew like  Mac users usually do...")

Anyway, a normal Python pypi-installable package comes with binary wheels, i e. 
things are pre-built, and it's merely matter of downloading these to get a 
functional package. Few minutes on a fast network, not hours.
By choosing to be an exception in the Python world,
Sage obviously does something quite wrong.

Dima

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/2D37D4FE-4FBC-4F65-8E7E-27B036B2E4C1%40gmail.com.

Re: [sage-devel] Re: SingularError in rational_parameterization

[Dima Pasechnik]

I've filed https://github.com/sagemath/sage/issues/37838

On Sat, Apr 20, 2024 at 5:34 PM Dima Pasechnik  wrote:

> This is due to https://github.com/sagemath/sage/pull/37495
> Sorry, this is the  usual careless reviewing of late, preventing people
> from using their own Singular (too "new")
> The check should have been conditional on building Sage's own Singular -
> otherwise it should have been ignored.
>
> You can revert the this PR, and re-run ./bootstrap
>
> On Saturday, April 20, 2024 at 5:10:41 PM UTC+1 Peter Mueller wrote:
>
>> Dima Pasechnik schrieb am Samstag, 20. April 2024 um 17:57:05 UTC+2:
>>
>> [...] well, this looks relevant.  "any of gmp ntl flint readline mpfr
>> cddlib is installed as or will be installed as SPKG"
>>
>> these are Singular's dependencies, and possibly not all of them are on
>> your OS.
>> In particular, flint is not there - you need Flint 3, and it's only in
>> the very latest Ubuntu, cf.
>> https://packages.ubuntu.com/search?searchon=sourcenames=flint
>>
>> You might want to install latest flint3, 3.1.2, into /usr/local/, and
>> try again.
>> This will be dodgy, and not really very good idea,
>> as your Singular is built with flint2,  I suppose...
>>
>>
>> well, all these packages were installed when I compiled sage:
>>
>> `pacman -Q gmp ntl flint readline mpfr cddlib` returns
>>
>> gmp 6.3.0-1
>> ntl 11.5.1-1
>> flint 3.1.2-1
>> readline 8.2.010-1
>> mpfr 4.2.1-2
>> cddlib 1:0.94m-1
>>
>> -- Peter
>>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/0e3b2cae-6a6c-45b6-af2d-d35118d044d1n%40googlegroups.com
> <https://groups.google.com/d/msgid/sage-devel/0e3b2cae-6a6c-45b6-af2d-d35118d044d1n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0hfzMDhN4_MUzKLfhXAjNJ%3DxsLdK2Mpeoo0pjiAaooww%40mail.gmail.com.

Re: [sage-devel] Re: SingularError in rational_parameterization

[Dima Pasechnik]

This is due to https://github.com/sagemath/sage/pull/37495
Sorry, this is the  usual careless reviewing of late, preventing people 
from using their own Singular (too "new")
The check should have been conditional on building Sage's own Singular - 
otherwise it should have been ignored.

You can revert the this PR, and re-run ./bootstrap

On Saturday, April 20, 2024 at 5:10:41 PM UTC+1 Peter Mueller wrote:

> Dima Pasechnik schrieb am Samstag, 20. April 2024 um 17:57:05 UTC+2:
>
> [...] well, this looks relevant.  "any of gmp ntl flint readline mpfr 
> cddlib is installed as or will be installed as SPKG"
>
> these are Singular's dependencies, and possibly not all of them are on 
> your OS.
> In particular, flint is not there - you need Flint 3, and it's only in the 
> very latest Ubuntu, cf.
> https://packages.ubuntu.com/search?searchon=sourcenames=flint
>
> You might want to install latest flint3, 3.1.2, into /usr/local/, and
> try again.
> This will be dodgy, and not really very good idea,
> as your Singular is built with flint2,  I suppose...
>
>
> well, all these packages were installed when I compiled sage: 
>
> `pacman -Q gmp ntl flint readline mpfr cddlib` returns
>
> gmp 6.3.0-1
> ntl 11.5.1-1
> flint 3.1.2-1
> readline 8.2.010-1
> mpfr 4.2.1-2
> cddlib 1:0.94m-1
>
> -- Peter
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/0e3b2cae-6a6c-45b6-af2d-d35118d044d1n%40googlegroups.com.

Re: [sage-devel] Re: SingularError in rational_parameterization

[Dima Pasechnik]

On Friday, April 19, 2024 at 12:36:26 PM UTC+1 Peter Mueller wrote:

@Dima, thanks, I know that though. Nevertheless, I now started from anew 
(that is I removed the sage directory and git-cloned sage to make sure that 
there are no remains causing trouble). After running configure, the script 
suggests to `sudo pacman -S eclib fflas-ffpack linbox nauty singular`. 


these suggestions are often bogus (and it's the case here). There is not 
check done on whether these are actually installed - it's only checking
whether such a package is available for your OS, but not going to be used 
by Sage.
 

However, all these packages are installed: `pacman -Q eclib fflas-ffpack 
linbox nauty singular` returns
eclib 20240408-1
fflas-ffpack 2.5.0-1
linbox 1.7.0-1
nauty 1:2.8.8-2
singular 4.3.2.p16-1

The possibly relevant snippets of the config.log are

[...]
It was created by Sage configure 10.4.beta3, which was
generated by GNU Autoconf 2.72.  Invocation command line was

  $ ./configure --enable-bliss --enable-cbc --enable-csdp --enable-dsdp 
--enable-gap_p
ackages --enable-libnauty --enable-mcqd --enable-msolve 
--enable-pari_galpol --enable-
scip --enable-scip_sdp --no-create --no-recursion
[...]
hostname = wma7117
uname -m = x86_64
uname -r = 6.8.5-arch1-1
uname -s = Linux
uname -v = #1 SMP PREEMPT_DYNAMIC Thu, 11 Apr 2024 01:47:33 +

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /home/mueller/.codon/bin/
PATH: /home/mueller/.codon/bin/
PATH: /home/mueller/local/copt/bin/
PATH: /usr/local/sbin/
PATH: /usr/local/bin/
PATH: /usr/bin/
PATH: /usr/bin/site_perl/
PATH: /usr/bin/vendor_perl/
PATH: /usr/bin/core_perl/
PATH: /home/mueller/local/bin/
PATH: /home/mueller/Adm/local/bin/
PATH: /home/mueller/local/gurobi/linux64/bin/

and

## Checking whether SageMath should install SPKG singular... ##
## - ##
configure:49864: checking whether any of gmp ntl flint readline mpfr cddlib 
is installed as or will be installed as SPKG
configure:49869: result: yes; install singular as well
configure:50085: no suitable system package found for SPKG singular


well, this looks relevant.  "any of gmp ntl flint readline mpfr cddlib is 
installed as or will be installed as SPKG"
these are Singular's dependencies, and possibly not all of them are on your 
OS.
In particular, flint is not there - you need Flint 3, and it's only in the 
very latest Ubuntu, cf.
https://packages.ubuntu.com/search?searchon=sourcenames=flint

You might want to install latest flint3, 3.1.2, into /usr/local/, and
try again.
This will be dodgy, and not really very good idea,
as your Singular is built with flint2,  I suppose...

Dima




dim...@gmail.com schrieb am Freitag, 19. April 2024 um 12:08:01 UTC+2:

On Fri, Apr 19, 2024 at 02:28:13AM -0700, 'Peter Mueller' via sage-devel 
wrote: 
> I just figured out that the installation from source (even with the 
> explicit configure option `--with-system-singular`) on an up to date arch 
> linux machine ignores the installed singular (`pacman -Q singular` 
returns 
> `singular 4.3.2.p16-1`). Not sure if it is a path problem that makes the 
> configure script fail to detect the singular installation. 
The 1st thing 1st, 
if your source install already has singular built, you need to uninstall 
it, for ./configure to pick up the system-wide one. 

if you post your config.log we can tell you more on why it goes wrong. 

Dima 

> 
> Antonio Rojas schrieb am Donnerstag, 18. April 2024 um 09:03:22 UTC+2: 
> 
> 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 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+...@googlegroups.com. 
> To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a671ea8e-e0c5-4dbe-9510-5139c9bb24ffn%40googlegroups.com.
 


-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/94d92418-763e-476c-9feb-24ea4863d402n%40googlegroups.com.

Re: [sage-devel] Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Dima Pasechnik]

Hi Volker,

On Sat, Apr 20, 2024 at 10:22 AM Volker Braun  wrote:

> Yes in a perfect world, but then you don't get a gold star for satisfying
> some purity test. We should just do the minimal amount of work to get us
> where we want to be. Lets focus on the direction to go and not too much on
> the process.
>


the keywords are "where we want to be" and "direction".
The revert should happen as there is no agreement on this.

It would help if we first sort out and agree on these, then we can resume
the normal operations.

IMHO it would help if you stopped touching these disputed PRs until this
these are done, or at least for a set period of time,
say a month or two.

Dima



>
> On Friday, April 19, 2024 at 7:18:03 PM UTC+2 Michael Orlitzky wrote:
>
>> On Fri, 2024-04-19 at 09:46 -0700, Matthias Koeppe wrote:
>> >
>> > Michael, note that in my message I asked for a vote on that dependency
>> > https://github.com/sagemath/sage/pull/36676.
>> >
>>
>> Even if 36676 gets approval, 36964 must be reverted. It was not
>> meaningfully voted upon.
>>
>> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/b9d41da8-57ec-4542-a5d8-7f2690849a49n%40googlegroups.com
> 
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3iAWpJQpMFzcF09-FnNgzMXnsExzpUti-YAZ%2BrhCNqDQ%40mail.gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Dima Pasechnik]

On 20 April 2024 08:56:30 BST, 'Martin R' via sage-devel 
 wrote:
>A follow-up question: do I understand correctly that common lisp (via 
>maxima) is the main dependency that prevents sagemath from being 
>pip-installable?

pip install sagemath-standard

already works in a venv on a box with enough deps
installed. Takes lot of time. To fix this,
anyhow, someone has to make their hands dirty and do to Lisp interface what's 
done to Pari/GP (cypari)
PPL (pplpy), primecount (primecountpy), etc.
Apart from Lisp, there is GAP (with the corresponding effort stalled).

That's what is much more urgent than attempting to slice up the maths 
functionality of sagelib.

Dima
>
>All the best,
>
>Martin
>On Friday 19 April 2024 at 21:34:06 UTC+2 Martin R wrote:
>
>> On Friday 19 April 2024 at 20:08:51 UTC+2 Matthias Koeppe wrote:
>>
>> On Friday, April 19, 2024 at 5:08:02 AM UTC-7 Martin R wrote:
>>
>> 2.) If this is about dependencies on other software, why aren't the 
>> distributions named after these dependencies?
>>
>>
>> Martin, I have answered this already when you asked it in the PR: Some are.
>>
>>
>> Matthias, this does not answer my question.  Maybe it is clearer if I ask: 
>> why do you introduce distributions sage-graphs, sage-combinat, 
>> sage-categories etc.
>>
>> Martin
>>
>>  
>>
>> Note that the description of the PR where you asked this question contains 
>> the list of the distributions: https://github.com/sagemath/sage/pull/36676
>> "We restructure the all.py files for modularization. Guided by the 
>> technical constraints outlined in 
>> https://groups.google.com/g/sage-devel/c/ozh-7ZZ848s, 
>> https://github.com/sagemath/sage/pull/35095 defines distribution packages 
>> (pip-installable packages) sagemath-{brial, combinat, eclib, flint, gap, 
>> giac, glpk, graphs, groups, homfly, lcalc, libbraiding, libecm, linbox, 
>> modules, mpmath, ntl, pari, plot, polyhedra, schemes, singular, 
>> standard-no-symbolics, symbolics}."
>>
>> My June 2023 sage-devel post 
>> https://groups.google.com/g/sage-devel/c/kiB32zP3xD4 explained that the 
>> design use "... 3 types of distribution packages:
>> - Packages that are named after a basic mathematical structure but may 
>> cover a wide range of generalizations/applications of this structure.
>> - Packages that are named after an upstream library. 
>> - Packages that are named after a technical functionality."
>>
>>
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/7F679D01-A0C0-482E-BFEA-68ABC1FC7C81%40gmail.com.

Re: [sage-devel] Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Dima Pasechnik]

Another attempt at derailing the ongoing vote, not unexpected.

Besides, Matthias must be really the greatest democrat of all - 1st he blocks a 
part of electorate from voting at the designated venue, and then invite 
everyone to vote there.

I urge everyone to ignore this alternative vote - to protest against this 
offensive behaviour.

Dima

On 18 April 2024 22:18:37 BST, Matthias Koeppe  wrote:
>Dear all:
>
>As an alternative to the proposal to back out the 
>PR https://github.com/sagemath/sage/pull/36964 whose *disputed dependency 
>PR https://github.com/sagemath/sage/pull/36676 which had not reached the 
>required 2:1 supermajority *of the dispute-resolution process *(it 
>currently only has a simple majority of 7 votes in favor, 5 votes against)* 
>--- I am asking for your votes on that dependency PR 
>https://github.com/sagemath/sage/pull/36676 to heal the process. This will 
>avoid further delays and disruptions.
>
>*What is the modularization project?* The Sage developer community has long 
>been aware of the severe problems that the monolithic design of Sage has 
>brought. See in particular the lively 2016 sage-devel thread "How we 
>develop Sage" (https://groups.google.com/g/ sage-devel/c/29ndCD8z94k) 
>initiated by William. In its current incarnation, "modularization project" 
>refers to my proposal from May 2020,
>- to use modern Python packaging ("PEP 517/518/660") and Python 3's 
>"implicit namespace packages" to 
>- break the Sage library into separately buildable and installable 
>"distribution packages"
>- while keeping the structure of the source tree mostly unchanged, 
>monolithic, for the convenience of the Sage developer community.
>For the project, hundreds of tickets/PRs have been prepared and merged over 
>the past 4 years, see the Meta-ticket 
>https://github.com/sagemath/sage/issues/29705 for a list.
>
>*Has the Sage community been informed and consulted regarding the 
>modularization project? *Yes, in addition to the normal review that all 
>tickets/PRs underwent:
>- I have given detailed presentations about the project in SageDays 110 
>(2020), 112.358 (2022), 120 (2023), 
>see https://github.com/sagemath/sage/issues/29705 for links.
>- A chapter of the Sage Developer Guide, 
>https://doc.sagemath.org/html/en/developer/packaging_sage_library.html#packaging-the-sage-library,
> 
>provides a detailed description of the design
>- I have posted numerous times to sage-devel, most recently the series 
>"SageMath modularization project: The five by five" (2023-06). See 
>https://github.com/sagemath/sage/issues/29705 for links to all of these.
>- Specifically, in the post "Modularization project: V. The blocs" 
>(https://groups.google.com/g/sage-devel/c/kiB32zP3xD4/m/GJ0qF7TTAAAJ, 
>2023-06), I outlined the design of the pip-installable packages such as 
>sagemath-combinat, sagemath-graphs, sagemath-flint, sagemath-plot etc. 
>- And in my 2023-11 post 
>https://groups.google.com/g/sage-devel/c/kiB32zP3xD4/m/GJ0qF7TTAAAJ in the 
>same thread, I asked: 
>> Ready for review: A restructuring of our "all.py" files along these 
>dependencies in https://github.com/sagemath/sage/pull/36676. This is an 
>opportunity to review the contents of the proposed distributions 
>implemented in Mega-PR https://github.com/sagemath/sage/pull/35095 (~50 
>kLOC changes, not open for review). As 
>https://github.com/sagemath/sage/pull/36676 rewrites all "all.py" files, it 
>is also an opportunity for a deliberate coding style decision for these 
>files. I welcome all constructive discussions in the PR.
>
>*What does the PR https://github.com/sagemath/sage/pull/36676 do? *Per its 
>title, "Restructure sage.*.all for modularization, replace relative by 
>absolute imports". The PR is "mostly harmless": There are no user-visible 
>changes; it's just a bunch of imports that are moved around. It includes no 
>policy change of any kind; it only executes a design that was previously 
>reviewed and carefully documented in separate PRs. Nothing permanent or 
>irreversible is done here. The new files provide the top-level namespaces 
>needed for doctesting modularized installations of Sage.
>
>*Has it been reviewed?* Yes, David Coudert and John Palmieri did a detailed 
>review. This was completed on November 15, 2023 --- over 5 months ago.
>
>*How did this PR become "disputed"?* Back in November, one commenter 
>floated an (untested) alternative design 
>(https://github.com/sagemath/sage/pull/36676#pullrequestreview-1726079717); 
>I explained 
>in https://github.com/sagemath/sage/pull/36676#issuecomment-1806873154 why 
>it's not suitable. Commenter demanded that the previously reviewed and 
>documented design is reopened for discussion, 
>https://github.com/sagemath/sage/pull/36676#issuecomment-1863667919. 
>
>*What are the concerns that have been made known during the voting process 
>for this PR (March/April 2024)?* I will not attempt to paraphrase, but here 
>are links to some posts so that you can find the 

Re: [sage-devel] VOTE: Revert merged PR with unreviewed dependencies

[Dima Pasechnik]

+1 to reverting the wrong merge

On 18 April 2024 16:54:08 BST, David Roe  wrote:
>Hi all,
>Sage has had a review process for over 15 years, but a combination of
>recent changes has led to the merging of a PR into sage-10.4.beta3 of a
>change (#36964 ) that I
>believe should not (yet) have been merged.  In #37796
> I created a PR to revert the
>change, which was opposed by the author of the original change.  After some
>voting 
>using the disputed PR policy
>,
>Matthias has asked
> for a
>vote on sage-devel about this reversion, in accordance with the section
>that "This process is intended as a lower-intensity method for resolving
>disagreements, and full votes on sage-devel override the process described
>below."  I am therefore asking you to vote (+1 means merge #37796
> in order to revert #36964
>).
>
>First, here are the relevant parts of the history of this particular change:
>
>- #36964  was created on
>December 25 by Matthias, positively reviewed
>
>by Kwankyu on Decemebr 27, disputed, received enough votes
> to
>get a positive review on April 7, and was merged
> by
>Volker on April 12.  It had dependencies: #37667,
>#36951
>, and #36676
>.  While #37667
> had positive review and was
>already been merged, the other two were still disputed: they had received
>an initial positive review but others objected and discussion was ongoing.
>
>- #37667  is not disputed.
>
>- #36951  was created on
>December 23 by Matthias, positively reviewed
>
>by Kwankyu on January 1, disputed, received enough votes
> (3-1)
>to change to positive review on April 7, had a clarification to bring back
>to (3-2) and remove positive review, then was included in the merge of
>#36964 . On April 13, John
>Palmieri voted in favor
>, so
>the current vote stands at 4-2, enough for the 2-1 threshold in order to
>get positive review under the disputed voting process.
>
>- #36676  was created on
>November 8 by Matthias, positively reviewed
> by
>John Palmieri on November 15, and then disputed.  The most recent count was 6-4
>in favor
>
>(falling short of the 2-1 ratio needed under the disputed voting process);
>since then I voted
> in
>favor, it was included in the merge of #36964
>, and then Martin voted
>against.
>
>
>At issue is the PR #36676 ,
>where discussion was still ongoing when #36964
> was merged.  The reversion of
>this PR proposed is purely for process reasons (I voted in favor of #36676
> before all this happened!).
>The 5 Sage developers opposed to #36676
> deserve to have our processes
>followed.  What went wrong?
>
>I think what happened resulted from a combination of the new disputed
>voting process, mismatched expectations around dependencies after the move
>to github, and Volker's release management scripts.  Several developers
>privately expressed concern prior to this merge about exactly this outcome,
>and I reassured them that dependencies would be taken into account.
>Unfortunately, dependencies are now (unlike in trac) just a text section of
>the PR comment, and the release scripts only see the label.
>
>
>There are lots of things to discuss around this chain of events.  I ask
>that everyone keep this thread focused on whether to merge #37796
> in order to revert #36964
>.  Some other topics, and
>places I 

[sage-devel] Urgent proposal: stop merging PRs without consensus, work on a way forward

[Dima Pasechnik]

We urgently need to recover some degree of sanity in how the contributions are 
merged.

The proposal is to halt the current trend of political PR reviews, namely only 
merge PRs where there is a consensus.

This is getting particularly urgent in view of few still disputed PRs being 
merged, and pushback against these merges being reverted.

Please discuss, I'll call a vote in, say, 24 hours.

Dima

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/BB0BC992-C775-4AC4-BCA3-279E6C82641C%40gmail.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On Mon, Apr 15, 2024 at 10:01 PM François Bissey 
wrote:

>
>
> On 16/04/24 04:41, kcrisman wrote:
> > SageMath has several other long-term contributors who also package
> > software. We're all roughly on the same page about what it would take
> > to fix the sage installation for end users.
> >
> >
> > And some of these people (perhaps kiwifb?) have not been as directly
> > involved in some of the recent disputes.   Maybe there is a path forward
> > (I also presume the CoCC is thinking about this).
>
> I would say I have involved myself too much already. I am regularly
> asked to review some of those tickets that are disputed or become disputed.
>
> It floods my inbox and makes my heart sink.
>

Well, on the latest disputed PR https://github.com/sagemath/sage/pull/37796
I proposed
to stop with this all and go back to getting the PRs approved by consensus.

Should we call an urgent general vote on this?

Dima



> François
>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/d7dd2f74-8c1a-4e9a-be42-5b4816065e30%40gmail.com
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0r4vFeD36jhVEBYhxGWebcCZ2_9iKc1J8tdoyJzRBAQw%40mail.gmail.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On 15 April 2024 22:13:59 BST, John H Palmieri  wrote:
>+1 to the inclusion of the package, in case anyone views the voting as 
>still open.
>
>François, thank you for letting us know about how the ongoing disputes are 
>affecting you. I feel your pain.

John, do you think Francois is the only one? I oscillate between quitting the 
project, making a fork, continuing this endless voting fight, etc. - instead of 
doing more useful things.

I propose to go back to merging PRs etc by consensus, while we figure out a 
compromise.

Dima

>
>Regards,
>  John
>
>
>On Monday, April 15, 2024 at 2:01:43 PM UTC-7 François Bissey wrote:
>
>>
>>
>> On 16/04/24 04:41, kcrisman wrote:
>> > SageMath has several other long-term contributors who also package
>> > software. We're all roughly on the same page about what it would take
>> > to fix the sage installation for end users.
>> > 
>> > 
>> > And some of these people (perhaps kiwifb?) have not been as directly 
>> > involved in some of the recent disputes.   Maybe there is a path forward 
>> > (I also presume the CoCC is thinking about this).
>>
>> I would say I have involved myself too much already. I am regularly 
>> asked to review some of those tickets that are disputed or become disputed.
>>
>> It floods my inbox and makes my heart sink.
>>
>> François
>>
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/B9B7E1DE-1150-4773-8091-2591A4CC0AB5%40gmail.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On Mon, Apr 15, 2024 at 5:41 PM kcrisman  wrote:

>
> We (not just Sage, but you and I!) have been discussing this for
> almost 15 years.
>
>
> Haha, true!
>
>
> SageMath has several other long-term contributors who also package
> software. We're all roughly on the same page about what it would take
> to fix the sage installation for end users.
>
>
> And some of these people (perhaps kiwifb?) have not been as directly
> involved in some of the recent disputes.   Maybe there is a path forward (I
> also presume the CoCC is thinking about this).
>
>
> But so far, every attempt to disentangle the
> library/distribution to enable this division of labor has been met
> with resistance by essentially one person.
>
>
> Well, more accurately there must be a critical mass of people who, like
> Kwankyu in some recent comments (apologies for not having link to hand),
> want to trust that the related process undertaken by that person is worth
> doing, and to let that proceed.  Otherwise they would have spoken up, as
> many longer-term developers are not shy of doing so on other matters.
>
> Regarding WSL in Dima's post, I thought
> https://github.com/sagemath/sage/pull/37184 (and the followups) addressed
> this quite a bit - that was what I was referring to.  If I could get it to
> work, I think anyone could.  But I didn't try Jupyterlab, maybe that's not
> included in it.  Anyway, I was definitely not referring to anyone who knows
> what "apt-get" is in WSL.  So am I right in your saying that Jupyter
> wouldn't work "out of the box" with Sage with the conda-based solution for
> WSL?  To me, that's an argument *for* batteries, not against.
>
> Same applies for the MacOS version provided by 3manifolds, my assumption
> was that this would work "out of the box" if you do sage -n jupyter or
> something.  That assumption could be wrong - but again, why put additional
> barriers to the user?  "Normal" software that "normal" i.e. non-developer
> people use in the real world doesn't do that.  Why make that a prerequisite
> for just doing math?  I hate to beat the dead horse of the now-debatable
> mission statement, but does Mathematica make you separately download and
> install a notebook?
>

scipy does,
sympy does,
Macaulay2 does,
GAP does,
R does,
Julia does...





>   Even LaTeX has this problem - you have to install the distribution
> separately from TeXShop or what have you - and just like the developer
> friction noted here, it's a little bit of extra friction.
>
> > What fragmentation are you talking about?
>
> I meant that it's a bit silly (from the Mac or Windows perspective) that
> one even needs Arch, Ubuntu, Debian, Gentoo, Fedora, or anything else on
> the massive (and probably incorrect) list on Wikipedia:
> https://en.wikipedia.org/wiki/List_of_Linux_distributions  That's a
> massive duplication of effort right there.
>
> > It has to be formulated and agreed upon in general lines, otherwise such
> a summit would be a waste of time.
>
> Agreed.  All of my points are irrelevant compared to getting us back on
> some consensus track.  That means toning down the rhetoric and candidly
> saying what sub-optimal concessions might be on the table (to be clear, for
> everyone).  It's clear now that at least two visions for Sage
> packaging/modularization which, in their current technical state, are
> viewed by stakeholders as colliding in their purest forms, but it seems
> unlikely that Sage is not Turing-complete enough to support a modus vivendi.
>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/7ebdcd4a-b8fa-4e1a-8f65-687730fa309bn%40googlegroups.com
> 
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2ge95V2XtFFtM3gsgyZsgUDZBb0sg%3DcLq%3DRSkqZwj_hg%40mail.gmail.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On Mon, Apr 15, 2024 at 5:41 PM kcrisman  wrote:

>
> We (not just Sage, but you and I!) have been discussing this for
> almost 15 years.
>
>
> Haha, true!
>
>
> SageMath has several other long-term contributors who also package
> software. We're all roughly on the same page about what it would take
> to fix the sage installation for end users.
>
>
> And some of these people (perhaps kiwifb?) have not been as directly
> involved in some of the recent disputes.   Maybe there is a path forward (I
> also presume the CoCC is thinking about this).
>

kiwifb has a custom-made Sage on a mini-distro (a Gentoo prefix) which
mostly works for him - and he's too busy anyway, I suppose.


>
>
> But so far, every attempt to disentangle the
> library/distribution to enable this division of labor has been met
> with resistance by essentially one person.
>
>
> Well, more accurately there must be a critical mass of people who, like
> Kwankyu in some recent comments (apologies for not having link to hand),
> want to trust that the related process undertaken by that person is worth
> doing, and to let that proceed.  Otherwise they would have spoken up, as
> many longer-term developers are not shy of doing so on other matters.
>

Kwankyu has been very open in saying that he does political voting.
I presume that's what applies to the rest of that "mass" you mention -
almost everyone there is a convicted serial macOS user.



> Regarding WSL in Dima's post, I thought
> https://github.com/sagemath/sage/pull/37184 (and the followups) addressed
> this quite a bit - that was what I was referring to.  If I could get it to
> work, I think anyone could.  But I didn't try Jupyterlab, maybe that's not
> included in it.  Anyway, I was definitely not referring to anyone who knows
> what "apt-get" is in WSL.  So am I right in your saying that Jupyter
> wouldn't work "out of the box" with Sage with the conda-based solution for
> WSL?  To me, that's an argument *for* batteries, not against.
>

No, no amount of "batteries" will help you here - you need your Jupyter to
be run on the Windows side, not on WSL side, so that you can use either a
Windows browser or (Windows-side) VS Code to run Jupyter.

What would really simplify things here is creation of a Windows based
installer, not mere a document
on dozens of things to be done to set it all up.

As to whether it would work with Conda-based Sage in WSL - I don't know,
the crucial thing here is automatic discovery of Sage's Jupyter kernel (a
small JSON file)

>
> Same applies for the MacOS version provided by 3manifolds, my assumption
> was that this would work "out of the box" if you do sage -n jupyter or
> something.
>

3manifolds app packages a completely separate full-blown Jupyter
installation
to interact with Sage (with their standard launcher), and that's the only
Jupyter they support.
They don't need to package "batteries" which are just ballast for their app.

 That assumption could be wrong - but again, why put additional barriers to
> the user?  "Normal" software that "normal" i.e. non-developer people use in
> the real world doesn't do that.  Why make that a prerequisite for just
> doing math?  I hate to beat the dead horse of the now-debatable mission
> statement, but does Mathematica make you separately download and install a
> notebook?   Even LaTeX has this problem - you have to install the
> distribution separately from TeXShop or what have you - and just like the
> developer friction noted here, it's a little bit of extra friction.
>
> > What fragmentation are you talking about?
>
> I meant that it's a bit silly (from the Mac or Windows perspective) that
> one even needs Arch, Ubuntu, Debian, Gentoo, Fedora, or anything else
>

Mac? I am not familiar with any medium/large size business which uses macOS
on anything apart from desk/laptop.

Windows? WSL didn't arise from nothing...

(sorry if I failed to notice irony here)

on the massive (and probably incorrect) list on Wikipedia:
> https://en.wikipedia.org/wiki/List_of_Linux_distributions  That's a
> massive duplication of effort right there.
>

Cf.
https://en.wikipedia.org/wiki/List_of_the_largest_Protestant_denominations
(and that's "protestant"+"largest" only)


> > It has to be formulated and agreed upon in general lines, otherwise such
> a summit would be a waste of time.
>
> Agreed.  All of my points are irrelevant compared to getting us back on
> some consensus track.  That means toning down the rhetoric and candidly
> saying what sub-optimal concessions might be on the table (to be clear, for
> everyone).  It's clear now that at least two visions for Sage
> packaging/modularization which, in their current technical state, are
> viewed by stakeholders as colliding in their purest forms, but it seems
> unlikely that Sage is not Turing-complete enough to support a modus vivendi.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and 

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On Mon, Apr 15, 2024 at 12:21 PM kcrisman  wrote:

>
> I understand that some macOS users are very comfortable with Sage the
> distro playing the role of a missing macOS package manager,
>
>
> The real question is about *users* in this case, not developers. I just
> got messed up the other day brew updating something which killed my Python
> 3.9 I need in order to use a specific package (nothing to do with Sage,
> completely orthogonal) for a certain course, a package which doesn't
> support the most recent Pythons yet, and frankly my teaching load (unlike
> perhaps that of most Sage developers, I acknowledge) doesn't leave time to
> learn the intricacies of pyenv or whatever there is out there to rectify
> such situations (I don't *mind* having 3.12 on my box ...).  Sage's
> "batteries included" means all my Sage installations of various vintages
> stay sandboxed, essentially, and that is pretty comforting.
>

Pyenv is easier than sage distro, much easier.
If there was an easy way to install Sage into a pyenv environment,
one could have used it...


> My guess is that most Sage *users* are in this kind of situation.
>

Well, depending on a legacy (3.9) Python version isn't the problem for the
most, I hope. :-)


>  The WSL solution using some version of conda now might allow something
> similar (?) for the VAST number of Windows users out there.
>

Combining WSL+conda might be a bit too sophisticated for - e.g. I'm not
sure it plays well with
using VS Code to run notebooks in WSL.
Thus, one probably would do in WSL "sudo apt-get install sage-jupyter",
installing Sage 9.5 - if the standard for WSL Ubuntu 22 is used). This is
old Sage...
Yes, one can follow the advice in
https://sagemanifolds.obspm.fr/install_ubuntu.html
to get an up to date Sage in your Ubuntu WSL.

One way or another, this involves packaging Sage for Ubuntu (current;y
stalled), or for Conda (something that suffers from the same issues as
other distro packaging)


>  CoCalc probably provides a single solution to a large number of users too
> (how large, I don't know) for people using Mac and Windows in their
> day-to-day work, who don't mind a little Terminal to get some math done but
> don't want to use Linux (among other reasons, because many of us can't
> afford our own personal computers for work, so we have to take the options
> work gives us, which is emphatically not Linux).  It's great that the
> fairly small number of Linux users wordwide have the package manager
> concept,
>
the VAST number of Windows (+WSL) users have the package manager concept
(in their WSL), too.
They all most probably do "sudo apt-get install sage-jupyter" if they want
to run Sage.



> but its very fragmentation (!!!) surely takes a lot of developer time too
> (not just for Sage) as well.  So this argument, by itself, isn't sufficient.
>

What fragmentation are you talking about?
Packaging even a relatively sophisticated CAS like GAP for an OS isn't a
particularly hard task.
Once done, updates aren't time consuming at all.
SageMath should be easier than GAP to package, and not much harder.
And it's much harder at present, as it stubbornly refuses to be a good
member of Python universe.


>
> but it makes me sad that I spent many months of my time debugging and
> improving Sage on macOS, and getting this kind of cold shoulder in response
> to my requests.
>
>
> This is totally legitimate, as I've said before, and is the real crux of
> the issue.  I would hope people who don't want "batteries included" could
> live with it if there weren't a lot of unseen maintenance.
>

Mind you, even macOS users of Sage, who use the 3-manifold app
from https://github.com/3-manifolds/Sage_macOS/releases (as recommended on
https://doc.sagemath.org/html/en/installation/#macos), so it's probably the
macOS majority,
don't use most of the "batteries". E.g. they don't use packaged Jupyter.
And the VAST number of Windows+WSL users don't use packaged Jupyter.
(and they don't use Python build tools, or sphinx, or packaged compilers...)


 Under past circumstances, there would have been a Sage Days of some kind
> by now (in person) to hash out how to resolve the situation *with an
> acceptable consensus*, even if still imperfect, which lightens the load
> significantly on Linux package managers while keeping the other progress
> made on track.  We need something approximating this sort of summit now to
> resolve these issues - and I certainly do think there is an acceptable
> solution out there.
>

It has to be formulated and agreed upon in general lines, otherwise such a
summit would be a waste of time.

Dima

-- 
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 visit 

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On 14 April 2024 19:14:51 BST, Matthias Koeppe  wrote:
>When I completed the NumFOCUS application yesterday, I had to go through 
>the past years of sage-devel posts to answer the new question "Where do you 
>host conversations about project development and governance (e.g. mailing 
>lists, forums, etc.), and how many participants do you have?" (see 
>https://github.com/sagemath/sage/wiki/NumFOCUS#q16-where-do-you-host-conversations-about-project-development-and-governance-eg-mailing-lists-forums-etc-and-how-many-participants-do-you-have)
>
>While doing so, I also collected the sage-devel threads in which packages 
>were proposed to be added as standard packages, following our project's 
>procedures:


This is not an answer. I would like an explanation why Sage the distro has to 
grow the bloat at ever increasing speed, why you think it is sustainable, but, 
most of all, why "batteries included" is meaningful in 2024, and why these 
procedures must stay as they are.

I understand that some macOS users are very comfortable with Sage the distro 
playing the role of a missing macOS package manager, but it makes me sad that   
I spent many months of my time debugging and improving Sage on macOS, and 
getting this kind of cold shoulder in response to my requests. 



Dima

>- "Add pplpy and gmpy2 as standard packages" 
>(https://groups.google.com/g/sage-devel/c/qoxVng1__0A/m/4HntWHp_AQAJ, 
>2018-02)
>- "Make giacpy_sage a standard package" 
>(https://groups.google.com/g/sage-devel/c/uYXGzG_py28/m/4SN5hts4FQAJ, 
>2020-02)
>- "Add tox as a standard package" 
>(https://groups.google.com/g/sage-devel/c/G5kMggTecA8/m/2aTZSt_AAwAJ, 
>2020-09)
>- "Making cmake a standard package" 
>(https://groups.google.com/g/sage-devel/c/Ccumny9Yioc/m/litCsb6gAwAJ, 
>2021-07)
>- "New standard package: GNU Info" 
>(https://groups.google.com/g/sage-devel/c/aIx8i-0MRo4/m/4WxL64JlBAAJ, 
>2021-07)
>- "Add more-itertools as a standard package" 
>(https://groups.google.com/g/sage-devel/c/Dq83PiiCAsU/m/43WX3JgjDgAJ, 
>2021-12) 
>- "Make Jupyterlab a standard package" 
>(https://groups.google.com/g/sage-devel/c/orUpb-YXIHk/m/d_zDX3xyDQAJ, 
>2022-03)
>- "Make Furo a standard package" 
>(https://groups.google.com/g/sage-devel/c/VTU_I-ecPlA/m/KMd9cMX9AQAJ, 
>2022-08) 
>- "Make ipympl a standard package" 
>(https://groups.google.com/g/sage-devel/c/fRufANUCNdY/m/RKhnlUYdAgAJ, 
>2023-09)
>
>Our project's procedures have not changed.
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/E6787E1A-38C9-4C92-A2EE-525BDD491631%40gmail.com.

Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals

[Dima Pasechnik]

On 12 April 2024 12:42:39 CEST, Georgi Guninski  wrote:
>On Fri, Apr 12, 2024 at 11:35 AM Dima Pasechnik  wrote:
>>
>> This should be fixed by https://github.com/sagemath/sage/pull/37792
>> please review
>>
>
>I suspect reproducing is hard, since it depends on the time of pressing CTL-C.

Well,  in all my tries the crash happened in the same place, the place that now 
is no longer reachable.

And the reason for the crash was, AFAIU, due to calling a plain Python code 
(where Ctrl-C was caught) from a "noexcept" Cython code. That is, it's a crash 
due to inability to properly process Ctrl-C.

How many more similar places are left there in Cython code in Sage, I don't 
know.

Dima


>Also, lack a crash may be silent memory corruption.
>
>It is weird that the crash is not always.
>
>Do you fix the attached new testcase (no interaction required, may
>need changing some constants)?
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/C701D76E-A116-4D83-B427-24C305F51201%40gmail.com.

Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals

[Dima Pasechnik]

This should be fixed by https://github.com/sagemath/sage/pull/37792
please review

On Thursday, April 11, 2024 at 10:19:31 PM UTC+1 dim...@gmail.com wrote:

> On Thu, Apr 11, 2024 at 03:30:34PM +0300, Georgi Guninski wrote:
> > Are the non-crashing codepaths in consistent state?
> > SEGV is in general sign of memory corruption and it may lead to wrong
> > math results or possibly have security implications.
>
> Here is an attempt to fix it; it appears that the call to
> characteristic() which causes a crash is a leftover which can simply be
> removed.
> https://github.com/dimpase/sage/pull/6
> (not yet a PR to the Sage repo, just want to see results of tests)
>
> Dima
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/8d176b7d-a826-4713-ac3a-2a19c1c75669n%40googlegroups.com.

Re: [sage-devel] Re: source code tarball?

[Dima Pasechnik]

to be fixed by https://github.com/sagemath/sage/pull/37791
Please review.

Dima

On Wednesday, April 10, 2024 at 5:19:56 PM UTC+1 John Cremona wrote:

> Thanks, that's the page I was expecting.
>
> I think it would be a good idea to have that linked more obviously, but  I 
> am not able to make a PR right now.
>
> I found a tarball on GitHub on the releases page, so made progress, though 
> as I reported elsewhere I have not yet been able to build sage from it on 
> one machine.
>
> John
>
>
>
> On Wed, 10 Apr 2024, 15:24 julian...@fsfe.org,  wrote:
>
>> I guess the idea is that further down on this page, you are told to 
>> follow the instructions in the README here 
>> https://github.com/sagemath/sage/#readme which in turn tells you get the 
>> "sources" from here https://www.sagemath.org/download-source.html.
>>
>> I agree that this is not terribly intuitive, however, the wikipedia link 
>> was introduced in
>>
>> commit 5cddc06a8118d8fb9211fe8232b1183daba9f01f
>> Date:   Tue Mar 29 15:11:07 2011 +0100
>>
>> So it's been there for quite a while but certainly the surroundings have 
>> been modified quite a bit since then.
>>
>> If you want to create a PR to change that link, I am happy to give it 
>> positive review.
>>
>> julian
>>
>> On Wednesday, April 10, 2024 at 11:56:23 AM UTC+3 John Cremona wrote:
>>
>>> In the first line of 
>>> https://doc.sagemath.org/html/en/installation/source.html#sec-installation-from-sources
>>>  
>>> the words "source code" are a link to the wikipedia page for "source code", 
>>> which is not very helpful.  I was expecting it to be a link to page shoing 
>>> where to download a tarball.  I sometimes use the tarball to install from 
>>> source, instead of using a git clone -- I assume that has not been 
>>> discontinued?
>>>
>>> John
>>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/52db9220-62b4-4fc5-ac5a-f77bd040a9b7n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/b52110d7-408b-40f6-8401-c526d0261d93n%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 11 April 2024 21:47:57 CEST, Matthias Koeppe  
wrote:
>Once again, the workflow files in .github/workflows have to be statically 
>present in a repository so that Actions work.
>And the .devcontainers files have to be statically present in a repository 
>so that Codespaces work. 

Yes, sure, as I said, you can have it statically present, and test a submodule 
containing sagelib from there.

There is nothing hard to design here, once you split the repo this way.


>
>If you want to propose a design for breaking our repository into multiple 
>repositories, work it out first. Learn about the relevant technological 
>restrictions. 
>It does not make sense to develop it here in a question-and-answer game. 
>In particular, this cannot be done here in this thread about governance; 
>it's only a distraction.
>
>Matthias
>
>
>On Thursday, April 11, 2024 at 12:36:20 PM UTC-7 Dima Pasechnik wrote:
>
>On 11 April 2024 18:06:42 CEST, Matthias Koeppe  
>wrote: 
>>On Thursday, April 11, 2024 at 4:28:12 AM UTC-7 dim...@gmail.com wrote: 
>> 
>>On Wed, Apr 10, 2024 at 04:23:13PM -0700, Matthias Koeppe wrote: 
>>> On Wednesday, April 10, 2024 at 3:25:16 PM UTC-7 Dima Pasechnik wrote: 
>>> Necessary reminder that we're discussing, as the subject says, the files 
>>> that control the GitHub workflows and the Codespaces. 
>>> What a developer may do on their local machine does not matter. 
>> 
>>But there is no difference here between a CI and a local machine here. 
>>A CI is perfectly capable of doing 
>>"git submodule update --remote" 
>>and proceed. 
>> 
>> 
>>No. These files are processed by GitHub before any custom code can be run. 
>
>Are you saying that "git submodule..." cannot be triggered by 
>repository_dispatch hook? 
>So GH Actions cannot be triggered by a submodule update? 
>
>
>
>> 
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/A3395AC1-7AE8-436A-B1AE-B864F5E79BA8%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 11 April 2024 18:06:42 CEST, Matthias Koeppe  
wrote:
>On Thursday, April 11, 2024 at 4:28:12 AM UTC-7 dim...@gmail.com wrote:
>
>On Wed, Apr 10, 2024 at 04:23:13PM -0700, Matthias Koeppe wrote: 
>> On Wednesday, April 10, 2024 at 3:25:16 PM UTC-7 Dima Pasechnik wrote: 
>> Necessary reminder that we're discussing, as the subject says, the files 
>> that control the GitHub workflows and the Codespaces. 
>> What a developer may do on their local machine does not matter. 
>
>But there is no difference here between a CI and a local machine here. 
>A CI is perfectly capable of doing 
>"git submodule update --remote" 
>and proceed.
>
>
>No. These files are processed by GitHub before any custom code can be run.

Are you saying that "git submodule..." cannot be triggered by 
repository_dispatch hook?
So GH Actions cannot be triggered by a submodule update?



>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/D6F9CBA3-4EF6-430C-A534-46B7514CD975%40gmail.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[Dima Pasechnik]

On Wed, Apr 10, 2024 at 6:14 PM Matthias Koeppe 
wrote:

> On Wednesday, April 10, 2024 at 6:49:11 AM UTC-7 julian...@fsfe.org wrote:
>
> We have carefully reviewed [...]
>
> We therefore disagree with characterizing opposing opinions as “artificial
> friction”, “hostile demands”, or an “attempt to sabotage”.
> Such allegations will have no effect other than to antagonize the other
> party. This is not helpful in fostering constructive debate.
>
>
> Julian, please, that's highly inappropriate. I'm not characterizing
> opposing *opinions*.
>

Matthias, you keep characterizing my input into discussions as "persistent
abusive conduct", see e.g. your
https://github.com/sagemath/sage/pull/36676#issuecomment-2048352139

I demand a public apology, and a lift of the block on GitHub.
Else Matthias should be banned from SageMath for a while, if not
permanently. Enough is enough.

Dima


> With this terminology I'm describing the modes of existing, persistent,
> non-constructive *actions* on these PRs by others.
>

> These are not "allegations"; what I am describing has been happening in
> plain sight, is fully documented, and has been reported to the sage-abuse
> and CoCC committees. As you know, some of these have already led to
> sanctions by the committees, while I am still waiting for acknowledgment
> (and clear actions) regarding numerous reported violations of our code of
> conduct (and reviewing code) by the current committee.
>
> I do understand that the new committee is still learning how to recognize
> and handle abuse; it's a complicated and challenging topic to master. In
> the meantime, as I have asked the committee in private already, more
> thoughtful restraint in issuing public reprimands is necessary.
>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/2bdbf209-edc2-4a0d-9b4c-de1c665d406bn%40googlegroups.com
> 
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3kPjHk8-_b69xesUWXgB51bXH3stkrw1_A%2Bet6c6Pq0Q%40mail.gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On Wed, Apr 10, 2024 at 11:10 PM Matthias Koeppe 
wrote:

> On Wednesday, April 10, 2024 at 2:40:18 PM UTC-7 Dima Pasechnik wrote:
>
> On Wed, Apr 10, 2024 at 9:02 PM Matthias Koeppe 
> wrote:
>
> On Wednesday, April 10, 2024 at 1:00:06 PM UTC-7 Dima Pasechnik wrote:
>
> On 10 April 2024 19:24:12 CEST, Matthias Koeppe 
> wrote:
> >On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
> >[...] git submodules [...]
> >
> >git submodules are included in a repository by specific commit sha of the
> >submodule repo.
> >So whenever one has to make a change in the submodule repo, one also has
> to
> >commit a change (by a second PR) in the main repo.
> Why a 2nd PR?
>
>
> I just explained it. To update the version (commit sha) of the submodule.
>
>
> Have you ever worked with submodules?
>
>
> Yes, Dima, I have.
>
>
> There is simply no need to keep the .gitsubmodules -
> the only file in the main repo affected by "git submodule update --remote"
> -
> always synchronized, commit-wise, for everyone.
>
>
> There is. Without doing that, the changes made in the submodule won't take
> effect.
>
This is not true.

  git submodule update --remote

will pick up submodules changes just fine.
Read the docs?

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq1niXYTBjvEgncLBxq9KyZEWdVBmSXRn6ab56OiX8s2AA%40mail.gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On Wed, Apr 10, 2024 at 9:02 PM Matthias Koeppe 
wrote:

> On Wednesday, April 10, 2024 at 1:00:06 PM UTC-7 Dima Pasechnik wrote:
>
> On 10 April 2024 19:24:12 CEST, Matthias Koeppe 
> wrote:
> >On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
> >
> >[...] git submodules [...]
> >
> >git submodules are included in a repository by specific commit sha of the
> >submodule repo.
> >So whenever one has to make a change in the submodule repo, one also has
> to
> >commit a change (by a second PR) in the main repo.
> Why a 2nd PR?
>
>
> I just explained it. To update the version (commit sha) of the submodule.
>

Have you ever worked with submodules?

There is simply no need to keep the .gitsubmodules -
the only file in the main repo affected by "git submodule update --remote"
-
always synchronized, commit-wise, for everyone.
Yes, it's a bit annoying to have that pesky .gitsubmodules around, and I
can imagine that
git-subtree etc I mentioned are a better alternative.

Dima

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0JXHPBpq4oFOjsBiaPoDGfqFWZpjT5H0xKGZ7cjXbMxQ%40mail.gmail.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[Dima Pasechnik]

On 10 April 2024 21:50:43 CEST, Matthias Koeppe  
wrote:
>On Monday, April 8, 2024 at 5:19:02 PM UTC-7 Dima Pasechnik wrote:
>
>On Mon, Apr 8, 2024 at 7:19 PM Matthias Koeppe  wrote:
>
> You will find the comments in these PRs instructive -- also as 
>illustration for a (long overdue) *discussion about governance and review 
>standards* in the Sage project.
>
>
>*1. Please vote +1 on both https://github.com/sagemath/sage/pull/36561 
><https://github.com/sagemath/sage/pull/36561> and 
>https://github.com/sagemath/sage/pull/37138 
><https://github.com/sagemath/sage/pull/37138>* ("Move metadata from 
>setup.cfg to pyproject.toml").
>These are trivial "chore" PRs. They update metadata of our pip-installable 
>packages "sage-conf" and "sagemath-standard" to the latest format.
>These straightforward and appropriately focused PRs have been held back by 
>months by *bundling the review of the PRs with unrelated issues.* I call 
>this "artificial friction"; see the discussion in the PRs. To help overcome 
>this artificial friction, please vote.
>
>
>This is not true - the friction is not artificial. It is due to legitimate 
>concerns of developers who are not interested in
>spending all of their time on ever growing "Sage the distribution", and/or 
>who see little merit in Matthias' sagelib modulalisation
>project, which uses Python features (most of all, namespace packages)
>not universally supported by a number of important tools, such as  Cython 
>and pytest.
>
>Please vote -1 on these two PRs (there are more similar PRs around). This 
>will force Matthias to reconsider his priorities [...]
>
>
>What Dima is describing here is exactly the inappropriate bundling that I 
>have called out.

There seems to be nothing else, short of a project fork, to make Matthias 
reconsider.


> It's a violation of our standards of review.

By calling out for a mass vote you have essentially asked for such a violation.

Otherwise the whole thing about designing PRs by massive voting is a massive 
waste of developers' time, as normal reviewing can be a time-consuming process, 
in particular if the PR concerns a not a very familiar topic.


>
>As majority voting on PRs is our current conflict resolution mechanism: 
>All, please vote.
>
So what exactly are you asking for? For reviews, or for massive violation of 
our reviewing standards?

Dima

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/062AA6C5-23E9-4CDC-A74D-D8FA8E1D606E%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 10 April 2024 19:24:12 CEST, Matthias Koeppe  
wrote:
>On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
>
>[...] git submodules [...]
>
>
>git submodules are included in a repository by specific commit sha of the 
>submodule repo.
>So whenever one has to make a change in the submodule repo, one also has to 
>commit a change (by a second PR) in the main repo. 
Why a 2nd PR? 

>Hence this does not solve anything; it only adds more friction.

Anyway, there are alternatives like git-subrepo 
https://github.com/ingydotnet/git-subrepo
and git-subtree, which are said to be 
much more convenient (myself I only used git-submodule, so this is only what 
others say)
and don't suffer from these real or imaginary problems with git-submodule.

Dima


-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/C9A68AC0-5474-4A85-9E5C-771CDF803176%40gmail.com.

Re: [sage-devel] Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On 10 April 2024 20:23:10 CEST, Matthias Koeppe  
wrote:
>Dima, our project does not have such a policy of not adding standard normal 
>packages. This bundling with your political demand is inappropriate and not 
>welcome here.


Why is it unwelcome?
I explained under what condition I am OK with making this package standard. I 
could have just said NO without any explanation.

It is technical and not political. Political is your " not welcome" remark.



>
>On Wednesday, April 10, 2024 at 11:20:14 AM UTC-7 Dima Pasechnik wrote:
>
>> As in the previous attempt, I am OK with it becoming standard only if it 
>> remains a pip package, a no new "batteries are included".
>>
>> As a matter of fact, there is no point in keeping Python toolchain 
>> packages vendored. They can all be pip packages just as well.
>>
>>
>> On 10 April 2024 05:44:36 CEST, Matthias Koeppe  
>> wrote:
>>
>>> We added python_build as an optional "pip" package (see 
>>> https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types
>>>  for 
>>> the terminology),
>>> - 
>>> https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/python_build#spkg-python-build
>>>  (added 
>>> in 2022).
>>>
>>> "python_build" (a.k.a. pypa/build) is the current standard front-end for 
>>> making source distributions and wheels from a Python source tree. It has 
>>> replaced the deprecated practices of calling "setup.py sdist" or "setup.py 
>>> bdist_wheel" directly. We already use it for building the modularized 
>>> distribution packages. Making it a standard package will allow us to 
>>> modernize the build infrastructure (front-end) for the Sage library in the 
>>> Sage distribution.
>>>
>>> I'm proposing to make it a standard package according to the procedures 
>>> in our developer guide. Per our policy, that's a "normal" package, so its 
>>> dependency pyproject_hooks will also be added. The PR is prepared in 
>>> https://github.com/sagemath/sage/pull/37300 
>>>
>>> This is a re-do of my proposal 
>>> https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc/m/NsyUa7iXAgAJ 
>>> whose discussion was stalled by commenters bundling it with political 
>>> demands. 
>>>
>>>
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/7C5A20B7-533C-4E75-8DEC-AE985DFBBAA9%40gmail.com.

Re: [sage-devel] Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

As in the previous attempt, I am OK with it becoming standard only if it 
remains a pip package, a no new "batteries are included".

As a matter of fact, there is no point in keeping Python toolchain packages 
vendored. They can all be pip packages just as well.

On 10 April 2024 05:44:36 CEST, Matthias Koeppe  
wrote:
>We added python_build as an optional "pip" package (see 
>https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types
> for 
>the terminology),
>- 
>https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/python_build#spkg-python-build
> (added 
>in 2022).
>
>"python_build" (a.k.a. pypa/build) is the current standard front-end for 
>making source distributions and wheels from a Python source tree. It has 
>replaced the deprecated practices of calling "setup.py sdist" or "setup.py 
>bdist_wheel" directly. We already use it for building the modularized 
>distribution packages. Making it a standard package will allow us to 
>modernize the build infrastructure (front-end) for the Sage library in the 
>Sage distribution.
>
>I'm proposing to make it a standard package according to the procedures in 
>our developer guide. Per our policy, that's a "normal" package, so its 
>dependency pyproject_hooks will also be added. The PR is prepared 
>in https://github.com/sagemath/sage/pull/37300 
>
>This is a re-do of my proposal 
>https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc/m/NsyUa7iXAgAJ whose 
>discussion was stalled by commenters bundling it with political demands. 
>
>-- 
>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 visit 
>https://groups.google.com/d/msgid/sage-devel/e6b74134-7ed7-4da4-8b41-bebeef5c1f15n%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/4133C84E-1CC6-41FF-9AB8-CCB28BAECF64%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 10 April 2024 03:39:00 CEST, Kwankyu Lee  wrote:
>How about redefining the meaning of "CI Fix" label:
>
>1. We designate a person to be the CI manager. 
>2. For PRs pertaining to the designated directories and files, we add "CI 
>Fix" label
>3. The CI manager has the right to merge PRs with "CI Fix" label to develop.
>4. The old meaning of "CI Fix" label as "immediate fixes" is dropped.
>5. Hot fix PRs for breakage of CI also gets "CI Fix" label.

No, this has a big risk that such a manager will accidentally push non-CI bits, 
and obviously the discipline for not mixing CI and non-CI bits in one commit/PR 
will need to be manually managed.

This is why my proposal to split the repo is much better in this way. 

(One of the mottos of the political party I am forced to set up is "monorepos 
considered harmful", along with "batteries excluded" :-))




>
>?
>
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/2F5FD23C-680E-4FC5-8ECE-69BE08A3F3B0%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 10 April 2024 02:04:48 CEST, Matthias Koeppe  
wrote:
>On Tuesday, April 9, 2024 at 4:20:56 PM UTC-7 Dima Pasechnik wrote:
>
>have a CI/sage-distro repo [...] with all that .github/ etc stuff needed 
>for CI, including a part of build/ - and checkout sagelib as a submodule.
>
>
>Also that does not work. Part of the .github/workflows is to run the CI on 
>the pull requests for the Sage library, and the .devcontainer is for making 
>GitHub Codespaces available on the pull requests for the Sage library.

Regarding CI, triggering a git update+CI run on an event in  another repo is 
done via a repository_dispatch hook. 
<https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#repository_dispatch>

Indeed, it would be silly if one needed to pollute another repo with your CI 
workflow files.

Dima
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/B44D0BAB-7B85-4121-B34E-5851FE72880E%40gmail.com.

[sage-devel] Re: [sagemath/sage] Restructure `sage.*.all` for modularization, replace relative by absolute imports (PR #36676)

[Dima Pasechnik]

Please whoever is not blocked by the author of this PR, record my -1 vote on 
this.

Yes, this vote has a political element in it.
You want to play politics - let us play it.

Dima

On 10 April 2024 02:40:40 CEST, Tobias Diez  wrote:
>@tobiasdiez requested your review on: sagemath/sage#36676 Restructure 
>`sage.*.all` for modularization, replace relative by absolute imports.
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/FAF996E6-B6EE-411C-93AA-CD18394A3CFF%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 10 April 2024 00:51:33 CEST, Matthias Koeppe  
wrote:
>On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
>
>How about moving them out of the main Sage tree into separate repos, which 
>can be accessed from the main tree as git submodules?
>
>
>That does not work. 
>.github/workflows orchestrates what runs in the repo -- so it has to be in 
>the repo.
>.devcontainer declares what is offered for the repo in GitHub -- so it has 
>to be in the repo.

Then the other way around - have a CI/sage-distro repo (which can very well 
have relaxed policies) with all that .github/ etc stuff needed for CI, 
including a part of build/ - and checkout sagelib as a submodule.

The orchestration between the two repos looks doable. 


>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/E50C6018-FE63-4F0F-8938-231E7A492A91%40gmail.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[Dima Pasechnik]

I think I will quit the Sage project as soon as decisions on technical merits 
of PRs and issues will start to be taken in a nakedly political way.

I am very strongly against any political overtones in  these matters - it 
reminds me all too well what's wrong is in academia in general.

Dima




On 9 April 2024 11:21:46 CEST, Kwankyu Lee  wrote:
>Hi,
>
>Reviewing a PR is a technical work, but voting on a disputed PR has a 
>political element. So I want to make a political remark concerning most of 
>the disputed PRs.
>
>The modularization project (making pip-installation packages that contain 
>portions of the sage library) started years ago with a general consensus of 
>the sage community. Matthias led the project and did most of hard works. 
>Many others did not care much about the project and still do not feel the 
>impact except when encountered with the (annoying) "# needs ..." tags.
>
>Matthias is also managing much of the sage build system and the CI (mostly 
>testing infrastructure) on github, partly to support the modularization 
>project. Many of us would appreciate that.
>
>Certainly Matthias is not an appointed dictator ruling the developers, but 
>I think we should at least acknowledge the leading role of him in the area 
>of his expertise. On technical discussions on PRs, we should give more 
>weight on his opinions from his expertise.
>
>I hope that you decide your vote by weighing the conflicting arguments on 
>the issues.
>
>Kwankyu
>
>-- 
>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 visit 
>https://groups.google.com/d/msgid/sage-devel/3b6b30f7-efea-4812-b5b7-0e1f5894f975n%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/01429D75-1154-433D-AC95-8B336A9FD754%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 9 April 2024 23:11:59 CEST, Matthias Koeppe  wrote:
>Dear Sage developers:
>I propose to consider the following governance change for a small part of 
>the Sage repository:
>1. The directories *.ci, .devcontainer, .github/workflows*. These are 
>special directories that control the GitHub workflows that run for example 
>on pull requests and when release tags are pushed.
>2. The files *tox.ini* and *build/bin/write-dockerfile.sh*. They contain 
>the infrastructure for portability testing of the Sage distribution 
>(https://doc.sagemath.org/html/en/developer/portability_testing.html). 
>
>Some of these files are shipped as part of the Sage distribution, but none 
>of them have any role in the build process or runtime of Sage, and thus 
>none of them are tested by the Release Manager.
>
>*Status quo: *All changes to these files go through the normal review 
>process for Sage PRs; when set to "positive review", Volker merges them 
>into the next development release.
>In the terminology of https://martinfowler.com/articles/ship-show-ask.html 
>(ht Gonzalo Tornaria), this is the "Ask" model.
>
>Acknowledgment: I'm grateful to all who have contributed to the review of 
>my PRs that made changes to these files in the past: thanks for your time 
>and energy.
>
>*Proposed change: *All changes to these files are made through PRs. When 
>the PR is ready, a developer in the Maintainer role directly merges the PR 
>into the "develop" branch.
>In other words, switch to the "Show" model for these changes.

How about moving them out of the main Sage tree into separate repos, which can 
be accessed from the main tree as git submodules?

Then they could be developed in a completely separate process, and the 
corresponding PRs and issues won't be clogging up the main repo (which is 
already overloaded with all sorts of tangentially relevant to sagelib things.)
And the governance of these parts will be a separate thing all together.


Dima

>
>*Why the change:*
>1. Changes to these files do not have any effect on the build and runtime 
>of Sage;
>- thus changes to these files do not risk breaking the mathematical 
>correctness, or the performance of anything in Sage;
>- hence there may not be the same need for formal review compared to 
>changes to the Sage library.
>
>2. Our project has a collective interest in smoothly operating development 
>infrastructure / quality assurance tools;
>- but tragedy of the commons;
>- more specifically, developing/improving such development tools only pays 
>off individually for developers with a sufficiently high volume of activity 
>(cf. 
>https://github.com/sagemath/sage/graphs/contributors?from=2020-01-01=2024-04-09=c);
>- there may also be a technical barrier that prevents developers from even 
>reviewing a PR that makes changes to these files;
>- hence, waiting for reviewers to approve a PR and waiting for the Release 
>Manager to merge it adds too much delay and friction.
>
>3. Examples (all PRs authored by me, waiting for review):
>- "CI build, doc-build: Run containers explicitly, separate jobs for 
>pyright, build, modularized tests, long tests" 
>(https://github.com/sagemath/sage/pull/36498) waiting for review since Oct 
>21, 2023
>- "GH Actions: Build platform-independent wheels of sagemath-environment, 
>sage-setup, sage-sws2rst for PyPI" 
>(https://github.com/sagemath/sage/pull/37099) waiting for review since Feb 5
>- "CI: Update Linux platforms / runners" waiting for review since Feb 14
>- "GH Actions: Build macOS arm64 wheels" 
>(https://github.com/sagemath/sage/pull/37503) waiting for review since Feb 
>28
>- "CI Build: Fix "test modularized distributions" 
>(https://github.com/sagemath/sage/pull/37750) waiting for review since Apr 4
>- "dist.yml: Download optional/experimental tarballs for GitHub Release 
>assets" (https://github.com/sagemath/sage/pull/37762) waiting for review 
>since Apr 6
>
>4. Non-examples (all PRs authored by me, waiting for review):
>- "CI Build: Show segfaults using GitHub annotations" 
>(https://github.com/sagemath/sage/pull/37738, waiting for review) -- this 
>makes changes in sage.doctest, so would continue to be reviewed normally
>- "tox.ini: Add environments ruff, ruff-minimal; GH Actions: run 
>ruff-minimal" (https://github.com/sagemath/sage/pull/37453, waiting for 
>review) -- this also makes changes in src/tox.ini and src/doc, so would 
>continue to be reviewed normally
>- "src/tox.ini (coverage:run): Set concurrency = multiprocessing,threads" 
>(https://github.com/sagemath/sage/pull/37010) -- makes changes in 
>src/tox.ini, so would continue to be reviewed normally
>- "sage -tox -e pyright: Update, speed up, isolate" 
>(https://github.com/sagemath/sage/pull/36515) -- makes changes to 
>pyrightconfig.json and src/tox.ini, so would continue to be reviewed 
>normally
>
>

-- 
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, 

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[Dima Pasechnik]

On Mon, Apr 8, 2024 at 7:19 PM Matthias Koeppe 
wrote:

> I need your help on these PRs. Please vote.
>
> Special expertise is not required for voting. You will find the comments
> in these PRs instructive -- also as illustration for a (long overdue) 
> *discussion
> about governance and review standards* in the Sage project.
>

> *1. Please vote +1 on both https://github.com/sagemath/sage/pull/36561
>  and
> https://github.com/sagemath/sage/pull/37138
> * ("Move metadata from
> setup.cfg to pyproject.toml").
> These are trivial "chore" PRs. They update metadata of our
> pip-installable packages "sage-conf" and "sagemath-standard" to the latest
> format.
> These straightforward and appropriately focused PRs have been held back by
> months by *bundling the review of the PRs with unrelated issues.* I call
> this "artificial friction"; see the discussion in the PRs. To help overcome
> this artificial friction, please vote.
>

This is not true - the friction is not artificial. It is due to legitimate
concerns of developers who are not interested in
spending all of their time on ever growing "Sage the distribution", and/or
who see little merit in Matthias' sagelib modulalisation
project, which uses Python features (most of all, namespace packages)
not universally supported by a number of important tools, such as  Cython
and pytest.

Please vote -1 on these two PRs (there are more similar PRs around). This
will force Matthias to reconsider his priorities, and enable
other voices to be heard. So far, Matthias refuses to reassess the
priorities of the project - instead he puts away
the criticism as "abuse" directed at him.

As a result of this friction, a number of developers have left or about to
leave the project, or are discussing
creation of a hard fork of Sage.

In particular, I think it is urgent to re-access the need for sagelib
modularisation in its current form.
It appears to be harming the project, and its benefits are questionable.

As well, it's urgent to make Sage more modular on the level of Sage the
distribution - the "interesting" part, sagelib,
is getting increasingly entangled in Sage the distribution (which is just a
constantly growing pile of Jupyter, Python, ans Sphinx-related
packages, which Matthias and few others are all too keen on hoarding).
This in particular makes Sage harder and harder to package for Linux, and
other, distributions (Packaging of Sage for Debian/Ubuntu and
Fedora has been stalled for years already).


> *2. Please vote -1 on both https://github.com/sagemath/sage/pull/37387
>  and
> https://github.com/sagemath/sage/pull/36951
> . *These PRs are about a
> Developer Experience issue, namely the workflow on GitHub that notifies
> developers when the HTML documentation is ready for inspection by PR author
> and reviewers. Now a few developers have made it known that they are
> annoyed by the notifications (whether received by email or the notification
> tool on the GitHub website), and the PRs seek to turn off most or all of
> the notifications. That *these notifications enable a productive
> notification-driven development style, and that the notifications serve the
> project's need for quality control on the formatted documentation*, has
> not received meaningful consideration.
>

We are not an enterprise with full-time developers 24 hours a day ready to
react to these endless notifications.
They are spam for almost everyone, and should be turned off.
Please, please vote +1 on them.

What's happening on these PRs is exactly what I had cautioned about in
> https://github.com/sagemath/sage/pull/36726#issuecomment-1820148873
> regarding the (then-proposed, now established) system of majority votes as
> a conflict resolution mechanism for PRs. To balance it, we need the
> involvement of the larger developer community: please vote.
>

No, what we really need is an honest general discussion on directions the
project is taking.
Right now it's going  nowhere, to ever growing pile of bugs noone even
talks about addressing (e.g. Pynac; Maxima;
memory leaks related to Singular; etc etc), to huge package bloat, etc.

Dima

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq1RJSA_WNgvjdiSboxYJ2e7X3h2bwOYh_du82aekdtO0A%40mail.gmail.com.

Re: [sage-devel] Bug in .subgroup?

[Dima Pasechnik]

On Thu, Apr 4, 2024 at 11:07 AM Dima Pasechnik  wrote:
>
> Yes, it's surely a bug; this example gives |gg|=2^27 (wow!), or a smaller one:
>
> sage: g=AbelianGroup([2,2])
> sage: gg=g.subgroup(g.list())
> sage: gg.cardinality().factor() # what?
> 2^3
> sage: g.cardinality().factor()
> 2^2
>
> Maybe related to https://github.com/sagemath/sage/pull/36986 ?

yes, indeed, it came from https://github.com/sagemath/sage/pull/36986
I've opened https://github.com/sagemath/sage/issues/37744

>
> On Thu, Apr 4, 2024 at 10:24 AM 'B. L.' via sage-devel
>  wrote:
> >
> > Hello,
> > to me it seems that with 10.3 there might be a bug in ".subgroup", see 
> > example below. The subgroup cardinality is wrong and the equality test of 
> > the group and the subgroup generated by all group elements yields "False". 
> > In previous versionls of SAGE this worked as expected.
> > Can anybody help?
> > Thanks and kind regards,
> > Barbara
> >
> >
> > sage: g = AbelianGroup([4, 4])
> > sage: gg = g.subgroup(g.list())
> > sage: g
> > Multiplicative Abelian group isomorphic to C4 x C4
> > sage: gg
> > Multiplicative Abelian subgroup isomorphic to C4 x C4 generated by {f1, 
> > f1^2, f1^3, f0, f0*f1, f0*f1^2, f0*f1^3, f0^2, f0^2*f1, f0^2*f1^2, 
> > f0^2*f1^3, f0^3, f0^3*f1, f0^3*f1^2, f0^3*f1^3}
> > sage: g.cardinality()
> > 16
> > sage: gg.cardinality()
> > 134217728
> > sage: g==gg
> > False
> >
> > --
> > 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 visit 
> > https://groups.google.com/d/msgid/sage-devel/55ecbb00-3927-4339-8cb3-f68347358446n%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq17xtj%2BroU9QWBMF6DV4HmPRg4EmgpXnLRzsad%2BZ8k6MA%40mail.gmail.com.

Re: [sage-devel] Bug in .subgroup?

[Dima Pasechnik]

Yes, it's surely a bug; this example gives |gg|=2^27 (wow!), or a smaller one:

sage: g=AbelianGroup([2,2])
sage: gg=g.subgroup(g.list())
sage: gg.cardinality().factor() # what?
2^3
sage: g.cardinality().factor()
2^2

Maybe related to https://github.com/sagemath/sage/pull/36986 ?

On Thu, Apr 4, 2024 at 10:24 AM 'B. L.' via sage-devel
 wrote:
>
> Hello,
> to me it seems that with 10.3 there might be a bug in ".subgroup", see 
> example below. The subgroup cardinality is wrong and the equality test of the 
> group and the subgroup generated by all group elements yields "False". In 
> previous versionls of SAGE this worked as expected.
> Can anybody help?
> Thanks and kind regards,
> Barbara
>
>
> sage: g = AbelianGroup([4, 4])
> sage: gg = g.subgroup(g.list())
> sage: g
> Multiplicative Abelian group isomorphic to C4 x C4
> sage: gg
> Multiplicative Abelian subgroup isomorphic to C4 x C4 generated by {f1, f1^2, 
> f1^3, f0, f0*f1, f0*f1^2, f0*f1^3, f0^2, f0^2*f1, f0^2*f1^2, f0^2*f1^3, f0^3, 
> f0^3*f1, f0^3*f1^2, f0^3*f1^3}
> sage: g.cardinality()
> 16
> sage: gg.cardinality()
> 134217728
> sage: g==gg
> False
>
> --
> 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 visit 
> https://groups.google.com/d/msgid/sage-devel/55ecbb00-3927-4339-8cb3-f68347358446n%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq12wP_ANzFv7RqPVrw1CTDRa8MuU0MA%2BXBXS6RnUGSKHQ%40mail.gmail.com.

Re: [sage-devel] Mysterious .sage behavior

[Dima Pasechnik]

On 31 March 2024 15:23:24 CEST, Marc Culler  wrote:
>This is a follow-up to a user's query in a Sage_macOS issue. 
>
>The current sage-env script contains the excerpt below.  It seems pretty 
>confusing that  Sage would create a directory named .sage/ipython-5.0.0 
>when Sage is shipping IPython 8.18.1.  What would be wrong with calling the 
>directory .sage/profiles/ipython--v1, and moving to ipython--v2 when 
>necessary?  Similarly for jupyter and matplotlib.

I must say I don't know what kind of problems these versioned names are meant 
to solve.

Dima
>
>- Marc
>
>if [ -z "$IPYTHONDIR" ]; then
># We hardcode a version number in the directory name. The idea is
># that we keep using the same version number as long as that is
># possible. Only when some future IPython version really requires
># a new structure for the $IPYTHONDIR should this version number be
># changed to the new IPython version.
>export IPYTHONDIR="$DOT_SAGE/ipython-5.0.0"
>fi
>
>if [ -z "$JUPYTER_CONFIG_DIR" ]; then
># We hardcode a version number in the directory name. The idea is
># that we keep using the same version number as long as that is
># possible. Only when some future Jupyter version really requires
># a new structure for the $JUPYTER_CONFIG_DIR should this version
># number be changed to the new jupyter_core version.
>export JUPYTER_CONFIG_DIR="$DOT_SAGE/jupyter-4.1"
>fi
>
>if [ -z "$MPLCONFIGDIR" ]; then
># We hardcode a version number in the directory name. The idea is
># that we keep using the same version number as long as that is
># possible. Only when some future Matplotlib version really requires
># a new structure for the $MPLCONFIGDIR should this version
># number be changed to the new matplotlib version.
>export MPLCONFIGDIR="$DOT_SAGE/matplotlib-1.5.1"
>fi
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/49795DE7-7E49-411F-8BDC-098473D6FC7D%40gmail.com.

Re: [sage-devel] Re: xz/liblzma has been compromised

[Dima Pasechnik]

On Fri, Mar 29, 2024 at 7:42 PM Dima Pasechnik  wrote:
>
> On Fri, Mar 29, 2024 at 7:39 PM Matthias Koeppe
>  wrote:
> >
> > Workaround with the Sage distribution: "./configure 
> > --without-system-liblzma --without-system-xz"
> > (Our xz package dates back from before the attackers were born;)
> >
> > Incidentally, the cryptographic protection of the Sage distribution is 
> > wildly insufficient.
> > I've opened https://github.com/sagemath/sage/issues/37691 for this -- any 
> > takers?
>
> I'd switch to sha256.
> And require PGP-signed commits, etc.
>
> well, I can't even comment on that issue :-)

By the way, the essential part of xz backdoor was sneaked in as a
modified  copy of a gnulib m4 macros file.
As this is "the" way to use gnulib - just vendor what they provide in
your source code - one may wonder again
about the virtues of vendoring a lot of code.
Potentially, any tarfile we host  may contain an exploit.

As well as anything produced on CI, VM, or, real, hosts running
compromised OS (latest unstable versions of Debian and Fedora were
compromised with this xz hack, Homebrew was, as well). So this is
something to review urgently, too.

Dima




>
>
> >
> >
> > On Friday, March 29, 2024 at 12:18:24 PM UTC-7 Dima Pasechnik wrote:
> >>
> >> https://www.openwall.com/lists/oss-security/2024/03/29/4
> >>
> >> if your have xz 5.6.0 or 5.6.1 installed (e.g. Debian testing/unstable)
> >> you have a backdoored xz.
> >
> > --
> > 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 visit 
> > https://groups.google.com/d/msgid/sage-devel/d75e7cc9-9743-4c20-b502-431d400dc5f2n%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq1w9X3aZ3z8U%3DC_BFD8Ffh_tE3JfNBGoSV%3DYYiFE2Guxg%40mail.gmail.com.

[sage-devel] testing notebooks with pytest --nbval ?

[Dima Pasechnik]

Is anyone testing their Sage Jupyter notebooks with pytest --nbval ?
I imagine that for collections of notebooks this can be used to set up CI tests.

Dima

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3qx3rwqCnUReDknQ7Rn38LwSbZ0LzGnQsvjh7k6EHkxA%40mail.gmail.com.

[sage-devel] Re: xz/liblzma has been compromised

[Dima Pasechnik]

and Homebrew.
Please upgrade your Homebrew. It should do a downgrade:

`brew upgrade` now "upgrades" xz from 5.6.1 -> 5.4.6

On Fri, Mar 29, 2024 at 7:36 PM Dima Pasechnik  wrote:
>
> aand Conda: https://anaconda.org/anaconda/xz shows version 5.6.1
>
> On Fri, Mar 29, 2024 at 7:18 PM Dima Pasechnik  wrote:
> >
> > https://www.openwall.com/lists/oss-security/2024/03/29/4
> >
> > if your have xz 5.6.0 or 5.6.1 installed (e.g. Debian testing/unstable)
> > you have a backdoored xz.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3%3DOQprCMf%3Dv2ubAoZVhFEHBSjf52LT9XHAR8nRiOR3GA%40mail.gmail.com.

Re: [sage-devel] Re: xz/liblzma has been compromised

[Dima Pasechnik]

On Fri, Mar 29, 2024 at 7:39 PM Matthias Koeppe
 wrote:
>
> Workaround with the Sage distribution: "./configure --without-system-liblzma 
> --without-system-xz"
> (Our xz package dates back from before the attackers were born;)
>
> Incidentally, the cryptographic protection of the Sage distribution is wildly 
> insufficient.
> I've opened https://github.com/sagemath/sage/issues/37691 for this -- any 
> takers?

I'd switch to sha256.
And require PGP-signed commits, etc.

well, I can't even comment on that issue :-)


>
>
> On Friday, March 29, 2024 at 12:18:24 PM UTC-7 Dima Pasechnik wrote:
>>
>> https://www.openwall.com/lists/oss-security/2024/03/29/4
>>
>> if your have xz 5.6.0 or 5.6.1 installed (e.g. Debian testing/unstable)
>> you have a backdoored xz.
>
> --
> 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 visit 
> https://groups.google.com/d/msgid/sage-devel/d75e7cc9-9743-4c20-b502-431d400dc5f2n%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3zGy3RRBaUpi_rS57dG7s6fP5i78K2Pseyw5paN6_roQ%40mail.gmail.com.

[sage-devel] Re: xz/liblzma has been compromised

[Dima Pasechnik]

aand Conda: https://anaconda.org/anaconda/xz shows version 5.6.1

On Fri, Mar 29, 2024 at 7:18 PM Dima Pasechnik  wrote:
>
> https://www.openwall.com/lists/oss-security/2024/03/29/4
>
> if your have xz 5.6.0 or 5.6.1 installed (e.g. Debian testing/unstable)
> you have a backdoored xz.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3TfwUtW%2B4ZV0GMr4egCUsrgjHTrTtzuVeKi5ARj4tuUA%40mail.gmail.com.

[sage-devel] xz/liblzma has been compromised

[Dima Pasechnik]

https://www.openwall.com/lists/oss-security/2024/03/29/4

if your have xz 5.6.0 or 5.6.1 installed (e.g. Debian testing/unstable)
you have a backdoored xz.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0T0eMogYB0K6isVEQy%3DL2JGfQMPrQwEXF_ECMmtiA4%2Bw%40mail.gmail.com.

Re: [sage-devel] Something wrong kept happening , pls help

[Dima Pasechnik]

On Friday, March 29, 2024 at 3:50:23 AM UTC Cassidy Taylor wrote:


Thank you for your reply!
However I cant change or update my conda environment cause the code I want 
to replicate (which called AgentNet)  have already specified restrictions 
on conda environment and other needed library versions such as pytorch 
1.11.0. 

But I will try to download sage 10.2 on my present conda 11.3 environment.


We are talking about https://github.com/KarolisMart/AgentNet

I am not entirely sure what the problem is. I am not sure why you ended up 
with errors building GMP.
Please explain exactly what you did.
I suppose you
1) installed Conda (on a Linux box or a Linux VM)
2) checked out https://github.com/KarolisMart/AgentNet
3) ran "conda env create -f environment.yml"

None of this should involve any compilation - as it's meant to use 
pre-built Conda packages.

 

Anyway , thank you again and wish you have a great day!
在2024年3月27日星期三 UTC+8 17:42:28 写道：

Hello,

your installation shows sage 9.6, but conda carries sage 10.2 now:
https://anaconda.org/conda-forge/sage

That's one you should be getting if you follow
https://doc.sagemath.org/html/en/installation/conda.html

Could it be that your conda environment needs an update?

HTH
Dima



On Wed, Mar 27, 2024 at 9:11 AM Cassidy Taylor  wrote:

Everytime I tried to download Sagemath in the conda environment I created 
on Ubuntu , the terminal kept showing this error(fig.1) . It shows that 
there is something wrong with the download of gmp-6.2.1(fig.2) , seemed 
like it is my C++ compiler not available. 
[image: 微信图片_20240327153329.png]

[image: 微信图片_20240327153257.png]

​BUT I have searched for so many days and so many ways , and I have checked 
that my C++ compiler is already downloaded(fig.3) god knows how many times, 
besides I also downloaded gmp-6.2.1.tar.zst on my ubuntu system. 
​
[image: 微信图片_20240327153307.png]
Pls reply ASAP , this really set back my postgraduate career...
Looking forward to your answering , thank you !

-- 
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+...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e6cad138-72a3-4406-b951-6b5ec4c40ed8n%40googlegroups.com
 

.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/914a98f7-837c-4055-ae8e-e64dd5518a6dn%40googlegroups.com.

Re: 与“[sage-devel] Something wrong kept happening , pls help”相关的私人帖子

[Dima Pasechnik]

On Thu, Mar 28, 2024 at 2:08 PM Cassidy Taylor  wrote:

> Happy to hear you back! 
> I have two questions want to ask now , first one is why I couldnt see my
> reply on Google Group sage-devel in our conversation? Seems like I can only
> start a conversation but cannot reply anyone?樂
>

you can use either a desktop/laptop browser to assess Google Group
interface - there you can reply.

Or you can use email interface  - sending emails and replies to
sage-devel@googlegroups.com.
(I cc this message there)



And the second one is kinda interesting which is the code I want to
> reproduce named AgentNet is "another" AgentNet , it is launched in 2023 on
> ICLR with full name "AGENT-BASED GRAPH NEURAL NETWORKS" and the author
> is Karolis Martinkus, the screenshot of this code is fig.1.
>

it seems to be using Sage in a very restricted way - using it to  generate
some particular graphs.
You cam remove the dependence on sage with a little work (adapting Sage's
code to using networkx's graphs instead)

Otherwise you could try removing fixed version constraints in AgentNet's
environment.yml, in hope that then Conda will be able to resolve the
environment.

HTH
Dima


>
> Dima Pasechnik  于2024年3月28日周四 20:34写道：
>
>>
>>
>> On Thu, Mar 28, 2024 at 3:54 AM Cassidy Taylor 
>> wrote:
>>
>>> Thank you for your reply!
>>> However I cant change or update my conda environment cause the code I
>>> want to reproduce (which is called  AgentNet) have already  specified
>>> restrictions on conda environment and other required library versions.
>>> But I wil try to download sage 10.2 on my conda-11.3 environment.
>>>
>>
>> AgentNet has not been updated for 7 years, and its GitHub repo is
>> "archived"
>> Getting it to work in 2024 might need more work - or, perhaps, using a
>> different tool all together.
>>
>> https://github.com/yandexdataschool/AgentNet
>>
>>
>>
>>> Anyway, thank you again and wish you have a great day!
>>>
>>> 在2024年3月27日星期三 UTC+8 17:42:28 写道：
>>>
>>> Hello,
>>>
>>> your installation shows sage 9.6, but conda carries sage 10.2 now:
>>> https://anaconda.org/conda-forge/sage
>>>
>>> That's one you should be getting if you follow
>>> https://doc.sagemath.org/html/en/installation/conda.html
>>>
>>> Could it be that your conda environment needs an update?
>>>
>>> HTH
>>> Dima
>>>
>>>
>>>
>>> On Wed, Mar 27, 2024 at 9:11 AM Cassidy Taylor 
>>> wrote:
>>>
>>> Everytime I tried to download Sagemath in the conda environment I
>>> created on Ubuntu , the terminal kept showing this error(fig.1) . It shows
>>> that there is something wrong with the download of gmp-6.2.1(fig.2) ,
>>> seemed like it is my C++ compiler not available.
>>> [image: 微信图片_20240327153329.png]
>>>
>>> [image: 微信图片_20240327153257.png]
>>>
>>> BUT I have searched for so many days and so many ways , and I have
>>> checked that my C++ compiler is already downloaded(fig.3) god knows how
>>> many times, besides I also downloaded gmp-6.2.1.tar.zst on my ubuntu
>>> system.
>>>
>>> [image: 微信图片_20240327153307.png]
>>> Pls reply ASAP , this really set back my postgraduate career...
>>> Looking forward to your answering , thank you !
>>>
>>> --
>>> 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+...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/sage-devel/e6cad138-72a3-4406-b951-6b5ec4c40ed8n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/sage-devel/e6cad138-72a3-4406-b951-6b5ec4c40ed8n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2sZpW58yOT07_99bGw_AZXZVbpT%3D_yoWfpyp4gnhja6g%40mail.gmail.com.

[sage-devel] Re: Bug in quadratic_defect

[Dima Pasechnik]

On Sunday, March 24, 2024 at 4:02:25 PM UTC Nils Bruin wrote:

On Sunday 24 March 2024 at 04:41:25 UTC-7 Przemysław Koprowski wrote:

Let me just comment on your words "searching the source, this routine isn't 
actually used elsewhere in sage" (here: 
https://github.com/sagemath/sage/pull/37657). It is not entirely true, 
because, as far as I know, the method is_padic_square (in the class of a 
number field element) internally relies on the quadratic_defect.

Thanks! I based my assessment on the search result that github returned for 
`quadratic_defect`. It only returned two hits for me.
Lesson: Don't rely on github search. It's far from exhaustive. 


indeed, entries in src/sage/rings/number_field/number_field.py are just 
missing in GitHub search. I filed a "feedback". 

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/1c8cefe6-0a14-4a93-91fb-da1c09ab5984n%40googlegroups.com.

Re: [sage-devel] Re: Bug in quadratic_defect

[Dima Pasechnik]

issues are for the cases without an already ready solution, or for something 
longer term than just one PR

On 23 March 2024 16:55:50 GMT, Nils Bruin  wrote:
>Thanks! this is now 
>
>https://github.com/sagemath/sage/issues/37656
>
>or
>
>https://github.com/sagemath/sage/pull/37657
>
>(I'm still a bit murky on what issues are used for)
>
>-- 
>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 visit 
>https://groups.google.com/d/msgid/sage-devel/ef63a7c8-845f-4cee-90c9-beca953568ban%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/70996D3D-A3D4-4EC0-9DE4-076D23D1F873%40gmail.com.

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

[Dima Pasechnik]

On 22 March 2024 23:01:47 GMT, Matthias Koeppe  wrote:
>On Friday, March 22, 2024 at 3:31:07 PM UTC-7 Dima Pasechnik wrote:
>
>They are not really "tested" - just as much of the rest of Jupiter stuff is 
>not tested in our CI.
>
>(installability - yes, 
>
> 
>The installability of it is exactly what was broken in Sage 10.2. 
>We test automatically so that we do not have to wait for users' bug reports.
>
>in a strange non-standard environment,
>
>
>The installability of the package is tested in the relevant environment, 
>namely the Sage venv.
>
>I need to ask you to drop these mischaracterizations of the Sage venv as 
>something "strange" or "non-standard". There's no technical basis for this, 


Of course it is strange and non-standard.
A custom venv, non-standard commands to launch things, pinned to seemingly 
random values versions of packages, etc.

>and repeating it is harmful to the project. 
>https://groups.google.com/g/sage-devel/c/OeN8o14s6Jc
>
>but whether the notebooks actually work, who knows)
>
>
>We know because the reviewer of the upgrade 
>ticket https://github.com/sagemath/sage/pull/37478 tested it. 

you claimed they are tested by CI, not by humans.


>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/61B136FB-2D22-4523-A59B-07ED765DF12B%40gmail.com.

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

[Dima Pasechnik]

I don't think that one would look for e.g. a Jupyter interface to Pari-GP in 
the catalog of sage spkgs.

The natural place is Pari-GP website.

They are not really "tested" - just as much of the rest of Jupiter stuff is not 
tested in our CI.
(installability - yes, in a strange non-standard environment, but whether the 
notebooks actually work, who knows)

pytest has a special plugin, nbmake, to test notebook, and testing notebook 
kernels/clients ought to involve running actual notebooks on them.

Jupyter interface for Singular seems to be an old beta, and it's just funny to 
try to offer anything for R, given how big R is compared to Sage.

Let's drop them all from Sage distribution.




On 22 March 2024 21:40:24 GMT, Matthias Koeppe  wrote:
>On Friday, March 22, 2024 at 12:02:30 PM UTC-7 Nils Bruin wrote:
>
>It looks to me like a project that can easily not be offered as an spkg, 
>with minimal effect, but I might be overlooking something. 
>
>
>What you might be overlooking is that 
>- our catalog of SPKGs is a useful curation that serves our users;
>- our workflows on GH Actions automatically test the packages in our 
>catalog on every release.
>
>-- 
>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 visit 
>https://groups.google.com/d/msgid/sage-devel/106f3ff1-42c1-469b-a536-7de0857c0080n%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CFECCC91-D26A-483F-A4FC-4AB4BBD298A5%40gmail.com.

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

[Dima Pasechnik]

On 22 March 2024 19:02:30 GMT, Nils Bruin  wrote:
>On Friday 22 March 2024 at 11:22:12 UTC-7 Matthias Koeppe wrote:
>
>10 days ago, the previous maintainer, Vincent Delecroix, announced that he 
>steps down from maintaining it. 
>https://groups.google.com/g/sage-devel/c/fy1ei6bLtmc
>I did some emergency maintenance and on that occasion I added the 
>"Maintainers" field in the metadata. Nobody specifically committed to 
>maintaining it or made a plan, as far as I know.
>
>
>Thanks for that. Obviously, when a maintainer steps down, some follow-up 
>should happen and by the location of the repository, the sagemath community 
>inherits the project in this case by default.
>
>It looks to me like a project that can easily not be offered as an spkg, 
>with minimal effect, but I might be overlooking something. So removing the 
>spkg could make sense.

There are also similarly disjoint from Sage packages r-jupyter, 
singular-jupyter, see


they can similarly be removed from Sage.
(but mentioned in the docs)


>
>Judging from the thread here:
>
>https://pari.math.u-bordeaux.fr/archives/pari-dev-2305/msg2.html
>
>this kernel is very much the basis for whatever Bill is considering. 
>Further down the thread, there is also a reference to Edgar Costa's kernel:
>
> https://github.com/edgarcosta/gp_kernel
>
>it looks like the discussion there may lead to a new home for the project 
>eventually (or another project to take its place).
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/B3CC456D-14F1-454B-A594-84CE4877765E%40gmail.com.

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

[Dima Pasechnik]

On Fri, Mar 22, 2024 at 5:13 PM Matthias Koeppe 
wrote:

> Let me just point out that the idea that "grant has ended, so we can kill
> its deliverables" is fundamentally flawed, and certainly is not and cannot
> be the position of our project.
>
> Infrastructure grants are exactly set up for their longer-term and broader
> impacts.
>

the bundling with SageMath was rather artificial in this case, and anyway
OpenDreamKit had more deliverables which were not meant to be bundled at
all.

Nobody says "kill it".
It's a standalone  PyPI project which does not use anything in SageMath,
nor it is used from SageMath.
It can be installed from PyPI if anyone needs it.




>
> Matthias
>
> On Friday, March 22, 2024 at 5:58:47 AM UTC-7 Dima Pasechnik wrote:
>
>> I don't see any reason for pari-jupyter being a sage package. It has
>> nothing in common with sagelib, it's a standalone jupyter kernel for
>> Pari-GP.
>> It has ended up in sage in OpenDreamKit times, to make granting agency
>> happy.
>>
>>
>> On Thu, Mar 21, 2024 at 8:42 AM Edgar Costa  wrote:
>>
>>> Bill Allombert has been working on a kernel via xeus:
>>> https://pari.math.u-bordeaux.fr/git/xeus-gp.git/
>>> Which addresses many of the issues with the current one.
>>> While we for its first stable release, I recommend mine:
>>> https://github.com/edgarcosta/gp_kernel/
>>> where I have addressed many of the issues, by going through the route
>>> that every cell is a temporary file, which is loaded in gp.
>>>
>>>
>>> On Thu, Mar 21, 2024 at 4:29 AM Matthias Koeppe 
>>> wrote:
>>>
>>>> - https://pypi.org/project/pari-jupyter/1.4.3rc1/
>>>> - I've added simple CODE_OF_CONDUCT and CONTRIBUTING files that just
>>>> point to the main sagemath repository
>>>> - using WIP sage-project-cookiecutter to simplify maintenance
>>>> https://github.com/sagemath/sage/pull/37541
>>>>
>>>> --
>>>> 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+...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/sage-devel/e822f186-6504-4516-9940-d03398f270b9n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/sage-devel/e822f186-6504-4516-9940-d03398f270b9n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>>> 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+...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/sage-devel/CA%2BiQ7x5FYigLmaKMc0wodYJB9BUqsdpyuy63RrxXoTcv%2BQKTJw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/sage-devel/CA%2BiQ7x5FYigLmaKMc0wodYJB9BUqsdpyuy63RrxXoTcv%2BQKTJw%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/c681d272-5561-4ef9-bdcc-33a1d503cee0n%40googlegroups.com
> <https://groups.google.com/d/msgid/sage-devel/c681d272-5561-4ef9-bdcc-33a1d503cee0n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2fci92VKp6c0mRxUt%2BVBzwBprMxQyENwsLa2n--uxHbw%40mail.gmail.com.

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

[Dima Pasechnik]

On Fri, Mar 22, 2024 at 3:01 PM Marc Culler  wrote:

> If one has Sage installed with the pari-jupyter package installed in Sage
> and one wants to run pari-jupyter, what does one do?  Is it equivalent to
> just installing pari-jupyter with pip and starting it up in the normal way?
>

I have pari+libpari installed systemwide. Then  installs pari-jupyter well
in a clean python 3.11 venv
Then I can run

pip install jupyterlab
jupyter kernelspec install --user
$(pwd)/share/jupyter/kernels/pari_jupyter


Then

jupyter lab

brings up a browser window with all the right notebooks, I can start
Pari-GP notebook, etc




> Does pari-jupyter use any components of Sage?  If the answers are "yes"
> and "no", then I agree that it is hard to see any reason why it should be a
> Sage package.
>

no, I don't think it does. Remove?

Dima


>
> - Marc
>
> On Friday, March 22, 2024 at 7:58:47 AM UTC-5 Dima Pasechnik wrote:
>
>> I don't see any reason for pari-jupyter being a sage package. It has
>> nothing in common with sagelib, it's a standalone jupyter kernel for
>> Pari-GP.
>> It has ended up in sage in OpenDreamKit times, to make granting agency
>> happy.
>>
>>
>> On Thu, Mar 21, 2024 at 8:42 AM Edgar Costa  wrote:
>>
>>> Bill Allombert has been working on a kernel via xeus:
>>> https://pari.math.u-bordeaux.fr/git/xeus-gp.git/
>>> Which addresses many of the issues with the current one.
>>> While we for its first stable release, I recommend mine:
>>> https://github.com/edgarcosta/gp_kernel/
>>> where I have addressed many of the issues, by going through the route
>>> that every cell is a temporary file, which is loaded in gp.
>>>
>>>
>>> On Thu, Mar 21, 2024 at 4:29 AM Matthias Koeppe 
>>> wrote:
>>>
>>>> - https://pypi.org/project/pari-jupyter/1.4.3rc1/
>>>> - I've added simple CODE_OF_CONDUCT and CONTRIBUTING files that just
>>>> point to the main sagemath repository
>>>> - using WIP sage-project-cookiecutter to simplify maintenance
>>>> https://github.com/sagemath/sage/pull/37541
>>>>
>>>> --
>>>> 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+...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/sage-devel/e822f186-6504-4516-9940-d03398f270b9n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/sage-devel/e822f186-6504-4516-9940-d03398f270b9n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>>> 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+...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/sage-devel/CA%2BiQ7x5FYigLmaKMc0wodYJB9BUqsdpyuy63RrxXoTcv%2BQKTJw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/sage-devel/CA%2BiQ7x5FYigLmaKMc0wodYJB9BUqsdpyuy63RrxXoTcv%2BQKTJw%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/2648a303-6b46-40d7-8a2e-1eb4f319e7ecn%40googlegroups.com
> <https://groups.google.com/d/msgid/sage-devel/2648a303-6b46-40d7-8a2e-1eb4f319e7ecn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3hnQBA%3DSRAnkC2ALCQD0fcbZGiCSrAKLYDwUu7wbUwCw%40mail.gmail.com.

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

[Dima Pasechnik]

I don't see any reason for pari-jupyter being a sage package. It has
nothing in common with sagelib, it's a standalone jupyter kernel for
Pari-GP.
It has ended up in sage in OpenDreamKit times, to make granting agency
happy.


On Thu, Mar 21, 2024 at 8:42 AM Edgar Costa 
wrote:

> Bill Allombert has been working on a kernel via xeus:
> https://pari.math.u-bordeaux.fr/git/xeus-gp.git/
> Which addresses many of the issues with the current one.
> While we for its first stable release, I recommend mine:
> https://github.com/edgarcosta/gp_kernel/
> where I have addressed many of the issues, by going through the route that
> every cell is a temporary file, which is loaded in gp.
>
>
> On Thu, Mar 21, 2024 at 4:29 AM Matthias Koeppe 
> wrote:
>
>> - https://pypi.org/project/pari-jupyter/1.4.3rc1/
>> - I've added simple CODE_OF_CONDUCT and CONTRIBUTING files that just
>> point to the main sagemath repository
>> - using WIP sage-project-cookiecutter to simplify maintenance
>> https://github.com/sagemath/sage/pull/37541
>>
>> --
>> 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 visit
>> https://groups.google.com/d/msgid/sage-devel/e822f186-6504-4516-9940-d03398f270b9n%40googlegroups.com
>> 
>> .
>>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/CA%2BiQ7x5FYigLmaKMc0wodYJB9BUqsdpyuy63RrxXoTcv%2BQKTJw%40mail.gmail.com
> 
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0QBQVeqx61hiak3MOeAiBGFNrKv0xBi53yQKtdB-%3Dr5w%40mail.gmail.com.

[sage-devel] Re: Vote: changes to Sage's Code of Conduct

[Dima Pasechnik]

+1

On Thursday, March 21, 2024 at 4:51:40 PM UTC John H Palmieri wrote:

> Dear Sage community,
>
> As announced at 
> https://groups.google.com/g/sage-devel/c/Xf6dbPLmKPY/m/p88auKlBAwAJ, I 
> propose some changes to the Code of Conduct. Those changes have been 
> discussed and modified based on feedback from several developers: visit 
> https://github.com/sagemath/sage/pull/37501 for details. Those changes 
> are now ready for a vote here on sage-devel. 
>
> Please vote: do you approve the changes to the Code of Conduct proposed at 
> https://github.com/sagemath/sage/pull/37501? Please vote on or before 
> March 31.
>
> In case you want a summary: the old code of conduct was pretty short, so 
> some details were added, and whole new sections were added. The proposed 
> changes were greatly inspired by similar documents from the SciPy and 
> NumFOCUS projects, and the proposed code now includes sections on 
> diversity, how to report potential violations,  names of the committee 
> members, and what is necessary to amend the document. There is also a new 
> document, a manual for the Code of Conduct Committee, which describes what 
> that committee does and what actions it might take to respond to reports. 
> That document is a modified version of SciPy's corresponding document.
>
> -- 
> John
>
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/ee207073-fb49-4878-bd5c-f5c3871b3a5an%40googlegroups.com.

[sage-devel] Re: Vote: Sage Code of Conduct

[Dima Pasechnik]

It's very important to note that with multiwinner approval voting, merely 
counting the votes per candidate and picking the top ones can lead to 
rather unfair results
(unlike in the single winner case).

For instance, if we elect k=3 candidates out of 6, say, $a,b,c,d,e,f$, and 
out of N=19 people, 10 vote for $a,b,c$, and 9 - for $d,e,f$, then, with 
approval voting, $a,b,c$ get elected (as $a,b,c$, get 10 votes each, more 
than $d,e,f$), and almost half the voters, 9 out of 10, get no 
representation of their views. 
This is obviously bad - in such a case a fair outcome would be something 
like $a,b,d$. Here "fair" has to be quantified, of course.
I've posted some details (and pointed at some solutions) on this here:
https://github.com/sagemath/sage/pull/37501#issuecomment-2004121053

It would be interesting to get the anonymised returned ballots and see if 
we did well on this occasion.
As well, adjustments ought to be made along the lines outlined above.

Dima

 
On Saturday, March 16, 2024 at 12:48:16 PM UTC kcrisman wrote:

> I also want to thank Vincent Delecroix, David Joyner, Harald Schilly, and 
> William Stein for their service on the committee up until this year.
>
>  
> Amen! 
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/ebc788db-79c3-4dc3-af55-23297d3c88c0n%40googlegroups.com.

[sage-devel] Re: Vote: Sage Code of Conduct

[Dima Pasechnik]

On Thursday, March 7, 2024 at 6:13:42 PM UTC David Roe wrote:

Dear Sage developers,
Thank you for those you nominated people for the committee following my 
request 
, and 
thank you for those of you willing to serve.  The nominees are

Nils Braun (nbr...@sfu.ca)


Braun? Or Bruin ?

I didn't notice when I voted (noticed only last night), as I blindly 
assumed it's Bruin,
and just went and searched for Nils Braun at SFU, (nobody found)
but that's too big a typo to let this unnoticed.

It can very well be that someone looked at Nils Braun ()
and was unable to figure out who this is - and just skipped.

Note that Nils Bruin has a github handle: https://github.com/nbruin
but it was not listed.

I think the vote shoud be re-done - if it's indeed not a mystical Nils Braun
on the ballot, and not Nils Bruin

Cheers,
Dima





 

J-P Labbé (jeanphil...@gmail.com, jplab on github)
John Palmieri (jhpalm...@gmail.com, jhpalmieri on github)
Viviane Pons (vivia...@gmail.com, VivianePons on github)
David Roe (roed...@gmail.com, roed314 on github)
Julian Rüth (julian...@fsfe.org, saraedum on github)
William Stein (wst...@gmail.com, williamstein on github)
Yuan Zhou (xiaoy...@gmail.com, yuan-zhou on github)

Please send votes to sage-c...@googlegroups.com* by Thursday, March 14.  We 
are using approval voting 
, so you can vote for 
as many candidates as you like.  The committee will include at least the 
top 5 candidates, and will be enlarged to include all tied candidates if 
there is a tie for 5th place.  Note that you can choose to vote for more or 
less than 5 candidates if you like.

Discussion of candidates is allowed (feel free to continue this thread), 
but please be respectful.  If you want to see the participation of these 
candidates in the Sage community, you can search by name on sage-devel 
 and on github 
.

Thanks for voting,
David
for the Sage Code of Conduct Committee

* We are replacing sage-...@googlegroups.com with sage-c...@googlegroups.com; 
they currently have the same membership.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/2a96cd6e-2509-4541-a3b5-8226c5ff2493n%40googlegroups.com.

Re: [sage-devel] VOTE: use the smooth model instead of the plane projective model for hyperelliptic curves

[Dima Pasechnik]

Sage's treatment of weighted polynomial rings is  buggy, cf. e.g.
https://github.com/sagemath/sage/issues/37167

this is something that should be addressed, one way or another



On Mon, Mar 11, 2024 at 9:31 PM Giacomo Pope  wrote:

> Dear all,
>
> *Summary*
>
> To better support arithmetic on Jacobians and have a more natural
> implementation of hyperelliptic curves, we should implement them as toric
> varieties with a weighted polynomial ring (1 : 3 : 1) instead of plane
> projective curves.
>
> *Yes / No*
>
> *Discussion*
>
> I am currently hoping to improve hyperelliptic curves and Jacobians of
> hyperelliptic curve in Sage. One big motivation for me is to try and get
> our computations with similar coverage to what exists in Magma to allow
> more academics in the field to benefit from the open-source community of
> Sage. The first main goal of this is for full featured arithmetic on the
> Jacobians of hyperelliptic curves.
>
> The big blocker for me currently is that currently Sage implements
> hyperelliptic curves in the plane projective model. This is not an issue
> for the current methods, and it also allows for sensible arithmetic on
> Jacobians when there is one point at infinity. However, the more natural
> model I believe is the smooth model which uses a weighted polynomial
> (weights of (1 : 3 : 1)). For example, this would allow us to have a
> natural way of performing arithmetic on the real model of hyperelliptic
> curves. Something important for my own research.
>
> I believe in terms of Sage code this means changing the hyperelliptic
> curves to be toric varieties rather than projective varieties and will
> ultimately lead to a lot of work in rewriting the classes.
>
> This is not unexpected though. For example the docstring of the `points()`
> method discusses the possibility of this change in the future:
> https://github.com/sagemath/sage/blob/e417e2205be84d6d567b8897527fa6945ad09bdb/src/sage/schemes/hyperelliptic_curves/hyperelliptic_finite_field.py#L805-L858
>
> This is associated with the sage-devel thread:
> https://groups.google.com/g/sage-devel/c/eKY85KwFldE which discusses
> progress on implementing arithmetic for Jacobians of hyperelliptic curves
> where there are 2, 1 (all cases) or 0 (only even genus) points at infinity.
> The work being done there uses a weighted polynomial ring to compute on the
> smooth model of hyperelliptic curves.
>
> *A note on inheritance*
>
> There is currently another hiccup in this transition. The class
> EllipticCurve_finite_field is a child of HyperellipticCurve_finite_field which
> seems to have happened at some point in the past when computing lists of
> points on the curve. As far as I can tell, this inheritance has no other
> used functionality. (Please correct me if I am missing something). I have
> shown in https://github.com/sagemath/sage/pull/37595 that this inherited
> method is always slower than using the group structure on the elliptic
> curve, so this inheritance can be removed once PR 37595 has been merged.
>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/dc78d787-5e82-4fdb-92cd-f299b71972c5n%40googlegroups.com
> 
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0Gs%2B8o244%2BJ6V9FsQgr9ReHMfM2VYoybRGA-czMpHvJQ%40mail.gmail.com.

Re: [sage-devel] Google Season of Docs – org application deadline April 2

[Dima Pasechnik]

On 11 March 2024 05:39:36 GMT, John H Palmieri  wrote:
>Dima's suggestion is appealing, and somewhat along those lines, I like the 
>idea changing Sage to use some standard documentation style 
>(https://github.com/sagemath/sage/issues/31044). If the program provides a 
>technical writer, though, those may not be suitable goals. 

The program only provides funds. Organisations have to find people to employ as 
"technical writers", but in a wide sense of the word, such a person can work on 
Sphinx-related stuff.

If one proposes the task  "documentation restructuring", Sphinx falls within 
the remit of such a task, IMHO.


> A quick glance 
>at least year's awards suggests a focus more on the writing and the 
>content, not how it is technically presented or generated.
>
>I don't know the whole history of our documentation, but at least some 
>versions of it were written by people with no knowledge of how to write 
>good software documentation — speaking only for myself and the parts that 
>I've worked on. I'm guessing that a technical writer's eyes might spot 
>things and see ways to improve them. We have lots of documentation, and I 
>think that some of it is very good, probably explains lots of things 
>clearly, but it may not always be written with the right audience in mind. 
>I think we could use more organization surrounding the tutorial, the 
>thematic tutorials, the PREP tutorials, constructions in Sage, a tour of 
>Sage, and the FAQ; this could very well make the documentation more 
>accessible and allow users to find documentation at the right level and 
>with the right content for what they're trying to do. All of that is the 
>documentation that we hope new users look at, and in my opinion that's 
>where we should focus.
>
>
>
>On Sunday, March 10, 2024 at 8:00:03 PM UTC-7 David Roe wrote:
>
>> I think the main question is who is willing to take the lead on writing 
>> and submitting applications (before April 2).  I don't have enough time in 
>> the next three weeks to do any writing, but I am willing to help brainstorm 
>> what form the proposal(s) should take and help edit proposals if someone 
>> else volunteers to write them.
>> David
>>
>> On Sun, Mar 10, 2024 at 6:18 PM Matthias Koeppe  
>> wrote:
>>
>>> Yes, we could prepare several proposals for separate projects. 
>>> One can see in the lists of past funded projects that some organizations 
>>> have received funding for two simultaneous projects.
>>>
>>> On Sunday, March 10, 2024 at 8:38:13 AM UTC-7 John Cremona wrote:
>>>
 Should there not be separate projects for documenting (1) building and 
 installing Sage; (2) using Sage (perhaps with some subject-specific 
 tutorials, some of which exist but might be worth updating) and (3) 
 documenting individual Sage functions and methods.

 These require different expertise, for example I recently found a badly 
 misleading docstring in the elliptic curves section, but only someone with 
 the right expertise would be able to rewrite it properly (yes, I will 
 create an issue for this soon!)

 John

 On Sun, 10 Mar 2024 at 15:03, David Roe  wrote:

> I think this would be good for Sage.  I think there are several 
> decisions to be made:
> * What are our most pressing documentation needs?  Personally, I think 
> we have a gap between the reference manual (which is extensive but has no 
> flow) and the thematic tutorials (which are written to tell a story but 
> are 
> just introductions).  I also poked around online for criticisms of Sage's 
> documentation and found complaints about not having separate pages for 
> each function  
> (compared to Mathematica's), some suggestions here 
> 
>  
> about focusing on aspects of Sage commonly used by beginners (like 
> plotting).
> * Who will be involved in applying and supervising the project?  This 
> could be a group or a single person.  I can help a bit, but I can't take 
> the lead.
> David
>
> On Sat, Mar 9, 2024 at 5:13 PM Matthias Koeppe  
> wrote:
>
>> SageMath could benefit from hiring a technical writer for a project to 
>> improve the Sage documentation. Google Season of Docs is a program 
>> that supports such projects. Some key facts:
>> - total project budget $5,000 - $15,000 USD (via OpenCollective) - 
>> https://developers.google.com/season-of-docs/docs/org-payments
>> - starts April 10 (or May 22 the latest), ends November 22, 2024 - 
>> https://developers.google.com/season-of-docs/docs/timeline
>>
>> Several of our peer projects (NumPy, Matplotlib, SymPy, R, Geomstats) 
>> are among the orgs that appear to have made successful use of this 
>> program 
>> in the past few years, see 
>> 

Re: [sage-devel] Google Season of Docs – org application deadline April 2

[Dima Pasechnik]

Not sure whether switching Sage to standard Sphinx/Python docbuilding tools
falls within the remit  of the Season of Docs, but it's surely a worthwhile
project - in particular if we can get funds for it.


On Sun, Mar 10, 2024 at 3:03 PM David Roe  wrote:

> I think this would be good for Sage.  I think there are several decisions
> to be made:
> * What are our most pressing documentation needs?  Personally, I think we
> have a gap between the reference manual (which is extensive but has no
> flow) and the thematic tutorials (which are written to tell a story but are
> just introductions).  I also poked around online for criticisms of Sage's
> documentation and found complaints about not having separate pages for
> each function  (compared
> to Mathematica's), some suggestions here
> 
> about focusing on aspects of Sage commonly used by beginners (like
> plotting).
> * Who will be involved in applying and supervising the project?  This
> could be a group or a single person.  I can help a bit, but I can't take
> the lead.
> David
>
> On Sat, Mar 9, 2024 at 5:13 PM Matthias Koeppe 
> wrote:
>
>> SageMath could benefit from hiring a technical writer for a project to
>> improve the Sage documentation. Google Season of Docs is a program that
>> supports such projects. Some key facts:
>> - total project budget $5,000 - $15,000 USD (via OpenCollective) -
>> https://developers.google.com/season-of-docs/docs/org-payments
>> - starts April 10 (or May 22 the latest), ends November 22, 2024 -
>> https://developers.google.com/season-of-docs/docs/timeline
>>
>> Several of our peer projects (NumPy, Matplotlib, SymPy, R, Geomstats) are
>> among the orgs that appear to have made successful use of this program in
>> the past few years, see
>> https://developers.google.com/season-of-docs/docs/2023/participants etc.
>>
>> Thoughts?
>>
>> --
>> 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 visit
>> https://groups.google.com/d/msgid/sage-devel/32bf06f2-6c35-40a9-855c-857c7af23799n%40googlegroups.com
>> 
>> .
>>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/CAChs6_mEgnbGQgJQHuT9rXLJZMtitYe1CxkUG9Fy0iFGqONRHg%40mail.gmail.com
> 
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq31NYoF%3D160t1iTw%3DH_0J9XYHqxHEwGrjuPAvRhFfNYCg%40mail.gmail.com.

Re: [sage-devel] Heun function support

[Dima Pasechnik]

On 10 March 2024 05:24:31 GMT, Steve Dodge  wrote:
>Hello, I was curious to know if there are any plans to include support for 
>Heun 
>functions  in Sage, or if anyone knows of a 
>reliable and well-documented implementation of them elsewhere.

https://reference.wolfram.com/language/guide/HeunAndRelatedFunctions.html

seem to describe an implementation


 I inquired 
>on Zulip  and David Roe suggest that I try asking here.
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/1B82B769-8661-4DE1-AD2B-8F379131EF60%40gmail.com.

Re: [sage-devel] Re: Labels and Reviewing

[Dima Pasechnik]

On 8 March 2024 14:11:41 GMT, 'Martin R' via sage-devel 
 wrote:
>I don't know exactly what case of blocking you have in mind,

on GitHub you can block a user - such a block prevents the blocked user from 
commenting and changing the status of your PRs and issues.

Currently there are a few Sage team members blocking each other.
I have made our CoC committee aware of this fact, but they are in no rush to 
rule on it, it seems.



>  but I'm going 
>to be bold and state that blocking among fellow developers (this is not 
>about private messages, right?) cannot really be a solution, in my opinion:
>
>* either there has been a substantial breach of conduct, in which case I 
>think the person cannot be part of sagemath anymore,
>* or otherwise, there shouldn't be a reason to block.
>
>I hope that we are talking about the empty set.
>
>Martin
>
>On Friday 8 March 2024 at 10:22:30 UTC+1 Dima Pasechnik wrote:
>
>> On Thu, Mar 7, 2024 at 8:39 PM David Roe  wrote:
>>
>>> Addressing a comment from Travis 
>>> <https://groups.google.com/g/sage-devel/c/IgBYUJl33SQ/m/CCKJ0dVCAAAJ> on 
>>> the voting thread:
>>>
>>> "but might want to consider cases when its 2 vs 1 as requiring at least 
>>> one other person involved. (Sorry for being late to realize this.)"
>>>
>>> This border case was actually one of the reasons that I suggested a 2 to 
>>> 1 threshold.  I think that if a single objector thinks that a PR should not 
>>> proceed and the author and reviewer both think it should, the onus should 
>>> be on the objector to find other developers who share their objections.
>>>
>>
>> As long as the issue of GitHub blocks is not resolved, this issue is moot. 
>> A developer can block their opponents
>> on GitHub to make sure there is not enough opposition to their PRs.
>>
>> David
>>>
>>> On Wed, Feb 28, 2024 at 10:53 AM Dima Pasechnik  wrote:
>>>
>>>>
>>>>
>>>> On Wed, Feb 28, 2024 at 11:29 AM Giacomo Pope  
>>>> wrote:
>>>>
>>>>> Apologies for the basic question in this thread, but recently I have 
>>>>> seen lots of conversation about the different labels and I want to 
>>>>> clarify 
>>>>> something for myself.
>>>>>
>>>>> In the past few PR I have made for Sage, randomised testing has 
>>>>> uncovered (usually) trivial bugs. I then write new PRs to fix these bugs.
>>>>>
>>>>> If there is code causing CI failure in random testing, should I mark 
>>>>> the fix for this as a "blocker", even if the chance of this failure is 
>>>>> small? I don't want to be melodramatic in my PR for fixes but I also want 
>>>>> to make sure I'm labelling things as expected,
>>>>>
>>>>
>>>> I don't think we ever tag anything but most onerous maths bugs as 
>>>> blockers
>>>> (e.g. we have a plenty of outstanding symbolic integration bugs).
>>>> That is, unless it's absolutely Earth-shuttering, don't use "blocker".
>>>>
>>>> Dima
>>>>  
>>>>
>>>>>
>>>>> On Wednesday, February 28, 2024 at 6:08:20 AM UTC David Roe wrote:
>>>>>
>>>>>> On Wed, Feb 28, 2024 at 1:01 AM Kwankyu Lee  wrote:
>>>>>>
>>>>>>> Thank you for making progress on these urgent issues. I suggest the 
>>>>>>> following:
>>>>>>>
>>>>>>> 1. Open two other new threads, each of which is for voting on each 
>>>>>>> proposal. 
>>>>>>> 2. On a proposal, it should be clear that *a positive vote (+1) is 
>>>>>>> for the whole proposal,* and if one is negative to any part of the 
>>>>>>> proposal, (s)he should give a negative vote (-1).  
>>>>>>>
>>>>>>
>>>>>> Voting threads seem reasonable.  I'll wait a day or two to see if 
>>>>>> people have any final comments before voting.
>>>>>>  
>>>>>>
>>>>>>> 3. A proposal is accepted if the number of positive votes is at least 
>>>>>>> twice of the number of the negative votes.
>>>>>>>
>>>>>>
>>>>>> Despite the fact that we're asking for this threshold in voting on a 
>>>>>> PR, the standard for votes on proposals on sage-devel is just a plain 
>&g

Re: [sage-devel] Re: Labels and Reviewing

[Dima Pasechnik]

On Thu, Mar 7, 2024 at 8:39 PM David Roe  wrote:

> Addressing a comment from Travis
> <https://groups.google.com/g/sage-devel/c/IgBYUJl33SQ/m/CCKJ0dVCAAAJ> on
> the voting thread:
>
> "but might want to consider cases when its 2 vs 1 as requiring at least
> one other person involved. (Sorry for being late to realize this.)"
>
> This border case was actually one of the reasons that I suggested a 2 to 1
> threshold.  I think that if a single objector thinks that a PR should not
> proceed and the author and reviewer both think it should, the onus should
> be on the objector to find other developers who share their objections.
>

As long as the issue of GitHub blocks is not resolved, this issue is moot.
A developer can block their opponents
on GitHub to make sure there is not enough opposition to their PRs.

David
>
> On Wed, Feb 28, 2024 at 10:53 AM Dima Pasechnik  wrote:
>
>>
>>
>> On Wed, Feb 28, 2024 at 11:29 AM Giacomo Pope 
>> wrote:
>>
>>> Apologies for the basic question in this thread, but recently I have
>>> seen lots of conversation about the different labels and I want to clarify
>>> something for myself.
>>>
>>> In the past few PR I have made for Sage, randomised testing has
>>> uncovered (usually) trivial bugs. I then write new PRs to fix these bugs.
>>>
>>> If there is code causing CI failure in random testing, should I mark the
>>> fix for this as a "blocker", even if the chance of this failure is small? I
>>> don't want to be melodramatic in my PR for fixes but I also want to make
>>> sure I'm labelling things as expected,
>>>
>>
>> I don't think we ever tag anything but most onerous maths bugs as blockers
>> (e.g. we have a plenty of outstanding symbolic integration bugs).
>> That is, unless it's absolutely Earth-shuttering, don't use "blocker".
>>
>> Dima
>>
>>
>>>
>>> On Wednesday, February 28, 2024 at 6:08:20 AM UTC David Roe wrote:
>>>
>>>> On Wed, Feb 28, 2024 at 1:01 AM Kwankyu Lee  wrote:
>>>>
>>>>> Thank you for making progress on these urgent issues. I suggest the
>>>>> following:
>>>>>
>>>>> 1. Open two other new threads, each of which is for voting on each
>>>>> proposal.
>>>>> 2. On a proposal, it should be clear that *a positive vote (+1) is
>>>>> for the whole proposal,* and if one is negative to any part of the
>>>>> proposal, (s)he should give a negative vote (-1).
>>>>>
>>>>
>>>> Voting threads seem reasonable.  I'll wait a day or two to see if
>>>> people have any final comments before voting.
>>>>
>>>>
>>>>> 3. A proposal is accepted if the number of positive votes is at least
>>>>> twice of the number of the negative votes.
>>>>>
>>>>
>>>> Despite the fact that we're asking for this threshold in voting on a
>>>> PR, the standard for votes on proposals on sage-devel is just a plain
>>>> majority (though of course I hope that we can come to a 2-1 consensus!).
>>>>
>>>> A minor suggestion for Proposal 2: for the label to be readable, I
>>>>> suggest "CI fix" for the name of the label (a blank between words).
>>>>>
>>>>
>>>> I'm happy to adjust the label to be "CI fix."
>>>>
>>>>
>>>>> We may use this thread to get more comments on the Proposals before
>>>>> opening voting threads.
>>>>>
>>>>> --
>>>>> 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+...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/sage-devel/554961a0-4ace-4317-bfcf-55b6a128bcden%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/sage-devel/554961a0-4ace-4317-bfcf-55b6a128bcden%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>> --
>>> 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 di

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[Dima Pasechnik]

On Tue, Feb 20, 2024 at 1:57 AM Nathan Dunfield 
wrote:

> On Monday, February 19, 2024 at 3:08:54 PM UTC-6 John H Palmieri wrote,
> responding to Dima:
>
> You said: "The difference between wheel packages vs pip packages is that
> the latter don't require pre-fetched wheels, and absence of the need for
> package (micro)management." The implication is that changing the package
> management system is, maybe not part of this proposal, but a next step. In
> other words, I'm getting this impression from your words, not by other
> "certain parties."
>
> You said: "My proposal is in fact aimed at reducing the number of pinned
> Sage dependecies, drastically." (You have made similar comments elsewhere
> in this thread.) How does (1) accomplish this? Either I'm missing something
> or you have not spelled everything out in your proposal.
>
> You said '"Allow" does not mean "Make all of the", it should be obvious.'
>
> "Allow" does not cause any changes to happen drastically. So what exactly
> are you proposing to accomplish these drastic changes? If you have a
> roadmap in mind, it would be helpful if you described it.
>
>
> My understanding is that allowing standard packages to be pip packages
> could greatly reduce the number of pinned Sage dependencies for two reasons:
>
> 1) a build-from-source or wheel package must explicitly pin its version,
> but, more importantly,
>
> 2) a pip package is allowed to install additional dependencies of PyPI
> that are not recorded anywhere in the Sage repo.
>
> A simple example is pytest.  Here it is as an optional pip package:
>
> https://github.com/sagemath/sage/tree/develop/build/pkgs/pytest
>
> To be upgraded to a standard package, under the current policy would need
> to be turned into a "wheel package" requires adding its dependencies like
> so:
>
> https://github.com/sagemath/sage/pull/37301
>
> Here, pytest has just a few dependencies, but jupyterlab has more like 50
> when you include dependencies of dependencies.
>
> 
>
> Personally, I think the current system of having everything pinned and
> explicitly recorded is the right choice, being more stable in my experience
> with other projects.
>

the experience of Sage macOS app is that it's better to leave Sage's
jupyterlab (with its ~193 packages) totally aside, and use the undiluted
upstream jupyterlab instead, see
https://github.com/sagemath/sage/issues/37533#issuecomment-1981375822




> In any event, switching to a pip package for e.g. jupterlab doesn't affect
> the final size or complexity of Sage as installed, just how many moving
> pieces there appear to be if you look in "sage/build/pkgs".
>
> Best,
>
> Nathan
>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/f81b8284-cb48-44fe-a3f7-158be2438335n%40googlegroups.com
> 
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2mMSU%3DjcjL%3DqJc69%3DGQ2pNDZt4FDVaJ%3Db%2Bb3N8gj72ww%40mail.gmail.com.

Re: [sage-devel] Jupyter Lab Sage menu

[Dima Pasechnik]

Recent versions (10.3.*) of Sage have jupyterlab included,
so it's a bit hard to tell what exactly is going
on without seeing versions, etc.
Conda seems to provide sage 10.2.

It could be that installation of jupyterlab on top of
sage breaks something in the environment.

Using 10.3.rc2 might be a better way.


On Wed, Mar 6, 2024 at 2:11 PM Viviane Pons  wrote:

> Dear all,
>
> I am working on a conda distribution of sage with jupyter lab. My conda
> environnement is only:
>
> name: jupyter-sage
>
> channels:
> - conda-forge
>
> dependencies:
> - jupyterlab
> - sage
>
>
> It works fine. I can launch it with "jupyter lab" or "sage
> --notebook=jupyterlab". I noticed that I had access to a bunch of tutorial
> links in the help menu (which is great!) but somehow this menu appears and
> disappears in ways that I don't understand at all. Do you know how / when
> this menu appears?
>
> I have attached two screenshots. The same worksheet with Sage kernel is
> opened in both. In one case, I have the menu, in the other not
>
> (it looks like the menu appears when I first open the notebook but then,
> at some point, it just disappears and never comes back unless I restart
> jupyter lab entirely)
>
> Best
>
> Viviane
>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/CAPAYYh6W7XRuFrjb0xBABO3%3DmayqKrLnNZH6CSXVDgNUhr9CCQ%40mail.gmail.com
> 
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq11f8zhNmN%3DXpWa6WEgMQjTqPxoO2eA1bJkgqT4FsNDug%40mail.gmail.com.

Re: [sage-devel] sensational bug!

[Dima Pasechnik]

Not confirmed here, either. We need more details about the machine, the OS,
the setup, etc.

Is it reproducible, i.e. if you repeat this command, does it fail again?

Dima

On Wed, Mar 6, 2024 at 9:47 AM 'Martin R' via sage-devel <
sage-devel@googlegroups.com> wrote:

> On
> https://github.com/sagemath/sage/actions/runs/8168335359/job/22330264302?pr=37545
>
> I see
>
> sage -t --long --random-seed=286735480429121101562228604801325644303
> src/sage/rings/tests.py
> **
> Error: Failed example:: Got: Random testing has revealed a problem in
> test_karatsuba_multiplication
> Please report this bug! You may be the first
> person in the world to have seen this problem.
> Please include this random seed in your bug report:
> Random seed: 305806809989734915896642073966608392384
> ValueError('Multiplication failed')
> test_karatsuba_multiplication(QQbar, 3, 3, numtests=2) # long time, needs
> sage.rings.number_field
> Expected nothing
> Got:
> Random testing has revealed a problem in test_karatsuba_multiplication
> Please report this bug! You may be the first
> person in the world to have seen this problem.
> Please include this random seed in your bug report:
> Random seed: 305806809989734915896642073966608392384
> ValueError('Multiplication failed')
>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/522bab60-a7e7-47f4-8d17-2c8ce329b85dn%40googlegroups.com
> 
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0kBnPtj-eeJ9RkbQwMcmo7hAJC%3D16DVvhUtOpnq5r%2BeQ%40mail.gmail.com.

Re: [sage-devel] VOTE: disputed PRs

[Dima Pasechnik]

I think this doesn't work. E.g. the proposal talks about setting PRs to "needs 
work", but banned by the PR's author team members can't do this.

That's why, as I said already, bans break the normal workflow, be it reviewing 
or voting.

On 4 March 2024 22:08:29 GMT, kcrisman  wrote:
>
>
>
>Dima, I think that if anyone is incapable of posting to a particular PR, 
>they should send email to someone who can post and ask them to record the 
>person's vote, resulting in a comment like "I am posting to record 1 
>negative vote from X, 2 positive votes from Y and Z".
>
>
>Yes, that would also go for those who do not choose to use GH.   
>
>-- 
>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 visit 
>https://groups.google.com/d/msgid/sage-devel/0ae620d2-8a84-4290-bf03-66f2d0d03264n%40googlegroups.com.

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/17148F09-3727-4760-88BC-924D13EA741B%40gmail.com.

Re: [sage-devel] VOTE: Use "CI Fix" label for merging into continuous integration runs

[Dima Pasechnik]

+1

On Mon, Mar 4, 2024 at 8:43 AM David Roe  wrote:

> The following proposal has been made several times the last few weeks: in
> PR #37428 , in this thread
>  and then in this
> thread .  It is
> orthogonal to the ongoing vote in this thread
> .  With no further
> discussion, I'm calling a vote.
>
> *Background*
>
> Starting in Sage 10.2, PRs with the Blocker label have been merged into
> all other PRs before running CI; see the changelog
> 
> and this post
>  for
> more details.  This has led to disagreements about whether this label
> should be applied.
>
> *Proposal*
> We use "CI Fix" rather than Blocker to determine whether an open PR should
> be merged before running CI.  Blocker will retain its previous meaning of a
> PR that should be merged before the next release is finished.  The process
> below describes how to resolve disagreements about whether the "CI Fix"
> label should be applied.
> a. Only PRs with positive review should be marked with the "CI Fix"
> label.  This should be done if both author and reviewer agree that it is
> appropriate, and a rationale should be given in a comment on the ticket.
> b. If a PR becomes disputed (as described in this proposal
> ), the "CI Fix"
> status can be voted on separately upon request; otherwise it should be
> applied if and only if positive review is applied.
>
> Voting will be open until Wednesday, March 13.
> David
>
>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/CAChs6_mYLUWXMU6AZKJGPKd2oz0AC_qAUjnGoD9Q9yixzNBC2w%40mail.gmail.com
> 
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0ovg%2B0rLyJpDBaew5eFvSBr70GDHN%3Da4cPS6J2xFNiEA%40mail.gmail.com.

Re: [sage-devel] VOTE: disputed PRs

[Dima Pasechnik]

David,
how about team members who are blocked on GitHub.
For GitHub voting to work, this has to be sorted out first.

Dima

On Mon, Mar 4, 2024 at 8:23 AM David Roe  wrote:

> With no further discussion on this thread
> , I'm calling a
> vote on a new process for resolving disagreements on a PR.
>
> *Proposal*
> It is now allowed to vote on disputed PRs directly on Github rather than
> bringing them to sage-devel.  Working things out amicably is preferable,
> and anyone is welcome to ask on sage-devel for more eyes on a PR.  If you
> notice a serious issue with a PR, it is acceptable to change it to Needs
> Work (and make a comment!) as an initial step, but if the author or
> reviewer do not agree then process below should be followed instead. This
> process is intended as a lower-intensity method for resolving
> disagreements, and full votes on sage-devel override the process described
> below.
> a. When there is disagreement about whether a PR should be merged, anyone
> may mark a PR as disputed.
> b. There is no scheduled vote, but rather an ongoing poll based on
> opinions expressed by developers on the PR (these opinions can be expressed
> via previous positive reviews or explicit comments giving approval).  The
> PR author is presumed to vote in favor; if they give up or no longer favor
> the PR they have the right to close the PR overall without any further
> voting.
> c. If the total number of positive votes is at least twice the number of
> negative votes, anyone involved may set the status to *positive review*;
> if the total number of positive votes is less than twice the number of
> negative votes, anyone involved may set the status to *needs review*.
> When either of these actions is taken, the person changing the status must
> list the people they are counting as positive and negative votes in a
> comment using @ mentions.
> d. The final decision on merging a disputed PR remains with the release
> manager, and we encourage the release manager to give enough time for
> everyone to express an opinion.
>
> Voting will be open until Wednesday, March 13.
> David
>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/CAChs6_n4az3_s16E%3DANOv_o%2B0SvavHwnpqKWYuOznGWTJoXqEg%40mail.gmail.com
> 
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq1%3D7Lo-WvhuOaQxubMX%3D2Vx%3DPcjACSivLQM3p4r786s%2Bw%40mail.gmail.com.

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

[Dima Pasechnik]

On Fri, Mar 1, 2024 at 5:58 PM 'Martin R' via sage-devel <
sage-devel@googlegroups.com> wrote:

> I don't understand - `degree` doesn't make much sense for Laurent series -
> there is no way to determine the degree of a LaurentSeries and no way to
> determine the degree of a LazyLaurentSeries with one minor exception -
> which is when it is known that the series terminates, but that's rare.
>

with series (power series, or formal Laurent series) the degree is
naturally the minimal degree,
not the maximal one. (for a non-0 series; ought to be -oo for 0).




> On Friday 1 March 2024 at 18:49:15 UTC+1 Giacomo Pope wrote:
>
>> Following this discussion, I have made a draft PR to change the degree
>> for *only* the LaurentPolynomialRing and I will see if the CI detects
>> anything.
>>
>> https://github.com/sagemath/sage/pull/37513
>>
>> I agree that if we change the LaurentPolynomialRing we should also change
>> the `LaurentSeriesRing`, at the moment `LazyLaurentSeriesRing` has no
>> method `degree()` but *does* have a `valuation()` method... so this is odd.
>>
>> On Friday, March 1, 2024 at 5:29:53 PM UTC Martin R wrote:
>>
>>> Could you expand on 'the whole valuation interpretation of "degree" goes
>>> out of the window'?  What do you mean with "valuation interpretation"?
>>>
>>> Is raising an exception out of the question?
>>>
>>> On Friday 1 March 2024 at 18:11:40 UTC+1 Nils Bruin wrote:
>>>
>>>> On Friday 1 March 2024 at 04:26:43 UTC-8 Dima Pasechnik wrote:
>>>>
>>>>
>>>> It seems that exactly the same algorithm will work (I didn't check
>>>> this!) for Laurent polynomials (they still form a Euclidean domain), and
>>>> there you better set degree(0)=-oo, otherwise it's going to be a problem.
>>>>
>>>> I think it's been established
>>>> that LaurentPolynomialRing(QQ,'x').zero().degree() == -1 is problematic.
>>>> With the definition that (1/x).degree() == -1 it clearly is.
>>>>
>>>> I think the question is more: do we have enough evidence that setting
>>>> degree(0) == -oo for *all* polynomial rings is significantly better (if
>>>> better at all) that it's worth the pain and incompatibilities that would
>>>> ensue from changing the rest of sage as well? That's not so clear to me.
>>>> From the perspective of multivariate polynomials, the whole valuation
>>>> interpretation of "degree" goes out of the window, so there "-1" is largely
>>>> available and quite possibly used extensively by the underlying libraries.
>>>>
>>>> I guess one could see what happens if the change is made to Laurent
>>>> polynomials (and Laurent series as well, perhaps?). Based on how that goes
>>>> one could re-evaluate degrees of 0 polynomials in other polynomial rings.
>>>>
>>>> Alternatively, we could deprecate degree on them in favour of using
>>>> valuation-inspired terms instead, where the extension val(0)=oo is more
>>>> universal. As Oscar's example in Matlab shows, the concept of degree gets
>>>> (mis)used for other, more implementation-oriented definitions as well, so
>>>> perhaps the term should just be avoided for Laurent polynomials.
>>>>
>>> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/b6ede155-fb29-4607-be7b-b028ce39e973n%40googlegroups.com
> <https://groups.google.com/d/msgid/sage-devel/b6ede155-fb29-4607-be7b-b028ce39e973n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3O5t0X6Arwt-A2%3D464xXMQsX87zm7a%3DE8JEf55ac5e0Q%40mail.gmail.com.

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

[Dima Pasechnik]

On Fri, Mar 1, 2024 at 5:11 PM Nils Bruin  wrote:

> On Friday 1 March 2024 at 04:26:43 UTC-8 Dima Pasechnik wrote:
>
>
> It seems that exactly the same algorithm will work (I didn't check this!)
> for Laurent polynomials (they still form a Euclidean domain), and there you
> better set degree(0)=-oo, otherwise it's going to be a problem.
>
> I think it's been established
> that LaurentPolynomialRing(QQ,'x').zero().degree() == -1 is problematic.
> With the definition that (1/x).degree() == -1 it clearly is.
>
> I think the question is more: do we have enough evidence that setting
> degree(0) == -oo for *all* polynomial rings is significantly better (if
> better at all) that it's worth the pain and incompatibilities that would
> ensue from changing the rest of sage as well? That's not so clear to me.
> From the perspective of multivariate polynomials, the whole valuation
> interpretation of "degree" goes out of the window, so there "-1" is largely
> available and quite possibly used extensively by the underlying libraries.
>

IMHO deg(0)=-1 was chosen by Singular long time ago for purely practical
programming reasons: in C++ one has to jump  through too many hoops in
order to add +oo/-oo to Z, as a type (and it was much harder still in
old-style C++ than it is now). (probably similarly for sympy).

As I mentioned, both Macaulay2 and GAP have convertion deg(0)=-oo.

For multivariate Laurent series total degree, indeed, makes little sense,
one has to talk about vectors of degrees. Perhaps for an n-variate Laurent
series one should choose deg(0)=(-oo,-oo,...,-oo).

Dima




>
> I guess one could see what happens if the change is made to Laurent
> polynomials (and Laurent series as well, perhaps?). Based on how that goes
> one could re-evaluate degrees of 0 polynomials in other polynomial rings.
>
> Alternatively, we could deprecate degree on them in favour of using
> valuation-inspired terms instead, where the extension val(0)=oo is more
> universal. As Oscar's example in Matlab shows, the concept of degree gets
> (mis)used for other, more implementation-oriented definitions as well, so
> perhaps the term should just be avoided for Laurent polynomials.
>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/60c42d22-28dc-4221-96a0-b174585c9c23n%40googlegroups.com
> <https://groups.google.com/d/msgid/sage-devel/60c42d22-28dc-4221-96a0-b174585c9c23n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0MdLQeTd6Gym_JNCquOm7YCLheLMyxPxn1LTF4mARLXQ%40mail.gmail.com.

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

[Dima Pasechnik]

On Fri, Mar 1, 2024 at 11:41 AM Oscar Benjamin 
wrote:

> On Fri, 1 Mar 2024 at 11:15, John Cremona  wrote:
> >
> > On Fri, 1 Mar 2024 at 11:03, Dima Pasechnik  wrote:
> >>
> >> On Fri, Mar 1, 2024 at 10:24 AM John Cremona 
> wrote:
> >>>
> >>> On Fri, 1 Mar 2024 at 10:04, Dima Pasechnik  wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 1 March 2024 09:07:26 GMT, 'Martin R' via sage-devel <
> sage-devel@googlegroups.com> wrote:
> >>>> >I'd be OK with raising an exception or with -oo, but it should be
> uniform,
> >>>> >and I think it should be the same for polynomials, Laurent
> polynomials and
> >>>> >in the same spirit for degree and valuation.
> >>>> >
> >>>> >It might be best to raise an exception, because this ensures that
> the zero
> >>>> >polynomial gets special treatment.
> >>>>
> >>>> Exceptions are expensive, performance-wise, and using them as a
> regular means of controlling the flow of the algorithm execution is not a
> good idea.
> >>>> A simple  if/then/else  is much cheaper.
> >>>
> >>>
> >>> Isn't this suggestion to have f.degree() raise an exception when f is
> zero, but also then that any code which needs the degree to treat 0 as a
> special case (where that makes sense)?   To it would be the caller's
> responsibility to do that with a test of f.is_zero() or whatever, rather
> than by seeing if an exception is triggered.
> >>
> >>
> >> Letting degree(0) throw an exception means that every place where you
> want to test whether the degree of fg satisfies something needs a testing
> whether f or g is 0, in order to avoid an exception.
> >
> >
> > Fair enough.  I had been assuming that for the types we are talking
> about testing for equality with 0 would be fast, but perhaps it is not.
>
> If p.degree() can do this quickly then there is no reason that some
> other function couldn't be made to return the equivalent of p.degree()
> < 0 quickly. It would sometimes be a bit awkward though for deg(0) to
> raise an exception. I see examples of code in sympy where e.g. the
> degrees of polynomials are reduced in a loop and having deg(0) < 0
> naturally captures the the control flow that is needed.
>
> >> OTOH, setting the degree of 0 to be -oo has an obvious advantage: it
> automaticlly gives mathematically correct degree of fg, by using
> degree(fg)=degree(f)+degree(g), regardless of f or g being 0. And checking
> the degree is (or at least ought to be) faster than comparing for equality
> to 0.
>
> Do you see examples where arithmetic with degree(0) is used in practice?
>
> When I looked for these in the sympy code I didn't find any even
> though the -oo convention was used. I just don't think it comes up in
> real code.
>

a natural way to program long division of univariate polynomial n by
univariate polynomial d,
to get n=dq+r can folllow Wikipedia's
https://en.wikipedia.org/wiki/Polynomial_long_division#Pseudocode

There they have the condion

*while* r ≠ 0 *and* degree(r) ≥ degree(d) *do*


which with the convention degree(0)=-oo can be simplified to

*while* degree(r) ≥ degree(d) *do*


here of course any negative degree(0) will work, e.g. -1, not only -oo.

It seems that exactly the same algorithm will work (I didn't check this!)
for Laurent polynomials (they still form a Euclidean domain), and there you
better set degree(0)=-oo, otherwise it's going to be a problem.

Dima


> > It's a little dangerous to talk of -oo being "mathematically correct",
> but I have given this definition myself in undergraduate course (and for
> the reason you give) so that's ok, especially as in Sage we do have -oo as
> a possible return value and no requiremt for the value to always be of the
> same type (e.g. Integer).
>
> There might not be any "requirement" for degree() to return objects of
> the same type but from a computational perspective it is generally
> better to use well defined types. Python allows mixing types up but
> that doesn't make it a good idea to do so especially in performance
> sensitive code.
>
> --
> Oscar
>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/CAHVvXxRDh1y6h3PiRZNAzT50DJAfgLGMxzhdMVrV1SiNWHO24w%40mail.gmail.com
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq31X6RUxzA0meovV%2Bq5toxCPGJqKb5DX9zRBizvA%3DoyaA%40mail.gmail.com.

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

[Dima Pasechnik]

On Fri, Mar 1, 2024 at 10:24 AM John Cremona  wrote:

>
>
> On Fri, 1 Mar 2024 at 10:04, Dima Pasechnik  wrote:
>
>>
>>
>> On 1 March 2024 09:07:26 GMT, 'Martin R' via sage-devel <
>> sage-devel@googlegroups.com> wrote:
>> >I'd be OK with raising an exception or with -oo, but it should be
>> uniform,
>> >and I think it should be the same for polynomials, Laurent polynomials
>> and
>> >in the same spirit for degree and valuation.
>> >
>> >It might be best to raise an exception, because this ensures that the
>> zero
>> >polynomial gets special treatment.
>>
>> Exceptions are expensive, performance-wise, and using them as a regular
>> means of controlling the flow of the algorithm execution is not a good idea.
>> A simple  if/then/else  is much cheaper.
>>
>
> Isn't this suggestion to have f.degree() raise an exception when f is
> zero, but also then that any code which needs the degree to treat 0 as a
> special case (where that makes sense)?   To it would be the caller's
> responsibility to do that with a test of f.is_zero() or whatever, rather
> than by seeing if an exception is triggered.
>

Letting degree(0) throw an exception means that every place where you want
to test whether the degree of fg satisfies something needs a testing
whether f or g is 0, in order to avoid an exception.

OTOH, setting the degree of 0 to be -oo has an obvious advantage: it
automaticlly gives mathematically correct degree of fg, by using
degree(fg)=degree(f)+degree(g), regardless of f or g being 0. And checking
the degree is (or at least ought to be) faster than comparing for equality
to 0.

Yes, it requires a change of the mental picture somehow. But same applies
for e.g. using projective setting instead of affine one in geometry: you
don't need to throw a mental exception as soon as you get parallel lines :-)

Dima






>
> John
>
>
>>
>> Dima
>> >
>> >Martin
>> >On Thursday 29 February 2024 at 22:54:20 UTC+1 Nils Bruin wrote:
>> >
>> >> On Thursday 29 February 2024 at 11:15:21 UTC-8 Dima Pasechnik wrote:
>> >>
>> >> How about using something like
>> https://github.com/NeilGirdhar/extended_int
>> >> ?
>> >> (Even better, do a PEP to have such a thing in Python proper...)
>> >> In old, totally duck-typed, Python this didn't really matter, but
>> nowadays
>> >> it does make
>> >> a perfect sense.
>> >>
>> >> At the moment, I think most degree functions do their best to return
>> sage
>> >> Integer objects; mainly so that coercion works well with them. So
>> whatever
>> >> solution we use should probably be based on objects that naturally
>> live in
>> >> the sage hierarchy. We do have an infinity object in sage and it
>> already
>> >> gets used for valuations.
>> >>
>> >> Incidentally:
>> >>
>> >>  sage: R.=LaurentSeriesRing(QQ)
>> >> sage: z=R(0)
>> >> sage: z.valuation()
>> >> +Infinity
>> >> sage: z.degree()
>> >> -1
>> >>
>> >> I don't quite know why laurent series have a degree defined at all,
>> but
>> >> they're keeping to the deg(0)=-1 convention.
>> >>
>> >> Incidentally:
>> >>
>> >> sage: A.=QQ[]
>> >> sage: B.=LaurentPolynomialRing(QQ)
>> >> sage: x.valuation(oo)
>> >> -1
>> >> sage: y.valuation(oo)
>> >> 1
>> >> so polynomial rings have a valuation (that will return +oo when
>> >> appropriate), but on LaurentPolynomialRing this gets silently broken:
>> the
>> >> argument simply gets ignored and the valuation at 0 is returned. So I
>> guess
>> >> you can get a well-behaving degree with
>> >>
>> >> f=0*y
>> >> -f(1/y).valuation()
>> >>
>> >
>>
>> --
>> 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 visit
>> https://groups.google.com/d/msgid/sage-devel/D20DACD9-8D5A-48F4-81F5-141CF0181BA1%40gmail.com
>> .
>>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/CAD0p0K45r2ishqx4kzEwuVF9%3DYDtojjteBn3snKMkGj8ijb72g%40mail.gmail.com
> <https://groups.google.com/d/msgid/sage-devel/CAD0p0K45r2ishqx4kzEwuVF9%3DYDtojjteBn3snKMkGj8ijb72g%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0zF8ARVr_FbbKd7WAhM8t6cBSqegXZzKsSSx1Au5mFMw%40mail.gmail.com.

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

[Dima Pasechnik]

On 1 March 2024 09:07:26 GMT, 'Martin R' via sage-devel 
 wrote:
>I'd be OK with raising an exception or with -oo, but it should be uniform, 
>and I think it should be the same for polynomials, Laurent polynomials and 
>in the same spirit for degree and valuation.
>
>It might be best to raise an exception, because this ensures that the zero 
>polynomial gets special treatment.

Exceptions are expensive, performance-wise, and using them as a regular means 
of controlling the flow of the algorithm execution is not a good idea.
A simple  if/then/else  is much cheaper.

Dima
>
>Martin
>On Thursday 29 February 2024 at 22:54:20 UTC+1 Nils Bruin wrote:
>
>> On Thursday 29 February 2024 at 11:15:21 UTC-8 Dima Pasechnik wrote:
>>
>> How about using something like https://github.com/NeilGirdhar/extended_int 
>> ?
>> (Even better, do a PEP to have such a thing in Python proper...)
>> In old, totally duck-typed, Python this didn't really matter, but nowadays 
>> it does make
>> a perfect sense.
>>
>> At the moment, I think most degree functions do their best to return sage 
>> Integer objects; mainly so that coercion works well with them. So whatever 
>> solution we use should probably be based on objects that naturally live in 
>> the sage hierarchy. We do have an infinity object in sage and it already 
>> gets used for valuations.
>>
>> Incidentally:
>>
>>  sage: R.=LaurentSeriesRing(QQ)
>> sage: z=R(0)
>> sage: z.valuation()
>> +Infinity
>> sage: z.degree()
>> -1
>>
>> I don't quite know why laurent series have a degree defined at all, but 
>> they're keeping to the deg(0)=-1 convention. 
>>
>> Incidentally:
>>
>> sage: A.=QQ[]
>> sage: B.=LaurentPolynomialRing(QQ)
>> sage: x.valuation(oo)
>> -1
>> sage: y.valuation(oo)
>> 1
>> so polynomial rings have a valuation (that will return +oo when 
>> appropriate), but on LaurentPolynomialRing this gets silently broken: the 
>> argument simply gets ignored and the valuation at 0 is returned. So I guess 
>> you can get a well-behaving degree with
>>
>> f=0*y
>> -f(1/y).valuation()
>>
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/D20DACD9-8D5A-48F4-81F5-141CF0181BA1%40gmail.com.

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

[Dima Pasechnik]

On Thu, Feb 29, 2024 at 4:34 PM Oscar Benjamin 
wrote:

> I recently reviewed cases in the sympy polys code that handle the
> degree of a zero polynomial:
> https://github.com/sympy/sympy/pull/25784
>
> My conclusion is that it is sometimes useful that deg(0) < deg(p) for
> p != 0 but otherwise it is not really possible to use the value of
> deg(0) for anything meaningful in practice. Generally if deg(p) is
> needed then the zero polynomial needs special handling that no
> particular value of deg(0) helps with. I would prefer that deg(0) = -1
> just so that the deg() function has a well defined type.
>

How about using something like https://github.com/NeilGirdhar/extended_int ?
(Even better, do a PEP to have such a thing in Python proper...)
In old, totally duck-typed, Python this didn't really matter, but nowadays
it does make
a perfect sense.


>
> For Laurent polynomials I am not sure that I would define a degree()
> method or if I did that it would be defined as the exponent of the
> leading term. It isn't clear to me when that notion of degree would be
> useful: it doesn't seem like it would generalise the ways that degree
> is  typically used for ordinary polynomials.
>
> On Thu, 29 Feb 2024 at 10:57, Giacomo Pope  wrote:
> >
> > There seem to be two things we could do here:
> >
> > 1. Have some form of vote / discussion on whether the degree of the zero
> polynomial should *ever* be -1
> > 2. Modify the degree calls for the LaurentSeries and
> LaurentPolynomialRing (maybe other Laurent* which I am unfamiliar with) to
> have the zero polynomial have degree -Infinity.
> >
> > Option 1 may be cleaner in the long run, but I assume will cause issues
> for more people in the short term. Option 2 seems fairly harmless and
> there's no good argument for degree -1 in this case.
> >
> > If anyone is interested in option 2, I will find time to make a PR to do
> this, but I will not start this work without other people's input as this
> is not code I am familiar with using and so I don't know what people could
> be relying on.
> > On Wednesday, February 28, 2024 at 6:41:48 PM UTC Dima Pasechnik wrote:
> >>
> >> On Wed, Feb 28, 2024 at 5:00 PM Nils Bruin  wrote:
> >>>
> >>> On Wednesday 28 February 2024 at 08:03:45 UTC-8 Giacomo Pope wrote:
> >>>
> >>>
> >>> I don't know the history of this choice or what we should be doing
> generally. -1 for polynomials with only positive degree seems like a
> computer science workaround, but for the LaurentPolynomialRing it just
> seems wrong?
> >>>
> >>>
> >>> I think it's more than just a CS workaround. It has its roots in
> dimension considerations: the space of polynomials of degree at most d is
> (d+1)-dimensional. WIth that convention, 0 having degree -1 makes perfect
> sense.
> >>
> >>
> >> well, it's the convention used in Singular.
> >> But GAP and Macaulay2 use -infinity.
> >>
> >> The arguments for -infinity:
> >>
> >> 1) degree of the product should be the sum of degrees; so it's got to
> be infinite.
> >> 2) it should be -infinity, to make sense of the rule that if you do
> division f/g with remainder r,
> >> the degree of the remainder should be less than the deg(r)<=deg(f), but
> if r=0 then the only way
> >> to get this is to use -infinity.
> >>
> >> Dima
> >>
> >>>
> >>>
> >>> For deg = - ord_infty it should definitely be -oo, though, and for
> Laurent polynomials the dimension argument doesn't work.
> >>>
> >>> --
> >>>
> >>> 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+...@googlegroups.com.
> >>>
> >>> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/ac40d2e7-5e71-43e1-8914-869081f9bdd9n%40googlegroups.com
> .
> >
> > --
> > 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 visit
> https://groups.google.com/d/msgid/sage-devel/6d95b253-fb17-4e2f-a61c-c723737774e8n%40googlegroups.com
> .
>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/CAHVvXxRe119u%3Dy-xk1O-BvWH_f1xxnHsuQCzZm_4xYRD-_NEFw%40mail.gmail.com
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2n-Zg02OpJZHOjPsRY9fbZx%3DqCjya3%3DPpRVNNSx_FBqA%40mail.gmail.com.

Re: [sage-devel] Re: VOTE: use "blocker" label only for PRs; use "critical" label for Issues

[Dima Pasechnik]

On Wed, Feb 28, 2024 at 4:46 PM William Stein  wrote:

>
>
> On Wed, Feb 28, 2024 at 8:39 AM Eric Gourgoulhon 
> wrote:
>
>> -1 from my side, for I think an issue can be a blocker.
>> For instance:
>> https://github.com/sagemath/sage/issues/36914
>> This issue, which regards the use of the notebook, could not have been
>> detected by the CI framework.  It is a serious regression and definitely a
>> blocker IMHO: are we willing to release a version of SageMath that cannot
>> be used without an internet connection?
>>
>
> Related to this, do you think
>
> https://github.com/sagemath/sage/issues/34233
>
> should also be a blocker?  In Sage if you create a plot with a large
> y-axis range, the labels on the y axis are
> mathematically incorrect, which is confusing to our largest group of users
> (beginners).
>

Sure, it can be a blocker, very well (or not to overload this word, it
could be "grave" or something).


To plot it, correctly, with sympy, you need to install 3 PyPI packages into
your Python3:
matplotlib, jupyterlab, sympy.

On the other hand, check all the 400 neatly arranged Sage's spkgs, CI
passing with flying colours..
.


>
> -- William
>
>
>>
>> Eric.
>>
>> Le mercredi 28 février 2024 à 07:45:03 UTC+1, Kwankyu Lee a écrit :
>>
>>> Hi,
>>>
>>> Here I withdraw the early premature "giving up" on my recent proposal,
>>> since afterwards there were some positive comments. Hence I open a voting
>>> for
>>>
>>> Proposal:
>>>
>>> 1. Do not use "blocker" label for Issues, as "blocker" means to delay
>>> the release.
>>> 2. Instead use "critical" label for a very serious and urgent Issue.
>>> 3. A PR fixing the "critical" Issue will likely get the "blocker" label.
>>> 4. Old Issues converted from trac with "critical" label will get the
>>> "major" label instead.
>>>
>>> Voting will end when there is no new vote for a week.
>>>
>>> This is a simple majority voting (following the standard on sage-devel
>>> proposal)!
>>>
>>> A positive vote is for all parts of the Proposal. So if you do not like
>>> any of (1) -- (4), cast a negative vote (-1).
>>>
>>>
>>> Happy voting!
>>>
>> --
>> 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 visit
>> https://groups.google.com/d/msgid/sage-devel/a2c85e9b-ac46-49d7-8385-f568fddfa236n%40googlegroups.com
>> 
>> .
>>
>
>
> --
> William (http://wstein.org)
>
> --
> 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 visit
> https://groups.google.com/d/msgid/sage-devel/CACLE5GB7pxdZQJO7CV8YvNw3gvrVzcpv-fYXZk0YejkcXdXoxQ%40mail.gmail.com
> 
> .
>

-- 
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 visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2uZEFfiM-cLKoFjxfkTkWhEd5S9B%3DjgZf3qxzcewR5HA%40mail.gmail.com.

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

[Dima Pasechnik]

On Wed, Feb 28, 2024 at 5:42 PM 'Animesh Shree' via sage-devel <
sage-devel@googlegroups.com> wrote:

> reason scipy factors only square sparse matrices
>
> Problem is basically in _superlu.gstrf
> <https://github.com/scipy/scipy/blob/4edfcaa3ce8a387450b6efce968572def71be089/scipy/sparse/linalg/_dsolve/linsolve.py#L437>it
> accepts only one dimension as input rather than both row and col.
> In c implementation
> <https://github.com/scipy/scipy/blob/4edfcaa3ce8a387450b6efce968572def71be089/scipy/sparse/linalg/_dsolve/_superlumodule.c#L202>
> we can see it uses N only
> <https://github.com/scipy/scipy/blob/4edfcaa3ce8a387450b6efce968572def71be089/scipy/sparse/linalg/_dsolve/_superlumodule.c#L246>
> and assumes A to be square matrix.
>

We can probably change scipy's code (and then do a PR) to accept a
non-square matrix.
The C code they have basically sets up a call to superlu, and gets the
results...


>
> Currently I am going with the solution given by *Dima* which uses block
> matrices.
>
> On Wednesday, February 28, 2024 at 9:49:07 PM UTC+5:30 Animesh Shree wrote:
>
>> Yes
>> Because of same reason I tried to commented scipy code
>> <https://github.com/scipy/scipy/blob/4edfcaa3ce8a387450b6efce968572def71be089/scipy/sparse/linalg/_dsolve/linsolve.py#L423C1-L424C77>
>> to test this.
>>
>> I got some error saying *RuntimeError: Factor is exactly singular*
>> But same worked for sage LU factorization in dense matrix for same matrix.
>>
>> -Scipy (Modified)--
>> >>> from scipy.sparse import csc_matrix
>> >>> from scipy.sparse.linalg import splu
>> >>> import numpy as np
>> >>> A = csc_matrix([[1,0,0],[5,0,2]], dtype=np.float64)
>> >>> print(A)
>>   (0, 0) 1.0
>>   (1, 0) 5.0
>>   (1, 2) 2.0
>> >>> splu(A)
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File
>> "/home/shay/miniconda3/envs/py39/lib/python3.9/site-packages/scipy/sparse/linalg/_dsolve/linsolve.py",
>> line 440, in splu
>> return _superlu.gstrf(N, A.nnz, A.data, indices, indptr,
>> RuntimeError: Factor is exactly singular
>> >>>
>>
>>
>>
>>
>> -Sage---
>> sage: A = Matrix(RDF, 2,3, [[1,0,0],[5,0,2]])
>> sage: A
>> [1.0 0.0 0.0]
>> [5.0 0.0 2.0]
>> sage: A.LU()
>> (
>> [0.0 1.0]  [1.0 0.0]  [ 5.0  0.0  2.0]
>> [1.0 0.0], [0.2 1.0], [ 0.0  0.0 -0.4]
>> )
>>
>>
>>
>> I am looking into it too.
>>
>>
>> On Wednesday, February 28, 2024 at 8:59:36 PM UTC+5:30 Dima Pasechnik
>> wrote:
>>
>>> There is a good reason for numerics people to adopt "SuperLU"
>>> factorisations over
>>> the classical PLU sparse decomposition - namely, it's more stable.
>>> Perhaps it should be made the Sage's default for sparse RDF matrices,
>>> too.
>>> By the way,
>>> https://portal.nersc.gov/project/sparse/superlu/superlu_ug.pdf
>>> (the manual for the upstream superlu) says it can handle non-square
>>> matrices.
>>>
>>> Dima
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Feb 28, 2024 at 1:09 PM 'Animesh Shree' via sage-devel <
>>> sage-...@googlegroups.com> wrote:
>>>
>>>> I went through the link.
>>>> It also returns perm_c and perm_r and the solution is represented as
>>>>
>>>> Pr * (R^-1) * A * Pc = L * U
>>>>
>>>> It is similar to one returned by scipy
>>>> >>> lu.perm_r
>>>>
>>>>array([0, 2, 1, 3], dtype=int32)
>>>>
>>>> >>> lu.perm_c
>>>>
>>>>array([2, 0, 1, 3], dtype=int32)
>>>>
>>>> I think it doesn't support square matrix too. Link
>>>> <https://github.com/scikit-umfpack/scikit-umfpack/blob/ce77944bce003a29771ae07be182af348c3eadce/scikits/umfpack/interface.py#L199C1-L200C81>
>>>> On Wednesday, February 28, 2024 at 6:17:26 PM UTC+5:30 Max Alekseyev
>>>> wrote:
>>>>
>>>>> One more option would be umfack via scikits.umfpack:
>>>>>
>>>>> https://scikit-umfpack.github.io/scikit-umfpack/reference/scikits.umfpack.UmfpackLU.html
>>>>>
>>>>> Regards,
>>>>> Max
>>>>> On Wednesday, February 28, 2024 at 7:07:53 AM UTC-5 Animesh Shree
>>>>> wrote:
>>>>>
>>>>>>