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

[John H Palmieri]

I also don't know when the linker was fixed and whether we need to support 
systems on which it is still broken. Anyway, if you want to open up a PR to 
avoid the call to xcode-select, I'd be happy to take a look. We could also 
revive some version of the branch at #36337 to filter out the warnings when 
doctesting.

-- 
John

On Thursday, April 25, 2024 at 1:19:50 PM UTC-7 John H Palmieri wrote:

> Take a look at the discussion at 
> https://github.com/sagemath/sage/pull/36337, in particular 
> https://github.com/sagemath/sage/pull/36337#issuecomment-1741293729. I 
> saw both "duplicate rpath" warnings and "duplicate library" warnings. Some 
> (maybe all, at least at that point) of the duplicate rpaths were removed by 
> https://github.com/sagemath/sage/pull/36364, but I don't know how to 
> prevent the duplicate libary warnings.
>
> -- 
> John
>
>
> On Thursday, April 25, 2024 at 1:07:17 PM UTC-7 marc@gmail.com wrote:
>
>> Hi John,
>>
>> I have noticed that .dylib files generated by Sage often have as many as 
>> 3 identical rpaths.  (When building the macOS app I remove all rpaths and 
>> replace them with a single rpath which is relative, meaning it starts with 
>> @loader_path.  Apple will not notarize app bundles with absolute rpaths.)
>>
>> I wonder if the "duplicate libraries" warnings are caused by duplicate 
>> rpath entries in the mach files.  I will try to test that hypothesis.
>>
>> Do you have any idea what could cause those duplicate rpaths?  Are there 
>> multiple -rpath options being passed to the compiler?
>>
>> - Marc
>>
>> On Thu, Apr 25, 2024 at 2:50 PM John H Palmieri  
>> wrote:
>>
>>> Hi Marc,
>>>
>>> I just tried building Sage without `-ld-classic`. It builds, but I get 
>>> warnings about "ignoring duplicate libraries", and those cause doctest 
>>> failures. The lines could be modified to test whether xcode-select is 
>>> present and executable first, or since Sage now does indeed build without 
>>> `-ld-classic`, we could filter out the warnings when doctesting.
>>>
>>> -- 
>>> John
>>>
>>>
>>> On Wednesday, April 24, 2024 at 3:20:54 PM UTC-7 marc@gmail.com 
>>> wrote:
>>>
>>>> Well, it almost solved the problem.
>>>>
>>>> It turns out that calling /usr/bin/gcc was not the only issue in 
>>>> sage-env.  That script also calls xcode-select.  On a system with no XCode 
>>>> app and no command line tools, calling gcc causes an error message to be 
>>>> printed to stderr and a dialog to open asking whether to install the 
>>>> command line tools.  Calling xcode-select on such a system prints the same 
>>>> error message but does not open the dialog. The error message appears in 
>>>> the terminal when running sage in a command line, which is annoying and/or 
>>>> alarming to someone with no plans to do anything involving compilation of 
>>>> C 
>>>> code.
>>>>
>>>> The calls to xcode-select were added in PR#36599 
>>>> <https://github.com/sagemath/sage/pull/36599> in order to force XCode 
>>>> to use Apple's ld-classic linker instead of ld when their new version of 
>>>> ld 
>>>> was totally broken.  This is done by adding -ld_classic to LDFLAGS.
>>>>
>>>> *Note to people who worked on PR #36599* (@jhpalmieri and @mkoeppe): I 
>>>> think Apple's new linker is working now, so it is probably no longer 
>>>> necessary and not a good idea to force use of ld_classic.
>>>>
>>>> - Marc
>>>>
>>>> On Tuesday, April 23, 2024 at 10:45:54 PM UTC-5 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,  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.
>>>>
>>>> - 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://g

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

[John H Palmieri]

Take a look at the discussion at 
https://github.com/sagemath/sage/pull/36337, in particular 
https://github.com/sagemath/sage/pull/36337#issuecomment-1741293729. I saw 
both "duplicate rpath" warnings and "duplicate library" warnings. Some 
(maybe all, at least at that point) of the duplicate rpaths were removed by 
https://github.com/sagemath/sage/pull/36364, but I don't know how to 
prevent the duplicate libary warnings.

-- 
John


On Thursday, April 25, 2024 at 1:07:17 PM UTC-7 marc@gmail.com wrote:

> Hi John,
>
> I have noticed that .dylib files generated by Sage often have as many as 3 
> identical rpaths.  (When building the macOS app I remove all rpaths and 
> replace them with a single rpath which is relative, meaning it starts with 
> @loader_path.  Apple will not notarize app bundles with absolute rpaths.)
>
> I wonder if the "duplicate libraries" warnings are caused by duplicate 
> rpath entries in the mach files.  I will try to test that hypothesis.
>
> Do you have any idea what could cause those duplicate rpaths?  Are there 
> multiple -rpath options being passed to the compiler?
>
> - Marc
>
> On Thu, Apr 25, 2024 at 2:50 PM John H Palmieri  
> wrote:
>
>> Hi Marc,
>>
>> I just tried building Sage without `-ld-classic`. It builds, but I get 
>> warnings about "ignoring duplicate libraries", and those cause doctest 
>> failures. The lines could be modified to test whether xcode-select is 
>> present and executable first, or since Sage now does indeed build without 
>> `-ld-classic`, we could filter out the warnings when doctesting.
>>
>> -- 
>> John
>>
>>
>> On Wednesday, April 24, 2024 at 3:20:54 PM UTC-7 marc@gmail.com 
>> wrote:
>>
>>> Well, it almost solved the problem.
>>>
>>> It turns out that calling /usr/bin/gcc was not the only issue in 
>>> sage-env.  That script also calls xcode-select.  On a system with no XCode 
>>> app and no command line tools, calling gcc causes an error message to be 
>>> printed to stderr and a dialog to open asking whether to install the 
>>> command line tools.  Calling xcode-select on such a system prints the same 
>>> error message but does not open the dialog. The error message appears in 
>>> the terminal when running sage in a command line, which is annoying and/or 
>>> alarming to someone with no plans to do anything involving compilation of C 
>>> code.
>>>
>>> The calls to xcode-select were added in PR#36599 
>>> <https://github.com/sagemath/sage/pull/36599> in order to force XCode 
>>> to use Apple's ld-classic linker instead of ld when their new version of ld 
>>> was totally broken.  This is done by adding -ld_classic to LDFLAGS.
>>>
>>> *Note to people who worked on PR #36599* (@jhpalmieri and @mkoeppe): I 
>>> think Apple's new linker is working now, so it is probably no longer 
>>> necessary and not a good idea to force use of ld_classic.
>>>
>>> - Marc
>>>
>>> On Tuesday, April 23, 2024 at 10:45:54 PM UTC-5 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,  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.
>>>
>>> - 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

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

[John H Palmieri]

Hi Marc,

I just tried building Sage without `-ld-classic`. It builds, but I get 
warnings about "ignoring duplicate libraries", and those cause doctest 
failures. The lines could be modified to test whether xcode-select is 
present and executable first, or since Sage now does indeed build without 
`-ld-classic`, we could filter out the warnings when doctesting.

-- 
John


On Wednesday, April 24, 2024 at 3:20:54 PM UTC-7 marc@gmail.com wrote:

> Well, it almost solved the problem.
>
> It turns out that calling /usr/bin/gcc was not the only issue in 
> sage-env.  That script also calls xcode-select.  On a system with no XCode 
> app and no command line tools, calling gcc causes an error message to be 
> printed to stderr and a dialog to open asking whether to install the 
> command line tools.  Calling xcode-select on such a system prints the same 
> error message but does not open the dialog. The error message appears in 
> the terminal when running sage in a command line, which is annoying and/or 
> alarming to someone with no plans to do anything involving compilation of C 
> code.
>
> The calls to xcode-select were added in PR#36599 
>  in order to force XCode to 
> use Apple's ld-classic linker instead of ld when their new version of ld 
> was totally broken.  This is done by adding -ld_classic to LDFLAGS.
>
> *Note to people who worked on PR #36599* (@jhpalmieri and @mkoeppe): I 
> think Apple's new linker is working now, so it is probably no longer 
> necessary and not a good idea to force use of ld_classic.
>
> - Marc
>
> On Tuesday, April 23, 2024 at 10:45:54 PM UTC-5 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,  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.
>
> - 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/c81c9434-3b0c-4730-b3e8-6e36802f5224n%40googlegroups.com.

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

[John H Palmieri]

+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.

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/94636127-868a-415a-9033-8159582292c6n%40googlegroups.com.

Re: [sage-devel] Mysterious .sage behavior

[John H Palmieri]

I searched for "ipython-5.0.0" in the source and found this:

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

So it should be viewed as "IPython, version 5.0.0 or later, as long as 
things remain compatible". Maybe it would be better to have a directory 
"ipython-config" (for example) with subdirectories that somehow convey the 
version information. We could also, or in addition, create a README file 
the existing directory with some sort of explanation.

-- 
John


On Monday, April 1, 2024 at 2:38:09 PM UTC-7 Marc Culler wrote:

> The problem that it *causes* is that people think that Sage has somehow 
> managed to install an ancient ipython-5.0.0 in their ~/.sage directory.  
> The user that reported this was indeed having problems because of an out of 
> date ipython thet they had installed with %pip.  The python package was 
> installed as a --user package  in  ~/.sage.   That is where the macOS app 
> installs all pip packages, being disallowed from putting them into the app 
> bundle itself because that would break the signature and macOS would then 
> refuse to run the app..
>
> The old version of ipython caused the new app to crash with the rather 
> amazing error message "object of type List is not iterable".  When the user 
> removed their ~/.sage directory everything worked as expected.  But then, 
> after starting Sage,  they checked to see what was actually in the 
> directory, and were alarmed to ",find" that Sage had re-installed 
> ipython-5.0.0.
>
> As I said, this idea confuses users, and understandably so.  It was not a 
> great idea. There were so many other, better, ways of naming the directory.
>
> Maybe for the next Sage release I will move the pip packages to 
> ~/Library/SageMath-X.Y.  That won't stop Sage from creating 
> ~/.sage/ipython-5.0.0 but it will remove the motivation for users to look 
> in the .sage directory and get confused.
>
> - Marc
>
> On Monday, April 1, 2024 at 3:31:06 PM UTC-5 Nils Bruin wrote:
>
>> One scenario where I could see this being beneficial:
>> These configurations are written into `$HOME/.sage` (normally), so that 
>> is not a location that is predicated by a venv or a localized subdir. If a 
>> user is using two different sagemath installs (e.g., one system, the other 
>> for development) that have incompatible ipython configs, they need to live 
>> in places that allow peaceful co-existence. This would do it. I agree the 
>> version number can look confusing, It seems like a historic artifact that 
>> we didn't need to change our ipython configs since version 5.0.0, probably. 
>> It looks to me like a fairly arbitrary choice how to mark that directory 
>> name. Not changing it would be the easiest solution, but if someone wants 
>> to make an argument that another naming convention has benefits (following 
>> common practices that have since evolved?) it could be changed, at the 
>> expense of everyone with an install needing to change locations of files 
>> they already customized. So based on that, I think the best time to change 
>> it (if at all) would be when an incompatible change in config is happening 
>> anyway.
>>
>>
>> On Monday 1 April 2024 at 12:20:16 UTC-7 Dima Pasechnik wrote:
>>
>>
>> I must say I don't know what kind of problems these versioned names are 
>> meant to solve. 
>>
>>  
>>
>> >On 31 March 2024 15:23:24 CEST, Marc Culler > > wrote :  
>>
>> >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 
>>
>>

-- 
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/3de2c4d8-f592-4088-bb61-c063d38ec110n%40googlegroups.com.

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

[John H Palmieri]

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/97bcddfd-5a48-4feb-ae61-f8c2e50f7cc3n%40googlegroups.com.

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

[John H Palmieri]

Dear all,

First, in response to Dima's post: yes, it should definitely be Nils Bruin 
on the ballot. My sincere apologies to Nils that we got his name wrong! If 
anyone would like to adjust their ballot in light of this, please let us 
know and we will make any corrections you request.

Second, voting closes tomorrow. Please vote!

Regards,
  John



On Wednesday, March 13, 2024 at 8:05:32 AM UTC-7 Dima Pasechnik wrote:

> 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/fd4b3d24-51a6-49fc-a59c-6167e7c05654n%40googlegroups.com.

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

[John H Palmieri]

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. 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 
> 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+...@googlegroups.com.
> To view this discussion on the web visit 
> 

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

[John H Palmieri]

Dear all,

Voting continues until Thursday. We have been acknowledging each vote as it 
comes in, so if you think you voted but have not received an 
acknowledgment, please email sage-conduct at googlegroups.com.

Regards,
  John



On Thursday, March 7, 2024 at 10:46:03 AM UTC-8 John H Palmieri wrote:

> Right, please email your vote to that group. Only members of the committee 
> can actually see the postings.
>
> On Thursday, March 7, 2024 at 10:44:03 AM UTC-8 Martin R wrote:
>
>> Thank you - apparently, I do not have permission to see that group.  I'll 
>> try to send my vote by email.
>>
>> On Thursday 7 March 2024 at 19:39:14 UTC+1 John H Palmieri wrote:
>>
>>> Martin: it's "sage-conduct" at googlegroups.com.
>>>
>>> On Thursday, March 7, 2024 at 10:29:58 AM UTC-8 Martin R wrote:
>>>
>>>> For some reason, I cannot see the name of the newsgroup I should be 
>>>> sending my vote to.  (I am using the google groups webinterface)
>>>>
>>>> Martin
>>>> On Thursday 7 March 2024 at 19:13:42 UTC+1 David Roe wrote:
>>>>
>>>>> Dear Sage developers,
>>>>> Thank you for those you nominated people for the committee following my 
>>>>> request 
>>>>> <https://groups.google.com/g/sage-devel/c/u-jUo098jQg/m/Hdiqzn0GAwAJ>, 
>>>>> and thank you for those of you willing to serve.  The nominees are
>>>>>
>>>>> Nils Braun (nbr...@sfu.ca)
>>>>> 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 
>>>>> <https://electionscience.org/library/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 <https://groups.google.com/g/sage-devel> and on github 
>>>>> <https://github.com/sagemath/sage>.
>>>>>
>>>>> 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/93b73d16-8b1f-40d8-ada0-f5d48bd520cen%40googlegroups.com.

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

[John H Palmieri]

Right, please email your vote to that group. Only members of the committee 
can actually see the postings.

On Thursday, March 7, 2024 at 10:44:03 AM UTC-8 Martin R wrote:

> Thank you - apparently, I do not have permission to see that group.  I'll 
> try to send my vote by email.
>
> On Thursday 7 March 2024 at 19:39:14 UTC+1 John H Palmieri wrote:
>
>> Martin: it's "sage-conduct" at googlegroups.com.
>>
>> On Thursday, March 7, 2024 at 10:29:58 AM UTC-8 Martin R wrote:
>>
>>> For some reason, I cannot see the name of the newsgroup I should be 
>>> sending my vote to.  (I am using the google groups webinterface)
>>>
>>> Martin
>>> On Thursday 7 March 2024 at 19:13:42 UTC+1 David Roe wrote:
>>>
>>>> Dear Sage developers,
>>>> Thank you for those you nominated people for the committee following my 
>>>> request 
>>>> <https://groups.google.com/g/sage-devel/c/u-jUo098jQg/m/Hdiqzn0GAwAJ>, 
>>>> and thank you for those of you willing to serve.  The nominees are
>>>>
>>>> Nils Braun (nbr...@sfu.ca)
>>>> 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 
>>>> <https://electionscience.org/library/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 <https://groups.google.com/g/sage-devel> and on github 
>>>> <https://github.com/sagemath/sage>.
>>>>
>>>> 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/bcc53760-2338-47ef-8a6c-0482c4a48bd7n%40googlegroups.com.

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

[John H Palmieri]

Martin: it's "sage-conduct" at googlegroups.com.

On Thursday, March 7, 2024 at 10:29:58 AM UTC-8 Martin R wrote:

> For some reason, I cannot see the name of the newsgroup I should be 
> sending my vote to.  (I am using the google groups webinterface)
>
> Martin
> On Thursday 7 March 2024 at 19:13:42 UTC+1 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)
>> 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/59ca7e2b-bf7c-4820-9861-008de9b009cfn%40googlegroups.com.

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

[John H Palmieri]

+1

-- 
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/db4939fa-dda7-4c53-b4f0-5bb229d3826bn%40googlegroups.com.

[sage-devel] Re: VOTE: disputed PRs

[John H Palmieri]

+1

On Monday, March 4, 2024 at 12:23:39 AM UTC-8 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/c5314119-140d-41ee-b9e9-37e2a3303487n%40googlegroups.com.

Re: [sage-devel] VOTE: disputed PRs

[John H Palmieri]

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".


On Monday, March 4, 2024 at 5:27:21 AM UTC-8 Dima Pasechnik wrote:

> 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+...@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/f5e76b29-0011-428e-bf97-43fc16c2f6e9n%40googlegroups.com.

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

[John H Palmieri]

There are suggestions along maybe similar lines at 
https://github.com/sagemath/sage/pull/36844, and I am trying to think of 
how we might incorporate your suggestions and the other ones. I've had the 
thought before about other documents (like our department's by-laws) that 
there should be two separate documents: the main one and then, separately, 
commentary (like the Talmud). These suggestions currently feel more like 
commentary to me, but one option would be to add a "commentary" section to 
the code of conduct.

-- 
John

On Friday, March 1, 2024 at 9:41:31 AM UTC-8 Martin R wrote:

> Thank you for the thoughtful reply!  You gave me a lot to think about, and 
> I'll do so over the weekend, rather than rushing.
>
> Best,
>
> Martin
> On Friday 1 March 2024 at 18:21:59 UTC+1 David Roe wrote:
>
>> Thank you for starting the conversation Martin.  I certainly think that 
>> all of these suggestions are appropriate to discuss, and that sage-devel is 
>> probably a better venue for discussion like this than the PR.
>>
>> On Fri, Mar 1, 2024 at 5:49 AM 'Martin R' via sage-devel <
>> sage-...@googlegroups.com> wrote:
>>
>>> I would like to ask whether we might want to add some of the following 
>>> to the code of conduct, I could not find it covered there.
>>>
>>> I admit that it is unclear to me whether the discussion should be on 
>>> pull requests only.  I don't want to add the following to John's pull 
>>> request, because it definitely doesn't belong there.  Opening another one 
>>> makes things even harder to follow, so I'm trying to be brave.
>>>
>>> I imagine that the issues below may be cultural things, so I would 
>>> perfectly understand that all or some of it is perfectly OK in some 
>>> communities, and therefore should not be part of the sage code of conduct.
>>>
>>> I also admit that some of the issues below are attitudes that make it 
>>> hard for me to work on sage.  There were some situations in which I would 
>>> possibly have stopped contributing to sage, if sage wasn't a professional 
>>> necessity for me.
>>>
>>
>> I'm sorry to hear that there were situations like this.  If you think it 
>> would be helpful to describe them in more detail privately (even if you're 
>> not seeking any kind of action), feel free to write to the Code of Conduct 
>> committee.
>>  
>> Here are my thoughts on your suggestions.  I think that some of them 
>> should definitely be included, though it's not completely clear to me where 
>> (it feels awkward to add yet another enumerated list).
>>  
>>
>>> 0. sage is a community effort, and not the project of a single or even a 
>>> few persons.  Try to not identify yourself with the code in sage.
>>>
>>  
>> The community aspect of Sage is currently discussed in the introduction, 
>> and perhaps we can tweak that to incorporate this suggestion.  As for the 
>> second half, I don't understand how it fits into a code of conduct, since 
>> it seems aimed at internal processes (like how to cope if your code is 
>> removed from Sage), rather than behavior.
>>
>> Currently our introduction is "The Sage community is comprised of an 
>> international mixture of mathematicians, computer scientists, engineers, 
>> researchers, teachers, amateurs, and others with varied backgrounds. This 
>> diversity is one of our strengths, but it can also lead to communication 
>> problems and unhappiness. People who love working on Sage can more 
>> effectively collaborate with others if they follow this code."  What do you 
>> feel is missing from this that you're trying to include?
>>  
>>
>>> 1. It is not OK to judge somebody else's attempts to improve sage other 
>>> than critisising it technically or casting a negative vote.  By contrast, 
>>> emphasising the positive aspects and appreciating the effort is welcome.
>>>
>>
>> I like the idea of including more about positivity, and this fits in with 
>> Guideline 2: "Be welcoming. We strive to be a community that welcomes and 
>> supports people of all backgrounds and identities."  Maybe we can append a 
>> sentence here like "When discussing contributions, endeavor to encourage 
>> positive aspects and avoid overly harsh criticism."
>>
>> I do think there are cultural differences here, and personally I think 
>> restricting negative feedback to just voting and "technical" criticism goes 
>> too far, partly because I don't think technical is very clearly defined.  
>> There are judgement calls to be made about what should be included into 
>> Sage, which are not always a matter of what method is technically 
>> superior.  I don't think we want to restrict developer's ability to offer 
>> negative feedback, but instead to encourage people to be positive and 
>> welcoming.  I'd like to hear other perspectives on this.
>>  
>>
>>> 2. It is not OK to emphasise oneselves contributions or stressing that 
>>> one has been right.  By contrast, it is fine to express that one is happy 
>>> or perhaps even proud to have solved a particular 

[sage-devel] Sage's Code of Conduct: proposed changes

[John H Palmieri]

Dear colleagues,

I am working on some changes to Sage's Code of Conduct, and I am asking for 
comments. Once the draft has stabilized, then we will hold a vote on 
sage-devel to approve (or not) the changes. Please visit 
https://github.com/sagemath/sage/pull/37501 to see the proposal.

The current Code of Conduct was approved by a vote in sage-devel almost 10 
years ago. My intention is not to alter the core principles in the Code of 
Conduct, but instead to add more details: for example, how should you 
report a possible violation, what are possible consequences if the Sage 
Code of Conduct Committee (what has until now been called the Sage Abuse 
Committee) finds that a violation occurred, how to amend the document, etc. 
The changes are based in large part on similar documents from SciPy and 
NumFOCUS: we are not reinventing the wheel.

As such, I hope that the proposed changes are (a) not controversial, and 
(b) a clear improvement. I could certainly be wrong about either of these, 
but I will make this suggestion: if you agree with me about (a) and (b) and 
you also want to propose changes that are potentially more controversial, 
then I would ask that you make that proposal separately so that the Sage 
community can vote on it separately, and the changes can be merged 
independently of each other.

Please take a look and leave comments on the PR.

-- 
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/aa75eee6-a2b6-4f0d-8992-4995ed9f4310n%40googlegroups.com.

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

[John H Palmieri]

That's called "whataboutism". Invoking what you consider inappropriate 
behavior by others is not relevant. Please stay on topic, and please follow 
Sage's code of conduct in your posts.

On Tuesday, February 27, 2024 at 1:01:25 PM UTC-8 Dima Pasechnik wrote:

>
>
> On 27 February 2024 20:44:50 GMT, John H Palmieri  
> wrote:
> >Sentences like "At the moment you are actively breaking down the precious 
> >project fabric, all in the name of you having your way" are personal 
> >attacks. Please stop.
>
> Blocking on GitHub members of the project is not a personal attack? 
> Of course it is.
>
>
> >
> >On Tuesday, February 27, 2024 at 12:36:44 PM UTC-8 Dima Pasechnik wrote:
> >
> >>
> >>
> >> On 27 February 2024 19:37:31 GMT, Matthias Koeppe  
>
> >> wrote:
> >> >On Tuesday, February 27, 2024 at 10:50:55 AM UTC-8 John H Palmieri 
> wrote:
> >> >
> >> >A pretty safe second choice would be to have "make download" also 
> >> download 
> >> >the relevant files for pip installation and tell pip where to find 
> them. 
> >> If 
> >> >we implemented this second choice [...]
> >> >
> >> >
> >> >The problem is that such tooling, even if "trivial", would need to be 
> >> >implemented, tested, and maintained as well. And typically this just 
> does 
> >> >not work when there is no developer who is actually interested in 
> using 
> >> it.
> >>
> >> It is a largely artificially invented, by you, problem, to shoot my 
> >> proposal down. Besides, these tools are trivial to build and maintain, 
> much 
> >> easier than your ever growing and breaking maze of packages we don't 
> even 
> >> need to vendor.
> >>
> >> At the moment you are actively breaking down the precious project 
> fabric, 
> >> all in the name of you having your way: 
> >>
> >> you blocked me (without bothering yo even tell me) and perhaps other 
> >> developers on GitHub, meaning that you effectively want to shut me up.
> >> (Well, I had no other choice but to block you too, as a countermeasure; 
> I 
> >> installed this block about 12:00 GMT, today.)
> >>
> >> Of course it's easy to skip this message. But tomorrow it might be you 
> who 
> >> Matthias might block, for disagreements with him.
> >> Why is this tolerated? This is a naked attempt to shut down the 
> opposition.
> >>
> >>
> >> >
> >> >We are better off with improving the tooling that we already know 
> *will* 
> >> >continue to be used: Namely the tooling for creating and maintaining 
> our 
> >> >metadata in build/pkgs.
> >>
> >> Or it will be discarded as useless, because doing things the way 
> projects 
> >> like scipy do is better.
> >>
> >> Your package tooling is makework, repeating with worse tools what 
> already 
> >> is done by Conda, Homebrew, Linux distros, etc. We are mainly a maths 
> >> project, not a distro project. Let us stay this way, and actually do 
> more 
> >> maths and less distro-like stuff.
> >>
> >> Dima
> >>
> >>
> >> > Issues such as:
> >> >- https://github.com/sagemath/sage/issues/36356, 
> >> >- https://github.com/sagemath/sage/pull/37322, 
> >> >- https://github.com/sagemath/sage/issues/37323, 
> >> >- https://github.com/sagemath/sage/issues/37314
> >> >
> >>
> >
>

-- 
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/3f85faf4-840a-4965-bd81-797f2733843fn%40googlegroups.com.

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

[John H Palmieri]

Sentences like "At the moment you are actively breaking down the precious 
project fabric, all in the name of you having your way" are personal 
attacks. Please stop.

On Tuesday, February 27, 2024 at 12:36:44 PM UTC-8 Dima Pasechnik wrote:

>
>
> On 27 February 2024 19:37:31 GMT, Matthias Koeppe  
> wrote:
> >On Tuesday, February 27, 2024 at 10:50:55 AM UTC-8 John H Palmieri wrote:
> >
> >A pretty safe second choice would be to have "make download" also 
> download 
> >the relevant files for pip installation and tell pip where to find them. 
> If 
> >we implemented this second choice [...]
> >
> >
> >The problem is that such tooling, even if "trivial", would need to be 
> >implemented, tested, and maintained as well. And typically this just does 
> >not work when there is no developer who is actually interested in using 
> it.
>
> It is a largely artificially invented, by you, problem, to shoot my 
> proposal down. Besides, these tools are trivial to build and maintain, much 
> easier than your ever growing and breaking maze of packages we don't even 
> need to vendor.
>
> At the moment you are actively breaking down the precious project fabric, 
> all in the name of you having your way: 
>
> you blocked me (without bothering yo even tell me) and perhaps other 
> developers on GitHub, meaning that you effectively want to shut me up.
> (Well, I had no other choice but to block you too, as a countermeasure; I 
> installed this block about 12:00 GMT, today.)
>
> Of course it's easy to skip this message. But tomorrow it might be you who 
> Matthias might block, for disagreements with him.
> Why is this tolerated? This is a naked attempt to shut down the opposition.
>
>
> >
> >We are better off with improving the tooling that we already know *will* 
> >continue to be used: Namely the tooling for creating and maintaining our 
> >metadata in build/pkgs.
>
> Or it will be discarded as useless, because doing things the way projects 
> like scipy do is better.
>
> Your package tooling is makework, repeating with worse tools what already 
> is done by Conda, Homebrew, Linux distros, etc. We are mainly a maths 
> project, not a distro project. Let us stay this way, and actually do more 
> maths and less distro-like stuff.
>
> Dima
>
>
> > Issues such as:
> >- https://github.com/sagemath/sage/issues/36356, 
> >- https://github.com/sagemath/sage/pull/37322, 
> >- https://github.com/sagemath/sage/issues/37323, 
> >- https://github.com/sagemath/sage/issues/37314
> >
>

-- 
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/15220b4c-09f8-4408-9152-816ef45b4261n%40googlegroups.com.

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

[John H Palmieri]

Regarding the proposal to allow standard packages to be pip packages, no 
one really knows how much people rely on the all-in-one tarball that we 
currently distribute. No one really knows how often the "make download" 
option is used for people who just clone the git repo and want to do all of 
their downloads at once. Since we don't know, the absolute safest course of 
action is to not change anything, but maybe that's too conservative. A 
pretty safe second choice would be to have "make download" also download 
the relevant files for pip installation and tell pip where to find them. If 
we implemented this second choice, I would support this aspect of Dima's 
proposal.

My impression from Dima's posts is that he would like us to frequently not 
provide version information for pip packages. Here are some of my thoughts:

As Nathan points out, this will likely lead to instability. Someone will 
upgrade some component, and most of the time that will be fine, but 
occasionally it will break something on some platform, and it could be 
annoying to track down the cause. If this leads to Sage failing to build, 
that's not great, but it would be *far worse* if Sage built and ran but 
produced some mathematically incorrect answers. Being able to control all 
of the versions means that our doctests are pretty robust. If we really 
want to go down the road of unpinning version requirements, I propose that 
we *always* pin version requirements for the mathematical components of 
Sage. If Jupyter or Sphinx doesn't work right, it doesn't affect the 
mathematics, but if linbox or pari don't work right (or ore_algebra, if you 
want a pip package), people could be getting different answers on different 
platforms and we might not know about it for a while. To maintain the 
mathematical integrity of the project, we should keep very careful control 
of the mathematical components of Sage.


On Saturday, February 24, 2024 at 3:40:02 PM UTC-8 Matthias Koeppe wrote:

> On Monday, February 12, 2024 at 6:42:07 PM UTC-8 Matthias Koeppe wrote:
>
> On Monday, February 12, 2024 at 3:52:29 PM UTC-8 Matthias Koeppe wrote:
>
>
> *Proposed action items: *
> *A.* Change https://github.com/sagemath/sage/blob/develop/README.md so 
> that "git clone" is described as the primary way to obtain the Sage 
> sources. That the big release tarball is available can be a footnote in the 
> Installation Guide (
> https://deploy-livedoc--sagemath.netlify.app/html/en/installation/source#installation-steps)
>  
> for the limited no-internet connectivity use case.
>
>
> That's now https://github.com/sagemath/sage/pull/37309 (needs review)
>
>
> Thanks for all comments on the PR. Ready for final review. 
>  
>
>  *B. *Likewise, get rid of all of these "Download Sage source code" pages 
> (https://www.sagemath.org/download-source.html, 
> https://www.sagemath.org/download-latest.html), mirror selection, etc. 
> from the Sage website. 
>
> That's now https://github.com/sagemath/website/pull/466
>
>
> This one has already been merged, thanks, Harald! 
> The "Download" menu no longer sends people to the tarball download pages. 
> The pages are, of course, still there, and links from the installation 
> guide point to them.
>
> [image: Screenshot 2024-02-24 at 3.34.47 PM.png]
>
> On Tuesday, February 20, 2024 at 6:44:32 PM UTC-8 Matthias Koeppe wrote:
>
> On Monday, February 19, 2024 at 12:09:54 PM UTC-8 Matthias Koeppe wrote:
>
> Prompted by the discussion of space use on the *local machines* of users 
> and developers, I propose another item in addition to A and B:
>
> *C. Advertise use of "git worktree" and recommend symlinking the 
> "upstream" directory.* For testing a new release when you have an 
> existing clone of the repository, using "git clone" another time is 
> overkill as it creates another copy of the .git directory. And there is no 
> point in having multiple copies of the "upstream" directory, as the 
> filenames of the tarballs change whenever the contents change.
>
>
> That's now https://github.com/sagemath/sage/pull/37411 (needs review)
>
>
> This one has been positively reviewed. Thanks, Lorenz! 
>
>

-- 
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/b448c1da-eb22-4402-aea7-09bec2ab88e9n%40googlegroups.com.

Re: [sage-devel] Re: Unload "blocker" label

[John H Palmieri]

(and Tobias also proposed in https://github.com/sagemath/sage/issues/37428)

On Monday, February 26, 2024 at 5:05:56 PM UTC-8 John H Palmieri wrote:

> I think that usage (1) is the correct use of "blocker," and usage (3) is 
> not. Usage (2) should have a new name, as Vincent proposes. Failing that, 
> this new use of "blocker" must be documented in 
> https://doc.sagemath.org/html/en/developer/review.html.
>
> On Monday, February 26, 2024 at 4:21:58 PM UTC-8 Kwankyu Lee wrote:
>
>> On Tuesday, February 27, 2024 at 2:43:18 AM UTC+9 Vincent Delecroix wrote:
>>
>> In that case, let me do a proposal. 
>>
>> Introduce a new label distinct from "blocker" for
>>
>> usage 2: PRs that should be merged temporarily before CI tests run
>>
>>
>> I meant by "merged temporarily" the "CI fixes" in Matthias' explanation:  
>>
>>- *Within the release candidate stage,* developers who mark a PR as a 
>>"blocker" so that it be merged in the upcoming stable release need to 
>> know 
>>whether their blocker PR will be conflicting with other blockers (= 
>>candidates for merging in the next rc). Having the "blocker" label double 
>>as the "CI fixes" trigger takes care of this.
>>
>> So blocker PRs get the chance to be tested together before the release by 
>> the "CI fixes" mechanism. Thus "usage 1" and "usage 2" are connected. 
>> Having distinct labels for them does not reflect the connection.
>>
>> I propose (as this discussion is a place to give proposals :-) to give 
>> "the chance to be tested together" only to blocker PRs with "positive 
>> review". This slightly separates "usage 1" and "usage 2". This proposal was 
>> suggested when the "CI fixes" mechanism was introduced, and can be 
>> activated easily.
>>
>>  
>>  
>>  
>>
>

-- 
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/667ef622-5c51-4591-b041-1782061dca8bn%40googlegroups.com.

Re: [sage-devel] Re: Unload "blocker" label

[John H Palmieri]

I think that usage (1) is the correct use of "blocker," and usage (3) is 
not. Usage (2) should have a new name, as Vincent proposes. Failing that, 
this new use of "blocker" must be documented in 
https://doc.sagemath.org/html/en/developer/review.html.

On Monday, February 26, 2024 at 4:21:58 PM UTC-8 Kwankyu Lee wrote:

> On Tuesday, February 27, 2024 at 2:43:18 AM UTC+9 Vincent Delecroix wrote:
>
> In that case, let me do a proposal. 
>
> Introduce a new label distinct from "blocker" for
>
> usage 2: PRs that should be merged temporarily before CI tests run
>
>
> I meant by "merged temporarily" the "CI fixes" in Matthias' explanation:  
>
>- *Within the release candidate stage,* developers who mark a PR as a 
>"blocker" so that it be merged in the upcoming stable release need to know 
>whether their blocker PR will be conflicting with other blockers (= 
>candidates for merging in the next rc). Having the "blocker" label double 
>as the "CI fixes" trigger takes care of this.
>
> So blocker PRs get the chance to be tested together before the release by 
> the "CI fixes" mechanism. Thus "usage 1" and "usage 2" are connected. 
> Having distinct labels for them does not reflect the connection.
>
> I propose (as this discussion is a place to give proposals :-) to give 
> "the chance to be tested together" only to blocker PRs with "positive 
> review". This slightly separates "usage 1" and "usage 2". This proposal was 
> suggested when the "CI fixes" mechanism was introduced, and can be 
> activated easily.
>
>  
>  
>  
>

-- 
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/001204a7-53fe-43ec-8be6-d2dbdd15b69dn%40googlegroups.com.

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

[John H Palmieri]

You're right, plus I was confusing "./bootstrap -d" (which is run by "make 
configure") with "./bootstrap -D" which forces the download.

On Monday, February 19, 2024 at 3:17:11 PM UTC-8 Matthias Koeppe wrote:

> On Monday, February 19, 2024 at 3:09:55 PM UTC-8 John H Palmieri wrote:
>
> By the way, I just cloned the Sage repo and ran "make configure", which 
> runs `./bootstrap`. The upstream directory is empty after that.
>
>
> You probably have autoconf/automake/... installed. In this case, it just 
> uses them to build the configure script. Downloading is a fallback that is 
> used when these "bootstrapping prerequisites" are not installed.
>
>
>

-- 
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/ed16aa03-8b75-4dd1-bf74-567882d16646n%40googlegroups.com.

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

[John H Palmieri]

If we keep a "configure" tarball in each separate Sage installation but 
they share the rest of "upstream", then we save a lot of space and a lot of 
downloading. A workflow like

% make configure
% configure --with-lots-of-options
% make

would be familiar and unchanged from the status quo when working with the 
git clone. Currently users don't have to run `./bootstrap` manually just to 
build Sage, and it would be nice to keep it this way.

By the way, I just cloned the Sage repo and ran "make configure", which 
runs `./bootstrap`. The upstream directory is empty after that. If it's 
getting used for temporary storage for this tarball, that can be done 
elsewhere (.upstream.d? config? some temporary directory?).

Another option for the location of a shared "upstream" would be Yet Another 
Environment Variable.

On Monday, February 19, 2024 at 2:41:11 PM UTC-8 Dima Pasechnik wrote:

> On Mon, Feb 19, 2024 at 10:29 PM Matthias Koeppe  
> wrote:
>
>> An option to "./configure" could work too, except that the "bootstrap" 
>> phase already downloads the "configure" tarball into that directory.
>
>
> an option to ./bootstrap then would be logical
>  
>
>>
>> Another possible direction: I've been thinking about creating a "./sage 
>> worktree" command, see https://github.com/sagemath/sage/issues/34744
>>
>>
>> On Monday, February 19, 2024 at 2:24:40 PM UTC-8 John H Palmieri wrote:
>>
>>> Regarding symlinking the upstream directory: instead or in addition, 
>>> what about an option to `./configure` for the location of that directory?
>>>
>>>
>>> On Monday, February 19, 2024 at 12:09:54 PM UTC-8 Matthias Koeppe wrote:
>>>
>>>> Prompted by the discussion of space use on the *local machines* of 
>>>> users and developers, I propose another item in addition to A and B:
>>>>
>>>> *C. Advertise use of "git worktree" and recommend symlinking the 
>>>> "upstream" directory.* For testing a new release when you have an 
>>>> existing clone of the repository, using "git clone" another time is 
>>>> overkill as it creates another copy of the .git directory. And there is no 
>>>> point in having multiple copies of the "upstream" directory, as the 
>>>> filenames of the tarballs change whenever the contents change.
>>>>
>>>> On Monday, February 19, 2024 at 11:42:01 AM UTC-8 John H Palmieri wrote:
>>>>
>>>> This (A and B below) has the advantage of being quite explicit. The 
>>>> original proposal
>>>>
>>>> 1) allow standard packages to be pip packages 
>>>>
>>>> 2) drop the contents of upstream/ from the Sage source tarballs. 
>>>>
>>>> sounds explicit, but the more the discussion goes on, the more I feel 
>>>> that there are hidden pieces. Does the proposal also mean removing version 
>>>> restrictions and all of the other claimed maintenance burden for various 
>>>> components of Sage? 
>>>>
>>>> Regarding item (2): if I clone the github repository, there is no 
>>>> upstream directory at the start, but after building Sage, it ends up being 
>>>> almost as large as in the current tarballs. (This is on OS X with a lot of 
>>>> homebrew packages installed.) So how much savings are we actually talking 
>>>> about? (Maybe it's not savings for the end user that are important, so 
>>>> *what* are we saving? Disk space on the mirrors?) Dima, can you please 
>>>> provide data? If we convert (according to (1)) to pip packages, those 
>>>> still 
>>>> need to be downloaded, and while they may not end up in "upstream" — I 
>>>> don't actually know how they work — don't they still take up disk space? 
>>>> So 
>>>> again, how much savings are we talking about? Please provide data.
>>>>
>>>> By the way, the git clone yields a package that is 616M on my machine. 
>>>> A good chunk of that is the .git directory. Are you proposing that we do 
>>>> not distribute this? (A recent beta tarball is 1.4G, unpacked 1.6G.)
>>>>
>>>> Regarding item (1): can you provide a list of packages that would 
>>>> become pip packages? Or describe how you would come up with a list?
>>>>
>>>>
>>>> On Monday, February 12, 2024 at 3:52:29 PM UTC-8 Matthias Koeppe wrote:
>>>>
>>>> I'll now offer:
>>>>
>>>> *

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

[John H Palmieri]

Regarding symlinking the upstream directory: instead or in addition, what 
about an option to `./configure` for the location of that directory?


On Monday, February 19, 2024 at 12:09:54 PM UTC-8 Matthias Koeppe wrote:

> Prompted by the discussion of space use on the *local machines* of users 
> and developers, I propose another item in addition to A and B:
>
> *C. Advertise use of "git worktree" and recommend symlinking the 
> "upstream" directory.* For testing a new release when you have an 
> existing clone of the repository, using "git clone" another time is 
> overkill as it creates another copy of the .git directory. And there is no 
> point in having multiple copies of the "upstream" directory, as the 
> filenames of the tarballs change whenever the contents change.
>
> On Monday, February 19, 2024 at 11:42:01 AM UTC-8 John H Palmieri wrote:
>
> This (A and B below) has the advantage of being quite explicit. The 
> original proposal
>
> 1) allow standard packages to be pip packages 
>
> 2) drop the contents of upstream/ from the Sage source tarballs. 
>
> sounds explicit, but the more the discussion goes on, the more I feel that 
> there are hidden pieces. Does the proposal also mean removing version 
> restrictions and all of the other claimed maintenance burden for various 
> components of Sage? 
>
> Regarding item (2): if I clone the github repository, there is no upstream 
> directory at the start, but after building Sage, it ends up being almost as 
> large as in the current tarballs. (This is on OS X with a lot of homebrew 
> packages installed.) So how much savings are we actually talking about? 
> (Maybe it's not savings for the end user that are important, so *what* are 
> we saving? Disk space on the mirrors?) Dima, can you please provide data? 
> If we convert (according to (1)) to pip packages, those still need to be 
> downloaded, and while they may not end up in "upstream" — I don't actually 
> know how they work — don't they still take up disk space? So again, how 
> much savings are we talking about? Please provide data.
>
> By the way, the git clone yields a package that is 616M on my machine. A 
> good chunk of that is the .git directory. Are you proposing that we do not 
> distribute this? (A recent beta tarball is 1.4G, unpacked 1.6G.)
>
> Regarding item (1): can you provide a list of packages that would become 
> pip packages? Or describe how you would come up with a list?
>
>
> On Monday, February 12, 2024 at 3:52:29 PM UTC-8 Matthias Koeppe wrote:
>
> I'll now offer:
>
> *Opinion 1. Nobody needs to care in the slightest what the size of that 
> release tarball is. *
>
> In any use cases with internet connectivity, people will be better off by 
> just cloning the git repo, not use the release tarball.
>
> If there are relevant use cases without internet connectivity (I have no 
> opinion to offer on this), then the release tarball has exactly the right 
> contents.
>
> *Proposed action items: *
> *A.* Change https://github.com/sagemath/sage/blob/develop/README.md so 
> that "git clone" is described as the primary way to obtain the Sage 
> sources. That the big release tarball is available can be a footnote in the 
> Installation Guide (
> https://deploy-livedoc--sagemath.netlify.app/html/en/installation/source#installation-steps)
>  
> for the limited no-internet connectivity use case.
>
> *B. *Likewise, get rid of all of these "Download Sage source code" pages (
> https://www.sagemath.org/download-source.html, 
> https://www.sagemath.org/download-latest.html), mirror selection, etc. 
> from the Sage website. 
>
>
> On Sunday, February 11, 2024 at 11:23:42 AM UTC-8 Dima Pasechnik wrote:
>
> Currently the standard packages cannot be pip packages, i.e. we must, in 
> effect, vendor them. This entails an extra effort which is often not 
> needed, in particular as we patch only very few Python packages. 
> Pip packages are on the other hand installed straight from PyPI. 
>
> Good examples of standard packages which can become pip ones are tox, 
> pytest (not yet standard). 
>
>
> The other difference is that by default these packages are not included in 
> the Sage releases source tarball. 
>
> Rather than adding them there I propose to split the upstream/* part of 
> the tarball into something optional - which is represented by a list of 
> files to download, and which is just not needed if you build while 
> connected to the internet. 
>
> This is a huge saving on the tarball size: with upstream/* in, Sage 10.2 
> tarball is 1.3Gb, and without it is smaller than 0.25Gb. 
>
> Note that as William writes, the desire to have 

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

[John H Palmieri]

On Monday, February 19, 2024 at 12:10:49 PM UTC-8 Dima Pasechnik wrote:

On Mon, Feb 19, 2024 at 7:42 PM John H Palmieri wrote:

This (A and B below) has the advantage of being quite explicit. The 
original proposal

1) allow standard packages to be pip packages 

2) drop the contents of upstream/ from the Sage source tarballs. 

sounds explicit, but the more the discussion goes on, the more I feel that 
there are hidden pieces. Does the proposal also mean removing version 
restrictions and all of the other claimed maintenance burden for various 
components of Sage? 


No, this is simply FUD spread by certain parties here. 


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.


 

pytest is good example of package which can be elevated to standard, but 
kept pip. In no place my
proposal 1) demands anything done for all packages.



Regarding item (2): if I clone the github repository, there is no upstream 
directory at the start, but after building Sage, it ends up being almost as 
large as in the current tarballs. (This is on OS X with a lot of homebrew 
packages installed.) So how much savings are we actually talking about? 
(Maybe it's not savings for the end user that are important, so *what* are 
we saving? Disk space on the mirrors?) Dima, can you please provide data? 
If we convert (according to (1)) to pip packages, those still need to be 
downloaded, and while they may not end up in "upstream" — I don't actually 
know how they work — don't they still take up disk space? So again, how 
much savings are we talking about? Please provide data.


I am talking about saving space on mirrors, and on bandwidth, by not 
packaging "upstream/".
(as I wrote: This is a huge saving on the tarball size: with upstream/* in, 
Sage 10.2 tarball is 1.3Gb, and without it is smaller than 0.25Gb.)
Local disk space nowadays is cheap, but space on mirrors, and bandwidth, 
don't come free.
(not everyone is on an unlimited internet)

As well, if you don't wipe up your local upstream/, its contents can  be 
reused.
(typically not so many packages are updated with each release after all)

However, as far as I can tell, by default pip package wheels are not stored 
in upstream/.
Perhaps there is an easy way to change this, I don't know.
 
 


By the way, the git clone yields a package that is 616M on my machine. A 
good chunk of that is the .git directory. Are you proposing that we do not 
distribute this? (A recent beta tarball is 1.4G, unpacked 1.6G.) 


Regarding item (1): can you provide a list of packages that would become 
pip packages? Or describe how you would come up with a list?


packages not involved in sagelib directly are good candidates, e.g. pytest, 
tox.
sphinx and jupyterlab are good candidates too, in my limited testing 
experiments.

Dima


On Monday, February 12, 2024 at 3:52:29 PM UTC-8 Matthias Koeppe wrote:

I'll now offer:

*Opinion 1. Nobody needs to care in the slightest what the size of that 
release tarball is. *

In any use cases with internet connectivity, people will be better off by 
just cloning the git repo, not use the release tarball.

If there are relevant use cases without internet connectivity (I have no 
opinion to offer on this), then the release tarball has exactly the right 
contents.

*Proposed action items: *
*A.* Change https://github.com/sagemath/sage/blob/develop/README.md so that 
"git clone" is described as the primary way to obtain the Sage sources. 
That the big release tarball is available can be a footnote in the 
Installation Guide (
https://deploy-livedoc--sagemath.netlify.app/html/en/installation/source#installation-steps)
 
for the limited no-internet connectivity use case.

*B. *Likewise, get rid of all of these "Download Sage source code" pages (
https://www.sagemath.org/download-source.html, 
https://www.sagemath.org/download-latest.html), mirror selection, etc. from 
the Sage website. 


On Sunday, February 11, 2024 at 11:23:42 AM UTC-8 Dima Pasechnik wrote:

Currently the st

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

[John H Palmieri]

This (A and B below) has the advantage of being quite explicit. The 
original proposal

1) allow standard packages to be pip packages 

2) drop the contents of upstream/ from the Sage source tarballs. 

sounds explicit, but the more the discussion goes on, the more I feel that 
there are hidden pieces. Does the proposal also mean removing version 
restrictions and all of the other claimed maintenance burden for various 
components of Sage? 

Regarding item (2): if I clone the github repository, there is no upstream 
directory at the start, but after building Sage, it ends up being almost as 
large as in the current tarballs. (This is on OS X with a lot of homebrew 
packages installed.) So how much savings are we actually talking about? 
(Maybe it's not savings for the end user that are important, so *what* are 
we saving? Disk space on the mirrors?) Dima, can you please provide data? 
If we convert (according to (1)) to pip packages, those still need to be 
downloaded, and while they may not end up in "upstream" — I don't actually 
know how they work — don't they still take up disk space? So again, how 
much savings are we talking about? Please provide data.

By the way, the git clone yields a package that is 616M on my machine. A 
good chunk of that is the .git directory. Are you proposing that we do not 
distribute this? (A recent beta tarball is 1.4G, unpacked 1.6G.)

Regarding item (1): can you provide a list of packages that would become 
pip packages? Or describe how you would come up with a list?


On Monday, February 12, 2024 at 3:52:29 PM UTC-8 Matthias Koeppe wrote:

> I'll now offer:
>
> *Opinion 1. Nobody needs to care in the slightest what the size of that 
> release tarball is. *
>
> In any use cases with internet connectivity, people will be better off by 
> just cloning the git repo, not use the release tarball.
>
> If there are relevant use cases without internet connectivity (I have no 
> opinion to offer on this), then the release tarball has exactly the right 
> contents.
>
> *Proposed action items: *
> *A.* Change https://github.com/sagemath/sage/blob/develop/README.md so 
> that "git clone" is described as the primary way to obtain the Sage 
> sources. That the big release tarball is available can be a footnote in the 
> Installation Guide (
> https://deploy-livedoc--sagemath.netlify.app/html/en/installation/source#installation-steps)
>  
> for the limited no-internet connectivity use case.
>
> *B. *Likewise, get rid of all of these "Download Sage source code" pages (
> https://www.sagemath.org/download-source.html, 
> https://www.sagemath.org/download-latest.html), mirror selection, etc. 
> from the Sage website. 
>
>
> On Sunday, February 11, 2024 at 11:23:42 AM UTC-8 Dima Pasechnik wrote:
>
>> Currently the standard packages cannot be pip packages, i.e. we must, in 
>> effect, vendor them. This entails an extra effort which is often not 
>> needed, in particular as we patch only very few Python packages. 
>> Pip packages are on the other hand installed straight from PyPI. 
>>
>> Good examples of standard packages which can become pip ones are tox, 
>> pytest (not yet standard). 
>>
>>
>> The other difference is that by default these packages are not included 
>> in the Sage releases source tarball. 
>>
>> Rather than adding them there I propose to split the upstream/* part of 
>> the tarball into something optional - which is represented by a list of 
>> files to download, and which is just not needed if you build while 
>> connected to the internet. 
>>
>> This is a huge saving on the tarball size: with upstream/* in, Sage 10.2 
>> tarball is 1.3Gb, and without it is smaller than 0.25Gb. 
>>
>> Note that as William writes, the desire to have Sage buildable without an 
>> internet connection was a requirement by a past Sage funder, gone about 10 
>> years ago. Thus there's no longer an obligation to have this option. 
>> I am not aware of a similar to Sage which provides tarballs allowing for 
>> an offline build. 
>>
>> Thus, I would like to call a vote on these two topics: 
>>
>> 1) allow standard packages to be pip packages 
>>
>> 2) drop the contents of upstream/ from the Sage source tarballs. 
>>
>>
>> --- 
>> 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/0a3c1c0b-ed3f-41eb-ab4a-5235432475dbn%40googlegroups.com.

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

[John H Palmieri]

What does this (a discussion of how Sage specifies version restrictions) 
have to do with the proposal? If it's relevant, that was not clear in the 
original proposal, so please clarify. It sounds like you might be proposing 
removing version checks on many of the packages Sage uses, or at least 
that's a conclusion I might draw from your critique of the amount of 
maintenance for Sage packages. Or maybe you are proposing redesigning the 
version specification system? In any case, it wasn't stated as part of the 
original proposal, so I don't know what was intended. If it is not relevant 
to the proposal, let's drop this part of the discussion.

I would also suggest dropping the question of whether we're "vendoring." 
The proposal clearly says that we should stop distributing the tarballs in 
the upstream directory, so whatever we call it, that part is clear.

(Maybe by "vendoring" you meant the combination of including the tarballs 
and the maintenance on the allowed versions, or maybe just including the 
tarballs, or maybe something else. The word "vendoring" does not seem to be 
helpful, so instead spelling out exactly what's meant for Sage could be 
helpful, at least if you meant more than just removing "upstream".)

On Monday, February 12, 2024 at 3:07:38 PM UTC-8 Dima Pasechnik wrote:

> On Mon, Feb 12, 2024 at 10:01 PM Matthias Koeppe
>  wrote:
> >
> > On Monday, February 12, 2024 at 10:49:04 AM UTC-8 Dima Pasechnik wrote:
> >
> > requirements.txt might as well specify the range, and this is used too 
> e.g.
> >
> > build/pkgs/phitigra/requirements.txt has
> > phitigra>=0.2.6
> >
> >
> > Yes, as I said in 
> https://groups.google.com/g/sage-devel/c/5kmxaw105lg/m/9rF77fvFAAAJ, 
> ""Pip" packages can either be pinned to a specific version, or set 
> acceptable version ranges, or be entirely unconstrained. This is set in the 
> file requirements.txt in the package directory."
> >
> > So this is all [...] confusing
> >
> >
> > That's why I'm taking the time to explain it clearly for the benefit of 
> everyone.
>
> I am sorry: I claimed that Sage has about 5 different ways to
> specify/restrict versions of its packages,
> and this makes it hugely confusing.
> You disagreed, but now you say that it needs an explanation.
>
> What really needs an explanation is how we ever went this far on a
> garden path. :-)
>

-- 
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/b89c5e20-0fb0-4c92-8333-4f1766a2bfa1n%40googlegroups.com.

[sage-devel] Re: Policy for disputed PRs: discussion

[John H Palmieri]

The original proposal allows for anyone to post to sage-devel to try to 
raise awareness ("Also note that an objector is welcome to attempt to bring 
others into the discussion on their side if they remain firmly opposed"). I 
prefer allowing the various participants the freedom to decide whether to 
start a discussion in sage-devel rather than forcing this to happen, but 
I'm happy to hear arguments for changing it as you propose.

For some topics and disputes, it is clear that they should be discussed on 
sage-devel, perhaps even discussed here before getting to the point of a 
PR. Recalling one of William's old April 1 jokes, if we wanted to consider 
switching the infrastructure from Python to Lisp, that would require a 
discussion on sage-devel first. You mentioned 
https://github.com/sagemath/sage/pull/35403, and I think that's another 
good example. That deals with which versions of Python we support and 
whether to automatically reject certain versions. Python plays such a 
central role in Sage, but at the same time that PR is somewhat technical, 
so I feel that it's on the border of "clearly should be discussed first on 
sage-devel" vs. "can be handled in the background". Once the conflict 
arose, it made a lot of sense to bring it to sage-devel. A third example: 
Kwankyu raised https://github.com/sagemath/sage/pull/36726, and in my view 
this one is very minor and technical, and I don't see a case for a long 
discussion or vote on sage-devel. Mentioning it here to raise awareness 
makes sense, but that should be the extent of it; the rest of the 
discussion can happen on github.

To the extent that this specific PR is emblematic of a particular approach 
to Sage development (a flawed approach in Dima's view, if I understand 
right), then the whole approach should be discussed here. Probably many of 
these issues in Sage development have been discussed already, but it's 
probably time to revisit them, to see if we can reestablish a baseline 
level of consensus.
 
On Wednesday, November 29, 2023 at 7:12:31 AM UTC-8 tobia...@gmx.de wrote:

> At first I was very enthusiastic about this proposed policy, but after 
> thinking about this for a bit I'm no longer convinced this is a good idea. 
>
> First of all, the policy sets out to solve the case "where there is a 
> general consensus, but one person (or a few people) disagree". In my 
> experience, this case is not a problem. All the examples mentioned so far 
> (and the few other examples I'm aware of), have usually one positive 
> reviewer and one negative review. This is not a general consensus. The 
> problem is more that a general consensus cannot be reached. Another aspect 
> of the issue is that usually only a very small group of 2 to 3 people is 
> involved in discussing the PR, which perhaps not surprisingly then more 
> easily results in a state where all arguments have been exchanged without 
> finding a solution satisfying everyone. 
> For example, with the proposed policy, Dima and me would have outvoted 
> Matthias in https://github.com/sagemath/sage/pull/35403. But this PR was 
> largely improved by the discussion on the mailing list (that it is still 
> not clear how to proceed with this PR is another sad story).
>
> In light of this, I would like to propose to change the policy proposal to 
> an automatic system that draws more attention to the PR, with the hope that 
> new people bring new input and ideas, which then resolves the conflict in a 
> natural way. The proposal is something along the following: if a PR is say 
> a week in the "disputed state" as defined above by Kwankyu, both parties 
> write a short statement of why they think it should or should not be 
> merged, and this summary is then posted to the mailing list. Not to start a 
> voting, but to raise awareness and invite other devs to join the 
> discussion. Similar calls for PR reviews are not uncommon on the mailing 
> list, so I don't think it would annoy subscribers too much.
>
> Finally, I think Dima raises a very important point. Most of the 
> discussions in these "disputed PRs" are a result of a lack of a common 
> vision for the project and agreement on what projects to work on. It would 
> be immensely more productive to have a general discussion e.g. about how to 
> proceed with sage-the-distribution (replace it?, with what?, how to sunset 
> it? reduce it? enlarge it?). As an example, I think conda is a good 
> candidate to replace sage-the-distribution and thus naturally open PRs with 
> changes in that direction. But if you don't agree with this general 
> direction, it's easy to find these changes annoying. On the other hand, if 
> there would be an agreement that conda was a nice experiment that we don't 
> want to continue, then I'm happy to delete it completely. But instead of a 
> general direction, we have this situation where every developer is having 
> their own ideas and little projects that they are working on, and that are 
> bound to step 

[sage-devel] Re: Policy for disputed PRs: discussion

[John H Palmieri]

I agree that we need a policy, and I am happy with David's proposal.

A tangential follow-up to Matthias: I think that our code of conduct should 
be part of the distributed documentation. Should it be in the Developer's 
Guide? In some other existing documentation? As a standalone document?

-- 
John

On Saturday, November 25, 2023 at 1:24:42 AM UTC-8 Kwankyu Lee wrote:

> I agree that we need a policy for disputed PRs.
>
> Such a policy should not operate in a way to condemn those raising 
> objections to the PR since we want to keep kind, productive, caring 
> atmosphere as Matthias put it. The policy should be clear and operate 
> semi-automatically. So I suggest the following detail:
>
> (1) When a PR becomes a disputed PR? A PR becomes a disputed PR when one 
> reviewer adds "positive review" label, another reviewer removes it, and the 
> author does not plan to work more on the PR according to the reviewer 
> objections.
>
> (2) How do we count approvers and disapprovers for a disputed PR: A 
> reviewer becomes an approver (who is in favor of the PR) when he/she sets 
> "Approve" in the github review system. A reviewer becomes a disapprover 
> (who objects the PR) when he/she sets "Request changes" in the github 
> review system.
>
> 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/e50b04dc-0e94-4440-9b0e-0c6e12bb470an%40googlegroups.com.

[sage-devel] Help with matroids (and more generally?), PR #36492

[John H Palmieri]

This post concerns https://github.com/sagemath/sage/pull/36492. The main 
topic of that PR is matroids about which I know almost nothing, so I am not 
the right person to review it. The structure of the PR perhaps opens up 
broader questions. The author has some new code, along with a PDF 
documenting it, and it is currently not designed to be incorporated into 
the existing sage.matroids module, but as more of a standalone piece of 
code.

- Should we have a "contrib" directory where we can easily include efforts 
like this?
- Should this particular code be instead included in our thematic 
tutorials? (If so, it needs someone to shepherd it through the process.)
- Or should this code be folded into the existing `sage.matroids` stuff?

-- 
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/fb6eea67-444c-4408-95e0-66119a535e11n%40googlegroups.com.

[sage-devel] Re: Errors with make on macOS

[John H Palmieri]

Try:

% make distclean # remove all progress, just in case
% brew install cddlib fplll gsl maxima python3 singular suite-sparse  # as 
recommended at the end of `./configure`
% ./configure

Then read the output and see if it still recommends installing gsl. I hope 
not. Then

% make


On Sunday, November 19, 2023 at 1:01:09 PM UTC-8 Josh Maglione wrote:

> When running 'make' in my sage directory, I encounter an error with the 
> gsl package. I am on a MacBook Pro using macOS Sonoma 14.1.1. I have also 
> attached logs. 
>
> Any help will be most appreciated. Thank you.
>
> Josh
>

-- 
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/ed2c4de3-e0f1-4795-b85d-a401aefb3f27n%40googlegroups.com.

Re: [sage-devel] Re: Question about make dependencies

[John H Palmieri]

If I respond using "verb" as a verb, do you really think I'm seriously 
criticizing you about using "vendor" as a verb? You're telling me to get a 
life? Get a sense of humor.

On Tuesday, November 14, 2023 at 3:45:07 PM UTC-8 Dima Pasechnik wrote:

> I have not invented the verb "to vendor", I merely picked it up from 
> Python docs and PEPs, e.g.
> https://www.python.org/dev/peps/pep-0518/#configparser
> (this one was written by  native English speakers, I think)
>
> You seem to prefer to pick on my supposedly broken English, rather than 
> read Python docs, as it's much less fun.
>
> Get a life.
>
>
>
> On Tue, 14 Nov 2023, 23:19 John H Palmieri,  wrote:
>
>> Not all Americans like to verb things so profligately.
>>
>> On Tuesday, November 14, 2023 at 1:15:07 PM UTC-8 Dima Pasechnik wrote:
>>
>>>
>>>
>>> On Tue, 14 Nov 2023, 20:39 Matthias Koeppe,  
>>> wrote:
>>>
>>>> On Tuesday, November 14, 2023 at 11:39:52 AM UTC-8 Dima Pasechnik wrote:
>>>>
>>>> On Tue, Nov 14, 2023 at 7:22 PM Marc Culler  
>>>> wrote: 
>>>> > On Tue, Nov 14, 2023 at 11:58 AM Dima Pasechnik  
>>>> wrote: 
>>>> >> I imagine it might be an artifact of the design of Sage on Mac app 
>>>> >> Marc is releasing: 
>>>> >> vendor everything. 
>>>> > 
>>>> > Vendor is a noun, not a verb. 
>>>>
>>>> It's a curse, to be precise, and it slows down the project a lot. 
>>>> We have to worry about over 400 packages!!! 
>>>> Bloody hell, pardon my UK French, we have more interesting problems to 
>>>> work on...
>>>>
>>>>
>>>> FWIW, I consider Marc's effort to provide a self-contained macOS app of 
>>>> Sage to be very valuable for the project.
>>>>
>>>> Dima is indeed using the word "vendor" incorrectly. I'm not concerned 
>>>> about the grammar; I use it as a verb, too, in this specific context.
>>>> For source code, "vendoring" (= including a copy of the source code of 
>>>> a dependency, modified or not, in the source code) is problematic for 
>>>> various well known reasons.
>>>> But to accuse a binary distribution of "vendoring" is simply 
>>>> meaningless. A binary distribution is made for the benefit of users.
>>>>
>>>
>>> I am not accusing Marc of vendoring, I am saying that him asking to 
>>> supply essentially all the components of Sage in source form is asking too 
>>> much, as it saddles us with extremely heavy maintenance task, for reasons 
>>> questionable.
>>>
>>> Suppose we remove gmp from the list of packages we vendor (yes, "to 
>>> vendor", i.e. "to perform vendoring", may be a verb, as we see here. As 
>>> Americans make verbs out of everything, I find myself being gaslighted here 
>>> by one of them.)
>>>
>>> What then, will it make the task of making a macOS Sage app impossible, 
>>> or much harder, all of a sudden?
>>> I have trouble believing this.
>>>
>>>
>>>> -- 
>>>> 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/fa119cf9-49bc-4b16-b6af-b1b6fd6584aen%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/sage-devel/fa119cf9-49bc-4b16-b6af-b1b6fd6584aen%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/943e37ef-0a11-4331-9e20-52141ccdddc7n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/943e37ef-0a11-4331-9e20-52141ccdddc7n%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/25a17216-502e-4c4d-b70d-73e6e028881cn%40googlegroups.com.

Re: [sage-devel] Re: Question about make dependencies

[John H Palmieri]

Not all Americans like to verb things so profligately.

On Tuesday, November 14, 2023 at 1:15:07 PM UTC-8 Dima Pasechnik wrote:

>
>
> On Tue, 14 Nov 2023, 20:39 Matthias Koeppe,  wrote:
>
>> On Tuesday, November 14, 2023 at 11:39:52 AM UTC-8 Dima Pasechnik wrote:
>>
>> On Tue, Nov 14, 2023 at 7:22 PM Marc Culler  wrote: 
>> > On Tue, Nov 14, 2023 at 11:58 AM Dima Pasechnik  
>> wrote: 
>> >> I imagine it might be an artifact of the design of Sage on Mac app 
>> >> Marc is releasing: 
>> >> vendor everything. 
>> > 
>> > Vendor is a noun, not a verb. 
>>
>> It's a curse, to be precise, and it slows down the project a lot. 
>> We have to worry about over 400 packages!!! 
>> Bloody hell, pardon my UK French, we have more interesting problems to 
>> work on...
>>
>>
>> FWIW, I consider Marc's effort to provide a self-contained macOS app of 
>> Sage to be very valuable for the project.
>>
>> Dima is indeed using the word "vendor" incorrectly. I'm not concerned 
>> about the grammar; I use it as a verb, too, in this specific context.
>> For source code, "vendoring" (= including a copy of the source code of a 
>> dependency, modified or not, in the source code) is problematic for various 
>> well known reasons.
>> But to accuse a binary distribution of "vendoring" is simply meaningless. 
>> A binary distribution is made for the benefit of users.
>>
>
> I am not accusing Marc of vendoring, I am saying that him asking to supply 
> essentially all the components of Sage in source form is asking too much, 
> as it saddles us with extremely heavy maintenance task, for reasons 
> questionable.
>
> Suppose we remove gmp from the list of packages we vendor (yes, "to 
> vendor", i.e. "to perform vendoring", may be a verb, as we see here. As 
> Americans make verbs out of everything, I find myself being gaslighted here 
> by one of them.)
>
> What then, will it make the task of making a macOS Sage app impossible, or 
> much harder, all of a sudden?
> I have trouble believing this.
>
>
>> -- 
>> 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/fa119cf9-49bc-4b16-b6af-b1b6fd6584aen%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/943e37ef-0a11-4331-9e20-52141ccdddc7n%40googlegroups.com.

[sage-devel] Re: https://github.com/sagemath/sage/wiki/Sage-10.2-Release-Tour

[John H Palmieri]

Where might changes to the Sage library go? I might want to highlight 
#36310.

On Friday, November 10, 2023 at 10:38:00 AM UTC-8 Matthias Koeppe wrote:

> So far we have:
>
> Sage 10.2 Release Tour 
> 
>
>- Live Documentation 
>
> 
>- Package upgrades and configuration changes 
>
> 
>- Python / Cython 
>
> 
>- NumPy / SciPy / Matplotlib 
>
> 
>- Bordeaux / Kaiserslautern / Paris 
>
> 
>- Other upgrades 
>
> 
>- New developer tools, modularization, deprecations 
>
> 
>- Open blocker PRs are applied automatically in CI workflows 
>
> 
>- ./configure --enable-system-site-packages (experimental) 
>
> 
>- make sagemath_categories-check 
>
> 
>- Deprecations 
>
>- Availability of Sage 10.2 and installation help 
>
> 
>- Sources 
>
>- Known problems and workarounds 
>
> 
>- Help 
>
>- More details 
>
>
>
>
>

-- 
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/91b0e53e-7d13-4bc0-aed9-8a42c506c761n%40googlegroups.com.

[sage-devel] Re: Need Some guidance

[John H Palmieri]

Read the Sage Developer's Guide 
(https://doc.sagemath.org/html/en/developer/) and take a look at the 
current issues for the project (https://github.com/sagemath/sage/issues).

On Tuesday, October 17, 2023 at 10:54:25 AM UTC-7 Himanshu Sharma wrote:

> Hello everyone I am currently new to open source and would love to 
> contribute something. My techstack includes 
> java,Django,python,mysql,apache,phpmyadmin. 
>
> > Please suggest me how to contribute furthur.
> Thank you all
>

-- 
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/f52b88a4-20ef-4cf8-9e82-0d74b0f22f89n%40googlegroups.com.

Re: [sage-devel] Poll: deprecate backslash operator

[John H Palmieri]

Right. According to the Sage Developer's Guide, "Deprecated code can only 
be removed one year after the first stable release in which it appeared," 
so it will work for at least a year, and then someone would have to take 
further action to remove it completely.

On Wednesday, October 4, 2023 at 12:26:01 PM UTC-7 John Cremona wrote:

> I assume that deprecation means that for a year or so people can still use 
> the backslash but will see a deprecation warning. This could last for quite 
> a long time, so existing code would not immediately break.
>
> On Wed, 4 Oct 2023, 18:41 Thierry Dumont,  
> wrote:
>
>> In "Computational Mathematics with SageMath" we have some backslash...
>>
>> So, if we deprecate it, we will have problems with the doctests 
>> asociated,... and with the book.
>>
>> I don't like the backslash for solving linear systems, but even Julia 
>> has adopted it, probably for Matlab users...
>>
>> t.d.
>>
>> Le 01/10/2023 à 05:17, Nils Bruin a écrit :
>> > Deprecate please.
>> > 
>> > -- 
>> > 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/699f7d70-4222-4f64-8ce4-e606478377a9n%40googlegroups.com
>>  
>> <
>> https://groups.google.com/d/msgid/sage-devel/699f7d70-4222-4f64-8ce4-e606478377a9n%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/90aec6f5-e47d-4981-941b-a7e909bcf518%40math.univ-lyon1.fr
>> .
>>
>

-- 
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/e1253d39-8856-4dae-b631-9e0c406293edn%40googlegroups.com.

[sage-devel] Re: Poll: deprecate backslash operator

[John H Palmieri]

By the way, see https://github.com/sagemath/sage/issues/36194 for a bug 
related to the preparser and "\".

On Tuesday, October 3, 2023 at 9:59:47 PM UTC-7 John H Palmieri wrote:

> The votes are overwhelmingly in favor of deprecating. I have opened 
> https://github.com/sagemath/sage/pull/36394 for this.
>
>
> On Monday, October 2, 2023 at 3:42:38 AM UTC-7 kcrisman wrote:
>
>> Though I am sympathetic to the pro-deprecation arguments and recognize 
>> they will win, I vote do not deprecate, as mission includes Matlab, and for 
>> backwards compatibility.  As an example, the first edition of the 
>> AMS-published "Sage for Undergraduates" used the backslash operator in a 
>> number of examples (comparing it explicitly with other solving methods for 
>> linear systems), so I presume the second edition has maintained that 
>> (though I don't personally own it and can't verify immediately; a related 
>> website does not seem to have all code examples).
>>
>> On Sunday, October 1, 2023 at 6:59:39 AM UTC-4 Ricardo Buring wrote:
>>
>>> Deprecate the pre-parsing of \
>>> the backslash operator please.
>>>
>>>

-- 
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/b6a41814-e185-4d8e-93e3-e868f0115436n%40googlegroups.com.

[sage-devel] Re: Poll: deprecate backslash operator

[John H Palmieri]

The votes are overwhelmingly in favor of deprecating. I have opened 
https://github.com/sagemath/sage/pull/36394 for this.


On Monday, October 2, 2023 at 3:42:38 AM UTC-7 kcrisman wrote:

> Though I am sympathetic to the pro-deprecation arguments and recognize 
> they will win, I vote do not deprecate, as mission includes Matlab, and for 
> backwards compatibility.  As an example, the first edition of the 
> AMS-published "Sage for Undergraduates" used the backslash operator in a 
> number of examples (comparing it explicitly with other solving methods for 
> linear systems), so I presume the second edition has maintained that 
> (though I don't personally own it and can't verify immediately; a related 
> website does not seem to have all code examples).
>
> On Sunday, October 1, 2023 at 6:59:39 AM UTC-4 Ricardo Buring wrote:
>
>> Deprecate the pre-parsing of \
>> the backslash operator please.
>>
>>

-- 
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/41076a42-da81-4875-ad20-6f355c496f08n%40googlegroups.com.

[sage-devel] Poll: deprecate backslash operator

[John H Palmieri]

I asked this already but with a different subject heading, so people may 
have missed it. 

BackslashOperator is defined in "sage/misc/misc.py", and the preparser 
converts "A \ b" to the appropriate Python code. The docstring for 
BackslashOperator says "Implements Matlab-style backslash operator for 
solving systems A \ b". 

This is not used much: for matrices, matroids, and a tiny bit (at least in 
the Sage library) for binary trees. Should we deprecate it?

Arguments for deprecation: the less we rely on the preparser, the better 
(at least as far as easing a transition between Python and Sage, for 
instance). The backslash operator is not in wide use in Sage. Currently its 
implementation breaks the standard Python use of "\" as a line-continuation 
marker.

Arguments against deprecation: it provides a convenient shorthand, and 
people may be familiar with it from Matlab or other systems.

-- 
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/a0659b81-f50f-4b59-91ed-42650409435an%40googlegroups.com.

Re: [sage-devel] What's the point of GF(2, impl='ntl')?

[John H Palmieri]

First, an error in the original message: it should have been 
"identity_matrix(F, 1)". That doesn't make any difference in the behavior. 
A little exploration suggests that the problem goes away if you make the 
identity matrix sparse: the problem may be with multiplying a dense matrix 
with a vector. I'm not sure about this, though.

This is with the most recent beta, built from scratch on several different 
OS X machines. It also happens on Sagecell. I have not yet opened an issue, 
because there are deeper existential questions: if linear algebra over this 
field is broken, and if there are no doctests to detect that it's broken, 
how viable is this implementation? How long has it been broken? Why has no 
one noticed? What is it used for? Should we keep it?

I think that if someone wanted to add a new implementation of a field to 
Sage today, we would insist on doctests verifying that it worked as a 
drop-in replacement for the existing implementations everywhere in Sage 
where fields get used. GF(2, impl='ntl') does not meet this standard. 
Someone can presumably fix this one bug, but is someone willing to add all 
of the doctests that should really be added?

On Friday, September 29, 2023 at 12:32:14 AM UTC-7 Vincent Delecroix wrote:

> What is your sage version? How did you install it? Did you open an
> issue on github?
>
> Best
> Vincent
>
> On Tue, 26 Sept 2023 at 07:00, John H Palmieri  
> wrote:
> >
> > Setup:
> >
> > sage: F = GF(2, impl='ntl')
> > sage: m_ntl = identity_matrix(1, F)
> > sage: v_ntl = vector(F, (1,))
> >
> > Now consider
> >
> > sage: m_ntl * v_ntl
> > sage: v_ntl * m_ntl
> >
> > I'm trying to multiply a 1x1 matrix by a 1-dimensional vector, in one 
> order or the other. Here's what happens: the first line fails with a 
> SignalError, and the second actually crashes Sage. If we are defining a 
> field that can't do linear algebra, shouldn't there be big warnings posted 
> somewhere? If we are defining a field like this, are there any expectations 
> that it should work broadly with Sage types and constructions? I just 
> discovered that cup products in mod 2 cohomology don't work when "mod 2" 
> means coefficients in GF(2, impl='ntl'), and I don't know if I should 
> bother trying to fix this.
> >
> > For what it's worth, I get the same with `GF(2, impl='givaro')`. Also 
> for what it's worth, explicitly converting `v_ntl` to a matrix allows the 
> matrix multiplication to work.
> >
> > I see this on two different OS X machines, one Intel and one Apple 
> Silicon.
> >
> > --
> > 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/faeffb72-3b16-4f37-90c4-f969e4d5c017n%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/378f06a5-2008-42fb-8642-32019a3a4976n%40googlegroups.com.

Re: [sage-devel] Discussion and poll: should Sage Integers have a backslash operator?

[John H Palmieri]

Okay, so maybe we should open this to other options: should we get rid of 
preparsing "\" into "BackslashOperator"?

For what it's worth, I removed the line defining `_backslash_` in 
binary_tree.py and and I only say one doctest failure in any obvious places 
(combinat and thematic_tutorials). So it's not even used much. Same for 
matroids.

I think that using \ to escape characters in strings still works, but 
line-continuation does not: in Sage, these fail:

sage: a = 3 + \

and

sage: \

whereas in pure Python, such backslashes would be treated as 
line-continuations. It should be possible to fix this while keeping the 
current preparser behavior for "\" in the middle of a line. Or as Nils 
proposes, getting rid of the current preparser behavior should also solve 
it.

On Wednesday, September 27, 2023 at 2:44:19 PM UTC-7 Nils Bruin wrote:

> I'm quite strongly against because it collides with a well-established 
> meaning of `\` in python: escape character. It's used to avoid command 
> termination by newline in things like formulas (as "\ parsed as whitespace rather than command termination outside of brackets).
>
> I'm in fact rather shocked that `\` in sage already doesn't work as it's 
> supposed to in python but instead gets substituted as "BackslashOperator()".
>
> Searching the codebase currently only shows "_backslash_" implemented on 
> matroid, matrix, and binary_tree, so extinguishing it should be doable. We 
> should definitely not entrench its use further.
>
> If you want to write your denominator first, you can already do ~2 * 3 . I 
> think that's already sufficiently perverse that we don't need another way 
> to spell that.
> On Wednesday, 27 September 2023 at 12:16:57 UTC-7 David Joyner wrote:
>
>> On Wed, Sep 27, 2023 at 2:32 PM John H Palmieri  
>> wrote:
>>
>>> The github issue #36060 (https://github.com/sagemath/sage/issues/36060) 
>>> proposes adding a backslash operator for Sage integers, so that "2 \ 3" 
>>> will return the same as "3 / 2". Do you support this?
>>>
>>>
>> I'm not for or against. However, I don't see the problem that 
>> implementing this "\" is going to solve. The ticket suggests that users 
>> will naturally type 2\3 instead of 3/2, if I am reading between the lines 
>> correctly. 
>>  
>>
>>> BackslashOperator is defined in "sage/misc/misc.py", and the preparser 
>>> converts "A \ b" to the appropriate Python code. The docstring for 
>>> BackslashOperator says "Implements Matlab-style backslash operator for 
>>> solving systems A \ b". 
>>>
>>> It seems pretty innocuous to me — in fact I don't care much either way — 
>>> but since Sage integers are so ubiquitous, it seems like a good idea to ask 
>>> before implementing it.
>>>
>>> -- 
>>> 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/3f157aa4-74cd-4c5c-bc76-f198c6417432n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/sage-devel/3f157aa4-74cd-4c5c-bc76-f198c6417432n%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/941e7314-5f78-454a-9017-fe752c630233n%40googlegroups.com.

[sage-devel] Discussion and poll: should Sage Integers have a backslash operator?

[John H Palmieri]

The github issue #36060 (https://github.com/sagemath/sage/issues/36060) 
proposes adding a backslash operator for Sage integers, so that "2 \ 3" 
will return the same as "3 / 2". Do you support this?

BackslashOperator is defined in "sage/misc/misc.py", and the preparser 
converts "A \ b" to the appropriate Python code. The docstring for 
BackslashOperator says "Implements Matlab-style backslash operator for 
solving systems A \ b". 

It seems pretty innocuous to me — in fact I don't care much either way — 
but since Sage integers are so ubiquitous, it seems like a good idea to ask 
before implementing it.

-- 
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/3f157aa4-74cd-4c5c-bc76-f198c6417432n%40googlegroups.com.

[sage-devel] What's the point of GF(2, impl='ntl')?

[John H Palmieri]

Setup:

sage: F = GF(2, impl='ntl')
sage: m_ntl = identity_matrix(1, F)
sage: v_ntl = vector(F, (1,))

Now consider

sage: m_ntl * v_ntl
sage: v_ntl * m_ntl

I'm trying to multiply a 1x1 matrix by a 1-dimensional vector, in one order 
or the other. Here's what happens: the first line fails with a SignalError, 
and the second actually crashes Sage. If we are defining a field that can't 
do linear algebra, shouldn't there be big warnings posted somewhere? If we 
are defining a field like this, are there any expectations that it should 
work broadly with Sage types and constructions? I just discovered that cup 
products in mod 2 cohomology don't work when "mod 2" means coefficients in 
GF(2, impl='ntl'), and I don't know if I should bother trying to fix this.

For what it's worth, I get the same with `GF(2, impl='givaro')`. Also for 
what it's worth, explicitly converting `v_ntl` to a matrix allows the 
matrix multiplication to work. 

I see this on two different OS X machines, one Intel and one Apple Silicon.

-- 
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/faeffb72-3b16-4f37-90c4-f969e4d5c017n%40googlegroups.com.

[sage-devel] Remove unnecessary docstring warnings?

[John H Palmieri]

When running Sage, if I look at some docststrings by doing foo.bar?, I see 
at the top

WARNING: the enclosing module is marked 'needs sage.graphs', so doctests 
may not pass.

Of course my copy of Sage has (as far as I know!) a working copy of 
sage.graphs. Should this warning only be printed conditionally when the 
module is missing? I took a quick look and didn't see a relevant ticket, 
but I might very well have missed it.

-- 
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/cbee800f-72ec-4ed7-bc12-e1562966cb3an%40googlegroups.com.

Re: [sage-devel] Python return types

[John H Palmieri]

I tried using mypy, and I also just ran "sage --tox -e pyright", and 
neither seems to flag the conflict between the signature "def 
signature(self) -> Integer:" and the output, which is some arithmetic with 
"len(...)" and hence a Python int. (And both mypy and pyright produce a ton 
of warnings, so if either is managing to flag anything worth fixing, it's 
likely to get drowned out. Or maybe I'm using them wrong...)

On Wednesday, September 6, 2023 at 1:45:10 PM UTC-7 Matthias Koeppe wrote:

> On Wednesday, September 6, 2023 at 11:02:15 AM UTC-7 Dima Pasechnik wrote:
>
> Should we run mypy on all the *.py files, at least, in our CI?
>
>
> We already have "sage --tox -e pyright", which is considered a better 
> choice than mypy.
>
> We are also running it in the GitHub CI as part of the Build & Test 
> workflow.
>
> See https://doc.sagemath.org/html/en/developer/tools.html#pyright
>

-- 
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/c99bdd6e-0fae-45e2-aafa-12525f6eea0bn%40googlegroups.com.

[sage-devel] Python return types

[John H Palmieri]

For a while now, Python has allowed return types to be specified in 
signatures:

def f() -> int:

It is my understanding that this doesn't actually do any error-checking or 
type-checking — see https://docs.python.org/3/library/typing.html. So this 
works without error:

def f() -> float:
return "hello"

This is cropping up in the Sage library. The file combinat/permutation.py 
has several methods that claim (according to their signature) to return an 
`Integer` but actually return an `int`, and this has led to at least one 
person being confused (a recent post on stackexchange cited in the github 
issue). Anyway, I've opened https://github.com/sagemath/sage/issues/36198 
for one of these instances, and we should be aware of this.

-- 
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/63bea4e5-ba57-4ddf-b59c-b46d59e3505bn%40googlegroups.com.

[sage-devel] Re: opinions requested on x + y behaviour for polynomials

[John H Palmieri]

In principle it seems okay, but to be honest, I don't think I understand 
Sage's polynomial rings. It seems like anything goes:

sage: R. = GF(2)[]
sage: S. = R[]
sage: S
sage: R.0 + S.0
x + x

Why am I allowed to construct S?

With your proposed changes, what happens in the following situation:

sage: T. = QQ[]
sage: U. = QQ[]
sage: t1, t2 = T.gens()
sage: u1, u2 = U.gens()

Can I now add t1, t2, u1, u2 by automatically creating QQ[x,y,z]?

Do we merge, and therefore identify, QQ[x,y] with QQ[y,x]?



On Saturday, August 26, 2023 at 12:22:39 AM UTC-7 Frédéric Chapoton wrote:

> Dear all,
>
> currently, if x and y are in two different polynomial rings, one cannot 
> add them.
>
> I propose in https://github.com/sagemath/sage/pull/36138 a sketch of 
> changes that would build a common polynomial ring by taking the union of 
> variables. This does not break too many things. Instead many doctests 
> checking for coercion failure now report coercion success. There are still 
> a few problematic things to solve, in particular about infinite polynomials 
> rings.
>
> Please express your opinion about that change of behaviour. 
>
> Frederic
>
> Question: what does magma do ?
>

-- 
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/30f627ea-06b7-4d08-81b6-a20bd14d952an%40googlegroups.com.

Re: [sage-devel] why sagemath creates so many file in TMPDIR and how to prevent this?

[John H Palmieri]

For what it's worth, the `alarm` function (provided by the cysignals 
package) allows for interrupting a command after a given amount of time.

sage: alarm?
Signature:  alarm(seconds)
Call signature: alarm(*args, **kwargs)
Type:   cython_function_or_method
String form:
File:   
Docstring: 
   Raise an "AlarmInterrupt" exception in a given number of seconds.
   This is useful for automatically interrupting long computations and
   can be trapped using exception handling.

   Use "cancel_alarm()" to cancel a previously scheduled alarm.

   INPUT:

   * "seconds" -- positive number, may be floating point

   OUTPUT: None

   EXAMPLES:

  >>> from cysignals.alarm import alarm, AlarmInterrupt
  >>> from time import sleep
  >>> try:
  ... alarm(0.5)
  ... sleep(2)
  ... except AlarmInterrupt:
  ... print("alarm!")
  alarm!
  >>> alarm(0)
  Traceback (most recent call last):
  ...
  ValueError: alarm() time must be positive



On Tuesday, August 15, 2023 at 8:09:49 AM UTC-7 Nasser M. Abbasi wrote:

>
> May be it is Python's multiprocessing then?.  The script does a LOOP 
> calling integrate command.
>
> But it does each call in separate process, using Python's MP. 
>
> Each command seems to create few folders. I just did one command
> and saw  these created:
>
> rwx--  2 me me4096 Aug 15 09:53 tmpmyvujuyg
> drwx--  2 me me4096 Aug 15 09:53 tmpd14tubax
> drwx--  2 me me4096 Aug 15 09:53 tmpmp7uvinu
> drwx--  2 me me4096 Aug 15 09:53 tmpe7tycr65
> drwx--  2 me me4096 Aug 15 09:53 tmpg0mt3zb4
>
> Since the script runs for 10's of thousands of integrals, and I have 3 
> running at same time, my TMP
> fills up and Linux runs short of file nodes and get warning that desk 
> space is short (even though
> the folder are empty, it is the file nodes causing this).  See
>
>
> this-computer-has-only-0-bytes-disk-remaining-message-from-linux-running-on-vi
>  
> 
>
> I use multiprocessing, since that is only way I know to  set a timeout on 
> the
> integrate command, since sagemath has no build in support for timeout on
> function call.
>
> Here is the basic flow of the script: (this is not the real script but
> a stripped down version)
> 
> #!/usr/bin/env sage
>
> import os, sys, time, datetime, ntpath
> import multiprocessing as mp
> from sage.all import *
>
> def doTheIntegration(q1,q2):
> problem = q1.get()
> integrand = SR(problem[0])
> theVar = SR(problem[1])
>anti = integrate(integrand,theVar)  
> q2.put(anti)
>
> if __name__ == "__main__":
>
> integrandAsString = "cos(x)"
> mp.set_start_method('spawn')
> q1= mp.Queue()
> q2= mp.Queue()
>
> q1.put([integrandAsString,"x"]) #integrand, variable
> process = mp.Process(target=doTheIntegration, args=(q1,q2,))  
> process.start()
> print("after process start()..waiting to finish") 
>   
>
> try:
> anti = q2.get(True,4*60) #4 minutes timeout
> 
> except Exception as ee:
> print("Exception in call to queue.get ",ee)
> print("type(exception).__name__=",type(ee).__name__)
> 
> del(q1)
> del(q2)
> process.terminate() 
> 
>
> I run this using  
>
> sage ./script.sage
>
> And see these tmp folders created. Since real script runs in a loop, the 
> tmp folders
> remain there until the script is done, which takes days.
>
> Is there a way not to create these tmp folders?
>
> Thanks
> --Nasser
>
> On Tuesday, August 15, 2023 at 8:28:39 AM UTC-5 Michael Orlitzky wrote:
>
>> On Tue, 2023-08-15 at 03:33 -0700, 'Nasser M. Abbasi' via sage-devel 
>> wrote: 
>> > Each time I run a sagemath script, I see 10's of thousands of files 
>> created 
>> > in my TMPDIR which I have to keep manually deleting. 
>>
>> There aren't too many parts of sage that use temporary files. What's 
>> the script doing? 
>>
>>

-- 
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/bcb3c7c7-22eb-4fbc-a7dc-9cb2ba0e7179n%40googlegroups.com.

[sage-devel] Re: Can we get rid of the "Consider using a block-scoped tag" warning?

[John H Palmieri]

Great!

I like Kwankyu's suggestion that once #36024 is merged (and #36026 and 
#35095), just run "sage --fixdoctests" on the whole Sage library.

On Friday, August 4, 2023 at 2:51:06 PM UTC-7 Matthias Koeppe wrote:

> Yes, the release tour contains a link to the new section in the 
> developer's guide - 
> https://sagemath-tobias.netlify.app/developer/doctesting.html#the-doctest-fixer
>
> On Friday, August 4, 2023 at 2:45:21 PM UTC-7 John H Palmieri wrote:
>
>> I appreciate the description of the changes in `sage --fixdoctests` in 
>> the release tour, but are these features described anywhere in Sage's 
>> documentation? I didn't see anything at #35749 or #36024.
>>
>> On Thursday, August 3, 2023 at 11:31:25 AM UTC-7 Matthias Koeppe wrote:
>>
>>> On Thursday, August 3, 2023 at 9:54:53 AM UTC-7 Volker Braun wrote:
>>>
>>> The test output is full of "Warning: Consider using a block-scoped tag 
>>> by inserting the line...", making it hard to see where the actual error is. 
>>>
>>> Whats the purpose of this? Is somebody working on converting the magic 
>>> comments?
>>>
>>>
>>> Yes, for example in https://github.com/sagemath/sage/pull/36026
>>>
>>> Help with this is welcome, in particular for files that are not already 
>>> fixed in https://github.com/sagemath/sage/pull/35095
>>>
>>> The improved "sage -fixdoctests" tool assists with it: 
>>> https://github.com/sagemath/sage/wiki/Sage-10.1-Release-Tour#sage--fixdoctests
>>>
>>>

-- 
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/245b657f-b4dc-4b7c-ba58-8e4e78557b97n%40googlegroups.com.

[sage-devel] Re: Can we get rid of the "Consider using a block-scoped tag" warning?

[John H Palmieri]

I appreciate the description of the changes in `sage --fixdoctests` in the 
release tour, but are these features described anywhere in Sage's 
documentation? I didn't see anything at #35749 or #36024.

On Thursday, August 3, 2023 at 11:31:25 AM UTC-7 Matthias Koeppe wrote:

> On Thursday, August 3, 2023 at 9:54:53 AM UTC-7 Volker Braun wrote:
>
> The test output is full of "Warning: Consider using a block-scoped tag by 
> inserting the line...", making it hard to see where the actual error is. 
>
> Whats the purpose of this? Is somebody working on converting the magic 
> comments?
>
>
> Yes, for example in https://github.com/sagemath/sage/pull/36026
>
> Help with this is welcome, in particular for files that are not already 
> fixed in https://github.com/sagemath/sage/pull/35095
>
> The improved "sage -fixdoctests" tool assists with it: 
> https://github.com/sagemath/sage/wiki/Sage-10.1-Release-Tour#sage--fixdoctests
>
>

-- 
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/3f2ed9e7-12fe-48e4-a32e-9a28a8b82f4en%40googlegroups.com.

[sage-devel] Re: strange error from integrate command with maxima 5.47 and sagemath 10.1 beta 6

[John H Palmieri]

I get the same error when evaluating this integral in Sage with its own 
Maxima. (version 5.46.0).


On Sunday, July 16, 2023 at 10:30:53 AM UTC-7 Matthias Koeppe wrote:

> On Sunday, July 16, 2023 at 5:48:00 AM UTC-7 Nasser M. Abbasi wrote:
>
> After some struggle,  build sagemath with maxima 5.47 upstream.
>
>
> Open a PR with the upgrade please
>
>

-- 
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/ae0f8999-20a3-4e37-9ca1-822f948fd85en%40googlegroups.com.

[sage-devel] IPython magic commands, automagic, and conflicts

[John H Palmieri]

IPython comes with various "magic" commands, for example "%ls" which runs 
the shell command "ls". The default mode in Sage is "Automagic is ON, % 
prefix IS NOT needed for line magics." This means that running "ls" within 
Sage does the same thing as running "%ls". So far so good. There are, 
though, some magic commands that don't work like this, because we have 
defined other functions that shadow them. These include:

- All interfaces, as far as I can tell. Something like "%Lisp" invokes an 
IPython magic command, and it behaves differently than just "Lisp". I 
personally don't use these interfaces, so I have no opinion about what to 
do here.

- %attach vs. attach. Similar but perhaps not identical? The help strings 
are certainly different.
- %colors vs. colors. Very different: the former lets you switch color 
schemes in the command-line interface. The latter is a "dict-like 
collection of colors"
- %display vs. display. Very different: the former lets you "switch between 
simple display and ASCII art". The latter displays "a Python object in all 
frontends."
- %edit vs. edit. Similar but not identical. The former opens "an editor 
and execute[s] the resulting code." The latter opens "source code of 
``obj`` in editor of your choice." Note that "%ed" and "ed" are both 
aliases for "%edit".
- %reset vs. reset. Similar but perhaps not identical? The help strings are 
certainly different. %reset takes some arguments, reset does not. Compare 
to "%reset_selective", which is the same as "reset_selective".
- %timeit vs. timeit. Similar but not identical.
- Also %load, %read_data, %save, maybe some others.

There is potential for confusion if users switch back and forth between 
IPython and Sage. There is also potential for confusion when two commands 
are similar but not identical. Is it worth addressing any of these? We 
could, for example, rename the Sage versions.

(See also https://github.com/sagemath/sage/issues/30661 for a somewhat 
related issue.)

-- 
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/733f3058-f2c3-40d7-9f7a-6b9cf2b294afn%40googlegroups.com.

Re: [sage-devel] Graphics files in Sage documentation

[John H Palmieri]

I confirm that I do not see any image files in 
local/share/doc/sage/html/en/reference/manifolds/sage/manifolds. All of the 
images (and all are in svg format) are in 
local/share/doc/sage/html/en/reference/manifolds/_images/. These are copies 
of files in 
local/share/doc/sage/inventory/en/reference/manifolds/sage/manifolds/ and 
its subdirectories. If your system can handle symlinks, and if the 
inventory directory is intact, you could create some symlinks to save more 
space. (The inventory build is where in the default build I see png, svg, 
and pdf files, but only svg files seem to be copied to the html directory.)

-- 
John


On Wednesday, June 28, 2023 at 2:20:16 PM UTC-7 Marc Culler wrote:

> Thank you!  Probably it is my bug, or it is somehow triggered by my wierd 
> setup.  That would probably mean some environment difference in the sage or 
> sage-env scripts, since those are basically the only things I have tinkered 
> with.
>
> Can you verify that you do not see any image files in the top level of, 
> say:
> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds ?
>
> - Marc
>
> On Wed, Jun 28, 2023 at 3:23 PM John H Palmieri  
> wrote:
>
>> By the way, on my machine, local/share/doc/sage are almost identical 
>> sizes in 10.1.beta3 and 10.1.beta4. I don't know what explains the 
>> difference you're seeing.
>>
>> On Wednesday, June 28, 2023 at 12:51:38 PM UTC-7 John H Palmieri wrote:
>>
>>> This change should produce only the .svg files:
>>>
>>> diff --git a/src/sage_docbuild/conf.py b/src/sage_docbuild/conf.py
>>> index 9b6b37480b..b5d6815c76 100644
>>> --- a/src/sage_docbuild/conf.py
>>> +++ b/src/sage_docbuild/conf.py
>>> @@ -128,7 +128,7 @@ from sage.all_cmdline import *
>>>  """
>>>  
>>>  plot_html_show_formats = False
>>> -plot_formats = ['svg', 'pdf', 'png']
>>> +plot_formats = ['svg']
>>>  
>>>  # We do *not* fully initialize intersphinx since we call it by hand
>>>  # in find_sage_dangling_links.
>>>
>>>
>>> (I'm not suggesting this as a general change, just for your particular 
>>> situation.)
>>>
>>>
>>> On Wednesday, June 28, 2023 at 12:07:46 PM UTC-7 Marc Culler wrote:
>>>
>>>> Note: I had already compressed the .svg files, hence the .gz extension.
>>>>
>>>> Before compression I get:
>>>>
>>>> % find local/share/doc/sage/html/en -name 'chart-12*'
>>>> local/share/doc/sage/html/en/reference/manifolds/_images/chart-12.svg
>>>>
>>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.svg
>>>>
>>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.png
>>>>
>>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.pdf
>>>>
>>>> - Marc
>>>>
>>>> On Wednesday, June 28, 2023 at 2:02:47 PM UTC-5 Marc Culler wrote:
>>>>
>>>>> I think I may have found a resolution of this problem, that involves 
>>>>> doing almost nothing.  It appears that sage_docbuild oftern builds image 
>>>>> in 
>>>>> all three formats - svg, png and pdf.  All three types get stored in the 
>>>>> html directory and the svg is duplicated:
>>>>>
>>>>> find local/share/doc/sage/html/en -name 'chart-12*'
>>>>>
>>>>> local/share/doc/sage/html/en/reference/manifolds/_images/chart-12.svg.gz
>>>>>
>>>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.svg.gz
>>>>>
>>>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.png
>>>>>
>>>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.pdf
>>>>>
>>>>> The actual html code seems to only uses the svg files stored in 
>>>>> _images.  Hopefully I can just remove the others without affecting the 
>>>>> html 
>>>>> documentation.
>>>>>
>>>>> grep -r chart-12 local/share/doc/sage/html/en/reference/manifolds
>>>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart.html:>>>>  
>>>>> alt="../../_images/chart-12.svg" class="plot-directive" 
>>>>> src="../../_images/chart-12.svg" />
>>>>>
>>>>> Since this seems to be a change between 10.1beta3 and 10.1beta4, I 
>>>>> 

Re: [sage-devel] Graphics files in Sage documentation

[John H Palmieri]

By the way, on my machine, local/share/doc/sage are almost identical sizes 
in 10.1.beta3 and 10.1.beta4. I don't know what explains the difference 
you're seeing.

On Wednesday, June 28, 2023 at 12:51:38 PM UTC-7 John H Palmieri wrote:

> This change should produce only the .svg files:
>
> diff --git a/src/sage_docbuild/conf.py b/src/sage_docbuild/conf.py
> index 9b6b37480b..b5d6815c76 100644
> --- a/src/sage_docbuild/conf.py
> +++ b/src/sage_docbuild/conf.py
> @@ -128,7 +128,7 @@ from sage.all_cmdline import *
>  """
>  
>  plot_html_show_formats = False
> -plot_formats = ['svg', 'pdf', 'png']
> +plot_formats = ['svg']
>  
>  # We do *not* fully initialize intersphinx since we call it by hand
>  # in find_sage_dangling_links.
>
>
> (I'm not suggesting this as a general change, just for your particular 
> situation.)
>
>
> On Wednesday, June 28, 2023 at 12:07:46 PM UTC-7 Marc Culler wrote:
>
>> Note: I had already compressed the .svg files, hence the .gz extension.
>>
>> Before compression I get:
>>
>> % find local/share/doc/sage/html/en -name 'chart-12*'
>> local/share/doc/sage/html/en/reference/manifolds/_images/chart-12.svg
>>
>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.svg
>>
>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.png
>>
>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.pdf
>>
>> - Marc
>>
>> On Wednesday, June 28, 2023 at 2:02:47 PM UTC-5 Marc Culler wrote:
>>
>>> I think I may have found a resolution of this problem, that involves 
>>> doing almost nothing.  It appears that sage_docbuild oftern builds image in 
>>> all three formats - svg, png and pdf.  All three types get stored in the 
>>> html directory and the svg is duplicated:
>>>
>>> find local/share/doc/sage/html/en -name 'chart-12*'
>>> local/share/doc/sage/html/en/reference/manifolds/_images/chart-12.svg.gz
>>>
>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.svg.gz
>>>
>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.png
>>>
>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.pdf
>>>
>>> The actual html code seems to only uses the svg files stored in 
>>> _images.  Hopefully I can just remove the others without affecting the html 
>>> documentation.
>>>
>>> grep -r chart-12 local/share/doc/sage/html/en/reference/manifolds
>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart.html:>>  
>>> alt="../../_images/chart-12.svg" class="plot-directive" 
>>> src="../../_images/chart-12.svg" />
>>>
>>> Since this seems to be a change between 10.1beta3 and 10.1beta4, I would 
>>> have to guess that it might be considered a bug.  So maybe I should move 
>>> this back to sage-release?
>>>
>>> - Marc
>>>
>>>
>>>
>>> On Wednesday, June 28, 2023 at 1:13:20 PM UTC-5 Marc Culler wrote:
>>>
>>>> I am not proposing using gzipped svg for a normal sage build.  I only 
>>>> want to do it for the Sage_macOS app, which will have a simple 
>>>> self-contained server running on the loopback interface that provides 
>>>> gzipped content (with the Content-Encoding header set to "gzip").  Of 
>>>> course I would be happy to work on incorporating the same mechanism in a 
>>>> standard build of Sage, and that would reduce the footprint of the 
>>>> documentation considerably.  But in the short term, for the macOS binary, 
>>>> I 
>>>> need to be able to find the magic switch which makes sage_docbuild use svg 
>>>> instead of png.
>>>>
>>>> I don't know how much of a problem the image size will pose.  There are 
>>>> some svg images already in the documentation, which seem to work, but I 
>>>> hadn't gotten to the stage of worrying about that yet.
>>>>
>>>> - Marc
>>>> On Wednesday, June 28, 2023 at 12:50:31 PM UTC-5 Michael Orlitzky wrote:
>>>>
>>>>> On Wed, 2023-06-28 at 10:07 -0700, Marc Culler wrote: 
>>>>> > 
>>>>> > BOTTOM LINE: we get more than a 90% reduction in size simply by 
>>>>> choosing to 
>>>>> > use the .svg extension when saving the plot instead of the .png 
>>>>> extension. 
>>>>> > 
>>>>&

Re: [sage-devel] Graphics files in Sage documentation

[John H Palmieri]

This change should produce only the .svg files:

diff --git a/src/sage_docbuild/conf.py b/src/sage_docbuild/conf.py
index 9b6b37480b..b5d6815c76 100644
--- a/src/sage_docbuild/conf.py
+++ b/src/sage_docbuild/conf.py
@@ -128,7 +128,7 @@ from sage.all_cmdline import *
 """
 
 plot_html_show_formats = False
-plot_formats = ['svg', 'pdf', 'png']
+plot_formats = ['svg']
 
 # We do *not* fully initialize intersphinx since we call it by hand
 # in find_sage_dangling_links.


(I'm not suggesting this as a general change, just for your particular 
situation.)


On Wednesday, June 28, 2023 at 12:07:46 PM UTC-7 Marc Culler wrote:

> Note: I had already compressed the .svg files, hence the .gz extension.
>
> Before compression I get:
>
> % find local/share/doc/sage/html/en -name 'chart-12*'
> local/share/doc/sage/html/en/reference/manifolds/_images/chart-12.svg
>
> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.svg
>
> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.png
>
> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.pdf
>
> - Marc
>
> On Wednesday, June 28, 2023 at 2:02:47 PM UTC-5 Marc Culler wrote:
>
>> I think I may have found a resolution of this problem, that involves 
>> doing almost nothing.  It appears that sage_docbuild oftern builds image in 
>> all three formats - svg, png and pdf.  All three types get stored in the 
>> html directory and the svg is duplicated:
>>
>> find local/share/doc/sage/html/en -name 'chart-12*'
>> local/share/doc/sage/html/en/reference/manifolds/_images/chart-12.svg.gz
>>
>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.svg.gz
>>
>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.png
>>
>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.pdf
>>
>> The actual html code seems to only uses the svg files stored in _images.  
>> Hopefully I can just remove the others without affecting the html 
>> documentation.
>>
>> grep -r chart-12 local/share/doc/sage/html/en/reference/manifolds
>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart.html:>  
>> alt="../../_images/chart-12.svg" class="plot-directive" 
>> src="../../_images/chart-12.svg" />
>>
>> Since this seems to be a change between 10.1beta3 and 10.1beta4, I would 
>> have to guess that it might be considered a bug.  So maybe I should move 
>> this back to sage-release?
>>
>> - Marc
>>
>>
>>
>> On Wednesday, June 28, 2023 at 1:13:20 PM UTC-5 Marc Culler wrote:
>>
>>> I am not proposing using gzipped svg for a normal sage build.  I only 
>>> want to do it for the Sage_macOS app, which will have a simple 
>>> self-contained server running on the loopback interface that provides 
>>> gzipped content (with the Content-Encoding header set to "gzip").  Of 
>>> course I would be happy to work on incorporating the same mechanism in a 
>>> standard build of Sage, and that would reduce the footprint of the 
>>> documentation considerably.  But in the short term, for the macOS binary, I 
>>> need to be able to find the magic switch which makes sage_docbuild use svg 
>>> instead of png.
>>>
>>> I don't know how much of a problem the image size will pose.  There are 
>>> some svg images already in the documentation, which seem to work, but I 
>>> hadn't gotten to the stage of worrying about that yet.
>>>
>>> - Marc
>>> On Wednesday, June 28, 2023 at 12:50:31 PM UTC-5 Michael Orlitzky wrote:
>>>
 On Wed, 2023-06-28 at 10:07 -0700, Marc Culler wrote: 
 > 
 > BOTTOM LINE: we get more than a 90% reduction in size simply by 
 choosing to 
 > use the .svg extension when saving the plot instead of the .png 
 extension. 
 > 

 SVG is the right choice for most graphics, but there are some practical 
 problems: 

 * The documentation needs to know how big to display an SVG graphic. 
 With a PNG, the default is to use the image's height/width in  
 pixels, but with SVG, there's no such obvious default. 

 * gzipped SVG doesn't work over the file:/// protocol in my firefox. 
 This hasn't been a big enough problem for me yet to diagnose it, 
 so I can't say how serious a problem it is. (I'll play around later 
 today.) 

 * Browser support in firefox/chrome alternatives still isn't great, 
 although I think webkit is getting a new SVG renderer "soon." This 
 is actually relevant more today than it was ten years ago, because  
 adding rust to firefox made it less portable, meaning you're 
 more likely to be stuck with one of those alternatives. 

 * Somebody's got to go through and look at 100MB of images to make  
 sure they still look right if we change 'em. 



-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: [sage-devel] Graphics files in Sage documentation

[John H Palmieri]

I tried making this change (which would affect each ".. PLOT:" directive) 
but the documentation failed to build:

diff --git a/src/sage_docbuild/conf.py b/src/sage_docbuild/conf.py
index 9b6b37480b..db33c4b1d6 100644
--- a/src/sage_docbuild/conf.py
+++ b/src/sage_docbuild/conf.py
@@ -115,7 +115,7 @@ def sphinx_plot(graphics, **kwds):
 mpl.rcParams['figure.figsize'] = [8.0, 6.0]
 mpl.rcParams['figure.dpi'] = 80
 mpl.rcParams['savefig.dpi'] = 100
-fn = tmp_filename(ext=".png")
+fn = tmp_filename(ext=".svg")
 graphics.save(fn)
 img = mpimg.imread(fn)
 plt.imshow(img)

The error: ValueError: filetype .svg not supported by save()



On Wednesday, June 28, 2023 at 11:13:20 AM UTC-7 Marc Culler wrote:

> I am not proposing using gzipped svg for a normal sage build.  I only want 
> to do it for the Sage_macOS app, which will have a simple self-contained 
> server running on the loopback interface that provides gzipped content 
> (with the Content-Encoding header set to "gzip").  Of course I would be 
> happy to work on incorporating the same mechanism in a standard build of 
> Sage, and that would reduce the footprint of the documentation 
> considerably.  But in the short term, for the macOS binary, I need to be 
> able to find the magic switch which makes sage_docbuild use svg instead of 
> png.
>
> I don't know how much of a problem the image size will pose.  There are 
> some svg images already in the documentation, which seem to work, but I 
> hadn't gotten to the stage of worrying about that yet.
>
> - Marc
> On Wednesday, June 28, 2023 at 12:50:31 PM UTC-5 Michael Orlitzky wrote:
>
>> On Wed, 2023-06-28 at 10:07 -0700, Marc Culler wrote: 
>> > 
>> > BOTTOM LINE: we get more than a 90% reduction in size simply by 
>> choosing to 
>> > use the .svg extension when saving the plot instead of the .png 
>> extension. 
>> > 
>>
>> SVG is the right choice for most graphics, but there are some practical 
>> problems: 
>>
>> * The documentation needs to know how big to display an SVG graphic. 
>> With a PNG, the default is to use the image's height/width in  
>> pixels, but with SVG, there's no such obvious default. 
>>
>> * gzipped SVG doesn't work over the file:/// protocol in my firefox. 
>> This hasn't been a big enough problem for me yet to diagnose it, 
>> so I can't say how serious a problem it is. (I'll play around later 
>> today.) 
>>
>> * Browser support in firefox/chrome alternatives still isn't great, 
>> although I think webkit is getting a new SVG renderer "soon." This 
>> is actually relevant more today than it was ten years ago, because  
>> adding rust to firefox made it less portable, meaning you're 
>> more likely to be stuck with one of those alternatives. 
>>
>> * Somebody's got to go through and look at 100MB of images to make  
>> sure they still look right if we change 'em. 
>>
>>

-- 
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/52dbf676-29ca-4e78-b453-a6cdfabc83dfn%40googlegroups.com.

Re: [sage-devel] Re: DeprecationWarning on sagecell in Graph([(0,1)]).vertices()

[John H Palmieri]

Just do a global search-and-replace: change ".vertices()" to 
".vertices(sort=True, key=id)" or ".vertices(sort=True, key=str)".

This is not a new change; the deprecation warning has been in place almost 
a year, and there was discussion leading up to it. See 
https://github.com/sagemath/sage/issues/22349, in particular. I don't think 
that Sage developers are going to revert back to sorting by default, 
especially since sorting arbitrary objects can be problematic. 

(Actually, looking back on old sage-devel posts, you asked about 
essentially this issue (incomparable objects in Python 3 and using them to 
label vertices in graphs) back in July '22: 
https://groups.google.com/g/sage-devel/c/zc1UlSJse34/m/aHsfFnCKAAAJ. So not 
only is it not new in general, it's not new to you, either.)

On Monday, June 26, 2023 at 10:00:25 PM UTC-7 Georgi Guninski wrote:

> Thanks.
>
> In my code, this backwards incompatibility breaks over
> 150 calls to Graph.vertices() and I suspect
> I am not the only one.
>
> I think the root of the problem is the change from python2
> to python3. In python2 |["A",1].sort()| works fine, while
> it doesn't work in python3.
>
> My recommendation is to reverse engineer python2.sort() and
> use it as a custom function for sorting heterogeneous vertices.
> In this scenario, the code won't be more broken than it was
> in python2.
>

-- 
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/90a764a4-1002-4128-b79a-4cf960d3d0cen%40googlegroups.com.

[sage-devel] Re: Graph([('A',1)]).adjacency_matrix() raises exception

[John H Palmieri]

By the way, I see this error message:

TypeError: Vertex labels are not comparable. You must specify an 
ordering using parameter ``vertices``

Indeed, this works:

g.adjacency_matrix(vertices=['A', 1])


On Monday, June 26, 2023 at 11:32:56 AM UTC-7 John H Palmieri wrote:

> Please read the help message for adjaceny_matrix.
>
> g = Graph([('A',1)])
> g.adjacency_matrix?
>
> prints, among other things:
>
>* "vertices" -- list (default: "None"); the ordering of the
>  vertices defining how they should appear in the matrix. By
>  default, the ordering given by "GenericGraph.vertices()" with
>  "sort=True" is used. If the vertices are not comparable, the
>  keyword "vertices" must be used to specify an ordering, or a
>  TypeError exception will be raised.
>
> Your vertices are not comparable.
>
>
> On Monday, June 26, 2023 at 8:20:50 AM UTC-7 Georgi Guninski wrote:
>
>> In both 9.6 and https://sagecell.sagemath.org/ 
>>
>> Graph([('A',1)]).adjacency_matrix() 
>>
>> raises exception 
>>
>> TypeError: '<' not supported between instances of 'int' and 'str' 
>>
>

-- 
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/0dda7971-e233-465d-9629-5dd4d2e7d65fn%40googlegroups.com.

[sage-devel] Re: Graph([('A',1)]).adjacency_matrix() raises exception

[John H Palmieri]

Please read the help message for adjaceny_matrix.

g = Graph([('A',1)])
g.adjacency_matrix?

prints, among other things:

   * "vertices" -- list (default: "None"); the ordering of the
 vertices defining how they should appear in the matrix. By
 default, the ordering given by "GenericGraph.vertices()" with
 "sort=True" is used. If the vertices are not comparable, the
 keyword "vertices" must be used to specify an ordering, or a
 TypeError exception will be raised.

Your vertices are not comparable.


On Monday, June 26, 2023 at 8:20:50 AM UTC-7 Georgi Guninski wrote:

> In both 9.6 and https://sagecell.sagemath.org/
>
> Graph([('A',1)]).adjacency_matrix()
>
> raises exception
>
> TypeError: '<' not supported between instances of 'int' and 'str'
>

-- 
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/b35e2927-c2ff-4541-9167-2e0d54a32a5an%40googlegroups.com.

Re: [sage-devel] Re: Cup Product and Wedge Product of Cochains

[John H Palmieri]

 These things need to happen, and they can happen independently at the 
start:

 - create a Github issue describing the problem and proposed solution
 - create a new version of chains.py including your fixes

Once these are both in place (and we can help with the first if necessary), 
then the review process can begin. To make the review process go more 
smoothly, please look at the Sage source code and the Developer's Guide and 
make your changes so that they fit with the established style in terms of 
coding, documentation, etc.


On Wednesday, June 21, 2023 at 2:27:36 PM UTC-7 Dima Pasechnik wrote:

> On Wed, Jun 21, 2023 at 9:51 PM Ezra Akresh  wrote:
> >
> > My team and I are quite unfamiliar with GitHub and don't know how and 
> where to put our code. Do you think that you could help us to add our code 
> into the library?
>
> We can certainly explain to you whatever is unclear in
> https://doc.sagemath.org/html/en/developer/index.html in this regard.
> It's also not hard to set up the corresponding tools on cocalc, if for
> one or another reason you can't do the necessary steps on your "real"
> computers.
>
>
> >
> > On Monday, June 19, 2023 at 1:51:41 PM UTC-5 John H Palmieri wrote:
> >>
> >> It looks like your problem is with the cup_product method for cochains 
> in sage/homology/chains.py. Is that right? As far as I can tell, that 
> method is not used anywhere else in the Sage library. In any case, feel 
> free to create a pull request to fix and improve it.
> >>
> >> On Saturday, June 17, 2023 at 9:28:05 PM UTC-7 Ezra Akresh wrote:
> >>>
> >>> We have provided an example inside this Cocalc notebook: 
> https://cocalc.com/share/public_paths/9a10e579b445d6b489fe88dd6ad4e4375d4f5fba
> >>>
> >>> On Friday, June 16, 2023 at 5:50:24 PM UTC-5 John H Palmieri wrote:
> >>>>
> >>>> Can you please provide an example where things do not work? Are you 
> talking about manifolds or cell complexes or some other classes?
> >>>>
> >>>> On Friday, June 16, 2023 at 1:14:32 PM UTC-7 Ezra Akresh wrote:
> >>>>>
> >>>>> In a recent project, my team and I developed functions for the cup 
> product and wedge product of cochains utilizing the functionality of 
> various Sage classes. We noticed that the current cup product function only 
> works for 0-simplices because the orientations do not match. We were 
> wondering if it would be helpful if we submitted our code to be added to 
> the library.
> >
> > --
> > 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/689efedf-2004-4c7a-83f1-1d384989939bn%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/4644add6-61be-4d6f-b174-8011127d9925n%40googlegroups.com.

[sage-devel] Re: Cup Product and Wedge Product of Cochains

[John H Palmieri]

It looks like your problem is with the cup_product method for cochains in 
sage/homology/chains.py. Is that right? As far as I can tell, that method 
is not used anywhere else in the Sage library. In any case, feel free to 
create a pull request to fix and improve it.

On Saturday, June 17, 2023 at 9:28:05 PM UTC-7 Ezra Akresh wrote:

> We have provided an example inside this Cocalc notebook: 
> https://cocalc.com/share/public_paths/9a10e579b445d6b489fe88dd6ad4e4375d4f5fba
>
> On Friday, June 16, 2023 at 5:50:24 PM UTC-5 John H Palmieri wrote:
>
>> Can you please provide an example where things do not work? Are you 
>> talking about manifolds or cell complexes or some other classes?
>>
>> On Friday, June 16, 2023 at 1:14:32 PM UTC-7 Ezra Akresh wrote:
>>
>>> In a recent project, my team and I developed functions for the cup 
>>> product and wedge product of cochains utilizing the functionality of 
>>> various Sage classes. We noticed that the current cup product function only 
>>> works for 0-simplices because the orientations do not match. We were 
>>> wondering if it would be helpful if we submitted our code to be added to 
>>> the library.
>>>
>>

-- 
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/55ed29cc-79fc-4274-b4b6-ac5b4c802d9dn%40googlegroups.com.

[sage-devel] Re: Cup Product and Wedge Product of Cochains

[John H Palmieri]

Can you please provide an example where things do not work? Are you talking 
about manifolds or cell complexes or some other classes?

On Friday, June 16, 2023 at 1:14:32 PM UTC-7 Ezra Akresh wrote:

> In a recent project, my team and I developed functions for the cup product 
> and wedge product of cochains utilizing the functionality of various Sage 
> classes. We noticed that the current cup product function only works for 
> 0-simplices because the orientations do not match. We were wondering if it 
> would be helpful if we submitted our code to be added to the library.
>

-- 
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/e0a03287-15ee-430e-83df-471523635c32n%40googlegroups.com.

Re: [sage-devel] Re: ping - please cast you vote: VOTE: Follow NEP 29: Recommended Python version

[John H Palmieri]

On Tuesday, May 30, 2023 at 12:59:54 PM UTC-7 G. M.-S. wrote:


Dima and Matthias,

I completely agree with Nils.

Could you (both of you) take a short vacation from SageMath, please?

More globally, I propose to stop this discussion completely for a few days.


+100

It's time for this discussion to stop.

 

Thanks in advance.

Guillermo

On Tue, 30 May 2023 at 21:14, Nils Bruin  wrote:

@dima, @matthias : this public forum is not an appropriate venue to discuss 
personal disagreements. From what you both write I get the impression you 
actually have a lot of common ground and only a few differences in opinion, 
but that personalities and discussion styles exaggerate the disagreements. 
I hope a moderator steps in to warn you about code of conduct and making 
discussions personal. In the mean time, stepping back and let things cool 
down is probably the better thing to do, since I don't see a positive 
outcome from continuing your current back-and-forth, and it's toxic for 
other people following the thread to be confronted by such discord between 
respected members of the community.

-- 

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/42fb0b3a-3f1c-48de-9a30-377e9dcd41cfn%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/2f3ed122-3fb7-4d7c-be65-b9cd21b07ae6n%40googlegroups.com.

[sage-devel] Re: Can I build Sage via MacPorts under MacOS 10.9?

[John H Palmieri]

In principle this should work. See 
https://github.com/sagemath/sage/issues/31505 for some relevant 
information. Others might have direct experience with it.

On Friday, May 5, 2023 at 11:24:07 AM UTC-7 Louis Deaett wrote:

> I'm interested in Sage development (and contributing some enhancements) 
> and so I'd like to be able to build the current release (and ultimately the 
> development branch) from source.
>
> I am running macOS 10.9 (Mavericks) because that is what I prefer, and 
> because some of my hardware tops out at that version.  Anyway, I've had 
> decent success getting open-source software up and running under MacPorts, 
> which has good support for 10.9 (and even earlier).
>
> So I've been working on building Sage from source using MacPorts. 
>  Compilation seems to go smoothly with MacPorts LLVM tools, but I've run 
> into some snags whereby the build for some SPKGs seems to get gummed up 
> when it can't locate some of the libraries or headers provided by 
> MacPorts.  By its nature, this hasn't felt like an insurmountable problem.
>
> Still, while I can keep hacking away at this, I figured I should ask:  Is 
> there any fundamental reason why what I'm trying to do should be impossible?
>
> If there are major barriers in my path with this that I'm just not 
> encountering yet or just haven't realized, then it would (of course) help 
> me out to know.
>
> For what it's worth, if building under MacPorts is theoretically possible 
> but would require some additional effort on the Sage side, then that's 
> something I'd be willing to contribute to, if anything comes out of my own 
> efforts.
>
> Thanks in advance for any advice!
>
> -- Louis

-- 
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/80e85248-fefa-4b47-a35c-c3f526677b8en%40googlegroups.com.

[sage-devel] Simons Software Research Faculty award

[John H Palmieri]

Dear US-based Sage developers,

The Simons Foundation has announced a Scientific Software Research Faculty 
Award — 
https://www.simonsfoundation.org/grant/scientific-software-research-faculty-award/
 
— and it might be appropriate for Sage development.

-- 
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/da2e6862-0b42-4da8-b8bf-aac2b0933dd4n%40googlegroups.com.

Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?

[John H Palmieri]

On Thursday, April 27, 2023 at 2:54:47 PM UTC-7 Isuru Fernando wrote:


I guess there are several requirements we need

1. Support for all major OS/architecture combinations
2. Easy to build for rare OS/architecture combinations
3. Possible to install as a non-root user
4. Binaries are available for non-root


This is a good list. We also need to agree about what fits into category 1. 
As far as platforms for developers are concerned, does plain OS X count, or 
plain OS X + Xcode command-line tools, or OS X + homebrew, or OS X + conda, 
etc.? 

 


AFAIK, there's no package manager that has all 4 above and we will have to 
pick which
requirements are more important than others.

Isuru
 


-- 
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/0a85f27c909f8d8f185801af2228e6331bcad544.camel%40orlitzky.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/131f110d-5862-4149-b49e-c4500b86cb4en%40googlegroups.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

[John H Palmieri]

In an attempt to make this less of a religious war and more akin to 
something like a rational discussion:

- The status quo is that we include Python3 and gcc. If you want to argue 
for their removal, you need to provide evidence that this will not cause 
problems for people on supported platforms. What's the evidence? In 
addition, what sort of evidence would convince you to change your mind and 
admit that these packages need to be kept for a while longer?

- On the other side of the coin, if you have opposed removing these 
packages, what sort of evidence would convince you to change your mind and 
admit that these packages can be removed from the Sage distribution?


On Wednesday, April 26, 2023 at 3:27:36 PM UTC-7 Matthias Koeppe wrote:

> On Wednesday, April 26, 2023 at 1:46:41 PM UTC-7 Dima Pasechnik wrote:
>
> On Wed, Apr 26, 2023 at 9:06 PM Matthias Koeppe 
>  wrote: 
> > 2. I'm not in favor of chipping away 1 package at a time in the name of 
> unsubstantiated, vague notions that a package is "ballast slowing down 
> Sage's progress". 
>
> It's not vague, it's very concrete. It has been done in the past, cf 
> e.g. R/rpy2, tar, etc., it can be continued just fine.
>
>
> Right, each of these was separately and concretely substantiated with 
> facts.
> - tar was dropped after it was found that on all supported platforms, the 
> standard system tar did the job.
> - R/rpy2, as I just explained in a message above.
>
> For context for the general readership of this list: 
> gcc/gfortran/python3 are directly tied to what platform support we can 
> claim (note that gcc/gfortran are the same package except for how the 
> scripts are called).
> I document this platform support in the release tours (see 
> https://github.com/sagemath/sage/wiki/Sage-9.8-Release-Tour#sources) 
> based on the tests that run on GH Actions. Changes to platform support of 
> the Sage distribution are tracked in 
> https://github.com/sagemath/sage/issues/32074
>
>

-- 
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/d62754bc-5dd4-4615-9bb5-ac9a6a3ce8f2n%40googlegroups.com.

[sage-devel] Re: Why SR('expression') fail on some but not others?

[John H Palmieri]

While

sage_eval('sin(x)')

does not work,

sage_eval('sin(x)', {'x': x})

does work. sage_eval needs to know the context (which variables have been 
defined, etc.) in which to evaluate. I am not an expert, but

sage_eval('sin(x)', locals=locals())

might work pretty reliably, without having to specify each previously 
defined variable by hand.


-- John


On Wednesday, April 26, 2023 at 12:05:03 AM UTC-7 Nasser M. Abbasi wrote:

> I can't use  SR(sage_eval(' expression'))  Now all my integral are 
> failing. 
> Here is an example
>
> >sage
> │ SageMath version 9.8, Release Date: 2023-02-11 │
> │ Using Python 3.11.1. Type "help()" for help.   │
>
> sage: var('x')
> x
>
> sage: SR(sage_eval('sin(x)'))
> ---
> NameError Traceback (most recent call last)
> Cell In [3], line 1
> > 1 SR(sage_eval('sin(x)'))
>
> File ~/TMP/sage-9.8/src/sage/misc/sage_eval.py:198, in sage_eval(source, 
> locals, cmds, preparse)
> 196 return locals['_sage_eval_returnval_']
> 197 else:
> --> 198 return eval(source, sage.all.__dict__, locals)
>
> File :1
>
> NameError: name 'x' is not defined
>
>
> But 
>
> sage: SR('sin(x)')
> sin(x)
>
> Works. 
>
> So adding  sage_eval() did not work.
>
> --Nasser
>
>
> On Wednesday, April 26, 2023 at 1:33:26 AM UTC-5 Nils Bruin wrote:
>
>> I think the problem is that the SR exression parses does not know about 
>> python's "(a,b)" tuple notation. If you replace the round brackets with 
>> square brackets, it does seem to work; at least for the example you give:
>>
>> sage: SR('hypergeometric([3/2,], [5/2, 3], -1/4*3^2)')
>>  hypergeometric((3/2,), (5/2, 3), -1/4*3^2)
>>
>> You could use the python parser instead, via something like:
>>
>>  SR(sage_eval(' hypergeometric((3/2,), (5/2, 3), -1/4*3^2)'))
>>
>> but note that SR will happily define symbols it doesn't know, whereas 
>> sage_eval will complain:
>>
>> sage: SR("my_function(var1,var2)")
>> my_function(var1, var2)
>> sage: SR(sage_eval("my_function(var1,var2)"))
>> NameError: name 'my_function' is not defined
>>
>>
>>
>> On Tuesday, 25 April 2023 at 23:08:02 UTC-7 Nasser M. Abbasi wrote:
>>
>>> I read integrals from a file. They all are stored as strings.
>>>
>>> Then use SR('expression') inside sagemath to convert them to sagemath 
>>> symbolic  expression before calling integrate.
>>>
>>> Some give parsing error. 
>>>
>>> Is using SR('expression') not the correct way to convert string to a 
>>> symbolic expression?
>>>
>>> I am using 9.8 on Linux. Here is an example
>>>
>>> >sage
>>> │ SageMath version 9.8, Release Date: 2023-02-11 │
>>> │ Using Python 3.11.1. Type "help()" for help.   │
>>>
>>> sage: hypergeometric((3/2,), (5/2, 3), -1/4*3^2)
>>> hypergeometric((3/2,), (5/2, 3), -9/4)
>>>
>>> You see, there is no error. But now if put the expression inside string 
>>> and use SR, it gives error:
>>>
>>>
>>> sage: SR('hypergeometric((3/2,), (5/2, 3), -1/4*3^2)')
>>>
>>> ---
>>> SyntaxError   Traceback (most recent call 
>>> last)
>>> File ~/TMP/sage-9.8/src/sage/symbolic/expression.pyx:13706, in 
>>> sage.symbolic.expression.new_Expression()
>>>   13705 from sage.calculus.calculus import 
>>> symbolic_expression_from_string
>>> > 13706 return parent(symbolic_expression_from_string(x))
>>>   13707 except SyntaxError as err:
>>>
>>> File ~/TMP/sage-9.8/src/sage/calculus/calculus.py:2578, in 
>>> symbolic_expression_from_string(s, syms, accept_sequence, parser)
>>>2576 parser._callable_constructor().set_names({k[0]: v for k, v in 
>>> syms.items()
>>>2577   if _is_function(v)})
>>> -> 2578 return parse_func(s)
>>>
>>> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:556, in 
>>> sage.misc.parser.Parser.parse_expression()
>>> 555 
>>> --> 556 cpdef parse_expression(self, s):
>>> 557 """
>>>
>>> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:568, in 
>>> sage.misc.parser.Parser.parse_expression()
>>> 567 cdef Tokenizer tokens = Tokenizer(s)
>>> --> 568 expr = self.p_expr(tokens)
>>> 569 if tokens.next() != EOS:
>>>
>>> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:792, in 
>>> sage.misc.parser.Parser.p_expr()
>>> 791 cdef int op
>>> --> 792 operand1 = self.p_term(tokens)
>>> 793 op = tokens.next()
>>>
>>> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:826, in 
>>> sage.misc.parser.Parser.p_term()
>>> 825 cdef int op
>>> --> 826 operand1 = self.p_factor(tokens)
>>> 827 op = tokens.next()
>>>
>>> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:869, in 
>>> sage.misc.parser.Parser.p_factor()
>>> 868 tokens.backtrack()
>>> --> 869 return self.p_power(tokens)
>>> 870 
>>>
>>> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:897, in 
>>> 

[sage-devel] Re: bug in realfield when passing float literals

[John H Palmieri]

"2*1.1" is not a float literal. Note that RR(2.2) does what you want.

On Monday, April 10, 2023 at 1:42:21 PM UTC-7 aw wrote:

> sage version: 9.4
> operating system: fedora 35
>
> float literals passed to realfield can yield wrong answers
>
> example:
>
> RR=RealField(200)
>
> print(RR(1.1))
> print(RR(11/10))
> print()
> print(RR(2*1.1))
> print(RR(2*11/10))
>
> output:
>
> 1.10
> 1.10
>
> 2.20017763568394002504646778106689453125
> 2.20
>
> this bug is trivial to fix
> float literals passed to realfield should be automatically cast as a ratio 
> of sage ints
> eg the float literal 1.1 should be cast to 11/10
>

-- 
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/5d29e9a1-7eb2-4f6c-bdd1-1a795d4bb533n%40googlegroups.com.

[sage-devel] git question/request

[John H Palmieri]

Would it be a good idea for Sage tarballs, at least the development 
versions, to come with `upstream` defined already? With a fresh 10.0.beta6 
tarball:

% git remote -v
trac https://github.com/sagemath/sagetrac-mirror.git (fetch)
trac ssh://g...@trac.sagemath.org:/sage.git (push)

Should this also (or instead) define `upstream` as 
https://github.com/sagemath/sage.git?

-- 
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/9c5fa356-feae-4c31-aa35-df56b27240d2n%40googlegroups.com.

Re: [sage-devel] Breakage on OS X

[John H Palmieri]

First, this is not the same error (a segfault) I frequently see when 
docbuilding.

Second, I see this after doing `unset MAKE` and then `make -j1`. I can hit 
the problem very quickly by running

./sage --docbuild reference/hyperbolic_geometry html

Third, and this is a separate issue, I don't understand why I'm getting the 
error. It's arising from plot_directive.py, but I've disabled plotting when 
I docbuild, by setting SAGE_DOCBUILD_OPTS=' --no-plot '. Why is it 
processing commands inside a `.. plot::` directive at all?


On Tuesday, March 28, 2023 at 12:52:07 PM UTC-7 Dima Pasechnik wrote:

On Tue, Mar 28, 2023 at 7:51 PM Dima Pasechnik  wrote: 
> 
> I tried building and testing the latest develop with Homebrew on Intel, 

oops, that was still with openblas minor version 21, not 22. Let me 
see if 22 works for me. 

> and I was getting segfaults in docbuilder. However, they went through 
with 
> 
> make -j1 
> 
> The usual macOS parallel docbuilder blues, it seems. 
> 
> 
> 
> On Tue, 28 Mar 2023, 19:35 John H Palmieri,  wrote: 
>> 
>> I ran "brew upgrade" recently on two different Macs, one Intel and one 
Apple Silicon, and now the Sage documentation fails to build: 
>> 
>> [hyperboli] from 
/Users/jpalmier/Desktop/Sage/sage_builds/TESTING/clean/sage-10.0.beta5/src/doc/en/reference/hyperbolic_geometry/sage/geometry/hyperbolic_space/hyperbolic_geodesic.rst:
 

>> [hyperboli] Traceback (most recent call last): 
>> [hyperboli] File "sage/matrix/matrix_double_dense.pyx", line 345, in 
sage.matrix.matrix_double_dense.Matrix_double_dense.__invert__ 
>> [hyperboli] M._matrix_numpy = scipy.linalg.inv(self._matrix_numpy) 
>> [hyperboli] File 
"/Users/jpalmier/Desktop/Sage/sage_builds/TESTING/clean/sage-10.0.beta5/local/var/lib/sage/venv-python3.11/lib/python3.11/site-packages/scipy/linalg/_basic.py",
 
line 975, in inv 
>> [hyperboli] raise LinAlgError("singular matrix") 
>> [hyperboli] numpy.linalg.LinAlgError: singular matrix 
>> [hyperboli] During handling of the above exception, another exception 
occurred: 
>> [hyperboli] Traceback (most recent call last): 
>> [hyperboli] File 
"/Users/jpalmier/Desktop/Sage/sage_builds/TESTING/clean/sage-10.0.beta5/local/var/lib/sage/venv-python3.11/lib/python3.11/site-packages/matplotlib/sphinxext/plot_directive.py",
 
line 517, in _run_code 
>> [hyperboli] exec(code, ns) 
>> [hyperboli] File "", line 3, in  
>> [hyperboli] File 
"/Users/jpalmier/Desktop/Sage/sage_builds/TESTING/clean/sage-10.0.beta5/src/sage/geometry/hyperbolic_space/hyperbolic_geodesic.py",
 
line 1625, in perpendicular_bisector 
>> [hyperboli] isom_mtrx = S.inverse() * (T1 * T2) * S 
>> [hyperboli] ^^^ 
>> [hyperboli] File "sage/matrix/matrix2.pyx", line 9964, in 
sage.matrix.matrix2.Matrix.inverse 
>> [hyperboli] return ~self 
>> [hyperboli] File "sage/matrix/matrix_double_dense.pyx", line 347, in 
sage.matrix.matrix_double_dense.Matrix_double_dense.__invert__ 
>> [hyperboli] raise ZeroDivisionError("input matrix must be nonsingular") 
>> [hyperboli] ZeroDivisionError: input matrix must be nonsingular 
>> 
>> (I saw this first with 10.0.beta6 but then went and tried with 
10.0.beta5, which had succeeded earlier. Now it fails.) 
>> 
>> Perhaps this is due to an upgraded openblas? That's the most obvious 
among the recently upgraded packages, at least to me: homebrew just 
upgraded these: 
>> 
>> drwxr-xr-x 3 jpalmier admin 96 Mar 27 10:21 gnupg 
>> drwxr-xr-x 3 jpalmier admin 96 Mar 27 10:21 pinentry 
>> drwxr-xr-x 3 jpalmier admin 96 Mar 27 10:21 npth 
>> drwxr-xr-x 3 jpalmier admin 96 Mar 27 10:21 libusb 
>> drwxr-xr-x 3 jpalmier admin 96 Mar 27 10:21 libksba 
>> drwxr-xr-x 3 jpalmier admin 96 Mar 27 10:21 libgcrypt 
>> drwxr-xr-x 3 jpalmier admin 96 Mar 27 10:21 libassuan 
>> drwxr-xr-x 3 jpalmier admin 96 Mar 27 10:21 libgpg-error 
>> drwxr-xr-x 3 jpalmier admin 96 Mar 27 10:00 gh 
>> drwxr-xr-x 3 jpalmier admin 96 Mar 27 10:00 imagemagick 
>> drwxr-xr-x 3 jpalmier staff 96 Mar 27 09:59 tox 
>> drwxr-xr-x 3 jpalmier admin 96 Mar 27 09:59 primecount 
>> drwxr-xr-x 3 jpalmier staff 96 Mar 27 09:59 tcl-tk 
>> drwxr-xr-x 3 jpalmier admin 96 Mar 27 09:59 qt 
>> drwxr-xr-x 3 jpalmier admin 96 Mar 27 09:59 gobject-introspection 
>> drwxr-xr-x 3 jpalmier admin 96 Mar 27 09:59 netpbm 
>> drwxr-xr-x 3 jpalmier admin 96 Mar 27 09:59 glib 
>> drwxr-xr-x 3 jpalmier admin 96 Mar 27 09:59 mpg123 
>> drwxr-xr-x 3 jpalmier admin 96 Mar 27 09:59 cmake 
>> drwxr-xr-x 3 jpalmier staff 96 Mar 27 09:59 ghostscript 
>> drwxr-xr-x 3 jpalmier staff 96 Mar 27 09:59 sqlite 
>> drwxr-xr-x

[sage-devel] Breakage on OS X

[John H Palmieri]

I ran "brew upgrade" recently on two different Macs, one Intel and one 
Apple Silicon, and now the Sage documentation fails to build:

[hyperboli]  from 
/Users/jpalmier/Desktop/Sage/sage_builds/TESTING/clean/sage-10.0.beta5/src/doc/en/reference/hyperbolic_geometry/sage/geometry/hyperbolic_space/hyperbolic_geodesic.rst:
[hyperboli] Traceback (most recent call last):
[hyperboli]   File "sage/matrix/matrix_double_dense.pyx", line 345, in 
sage.matrix.matrix_double_dense.Matrix_double_dense.__invert__
[hyperboli] M._matrix_numpy = scipy.linalg.inv(self._matrix_numpy)
[hyperboli]   File 
"/Users/jpalmier/Desktop/Sage/sage_builds/TESTING/clean/sage-10.0.beta5/local/var/lib/sage/venv-python3.11/lib/python3.11/site-packages/scipy/linalg/_basic.py",
 
line 975, in inv
[hyperboli] raise LinAlgError("singular matrix")
[hyperboli] numpy.linalg.LinAlgError: singular matrix
[hyperboli] During handling of the above exception, another exception 
occurred:
[hyperboli] Traceback (most recent call last):
[hyperboli]   File 
"/Users/jpalmier/Desktop/Sage/sage_builds/TESTING/clean/sage-10.0.beta5/local/var/lib/sage/venv-python3.11/lib/python3.11/site-packages/matplotlib/sphinxext/plot_directive.py",
 
line 517, in _run_code
[hyperboli] exec(code, ns)
[hyperboli]   File "", line 3, in 
[hyperboli]   File 
"/Users/jpalmier/Desktop/Sage/sage_builds/TESTING/clean/sage-10.0.beta5/src/sage/geometry/hyperbolic_space/hyperbolic_geodesic.py",
 
line 1625, in perpendicular_bisector
[hyperboli] isom_mtrx = S.inverse() * (T1 * T2) * S
[hyperboli] ^^^
[hyperboli]   File "sage/matrix/matrix2.pyx", line 9964, in 
sage.matrix.matrix2.Matrix.inverse
[hyperboli] return ~self
[hyperboli]   File "sage/matrix/matrix_double_dense.pyx", line 347, in 
sage.matrix.matrix_double_dense.Matrix_double_dense.__invert__
[hyperboli] raise ZeroDivisionError("input matrix must be nonsingular")
[hyperboli] ZeroDivisionError: input matrix must be nonsingular

(I saw this first with 10.0.beta6 but then went and tried with 10.0.beta5, 
which had succeeded earlier. Now it fails.)

Perhaps this is due to an upgraded openblas? That's the most obvious among 
the recently upgraded packages, at least to me: homebrew just upgraded 
these:

drwxr-xr-x  3 jpalmier  admin  96 Mar 27 10:21 gnupg
drwxr-xr-x  3 jpalmier  admin  96 Mar 27 10:21 pinentry
drwxr-xr-x  3 jpalmier  admin  96 Mar 27 10:21 npth
drwxr-xr-x  3 jpalmier  admin  96 Mar 27 10:21 libusb
drwxr-xr-x  3 jpalmier  admin  96 Mar 27 10:21 libksba
drwxr-xr-x  3 jpalmier  admin  96 Mar 27 10:21 libgcrypt
drwxr-xr-x  3 jpalmier  admin  96 Mar 27 10:21 libassuan
drwxr-xr-x  3 jpalmier  admin  96 Mar 27 10:21 libgpg-error
drwxr-xr-x  3 jpalmier  admin  96 Mar 27 10:00 gh
drwxr-xr-x  3 jpalmier  admin  96 Mar 27 10:00 imagemagick
drwxr-xr-x  3 jpalmier  staff  96 Mar 27 09:59 tox
drwxr-xr-x  3 jpalmier  admin  96 Mar 27 09:59 primecount
drwxr-xr-x  3 jpalmier  staff  96 Mar 27 09:59 tcl-tk
drwxr-xr-x  3 jpalmier  admin  96 Mar 27 09:59 qt
drwxr-xr-x  3 jpalmier  admin  96 Mar 27 09:59 gobject-introspection
drwxr-xr-x  3 jpalmier  admin  96 Mar 27 09:59 netpbm
drwxr-xr-x  3 jpalmier  admin  96 Mar 27 09:59 glib
drwxr-xr-x  3 jpalmier  admin  96 Mar 27 09:59 mpg123
drwxr-xr-x  3 jpalmier  admin  96 Mar 27 09:59 cmake
drwxr-xr-x  3 jpalmier  staff  96 Mar 27 09:59 ghostscript
drwxr-xr-x  3 jpalmier  staff  96 Mar 27 09:59 sqlite
drwxr-xr-x  3 jpalmier  staff  96 Mar 27 09:59 openblas

"brew info openblas" says that it's version 0.3.22, whereas Sage comes with 
0.3.21. Everything works after building with `./configure 
--with-system-openblas=no`, but that flag triggers some other packages to 
be built by Sage rather than come from the system, so I'm not 100% sure 
it's the issue.

Has anyone else seen this?

-- 
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/3ea9fe96-6f53-4ace-9cfe-454e863a1e6an%40googlegroups.com.

[sage-devel] Re: What happened to Mathematica magics ?

[John H Palmieri]

Yes, please create a new issue. You can cc me, but I don't know the best 
way to fix it.

I saw the other issue (that %lsmagic isn't helpful by default), but 
fortunately "%" works. It would be great to fix this, too. 

On Wednesday, March 1, 2023 at 12:09:41 AM UTC-8 Emmanuel Charpentier wrote:

> Thank you for the explanation.
>
> The short-term fix works, but is noisy. Furthermore, it seems that it 
> *must* be executed at toplevel : wrapping it in a function and calling 
> this function doesn't work. So including it in a startup file doesn't seem 
> reasonable.
>
> The issue you pointed has been  closed on Jan 6, 2023. Do I need to create 
> a new issue for this problem ?
>
> BTW, diagnosting the problem is complicated by this issue 
> <https://github.com/sagemath/sage/issues/30661>, which seems to be at the 
> bottom of the stack...
>
> Le mercredi 1 mars 2023 à 04:24:36 UTC+1, John H Palmieri a écrit :
>
>> I think it's due to https://github.com/sagemath/sage/issues/34547. That 
>> ticket was created because with the old behavior in Sage, instance of 
>> Octave(), Mathematica(), etc. were created when Sage started up, regardless 
>> of the availability of the corresponding software. Once those became lazy 
>> imports, they are apparently not detected by the code in 
>> sage/repl/interface_magic.py. We could restore the old non-lazy imports, or 
>> we could not be so clever about magic commands and define them manually, or 
>> there are probably other solutions.
>>
>> The following sequence of commands seems to restore them, at least in the 
>> command line (haven't tested the notebook), if you want a short-term fix:
>>
>> from sage.repl.interface_magic import InterfaceMagic
>> import sage.interfaces.all
>> sage.interfaces.all.__dict__
>> InterfaceMagic.register_all()
>>
>>
>> On Tuesday, February 28, 2023 at 7:03:24 AM UTC-8 Emmanuel Charpentier 
>> wrote:
>>
>>> I don’t use them very often, bu the %mathematica and %%mathematica 
>>> magics seem to have recently disappeared. They don’t appear in the 
>>> %lsmagic output, and raise an error when one attempts to use them.
>>>
>>> Can someone shed any light on this ? 
>>> ​
>>>
>>

-- 
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/541a4edc-23e8-4cfe-afdc-37b96c590d4bn%40googlegroups.com.

[sage-devel] Re: What happened to Mathematica magics ?

[John H Palmieri]

I think it's due to https://github.com/sagemath/sage/issues/34547. That 
ticket was created because with the old behavior in Sage, instance of 
Octave(), Mathematica(), etc. were created when Sage started up, regardless 
of the availability of the corresponding software. Once those became lazy 
imports, they are apparently not detected by the code in 
sage/repl/interface_magic.py. We could restore the old non-lazy imports, or 
we could not be so clever about magic commands and define them manually, or 
there are probably other solutions.

The following sequence of commands seems to restore them, at least in the 
command line (haven't tested the notebook), if you want a short-term fix:

from sage.repl.interface_magic import InterfaceMagic
import sage.interfaces.all
sage.interfaces.all.__dict__
InterfaceMagic.register_all()


On Tuesday, February 28, 2023 at 7:03:24 AM UTC-8 Emmanuel Charpentier 
wrote:

> I don’t use them very often, bu the %mathematica and %%mathematica magics 
> seem to have recently disappeared. They don’t appear in the %lsmagic 
> output, and raise an error when one attempts to use them.
>
> Can someone shed any light on this ? 
> ​
>

-- 
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/6f3b7852-de6e-42c9-8c9a-11518b0b0596n%40googlegroups.com.

[sage-devel] Re: MIgration to GitHub: Heads-up on org invitations

[John H Palmieri]

Can we be proactive and request membership somewhere through GitHub, or do 
we have to receive an invitation?

On Wednesday, February 1, 2023 at 3:57:51 PM UTC-8 Andrew wrote:

> Thank you for all of your work on this!
> Andrew
>
> On Thursday, 2 February 2023 at 10:10:01 am UTC+11 Matthias Koeppe wrote:
>
>> It may take a little bit longer because we've hit the rate limit for org 
>> invitation.
>>
>> On Wednesday, February 1, 2023 at 2:11:37 PM UTC-8 Matthias Koeppe wrote:
>>
>>> Yes, by email. I think all invitations will have been sent out within 
>>> the next 2 hours.
>>>
>>> On Wednesday, February 1, 2023 at 12:52:25 PM UTC-8 Kwankyu Lee wrote:
>>>
 Does the invitation come by email? I didn't receive it yet.

 On Thursday, February 2, 2023 at 4:52:10 AM UTC+9 Matthias Koeppe wrote:

> I am sending out invitations to all Sage contributors with known 
> GitHub accounts to join the sagemath organization (unless they are 
> already 
> a Member).
>
> If you accept the invitation, your contributions to Sage (tickets, 
> comments, ...) will be connected to your GitHub account.
>
> Otherwise, we have to create a placeholder account ("mannequin") for 
> your contribution. Our GitHub migration team contact has assured us that 
> it 
> will be possible to link mannequins to real accounts later; but it is an 
> extra step, so it pays off to respond quickly to the invitation.
>
>
>
>

-- 
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/423ebadd-8ffa-4cba-9fcd-4449f767b7c9n%40googlegroups.com.

Re: URGENT: Re: [sage-devel] Jan 30 to Feb 4: Trac downtime, migration to GitHub

[John H Palmieri]

Is there going to be one more round of (presumably automatic) additions to 
trac, providing a link from each trac ticket to the corresponding GH issue?


On Monday, January 30, 2023 at 2:06:34 PM UTC-8 dim...@gmail.com wrote:

> On Mon, Jan 30, 2023 at 9:56 PM Kwankyu Lee  wrote:
> >
> > On Tuesday, January 31, 2023 at 5:41:39 AM UTC+9 dim...@gmail.com wrote:
> >
> > Did you log out? Or you were basically kicked out?
> >
> > I didn't log out.
>
> OK, so perhaps (former) TRAC_ADMINS, such as David, are treated 
> differently?
> OK, it's good news. We didn't have many of these (under 20), so it's
> reasonable to assume they won't
> go change contents, if for some reason they have an authenticated to
> trac browser session lying somewhere...
>
>
>
> >
> > --
> > 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/e92978b7-54f7-4a18-ad89-30c64ce306d3n%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/d52b9dd9-90ae-4ddb-9a8e-a97921ac4455n%40googlegroups.com.

[sage-devel] Re: Final call for GitHub user names

[John H Palmieri]

"palmieri" and "palmiery" and "jpalmieri" appear (probably from mistakes 
with cc entries), and they should all be changed to match my correct trac 
name "jhpalmieri" (same as my github id).

On Wednesday, January 18, 2023 at 6:14:16 PM UTC-8 Kwankyu Lee wrote:

> Dear readers,
>
> Attached unmapped_users.pdf is the list of usernames encountered in the 
> preparation of the migration from Trac to GitHub, *with no corresponding 
> GitHub user name*. We are planning to create mannequin GitHub ids 
> (connected with no real GitHub user) for the usernames in the list.
>
> *Check the list and if you are the owner of the username or know the 
> owner, then please inform us here about the owner (full name or Trac 
> username) and, if known, his/her GitHub user name.*
>
> - username: possibly misspelled or non-human
> - known on trac: True if username belongs to a valid Trac account; False 
> otherwise
> - mention:: True if username is mentioned in a ticket comment
> - mention: False if username is found as reporter, owner, author, or in cc 
> of a ticket
> - mannequin: planned mannequin id
> - frequency: number of appearance times in Trac
>
> For more information, visit 
> https://github.com/sagemath/trac-to-github/issues/77
>

-- 
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/df24c651-ebd1-45ef-b366-971c8d959968n%40googlegroups.com.

[sage-devel] Re: Determinant of a SR matrix substituted by a floating number is not numerical stable

[John H Palmieri]

Your current code has fragments like this:

weighted_load = load_obj(f'./sym.sobj')
print(f'weighted == weighted_load {weighted == weighted_load}')
save(weighted, f'./sym.sobj')

In particular, "sym.sobj" is read before it is written, so 'weighted_load' 
will be None. If I put the "save" lines earlier, I see this:

weighted == weighted_load True
realm == realm_load: True
realm != realm_load: False
determinant
-7.116356115499656e-14
-7.116356115499656e-14
-7.116356115499656e-14

Having said all of that, I think that determinants tend to be numerically 
unstable, and it would not be surprising for a number so close to zero to 
display that instability. A small change in one of the entries of the 
matrix, due to how the decimals are represented, could easily change the 
determinant.

On Wednesday, January 4, 2023 at 9:12:55 AM UTC-8 ivana...@gmail.com wrote:

> I found I got different determinant value every time I ran my program. I 
> tried to save the current matrix and load the matrix in the next run, and I 
> compared two matrices. The compare results are not stable either. Sometime 
> they are the same and not the same at the same time (A == B is False and A 
> != B is False either)!
>
> Here is the minimal case I could figure out. I tried to replace the 
> testing matrix to a simpler one, but the issue could not be reproduced 
> after replacing. I am sorry about giving you some many lines of code. I 
> guess it's not easy to read code on Google Groups, so the file is attached.
>
> from functools import cache
>
> from sage.all_cmdline import *
>
>
> l = 1
>
>
> def load_obj(filename):
> try:
> return load(filename)
> except FileNotFoundError:
> return None
>
>
> @cache
> def expected_distance(n, l):
> if n <= -2:
> return 0
> if n == -1:
> return -2 * x
> if n == 0:
> return 1
> return ((
> - 4 * (2 * (n + 1) - 1) * expected_distance(n - 1, l) \
> - n * ((n + 1) * (n - 1) - 4 * l * (l + 1)) * expected_distance(n 
> - 2, l)
> ) / (8 * (n + 1) * x)).full_simplify()
>
> # Generate the matrix for testing. I tried to figure out a minimal 
> reproducible
> # code, but I failed.
> depth = 8
> functions = [expected_distance(i, l) for i in range(depth * 2 - 1)]
> hankel = matrix.hankel(functions[:depth], functions[depth:depth * 2 - 1], 
> SR)
> weighted = matrix(depth, depth, [(hankel[i][j] / hankel[0][j] / hankel[i][
> 0])
>  for i in range(depth)
>  for j in range(depth)])
>
> # Only with this useless line, you can see the first and the second cases
> # listed in the comment (*) below.
> weighted = weighted.submatrix(0, 0, depth, depth)
>
> weighted_load = load_obj(f'./sym.sobj')
> print(f'weighted == weighted_load {weighted == weighted_load}')
> save(weighted, f'./sym.sobj')
>
> realm = weighted.substitute({x: -0.0070218})
> realm2 = weighted.substitute({x: -0.0070218})
> realm_load = load_obj(f'./real.sobj')
> save(realm, f'./real.sobj')
>
> # (*) There are three possible output of this two lines
> # 1.
> # realm == realm_load: False
> # realm != realm_load: False
> # 2.
> # realm == realm_load: True
> # realm != realm_load: False
> # 3.
> # realm == realm_load: False
> # realm != realm_load: True
> #
> # The possibilities of each case are almost the same.
> print(f'realm == realm_load: {realm == realm_load}')
> print(f'realm != realm_load: {realm != realm_load}')
>
> # The determinant values are different in defferent runs
> print('determinant')
> print(realm.det())
> print(realm2.det())
> print(realm_load.det())
>
> # Only print something when the third case happened.
> for i in range(realm.nrows()):
> for j in range(realm.ncols()):
> if realm[i][j] != realm_load[i][j]:
> print(f'{(i, j)}')
> print(realm[i][j])
> print(realm_load[i][j])
>
>

-- 
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/a7e473a2-7dfa-4e69-9f15-651ef6e77c09n%40googlegroups.com.

[sage-devel] Re: SageMath 9.8 beta 4: Error building a wheel for scipy-1.9.2

[John H Palmieri]

What OS? I'm guessing Mac OS, in which case you need the fix at 
https://trac.sagemath.org/ticket/34658, or build 9.8.beta3 or wait for a 
later beta release that includes the fix.

-- 
John


On Saturday, November 26, 2022 at 12:40:30 PM UTC-8 beingn...@gmail.com 
wrote:

> Dear SageMath,
>
> scipy-1.92 was successfully built with the default configuration:
>
> ./configure
>
> SageMath was then built again with:
>
> ,/configure --prefix=/mnt/g/Maths/sage-9.8/b4.0
>
> This new build failed at 'scipy-1.9.2'.  Your help to debug and fix this 
> issue is much appreciated. 
> Please find 'non-default-config.log', 'non-default-scipy-1.9.2.log' and 
> 'default-scipy-1.9.2.log' in the attached 'report.b4.0.7z'
>
> With best wishes and regards,
>
> phi
>
>
>
>
>

-- 
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/ac577b22-8952-4e99-b8c8-8f7462e9c43fn%40googlegroups.com.

[sage-devel] Re: The documentation built for #34730 needs your attention for checking

[John H Palmieri]

I think the use of Tachyon instead of Jmol must be particular to that 
setup. When I build the docs with #34730, it looks the same as in the 
develop branch, same as on sagemath.org.

On Wednesday, November 9, 2022 at 1:24:38 PM UTC-8 Eric Gourgoulhon wrote:

> PS: the loss of text3d is particularly apparent here:
>
> https://aa74d4badcbe6841833ff983ad5f756c5ac78752--sagemath-tobias.netlify.app/reference/plot3d/sage/plot/plot3d/shapes2.html#sage.plot.plot3d.shapes2.text3d
> as compared to
>
> https://doc.sagemath.org/html/en/reference/plot3d/sage/plot/plot3d/shapes2.html#sage.plot.plot3d.shapes2.text3d
>
> Le mercredi 9 novembre 2022 à 22:19:23 UTC+1, Eric Gourgoulhon a écrit :
>
>> Le mercredi 9 novembre 2022 à 06:22:43 UTC+1, Kwankyu Lee a écrit :
>>
>>> Hi,
>>>
>>> Trac #34730 rebases sage_autodoc onto the upgraded Sphinx 5.3.0. It is 
>>> responsible for formatting Sage objects (functions, classes, etc.) to build 
>>> documentation.
>>>
>>> Please check your favorite sections in our documentation 
>>>
>>>
>>> https://aa74d4badcbe6841833ff983ad5f756c5ac78752--sagemath-tobias.netlify.app/
>>>
>>> for any regression due to #34730. 
>>>
>>
>> At first glance, looks good, thanks. 
>> Regarding 3D plots, they are rendered with Tachyon, instead of Jmol  for 
>> Sage 9.7: compare
>>
>> https://aa74d4badcbe6841833ff983ad5f756c5ac78752--sagemath-tobias.netlify.app/reference/plot3d/sage/plot/plot3d/plot3d.html
>> with 
>>
>> https://doc.sagemath.org/html/en/reference/plot3d/sage/plot/plot3d/plot3d.html
>> Any reason for this? (the drawback of Tachyon is that we are loosing axes 
>> labels, as well as text3d). 
>>
>> Eric. 
>>
>

-- 
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/35d3b133-def7-4b48-844d-1f9b998cd96fn%40googlegroups.com.

Re: [sage-devel] Re: polynomial coefficients -- sparse=True default -- why?

[John H Palmieri]

See https://trac.sagemath.org/ticket/33813 for a somewhat related issue, by 
the way.

On Wednesday, October 19, 2022 at 1:18:56 PM UTC-7 john.c...@gmail.com 
wrote:

> My suggestion was only for univariate polynomials. I am certainly not
> proposing this for multivariate polynomials. I still cannot think of
> a use case for the current default for univariate polynomials. (And,
> more than one person has complained to me about this "very annoying
> and incomprehensible" behaviour.)
>
> John
>
> On Wed, 19 Oct 2022 at 21:10, Dima Pasechnik  wrote:
> >
> > Could it be it's the same default for univariate and multivariate cases? 
> In the latter case, it's easier to blow off memory usage to store zeros...
> >
> > On Wed, 19 Oct 2022, 21:06 David Ayotte,  wrote:
> >>
> >> I agree with this suggestion. Whenever I am looking for the 
> coefficients of a polynomial, I also use the option "sparse=False" as this 
> gives me indirect information about the degree of each associated monomial. 
> In fact, I remember being a bit confused when I first used this method.
> >>
> >> Best,
> >>
> >> David A.
> >>
> >> Le mercredi 19 octobre 2022 à 12:34:59 UTC-4, john.c...@gmail.com a 
> écrit :
> >>>
> >>> Does anyone ever use pol.coefficients() and not
> >>> pol.coefficients(sparse=False)? I mean, why is the default option
> >>> sparse=True? There must be very few occasions for the default,and I
> >>> get tired of typing sparse=False I do know that pol.list() is the
> >>> same as pol.coefficients(sparse=False).
> >>>
> >>> I would be happy to propose changing the default, with an appropriate
> >>> depreciation warning for the usual period.
> >>>
> >>> 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/aafed6b4-fd16-4aa1-a7df-a63526470eeen%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+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/CAAWYfq0NEvr7fOr7Q16VQG0BnKeWCZZf%2BDND%3DXagk9ChOOEWFw%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/7f31906c-1da1-4cb8-a7ad-9828212ee88fn%40googlegroups.com.

[sage-devel] Re: Help wanted: Issue and PR templates, replacement for ticket dependencies

[John H Palmieri]

I think it's okay to not make things mandatory. For labels, I propose a 
simple approach first: "Blocker" or not, "Bug" or not. (Currently, the 
"Task" type isn't used much, so the major distinction is between "Defect" 
and "Enhancement". Changing to "Bug" or not captures this.) I like the 
current "Component" setup, and I don't know how to replicate that well with 
user-generated labels: we're going to get typos and variations: "AG" or 
"AlgebraicGeometry" or "algebraic-geometry" or ... But it's worth trying.

On Monday, October 17, 2022 at 11:40:27 PM UTC-7 seb@gmail.com wrote:

> There are two essential disadvantages of the issue form:
>
> 1. It is not available for PR.
> 2. The given structure is completely flattened after the issue has been 
> created. In particular, the entries of the dropdown menus of the issue 
> header are not visible (i.e. dropdown boxes are flattened to the selected 
> entry) .
>
> An advantage is that the issue is not created until all checkboxes are 
> set. So this can be used to make things mandatory. This doesn't seem to be 
> possible with the template.
>
>
> tobias...@gmail.com schrieb am Montag, 17. Oktober 2022 um 21:07:12 UTC+2:
>
>> You can have advanced more advanced controls like checkboxes or 
>> dropdownboxes in issue forms, see 
>> https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-githubs-form-schema#dropdown.
>>  
>> Some of this is used in 
>> https://github.com/sagemath/sage-gh-templates-sandbox/pull/1.
>>
>> On Monday, 17 October 2022 at 19:50:45 UTC+2 seb@gmail.com wrote:
>>
>>> I think there are two steps to be taken. The first step is to define a 
>>> suitable template to collect all the important information in the header of 
>>> issues and PRs that we are used to from the Trac ticket box.
>>>
>>> In terms of dependencies between PRs, this will map what we are used to. 
>>> The second step according to discussion 4477 
>>>  will go beyond 
>>> that. So this has a lower priority. But it will be nice to have!
>>>
>>> As for the first step, I would suggest having templates that mimic the 
>>> Trac ticket box for example:
>>>
>>> $ cat .github/ISSUE_TEMPLATE/trac_ticket_like_issue.md
>>> ---
>>> name: Issue according to Trac ticket
>>> about: This template provides a similar structure to a Trac ticket
>>> title: "[Short Description] "
>>> labels: 'p:major'
>>> milestone: 'sage-9.8'
>>> assignees: ''
>>>
>>> ---
>>>
>>> # Checklist for creating a Trac ticket-like issue
>>>
>>> - [ ] I have read 
>>> [README.md](https://github.com/sagemath/sage/blob/develop/README.md)
>>> - [ ] I have read [the Troubleshooting section in the Installation 
>>> Guide](https://doc.sagemath.org/html/en/installation/troubles.html)
>>> - [ ] I have checked that this will not be a duplicate
>>> - [ ] I have chosen a label from the Type 
>>> listt:bugt:enhancementt:task
>>> - [ ] I have chosen a label from the Priority 
>>> listp:blockerp:criticalp:majorp:minorp:trivial
>>> - [ ] I have chosen a label from the Component 
>>> listc:algebrac:algebraic 
>>> geometryc:...
>>>
>>> # Information that used to be in the Trac ticket box
>>>
>>> |||||
>>> |-|-|-|-|
>>> |Authors||Reviewers||
>>> |Keywords||Report upstream||
>>> |Dependencies||Stopgaps||
>>>
>>> # Description of the issue
>>>
>>> This would also help with the change of habits. But it seems that this 
>>> cannot be done only through appropriate templates. As far as I’ve seen, 
>>> there’s no way to have radio buttons or select lists with GitHub markdown, 
>>> even with plain HTML. Therefore, we would also need to implement 
>>> corresponding GitHub actions (see also my comment on issue 8 
>>>  in the trac-to-github 
>>> repo ). These would be 
>>> needed to synchronize between corresponding Trac and GitHub features, too.
>>>
>>> If there is interest to have such a template I can volunteer to produce 
>>> a first draft (but maybe this will take a while since I have only short 
>>> time-slots and I’m inexperienced with these GitHub tools).
>>> ​
>>> Matthias Koeppe schrieb am Montag, 10. Oktober 2022 um 20:42:28 UTC+2:
>>>
 As discussed previously, Issue and PR templates on GitHub can provide a 
 replacement for the Trac ticket box. See 
 ​https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository
  
 

 https://github.com/sagemath/sage-gh-templates-sandbox is open for 
 trying out possible designs for these templates. A first draft of one 
 template:
 

[sage-devel] Re: Help wanted: Issue and PR templates, replacement for ticket dependencies

[John H Palmieri]

I like the idea of mimicking the trac setup, but moving away from trac also 
lets us reconsider parts of the trac interface. I personally do not find 
the "Priority" label very helpful, other than whether it's a blocker or 
not. What do others think? We could just ask people to label "Blocker" if 
necessary, or I suppose have one template for a blocker, one template for 
everything else. (Probably better to use labels, since we see issues change 
from blocker to not and then back again, so having different templates 
would be cumbersome.) 

A broader question is, which parts of the trac interface do we want to 
keep, and which parts can we dispense with? Also, where is the right place 
to have this discussion?

On Monday, October 17, 2022 at 10:50:45 AM UTC-7 seb@gmail.com wrote:

> I think there are two steps to be taken. The first step is to define a 
> suitable template to collect all the important information in the header of 
> issues and PRs that we are used to from the Trac ticket box.
>
> In terms of dependencies between PRs, this will map what we are used to. 
> The second step according to discussion 4477 
>  will go beyond that. 
> So this has a lower priority. But it will be nice to have!
>
> As for the first step, I would suggest having templates that mimic the 
> Trac ticket box for example:
>
> $ cat .github/ISSUE_TEMPLATE/trac_ticket_like_issue.md
> ---
> name: Issue according to Trac ticket
> about: This template provides a similar structure to a Trac ticket
> title: "[Short Description] "
> labels: 'p:major'
> milestone: 'sage-9.8'
> assignees: ''
>
> ---
>
> # Checklist for creating a Trac ticket-like issue
>
> - [ ] I have read 
> [README.md](https://github.com/sagemath/sage/blob/develop/README.md)
> - [ ] I have read [the Troubleshooting section in the Installation 
> Guide](https://doc.sagemath.org/html/en/installation/troubles.html)
> - [ ] I have checked that this will not be a duplicate
> - [ ] I have chosen a label from the Type 
> listt:bugt:enhancementt:task
> - [ ] I have chosen a label from the Priority 
> listp:blockerp:criticalp:majorp:minorp:trivial
> - [ ] I have chosen a label from the Component 
> listc:algebrac:algebraic 
> geometryc:...
>
> # Information that used to be in the Trac ticket box
>
> |||||
> |-|-|-|-|
> |Authors||Reviewers||
> |Keywords||Report upstream||
> |Dependencies||Stopgaps||
>
> # Description of the issue
>
> This would also help with the change of habits. But it seems that this 
> cannot be done only through appropriate templates. As far as I’ve seen, 
> there’s no way to have radio buttons or select lists with GitHub markdown, 
> even with plain HTML. Therefore, we would also need to implement 
> corresponding GitHub actions (see also my comment on issue 8 
>  in the trac-to-github 
> repo ). These would be 
> needed to synchronize between corresponding Trac and GitHub features, too.
>
> If there is interest to have such a template I can volunteer to produce a 
> first draft (but maybe this will take a while since I have only short 
> time-slots and I’m inexperienced with these GitHub tools).
> ​
> Matthias Koeppe schrieb am Montag, 10. Oktober 2022 um 20:42:28 UTC+2:
>
>> As discussed previously, Issue and PR templates on GitHub can provide a 
>> replacement for the Trac ticket box. See 
>> ​https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository
>>  
>> 
>>
>> https://github.com/sagemath/sage-gh-templates-sandbox is open for trying 
>> out possible designs for these templates. A first draft of one template:
>> ​https://github.com/sagemath/sage-gh-templates-sandbox/issues/new/choose 
>> 
>>
>>
>> Related: Help is needed with choosing a good replacement for our Trac 
>> ticket dependencies. As suggested in 
>> ​https://github.com/sagemath/publications/pull/142#issuecomment-1259001501 
>> 
>>  and ​https://groups.google.com/g/sage-devel/c/hX6ojxlNwOU/m/dup_Ywu1BQAJ 
>> , 
>> we should add to ​the transition guide 
>> 
>>  how 
>> to model Trac's ticket dependencies in GitHub PRs. See 
>> ​https://github.com/orgs/community/discussions/4477 
>>  for solutions.
>>
>>
>> This is 

Re: [sage-devel] Re: Democratic issue: rushing decisions

[John H Palmieri]

On Friday, October 7, 2022 at 9:48:29 AM UTC-7 tobias...@gmail.com wrote:

> I just had another look at the voting thread, where most votes were voiced 
> in the first two days, and the almost-slient discussion thread, where 
> mostly a few practical aspects of the migrations were discussed. From this, 
> I don't get the impression that the most voters felt they needed more time 
> to think or discuss their decision.
>

Discussions about the timing of the vote were mainly in the thread 
"incremental migration to github?", not the discussion thread or the vote 
thread.Also, I'm not sure it matters what "most voters" felt. If a few 
people felt the need to delay, that should have an effect.

 

>
> In general, I would keep the voting system simple. The migration to github 
> was one particular vote, but for example the voting on the doc styles was 
> held without much of a prior discussion and on a shorter deadline.
>
> So maybe something simple as the following?
> "Small votes:" Have to have a github issue that is at least one week old, 
> don't require a discussion on the mailing list and the voting period cannot 
> be shorter than 4 days.
> "Big votes": Require a discussion thread on the mailing list that is at 
> least one week old and the voting period cannot be shorter than 1.5 weeks.
> Upon the public request of a single member of the mailing list, every 
> "small vote" can be upgraded to a "big vote". In this case, all previously 
> handed-in votes are invalid and a discussion thread has to be opened.
>
> On Friday, 7 October 2022 at 17:43:02 UTC+2 John H Palmieri wrote:
>
>> I apologize for being indirect. I was responding to Dima's sentence, "... 
>> the delay was requested by an individual ..." which implies that there was 
>> just one person requesting the delay. I was pointing out, apparently too 
>> indirectly, that more than one person had requested a delay, and perhaps 
>> not everyone who requested a delay was guilty, in Dima's view, of some 
>> transgression.
>>
>> In short: Dima, cut it out with the straw men ("straw man: an 
>> intentionally misrepresented proposition that is set up because it is 
>> easier to defeat than an opponent's real argument").
>>
>>
>> On Friday, October 7, 2022 at 3:45:27 AM UTC-7 dim...@gmail.com wrote:
>>
>>> On Fri, Oct 7, 2022 at 12:19 AM Kwankyu Lee  wrote: 
>>> > 
>>> > 
>>> > 
>>> > On Friday, October 7, 2022 at 7:05:38 AM UTC+9 John H Palmieri wrote: 
>>> >> 
>>> >> Dima, presumably you're not talking about me, although I proposed 
>>> that "we start a vote around October 1". 
>>> > 
>>> > 
>>> > I guess he means: https://trac.sagemath.org/ticket/33725#comment:26 
>>>
>>> yes, that's exactly what I meant. 
>>>
>>> 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+...@googlegroups.com. 
>>> > To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/sage-devel/be5e2daa-6e2d-4437-bc3a-a8bf38f5a5c6n%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/bff3f1e3-53b5-4ff4-a12d-ccc3993eed0en%40googlegroups.com.

Re: [sage-devel] Re: Democratic issue: rushing decisions

[John H Palmieri]

Maybe more to the point, the thread was going in the direction of a general 
policy discussion about how to conduct votes and how to handle requests for 
delays. Dima interrupted, unprompted as far as I can see, by bringing back 
up the particular recent case along with comments about one particular 
person who had advocated for a delay. We should be able to discuss general 
policy issues without this kind of derailing.

On Friday, October 7, 2022 at 8:43:02 AM UTC-7 John H Palmieri wrote:

> I apologize for being indirect. I was responding to Dima's sentence, "... 
> the delay was requested by an individual ..." which implies that there was 
> just one person requesting the delay. I was pointing out, apparently too 
> indirectly, that more than one person had requested a delay, and perhaps 
> not everyone who requested a delay was guilty, in Dima's view, of some 
> transgression.
>
> In short: Dima, cut it out with the straw men ("straw man: an 
> intentionally misrepresented proposition that is set up because it is 
> easier to defeat than an opponent's real argument").
>
>
> On Friday, October 7, 2022 at 3:45:27 AM UTC-7 dim...@gmail.com wrote:
>
>> On Fri, Oct 7, 2022 at 12:19 AM Kwankyu Lee  wrote: 
>> > 
>> > 
>> > 
>> > On Friday, October 7, 2022 at 7:05:38 AM UTC+9 John H Palmieri wrote: 
>> >> 
>> >> Dima, presumably you're not talking about me, although I proposed that 
>> "we start a vote around October 1". 
>> > 
>> > 
>> > I guess he means: https://trac.sagemath.org/ticket/33725#comment:26 
>>
>> yes, that's exactly what I meant. 
>>
>> 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+...@googlegroups.com. 
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/be5e2daa-6e2d-4437-bc3a-a8bf38f5a5c6n%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/b3121e9a-0939-4156-9a84-1a7308181e59n%40googlegroups.com.

Re: [sage-devel] Re: Democratic issue: rushing decisions

[John H Palmieri]

I apologize for being indirect. I was responding to Dima's sentence, "... 
the delay was requested by an individual ..." which implies that there was 
just one person requesting the delay. I was pointing out, apparently too 
indirectly, that more than one person had requested a delay, and perhaps 
not everyone who requested a delay was guilty, in Dima's view, of some 
transgression.

In short: Dima, cut it out with the straw men ("straw man: an intentionally 
misrepresented proposition that is set up because it is easier to defeat 
than an opponent's real argument").


On Friday, October 7, 2022 at 3:45:27 AM UTC-7 dim...@gmail.com wrote:

> On Fri, Oct 7, 2022 at 12:19 AM Kwankyu Lee  wrote:
> >
> >
> >
> > On Friday, October 7, 2022 at 7:05:38 AM UTC+9 John H Palmieri wrote:
> >>
> >> Dima, presumably you're not talking about me, although I proposed that 
> "we start a vote around October 1".
> >
> >
> > I guess he means: https://trac.sagemath.org/ticket/33725#comment:26
>
> yes, that's exactly what I meant.
>
> 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+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/be5e2daa-6e2d-4437-bc3a-a8bf38f5a5c6n%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/da21919d-2b1d-488d-adca-df4b4b2d6ba8n%40googlegroups.com.

Re: [sage-devel] Re: Democratic issue: rushing decisions

[John H Palmieri]

Dima, presumably you're not talking about me, although I proposed that "we 
start a vote around October 1".

Anyway, the point of having a policy is so that we don't have to concern 
ourselves with the motives of the people requesting the delay or anything 
else: we would just handle the request as our policy dictates.

On Thursday, October 6, 2022 at 12:42:17 PM UTC-7 dim...@gmail.com wrote:

>
>
> On Thu, 6 Oct 2022, 20:21 Jonathan Thornburg,  wrote:
>
>> On Thu, Oct 6, 2022 at 8:45 AM John H Palmieri  
>> wrote:
>> > There is nothing in our department's bylaws to provide for a delay of
>> > voting, but we have a chair and we have an executive committee, and the
>> > hope is that they care not only about the particular issue at hand, but
>> > also about the atmosphere in the department. So if someone asked for a
>> > delay, probably the executive committee would consider it and make a
>> > decision. That would not likely result in a vote on whether to delay, 
>> but
>> > just a decision to delay the vote, and probably to schedule some 
>> meetings
>> > for discussion.
>>
>> On Thu, Oct 06, 2022 at 09:25:26AM -0700, William Stein wrote:
>> > Thanks!  So it's basically this model that you already described:
>> > "Alternatively, we have a steering committee that steps in to make
>> > decisions, for example about the timing of votes, when there is
>> > disagreement."   Having an elected steering committee is common in
>> > other software projects I pay attention to (e.g., Python and Jupyter).
>>
>> As another data point, in section 12.8 of his book "The Design and
>> Evolution of C++", Bjarne Stroustrup describes an invocation of a
>> "delay a vote to the next meeting" rule in the ANSI/ISO C++ standards
>> committee (which at the time typically met about 3 times per year):
>>
>>   [[a proposal for extending the C++ language]] was presented at the
>>   standards meeting in Seattle in July 1990.  There appeared to be a
>>   massive majority for making this the first non-mandated extension
>>   to C++.  At that point, Beth Crockett from Apple stopped the committee
>>   dead in its tracks by invoking what is known as the "two week rule:"
>>   Any member can postpone voting on a proposal that has not been in
>>   the hands of the members at least two weeks before the meeting until
>>   the following meeting.  This rule protects people against being rushed
>>   into things they don't understand and ensures that there will always
>>   be time to consult with colleagues.
>>
>>   As you might imagine, Beth didn't gain instant popularity by that
>>   veto.  However, her caution was well founded, and she saved us from
>>   making a bad mistake.  Thanks!  As we reexamined the problem after
>>   the meeting, Doug McIlroy [[found a better solution]]
>>
>
> In our case, the delay was requested by an individual who for months 
> ignores repeated requests to provide a backup of our old wiki (which he 
> hosts in his academic department, without anyone else having access to the 
> host). One of the reasons for delay given was that he was upset that I 
> "violently" (I guess in Frenchish this means "bluntly") pointed this out on 
> this very forum, as an example of dangers of a small bus factor.
>
> And in our case the voting was allowed over a long period of time.
>
> Dima
>
>
>
>
>> -- 
>> -- "Jonathan Thornburg [remove -color to reply]" <
>> dr.j.th...@gmail-pink.com>
>>currently on the west coast of Canada
>>"Why would we install sewers in London?  Everyone keeps getting cholera
>> again and again so there's obviously no reason to install sewers.  We
>> just need to get used to this as the new normal."
>> -- 2022-Jul-25 tweet by "Neoliberal John Snow"
>>
>> -- 
>> 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/Yz8qqM4YuOVtYNJI%40iron.bkis-orchard.net
>> .
>>
>

-- 
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/dc8bfb2b-1aa0-4b47-93df-8af1ef9f6912n%40googlegroups.com.

Re: [sage-devel] Re: Democratic issue: rushing decisions

[John H Palmieri]

Hi William,

There is nothing in our department's bylaws to provide for a delay of 
voting, but we have a chair and we have an executive committee, and the 
hope is that they care not only about the particular issue at hand, but 
also about the atmosphere in the department. So if someone asked for a 
delay, probably the executive committee would consider it and make a 
decision. That would not likely result in a vote on whether to delay, but 
just a decision to delay the vote, and probably to schedule some meetings 
for discussion.

  John

On Wednesday, October 5, 2022 at 9:18:04 PM UTC-7 wst...@gmail.com wrote:

> On Wed, Oct 5, 2022 at 8:09 PM John H Palmieri  
> wrote:
> >
> > The main response I saw to the requests for a slower process was from 
> David Roe, saying, "Finally, since we're just voting on trac vs github I 
> don't think there's a need to draw out the discussion until October 1, and 
> several people (William and Dima) have made arguments for making a decision 
> more quickly." I find this rather dismissive of the views of those who 
> requested a more deliberate process. It would be good to have a procedure 
> for determining timing for votes, something other than one person just 
> making a decision.
> >
> > As a starting point:
> >
> > 1. Anyone can call for a vote, and the vote should last at least a week: 
> it is not reasonable to ask for votes more quickly than that, barring an 
> emergency that demands very fast action. We call for votes all the time, 
> e.g. recent decisions about formatting options for Sage documentation, and 
> there is no reason to make the overall procedure more complicated.
> > 2. Anyone can then request a delay or an extension of the vote. The 
> default response should be to accept the delay/extension: "yes, the vote 
> will now end on ...". If people believe that the delay is unreasonable ("we 
> need to delay this vote by 25 years") or if they have other reasons to 
> object, then we can hold a one-week vote, no delays allowed, to decide 
> whether to accept the delay or not.
> >
> > The second point is flawed: what to do if there are multiple requests to 
> delay? Maybe see if the people making the requests can come to a consensus 
> about the time. If not, then vote on the shortest proposed delay? The 
> longest one? The average? (We have a reasonably healthy community, but all 
> the same, I don't want to create a rule that can be abused: one person asks 
> for a ridiculous delay, then we hold a one-week vote that fails, then 
> another person, or even the same person, asks for another ridiculous delay, 
> etc.)
> >
> > Alternatively, we have a steering committee that steps in to make 
> decisions, for example about the timing of votes, when there is 
> disagreement.
> >
> > Other options?
>
> What happens in an academic department (e.g., UW)? For example, what
> if there is an important department vote about to happen that is
> brought to the faculty by a committee, and a faculty member states at
> the faculty meeting: "we should delay this vote for 2 weeks to respect
> people with a busy schedule, to allow a constructive debate, and to
> explore all possibilities". Is there a procedure for delaying votes
> in faculty meetings?
>
> I'm just asking because bylaws tend to spell out in detail the answers
> to questions like this, and it's nice to have a concrete example.
>
> I tried searching for examples of delaying votes in US politics, and
> in Summer 2020, Trump tried very hard to delay the US presidential
> election:
>
> https://www.google.com/search?q=trump+delay+election
>
> >
> > --
> > John
> >
> >
> >
> > On Wednesday, October 5, 2022 at 3:11:12 AM UTC-7 Thierry 
> (sage-googlesucks@xxx) wrote:
> >>
> >> Hi,
> >>
> >> several developers asked for delays, to respect people with a busy
> >> schedule, to allow a constructive debate, to explore all possibilities,
> >> to move away from the noise and confusion related to a minor event
> >> [1,2,3,4,5,6].
> >>
> >> Democracy is not a race, i wish such a simple and reasonable request to
> >> be respected.
> >>
> >> Ciao,
> >> Thierry
> >>
> >> [1] John : "I don't see a reason to rush a vote"
> >> https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/q5V9ov5FAAAJ
> >>
> >> [2] Jan : "I don't think the move is so urgent though"
> >> https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/0Lk5pzdjBwAJ
> >>
> >> [3] Vincent : "For me the discussion in this thread is very premature"
> >

[sage-devel] Re: Democratic issue: rushing decisions

[John H Palmieri]

The main response I saw to the requests for a slower process was from David 
Roe, saying, "Finally, since we're just voting on trac vs github I don't 
think there's a need to draw out the discussion until October 1, and 
several people (William and Dima) have made arguments for making a decision 
more quickly." I find this rather dismissive of the views of those who 
requested a more deliberate process. It would be good to have a procedure 
for determining timing for votes, something other than one person just 
making a decision.

As a starting point:

1. Anyone can call for a vote, and the vote should last at least a week: it 
is not reasonable to ask for votes more quickly than that, barring an 
emergency that demands very fast action. We call for votes all the time, 
e.g. recent decisions about formatting options for Sage documentation, and 
there is no reason to make the overall procedure more complicated.
2. Anyone can then request a delay or an extension of the vote. The default 
response should be to accept the delay/extension: "yes, the vote will now 
end on ...". If people believe that the delay is unreasonable ("we need to 
delay this vote by 25 years") or if they have other reasons to object, then 
we can hold a one-week vote, no delays allowed, to decide whether to accept 
the delay or not.

The second point is flawed: what to do if there are multiple requests to 
delay? Maybe see if the people making the requests can come to a consensus 
about the time. If not, then vote on the shortest proposed delay? The 
longest one? The average? (We have a reasonably healthy community, but all 
the same, I don't want to create a rule that can be abused: one person asks 
for a ridiculous delay, then we hold a one-week vote that fails, then 
another person, or even the same person, asks for another ridiculous delay, 
etc.)

Alternatively, we have a steering committee that steps in to make 
decisions, for example about the timing of votes, when there is 
disagreement.

Other options?

-- 
John



On Wednesday, October 5, 2022 at 3:11:12 AM UTC-7 Thierry 
(sage-googlesucks@xxx) wrote:

> Hi,
>
> several developers asked for delays, to respect people with a busy
> schedule, to allow a constructive debate, to explore all possibilities,
> to move away from the noise and confusion related to a minor event
> [1,2,3,4,5,6].
>
> Democracy is not a race, i wish such a simple and reasonable request to
> be respected.
>
> Ciao,
> Thierry
>
> [1] John : "I don't see a reason to rush a vote"
> https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/q5V9ov5FAAAJ
>
> [2] Jan : "I don't think the move is so urgent though"
> https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/0Lk5pzdjBwAJ
>
> [3] Vincent : "For me the discussion in this thread is very premature"
> https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/ZTXx_speBwAJ
>
> [4] Sébastien : "The urgency of short term issues does not imply the 
> urgency of long term issues"
> https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/B19uBWUJCAAJ
>
> [5] Travis : "First off, we need to slow down significantly as we do not 
> have an general clear consensus about doing this move."
> https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/E3_sU2Y6CAAJ
>
> [6] Thierry : "one month break is a bare minimum."
> https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/STo_AT9qFgAJ
>
>

-- 
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/66bd89d6-7cbc-4262-9c22-66d8c238eb35n%40googlegroups.com.

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

[John H Palmieri]

You would think that this would be a solved problem: others in the open 
source community must have be in the practice of backing up their GitHub 
info.

On Thursday, September 29, 2022 at 6:55:44 PM UTC-7 Nils Bruin wrote:

> A fair point made: an "exit strategy" from Github should exist and should 
> ideally take into account that this exit may need to happen at a time where 
> github is no longer able/willing to cooperate in this exit: in other words, 
> we should ideally *back up* our issues and pull-request histories. The APIs 
> are there; writing the scripts to pull this stuff (incrementally?) would be 
> quite a bit of work, but then running it shouldn't be so bad.
>
> This is just common sense data security policy: to us github is a single 
> point-of-failure. You want to store with some frequency snapshots of the 
> data there.
>
> On Tuesday, 27 September 2022 at 14:45:51 UTC-7 tobias...@gmail.com wrote:
>
>> Okay, fair enough! Then it's a bit more work to get tickets into PRs (for 
>> devs) but maybe its a good idea to start with a clean slate.
>>
>> On Tuesday, 27 September 2022 at 22:31:57 UTC+2 dim...@gmail.com wrote:
>>
>>>
>>>
>>> On Tue, 27 Sep 2022, 21:12 Tobias Diez,  wrote:
>>>
 Just to make sure we are talking about the same thing. Imagine a 
 currently open ticket with a linked branch. How is this going to be 
 migrated? My assumption has been that this will create a PR from 
 sagemath/sagetrac-mirror/branch into sagemath/sage.

>>>
>>> No, there will be an issue on sagemath/sage, no PR. There will be a link 
>>> to a branch on sagetrac-mirror (which will be readonly). 
>>>
>>> To proceed, just push this branch to your personal fork of sagemath/sage 
>>> and make a PR from there.
>>> At this point it becomes a usual github workflow.
>>>
>>>
 If thats indeed the plan (which I find is a good plan), then there are 
 the following issues:
 - sagetrac-mirror is not a fork of sage, thus it might not be possible 
 to create a PR from it (at leas from the web interface its not possible, 
 not sure about the API)
 - sagetrac-mirror cannot be archived otherwise it will be readonly 
 (this is taken care of my Matthias recent edit to the migration wiki page)
 - devs might not have the permission to push to sagetrac-mirror 
 (currently there is a branch protection rule in place that prevents any 
 direct commits, but even if that's removed I'm not sure if everyone can 
 just push to it)

>>>
>>> all this is avoided if done as I described above 
>>>
>>> Dima
>>>
>>>
 On Tuesday, 27 September 2022 at 15:29:35 UTC+2 dim...@gmail.com wrote:

>
>
> On Tue, 27 Sep 2022, 14:08 Tobias Diez,  wrote:
>
>> Yes, the target repo of these PRs will be the (new) sagemath/sage, 
>> but the source will be sagemath/sagetrac-mirror, right? 
>
>
>
> Hmm, I might have missed something - what is the need to have 2 repos 
> here, if 1 is sufficient?
>
> Any fork of sagemath/sage may be a source of a PR, not only 
> sagetrac-mirror
>
>
> So in order to update the pull request one needs to push the changes 
>> to sagemath/sagetrac-mirror (it is not possible to update a PR by 
>> pushing 
>> to /refs/pull/xyz, because this is readonly). Thus, if sagetrac-mirror 
>> is 
>> archived (and thus readonly), the only way to work on existing 
>> tickets/branches would be to checkout the existing branch (from either 
>> sagetrac-mirror or sage/refs/pull), make changes, push to a new fork, 
>> create a new PR, close the old PR (essentially the workflow 
>> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally#modifying-an-inactive-pull-request-locally
>> ).
>>
>> On Tuesday, 27 September 2022 at 13:59:45 UTC+2 dim...@gmail.com 
>> wrote:
>>
>>> On Tue, Sep 27, 2022 at 11:29 AM Tobias Diez  
>>> wrote: 
>>> > 
>>> > One more question: The current plan is to use the sagetrac-mirror 
>>> repo as the base for creating PRs but also to archived it. However, if 
>>> I'm 
>>> not mistaken, that makes all branches in sagetrac-mirror readonly and 
>>> thus 
>>> one cannot continue working on existing PRs by pushing to the 
>>> corresponding 
>>> branch in sagetrac-mirror. 
>>>
>>> IMHO the plan is to create new PRs in sagemath/sage, not in 
>>> sagemath/sagetrac-mirror 
>>> There won't be "existing" PRs, only issues, pointing to branches on 
>>> sagetrac-mirror 
>>>
>>>
>>>
>>> > On Tuesday, 27 September 2022 at 10:02:06 UTC+2 seb@gmail.com 
>>> wrote: 
>>> >> 
>>> >> Matthias Koeppe schrieb am Samstag, 24. September 2022 um 
>>> 19:09:46 UTC+2: 
>>> >>> 
>>> >>> On Saturday, September 24, 2022 at 9:27:46 AM UTC-7 mathzeta2 
>>> wrote: 
>>> 

Re: [sage-devel] View issues

[John H Palmieri]

If you do `view(G, debug=True)`, it will first print out the entire LaTeX 
file that it's using. You could paste that into an actual file and see if 
you can pin down what the error is, and whether it's coming from your TeX 
installation or somewhere else.


On Tuesday, September 27, 2022 at 12:32:38 PM UTC-7 dim...@gmail.com wrote:

> On Tue, Sep 27, 2022 at 8:16 PM Ben Salisbury  wrote:
> >
> > Hi all,
> >
> > I'm having trouble with the view method. For example,
> >
> > sage: G = graphs.PetersenGraph()
> > sage: view(G)
>
> works for me with Sage 9.8.beta0
>
> >
> > produced the following error.
> >
> > An error occurred.
> > This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022) 
> (preloaded format=pdflatex 2022.9.9) 17 SEP 2022 18:58
> > entering extended mode
> > restricted \write18 enabled.
> > %&-line parsing enabled.
> > **\nonstopmode \input{sage.tex}
> > (./sage.tex 
> (/usr/local/texlive/2022/texmf-dist/tex/latex/base/article.cls
> > Document Class: article 2021/10/04 v1.4n Standard LaTeX document class
> > (/usr/local/texlive/2022/texmf-dist/tex/latex/base/size10.clo
> > File: size10.clo 2021/10/04 v1.4n Standard LaTeX file (size option)
> > )
> > \c@part=\count185
> > \c@section=\count186
> > \c@subsection=\count187
> > \c@subsubsection=\count188
> > \c@paragraph=\count189
> > \c@subparagraph=\count190
> > \c@figure=\count191
> > \c@table=\count192
> > \abovecaptionskip=\skip47
> > \belowcaptionskip=\skip48
> > \bibindent=\dimen138
> > )
> > (/usr/local/texlive/2022/texmf-dist/tex/latex/amsmath/amsmath.sty
> > Package: amsmath 2021/10/15 v2.17l AMS math features
> > \@mathmargin=\skip49
> >
> > 
> >
> > ! Undefined control sequence.
> > \@outputpage ...istfalse \@parboxrestore \shipout
> > \vbox {\set@typeset@protec...
> > l.118 \end{document}
> >
> > (That makes 100 errors; please try again.)
> > Here is how much of TeX's memory you used:
> > 17546 strings out of 478268
> > 364860 string characters out of 5846348
> > 670991 words of memory out of 500
> > 35436 multiletter control sequences out of 15000+60
> > 472216 words of font info for 40 fonts, out of 800 for 9000
> > 1141 hyphenation exceptions out of 8191
> > 94i,9n,104p,428b,907s stack positions out of 
> 1i,1000n,2p,20b,20s
> >
> > ! ==> Fatal error occurred, no output PDF file produced!
> >
> > Latex error
> >
> > Is there a known error or is my installation messed up (or something 
> else)?
> >
> > Best,
> > Ben
> >
> > --
> > 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/bb617109-e9a3-4a91-b3ac-4238c15f40f4n%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/754cd816-2a30-4d41-b03d-b982d84a159dn%40googlegroups.com.

Re: [sage-devel] Temporary files problems

[John H Palmieri]

I created https://trac.sagemath.org/ticket/34593: we should document how to 
change the location of the temporary directory, and maybe we should create 
a `.tmpreaper` file.


On Tuesday, September 27, 2022 at 11:06:01 AM UTC-7 Michael Orlitzky wrote:

> On Tue, 2022-09-27 at 18:10 +0100, Dima Pasechnik wrote:
> > Basically, we should deprecate and remove tmp_dir() and tmp_filename()
> > from Sage.
> > Does Sagecell use them? It should not, Python3 has perfectly good
> > replacements...
> > 
>
> That was always the plan. From #33213:
>
> > Afterward, the custom functions tmp_dir() and tmp_filename() can be
> > deprecated in favor of tempfile.TemporaryDirectory() and 
> > tempfile.NamedTemporaryFile().
>
> That solves the problem.
>
>

-- 
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/318737a6-85d2-4860-abf0-bb8546294660n%40googlegroups.com.

Re: [sage-devel] Temporary files problems

[John H Palmieri]

On Tuesday, September 27, 2022 at 10:11:00 AM UTC-7 dim...@gmail.com wrote:

> Basically, we should deprecate and remove tmp_dir() and tmp_filename() 
> from Sage. 
> Does Sagecell use them? It should not, Python3 has perfectly good 
> replacements... 
>

As long as we test everything on a variety of platforms and browsers, 
because it seems that things are broken on some platforms now. 
https://ask.sagemath.org/question/64192/temporary-html-files-location-in-sage-97/

 

>
> On Tue, Sep 27, 2022 at 6:06 PM Matthias Koeppe 
>  wrote: 
> > 
> > Previous discussion -- in the ticket that made these changes to SAGE_TMP 
> --- https://trac.sagemath.org/ticket/33213#comment:11 
> > 
> > 
> > On Tuesday, September 27, 2022 at 9:10:28 AM UTC-7 novo...@gmail.com 
> wrote: 
> >> 
> >> On Tuesday, 27 September 2022 at 03:22:47 UTC-6 dim...@gmail.com 
> wrote: 
> >>> 
> >>> On Tue, Sep 27, 2022 at 3:58 AM Andrey Novoseltsev  
> wrote: 
> >>> > this temporary directory is created and then used ever after. But 
> what if it gets deleted? 
> >>> I think it's meant to be used in a context manager, i.e. with with 
> >>> statement, e.g., citing python docs: 
> >>> 
> >>> >>> with tempfile.TemporaryDirectory() as tmpdirname: 
> >>> ... print('created temporary directory', tmpdirname) 
> >>> >>> 
> >>> # directory and contents have been removed 
> >>> 
> >>> Or with a callback (from Sage source) 
> >>> 
> >>> TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory() 
> >>> atexit.register(lambda: TMP_DIR_FILENAME_BASE.cleanup()) 
> >>> 
> >>> 
> >>> Needless to say, one can interfere with it in a bad way messing around 
> >>> with ~/.sage/ - but so it the case for any file-based process... 
> >>> 
> >> 
> >> It seems to me like a pretty common and sensible practice, that /tmp 
> directories get cleaned up, especially on systems with lots of activity. I 
> would not consider it as "a bad way messing around". But creating a 
> temporary directory and then counting on it being there hours later for 
> another quick temporary operation may be a bit too optimistic. That 
> callback is designed to clean up after Sage quits, which is a good thing to 
> do, but it is not related to being able to use the directory. 
> > 
> > -- 
> > 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/8400b398-f51a-4a1b-a911-32f60ef8b8fdn%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/86132f9c-85ef-4d16-a699-0625795371f8n%40googlegroups.com.

Re: [sage-devel] Temporary files problems

[John H Palmieri]

On Tuesday, September 27, 2022 at 8:33:01 AM UTC-7 dim...@gmail.com wrote:

>
>
> On Tue, 27 Sep 2022, 15:45 John H Palmieri,  wrote:
>
>> One of the issues is that code in Sage is using this temporary directory 
>> in the background; the user is not doing it and has no control over it. 
>> Regardless of the context manager approach, apparently some browsers refuse 
>> to open local files that are not in the user's home directory, so this 
>> location just won't work for them.
>>
>
> tempfile.TemporaryDirectory(*suffix=None*, *prefix=None*, *dir=None*, 
> *ignore_cleanup_errors=False*)
>
>
> dir=  may be used to set a directory to place
> the created one in.
>

Exactly, and this is what we should allow users to customize, but they 
currently can't (without modifying the Sage source code).

 

On Tuesday, September 27, 2022 at 2:22:47 AM UTC-7 dim...@gmail.com wrote:
>>
>>> On Tue, Sep 27, 2022 at 3:58 AM Andrey Novoseltsev  
>>> wrote: 
>>> > 
>>> > Hello! 
>>> > 
>>> > I've run into this while testing upgrades to Ubuntu 22.04 from 20.04, 
>>> but it seems that it comes from how temporary files are handled in Sage 
>>> 9.7: 
>>> > 
>>> > TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory() 
>>> > 
>>> > this temporary directory is created and then used ever after. But what 
>>> if it gets deleted? 
>>> I think it's meant to be used in a context manager, i.e. with with 
>>> statement, e.g., citing python docs: 
>>>
>>> >>> with tempfile.TemporaryDirectory() as tmpdirname: 
>>> ... print('created temporary directory', tmpdirname) 
>>> >>> 
>>> # directory and contents have been removed 
>>>
>>> Or with a callback (from Sage source) 
>>>
>>> TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory() 
>>> atexit.register(lambda: TMP_DIR_FILENAME_BASE.cleanup()) 
>>>
>>>
>>> Needless to say, one can interfere with it in a bad way messing around 
>>> with ~/.sage/ - but so it the case for any file-based process... 
>>>
>>>
>>>
>>> For example, what if someone uses tmpreaper or something similar, 
>>> when old files are removed from /tmp? Sage does not notice it, but 
>>> things break in a weird way, e.g. plots are not displayed and the 
>>> error message is not transparent. 
>>> > 
>>> > I believe this is exactly what is happening and I would appreciate 
>>> some attention to this matter ;-) 
>>> > 
>>> > Thank you! 
>>> > Andrey 
>>> > 
>>> > -- 
>>> > 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/5ee63ec7-26b2-4c32-a5a7-45fb63a11327n%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+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/bcfa5eaa-600b-4752-8b52-189422564a49n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/bcfa5eaa-600b-4752-8b52-189422564a49n%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/bce8d7cd-9a48-4bb6-8bfd-eb797225a02cn%40googlegroups.com.

Re: [sage-devel] Temporary files problems

[John H Palmieri]

One of the issues is that code in Sage is using this temporary directory in 
the background; the user is not doing it and has no control over it. 
Regardless of the context manager approach, apparently some browsers refuse 
to open local files that are not in the user's home directory, so this 
location just won't work for them.


On Tuesday, September 27, 2022 at 2:22:47 AM UTC-7 dim...@gmail.com wrote:

> On Tue, Sep 27, 2022 at 3:58 AM Andrey Novoseltsev  
> wrote:
> >
> > Hello!
> >
> > I've run into this while testing upgrades to Ubuntu 22.04 from 20.04, 
> but it seems that it comes from how temporary files are handled in Sage 9.7:
> >
> > TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory()
> >
> > this temporary directory is created and then used ever after. But what 
> if it gets deleted?
> I think it's meant to be used in a context manager, i.e. with with
> statement, e.g., citing python docs:
>
> >>> with tempfile.TemporaryDirectory() as tmpdirname:
> ... print('created temporary directory', tmpdirname)
> >>>
> # directory and contents have been removed
>
> Or with a callback (from Sage source)
>
> TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory()
> atexit.register(lambda: TMP_DIR_FILENAME_BASE.cleanup())
>
>
> Needless to say, one can interfere with it in a bad way messing around
> with ~/.sage/ - but so it the case for any file-based process...
>
>
>
> For example, what if someone uses tmpreaper or something similar,
> when old files are removed from /tmp? Sage does not notice it, but
> things break in a weird way, e.g. plots are not displayed and the
> error message is not transparent.
> >
> > I believe this is exactly what is happening and I would appreciate some 
> attention to this matter ;-)
> >
> > Thank you!
> > Andrey
> >
> > --
> > 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/5ee63ec7-26b2-4c32-a5a7-45fb63a11327n%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/bcfa5eaa-600b-4752-8b52-189422564a49n%40googlegroups.com.

[sage-devel] Re: Temporary files problems

[John H Palmieri]

See also 
https://ask.sagemath.org/question/64192/temporary-html-files-location-in-sage-97/
 
— some browsers can't access local files in /tmp from the notebook, so 
plots do not appear. Perhaps TMP_DIR_FILENAME_BASE could be customizable. 
Other options?

On Monday, September 26, 2022 at 7:58:01 PM UTC-7 novo...@gmail.com wrote:

> Hello!
>
> I've run into this while testing upgrades to Ubuntu 22.04 from 20.04, but 
> it seems that it comes from how temporary files are handled in Sage 9.7:
>
> TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory()
>
> this temporary directory is created and then used ever after. But what if 
> it gets deleted? For example, what if someone uses tmpreaper or something 
> similar, when old files are removed from /tmp? Sage does not notice it, but 
> things break in a weird way, e.g. plots are not displayed and the error 
> message is not transparent.
>
> I believe this is exactly what is happening and I would appreciate some 
> attention to this matter ;-)
>
> Thank you!
> Andrey
>

-- 
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/77b4298e-9810-4432-8e4c-22d1934be009n%40googlegroups.com.

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

[John H Palmieri]

Will the changeover also mark Sage 10.0? Is there a vision for what Sage 
10.0 means?

On Saturday, September 24, 2022 at 8:48:15 PM UTC-7 Matthias Koeppe wrote:

> I've added this to 
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#conversion-of-trac-tickets-and-the-trac-wiki-to-github
>  
> now
>
> On Saturday, September 24, 2022 at 5:46:15 PM UTC-7 Matthias Koeppe wrote:
>
>> On Saturday, September 24, 2022 at 5:15:11 PM UTC-7 John H Palmieri wrote:
>>
>>> I think I'm missing part of this. What is the actual path to switching 
>>> to GitHub? I've seen pages describing how individual development tasks will 
>>> be converted from trac to GitHub, but what does the overall transition look 
>>> like?
>>>
>>> - Do we just say, before November 1 (or whenever) we're doing everything 
>>> on trac, and after we're doing everything on GitHub?
>>>
>>
>> Yes, exactly (although we have not discussed the date yet).
>>
>> On the switchover day, it would look like this: 
>> 1. We take Trac offline, reconfigure it to be read-only, bring it online.
>> 2. Convert all tickets to Issues in a new repo. (This preserves the 
>> ticket numbers as Issue numbers.)
>> 3. Final check that the new repo is OK.
>> 4. Replace sagemath/sage by the new repo.
>> 5. Announce that sagemath/sage is now open for Issues and PRs.
>>
>>
>>

-- 
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/76dfd93f-e254-46e1-b86b-988e1ff88c60n%40googlegroups.com.

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

[John H Palmieri]

I think I'm missing part of this. What is the actual path to switching to 
GitHub? I've seen pages describing how individual development tasks will be 
converted from trac to GitHub, but what does the overall transition look 
like?

- Do we just say, before November 1 (or whenever) we're doing everything on 
trac, and after we're doing everything on GitHub?
- Or is there a period where both are active and people can slowly 
transition? We have a GitHub page now; if the transition is approved, do 
people start creating issues and pull requests right away?
- Or some other option?

I apologize if this has been discussed and I missed it.

On Saturday, September 24, 2022 at 10:09:46 AM UTC-7 Matthias Koeppe wrote:

> On Saturday, September 24, 2022 at 9:27:46 AM UTC-7 mathzeta2 wrote:
>
>> Is it possible to choose the issue numbers in GH when making a migration? 
>> Then, setting a redirect of the form "
>> https://trac.sagemath.org/ticket/$TICKET_NUMBER -> 
>> https://github.com/sagemath/sage/issues/$TICKET_NUMBER; will make the 
>> lion's share of the links still relevant.
>>
>
> Yes, to map it like this is the plan.
>  
>
>> This does not preserve fragments like "#comment:7", which is useful in 
>> long ticket discussions.
>>
>
> Thanks, I've opened https://github.com/sagemath/trac-to-github/issues/7 
> for this.
>
>
>

-- 
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/9b4a5765-c00c-456e-bb11-67dbad37e19an%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[John H Palmieri]

On Sunday, September 18, 2022 at 2:55:34 PM UTC-7 dim...@gmail.com wrote:

>
>
> On Sun, 18 Sep 2022, 22:44 John H Palmieri,  wrote:
>
>> William, this is exactly why I search in the sage-trac Google group 
>> rather than on the trac website. 
>
>
> it's looks easy to set up posting of issues/comments to a google group.
>
> The sage-trac group is also good for browsing to see recent activity.
>>
>
> for recent activities there are GitHub tools, probably more suitable for 
> such a tack.
>

Great! Is there any information on this on the migration plan? I didn't see 
anything at a quick glance.


>
>> On Sunday, September 18, 2022 at 11:12:59 AM UTC-7 wst...@gmail.com 
>> wrote:
>>
>>> On Sun, Sep 18, 2022 at 10:27 AM Matthias Koeppe 
>>>  wrote: 
>>> > 
>>> > On Sunday, September 18, 2022 at 10:14:26 AM UTC-7 Nils Bruin wrote: 
>>> >> 
>>> >> On Saturday, 17 September 2022 at 17:55:10 UTC-7 Matthias Koeppe 
>>> wrote: 
>>> >>> 
>>> >>> 
>>> >>> The conversion of the Trac tickets to GitHub Issues/PRs only works 
>>> in one shot. Incrementally syncing updates from Trac to existing issues is 
>>> not possible. 
>>> >> 
>>> >> 
>>> >> Migration *to* GH is one thing, but as has been pointed out, we 
>>> should have an exit strategy as well, or at least an idea of a roadmap to 
>>> move from github to elsewhere. The code itself is trivial to move: it's a 
>>> git repo. However, as has been shown in the past, the discussions (now in 
>>> tickets on trac, but if moved in issues and PRs) can sometimes be of 
>>> immense value as well. I suppose that if moving from GH to GL is as trivial 
>>> as claimed before, GH must have a way of exporting issues and PRs. 
>>> >> 
>>> >> Would someone be able to give an informed assessment or a feasibility 
>>> study of extracting issues and PRs from GH? How searchable are they and how 
>>> do cross-links survive an extraction (also important for trac-to-GH)? 
>>> Presently, trac is fairly searchable due to its own search functions plus 
>>> its general indexing by google's search engine. Hopefully we'd have 
>>> something at least matching that for GH. 
>>> >> 
>>> >> Perhaps part of our setup should also be that we "backup" this part 
>>> of our github setup: githubs own infrastructure is of course excellently 
>>> resilient against technological problems but a new failure mode is 
>>> introduced due to their governance and policy: in the extremely unlikely 
>>> event that sagemath on GH would get "locked" due to a misunderstanding (or 
>>> malice?) we might not be at their mercy for extracting our valuable 
>>> history. 
>>> > 
>>> > 
>>> > I agree that it would be valuable to add at least some starting points 
>>> in this direction. 
>>> > As a beginning, I have created the section: 
>>> > 
>>> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#retrieving-data-from-github
>>>  
>>> > to include the link https://docs.github.com/en/rest to GitHub's REST 
>>> API, which gives access to everything and is extremely well documented. 
>>>
>>> I used this GitHub REST API a lot recently to implement proxying of 
>>> content from GitHub to CoCalc, and it is indeed *extremely* good. 
>>>
>>> This is a 3 minute video demoing importing github repos to gitlab, 
>>> which emphasizes answers to a lot of natural frequent questions 
>>> (involving users, issue comments, labels, etc.): 
>>>
>>> https://www.youtube.com/watch?v=VYOXuOg9tQI 
>>>
>>> In my experience, the search built into GitHub is at least 10x (or 
>>> maybe 100x?) faster than our trac search, e.g., try searching 
>>> https://trac.sagemath.org/search versus 
>>> https://github.com/python/cpython/issues . In addition GitHub's 
>>> advanced search capabilities are useful (in terms of sorting, refining 
>>> queries, querying by label, etc.). 
>>>
>>>
>>> -- 
>>> 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+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/02f5020e-7c69-4be3-a277-cf5b47fb635bn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/02f5020e-7c69-4be3-a277-cf5b47fb635bn%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/d2532c0b-528c-4bfb-a1d6-160cfb3671d5n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[John H Palmieri]

William, this is exactly why I search in the sage-trac Google group rather 
than on the trac website. The sage-trac group is also good for browsing to 
see recent activity.

On Sunday, September 18, 2022 at 11:12:59 AM UTC-7 wst...@gmail.com wrote:

> On Sun, Sep 18, 2022 at 10:27 AM Matthias Koeppe
>  wrote:
> >
> > On Sunday, September 18, 2022 at 10:14:26 AM UTC-7 Nils Bruin wrote:
> >>
> >> On Saturday, 17 September 2022 at 17:55:10 UTC-7 Matthias Koeppe wrote:
> >>>
> >>>
> >>> The conversion of the Trac tickets to GitHub Issues/PRs only works in 
> one shot. Incrementally syncing updates from Trac to existing issues is not 
> possible.
> >>
> >>
> >> Migration *to* GH is one thing, but as has been pointed out, we should 
> have an exit strategy as well, or at least an idea of a roadmap to move 
> from github to elsewhere. The code itself is trivial to move: it's a git 
> repo. However, as has been shown in the past, the discussions (now in 
> tickets on trac, but if moved in issues and PRs) can sometimes be of 
> immense value as well. I suppose that if moving from GH to GL is as trivial 
> as claimed before, GH must have a way of exporting issues and PRs.
> >>
> >> Would someone be able to give an informed assessment or a feasibility 
> study of extracting issues and PRs from GH? How searchable are they and how 
> do cross-links survive an extraction (also important for trac-to-GH)? 
> Presently, trac is fairly searchable due to its own search functions plus 
> its general indexing by google's search engine. Hopefully we'd have 
> something at least matching that for GH.
> >>
> >> Perhaps part of our setup should also be that we "backup" this part of 
> our github setup: githubs own infrastructure is of course excellently 
> resilient against technological problems but a new failure mode is 
> introduced due to their governance and policy: in the extremely unlikely 
> event that sagemath on GH would get "locked" due to a misunderstanding (or 
> malice?) we might not be at their mercy for extracting our valuable history.
> >
> >
> > I agree that it would be valuable to add at least some starting points 
> in this direction.
> > As a beginning, I have created the section:
> > 
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#retrieving-data-from-github
> > to include the link https://docs.github.com/en/rest to GitHub's REST 
> API, which gives access to everything and is extremely well documented.
>
> I used this GitHub REST API a lot recently to implement proxying of
> content from GitHub to CoCalc, and it is indeed *extremely* good.
>
> This is a 3 minute video demoing importing github repos to gitlab,
> which emphasizes answers to a lot of natural frequent questions
> (involving users, issue comments, labels, etc.):
>
> https://www.youtube.com/watch?v=VYOXuOg9tQI
>
> In my experience, the search built into GitHub is at least 10x (or
> maybe 100x?) faster than our trac search, e.g., try searching
> https://trac.sagemath.org/search versus
> https://github.com/python/cpython/issues . In addition GitHub's
> advanced search capabilities are useful (in terms of sorting, refining
> queries, querying by label, etc.).
>
>
> -- 
> 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/02f5020e-7c69-4be3-a277-cf5b47fb635bn%40googlegroups.com.