[sage-devel] Re: CI Is (Generally) Broken

[Travis Scrimshaw]

Also, it has sometimes happened the CI is not correctly pulling in the 
changed files. This occurred specifically for a py -> pyx file change.

Best,
Travis

On Thursday, May 16, 2024 at 10:01:45 AM UTC+9 Travis Scrimshaw wrote:

> As the title says. Most PRs I see end up with this initial build failure:
>
> Run export MAKE="make -j2 --output-sync=recurse" SAGE_NUM_THREADS=4 
> + cd /sage 
> + export 'MAKE=make -j2 --output-sync=recurse' SAGE_NUM_THREADS=4 
> + MAKE='make -j2 --output-sync=recurse' 
> + SAGE_NUM_THREADS=4 
> + ./sage -t --new -p4 
> no stored timings available 
> Running doctests with ID 2024-05-16-00-35-14-3cd651fa. 
> Running with SAGE_LOCAL='/sage/local' and 
> SAGE_VENV='/sage/local/var/lib/sage/venv-python3.10' 
> Using 
> --optional=bliss,coxeter3,debian,mcqd,meataxe,pip,sage,sage_spkg,sirocco,tdlib
>  
>
> Features to be detected: 
> 4ti2,SAGE_SRC,benzene,bliss,buckygen,conway_polynomials,csdp,cvxopt,cvxopt,database_cremona_ellcurve,database_cremona_mini_ellcurve,database_cubic_hecke,database_ellcurves,database_graphs,database_jones_numfield,database_knotinfo,dvipng,ecm,fpylll,fricas,gap_package_atlasrep,gap_package_design,gap_package_grape,gap_package_guava,gap_package_hap,gap_package_polycyclic,gap_package_qpa,gap_package_quagroup,gfan,graphviz,imagemagick,ipython,jmol,jupymake,kenzo,latte_int,lrcalc_python,lrslib,matroid_database,mcqd,meataxe,mpmath,msolve,nauty,networkx,numpy,palp,pandoc,pdf2svg,pdftocairo,pexpect,phitigra,pillow,plantri,polytopes_db,polytopes_db_4d,pplpy,primecountpy,ptyprocess,pynormaliz,pyparsing,python_igraph,requests,rubiks,sage.combinat,sage.geometry.polyhedron,sage.graphs,sage.groups,sage.libs.braiding,sage.libs.ecl,sage.libs.flint,sage.libs.gap,sage.libs.linbox,sage.libs.m4ri,sage.libs.ntl,sage.libs.pari,sage.libs.singular,sage.misc.cython,sage.modular,sage.modules,sage.numerical.mip,sage.plot,sage.rings.complex_double,sage.rings.finite_rings,sage.rings.function_field,sage.rings.number_field,sage.rings.padics,sage.rings.polynomial.pbori,sage.rings.real_double,sage.rings.real_mpfr,sage.sat,sage.schemes,sage.symbolic,sage_numerical_backends_coin,sagemath_doc_html,scipy,singular,sphinx,symengine_py,sympy,tdlib,threejs
>  
>
> fatal: not a git repository: /new/.git/worktrees/worktree-image 
> Doctesting files changed since last git commit 
> Traceback (most recent call last): 
> File "/sage/src/bin/sage-runtests", line 166, in  
> err = DC.run() 
> File "/sage/src/sage/doctest/control.py", line 1571, in run 
> self.add_files() 
> File "/sage/src/sage/doctest/control.py", line 932, in add_files 
> change = subprocess.check_output(["git", 
> File "/usr/lib/python3.10/subprocess.py", line 421, in check_output 
> return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 
> File "/usr/lib/python3.10/subprocess.py", line 526, in run 
> raise CalledProcessError(retcode, process.args, 
> subprocess.CalledProcessError: Command '['git', '--git-dir=/sage/.git', 
> '--work-tree=/sage', 'status', '--porcelain']' returned non-zero exit 
> status 128. 
> Error: Process completed with exit code 1.
>
> Previously, this was rare, but now it seems to be very common.
>
> Also, when there is a docbuild failure, the output is completely useless. 
> I can't even find what files are causing the failure, much less what the 
> reason for the failure was. (The cryptic sphinx errors were at least 
> marginally helpful for this.) However, this is unrelated to the main issue 
> above.
>
> Best,
> Travis
>
>

-- 
You received this message because you are subscribed 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/66d4247b-12b2-495b-9e08-b3024c10bb3fn%40googlegroups.com.

[sage-devel] CI Is (Generally) Broken

[Travis Scrimshaw]

As the title says. Most PRs I see end up with this initial build failure:

Run export MAKE="make -j2 --output-sync=recurse" SAGE_NUM_THREADS=4 
+ cd /sage 
+ export 'MAKE=make -j2 --output-sync=recurse' SAGE_NUM_THREADS=4 
+ MAKE='make -j2 --output-sync=recurse' 
+ SAGE_NUM_THREADS=4 
+ ./sage -t --new -p4 
no stored timings available 
Running doctests with ID 2024-05-16-00-35-14-3cd651fa. 
Running with SAGE_LOCAL='/sage/local' and 
SAGE_VENV='/sage/local/var/lib/sage/venv-python3.10' 
Using 
--optional=bliss,coxeter3,debian,mcqd,meataxe,pip,sage,sage_spkg,sirocco,tdlib 

Features to be detected: 
4ti2,SAGE_SRC,benzene,bliss,buckygen,conway_polynomials,csdp,cvxopt,cvxopt,database_cremona_ellcurve,database_cremona_mini_ellcurve,database_cubic_hecke,database_ellcurves,database_graphs,database_jones_numfield,database_knotinfo,dvipng,ecm,fpylll,fricas,gap_package_atlasrep,gap_package_design,gap_package_grape,gap_package_guava,gap_package_hap,gap_package_polycyclic,gap_package_qpa,gap_package_quagroup,gfan,graphviz,imagemagick,ipython,jmol,jupymake,kenzo,latte_int,lrcalc_python,lrslib,matroid_database,mcqd,meataxe,mpmath,msolve,nauty,networkx,numpy,palp,pandoc,pdf2svg,pdftocairo,pexpect,phitigra,pillow,plantri,polytopes_db,polytopes_db_4d,pplpy,primecountpy,ptyprocess,pynormaliz,pyparsing,python_igraph,requests,rubiks,sage.combinat,sage.geometry.polyhedron,sage.graphs,sage.groups,sage.libs.braiding,sage.libs.ecl,sage.libs.flint,sage.libs.gap,sage.libs.linbox,sage.libs.m4ri,sage.libs.ntl,sage.libs.pari,sage.libs.singular,sage.misc.cython,sage.modular,sage.modules,sage.numerical.mip,sage.plot,sage.rings.complex_double,sage.rings.finite_rings,sage.rings.function_field,sage.rings.number_field,sage.rings.padics,sage.rings.polynomial.pbori,sage.rings.real_double,sage.rings.real_mpfr,sage.sat,sage.schemes,sage.symbolic,sage_numerical_backends_coin,sagemath_doc_html,scipy,singular,sphinx,symengine_py,sympy,tdlib,threejs
 

fatal: not a git repository: /new/.git/worktrees/worktree-image 
Doctesting files changed since last git commit 
Traceback (most recent call last): 
File "/sage/src/bin/sage-runtests", line 166, in  
err = DC.run() 
File "/sage/src/sage/doctest/control.py", line 1571, in run 
self.add_files() 
File "/sage/src/sage/doctest/control.py", line 932, in add_files 
change = subprocess.check_output(["git", 
File "/usr/lib/python3.10/subprocess.py", line 421, in check_output 
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 
File "/usr/lib/python3.10/subprocess.py", line 526, in run 
raise CalledProcessError(retcode, process.args, 
subprocess.CalledProcessError: Command '['git', '--git-dir=/sage/.git', 
'--work-tree=/sage', 'status', '--porcelain']' returned non-zero exit 
status 128. 
Error: Process completed with exit code 1.

Previously, this was rare, but now it seems to be very common.

Also, when there is a docbuild failure, the output is completely useless. I 
can't even find what files are causing the failure, much less what the 
reason for the failure was. (The cryptic sphinx errors were at least 
marginally helpful for this.) However, this is unrelated to the main issue 
above.

Best,
Travis

-- 
You received this message because you are subscribed 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/fbb0af54-0a53-40e5-be00-732a5f0640can%40googlegroups.com.

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

[Travis Scrimshaw]

On Tuesday, May 14, 2024 at 9:48:32 AM UTC+9 Matthias Koeppe wrote:

On Sunday, May 12, 2024 at 6:50:05 PM UTC-7 Travis Scrimshaw wrote:

That model is not how we have worked as a community, nor do I think it is a 
productive way to run a smaller developer community such as ours.


I'm not sure what your reference point may be for this description, but in 
my experience it has not been remotely like this ever since I started 
contributing to Sage (2015). The project's infrastructure (in the past, for 
example Trac or the patchbot) has been run by volunteer administrators; the 
wiki page https://github.com/sagemath/sage/wiki/Infrastructure is intended 
to keep track of it (though much info is likely outdated), and there is a 
closed mailing list "sagemath-admins" for those involved. 


Maintaining the infrastructure, yes. However, the way it interacts with the 
developers and the things that are forced upon the developers. Things that 
affect everyone have traditionally gotten at least a post on sage-devel 
notifying about the change before it is accepted, with potentially an 
exception for those from our BDFL. The issue at hand is not some background 
maintenance or something that can be ignored if desired.

To this point, I cannot (effectively) disable it because the bot 
automatically is adding it every time a change occurs.


Perhaps a good reference: 
https://www.redhat.com/en/blog/understanding-open-source-governance-models

That's not relevant to how we do things. You could argue that we should 
follow one of those, but that is separate.

Best,
Travis

-- 
You received this message because you are subscribed 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/f214cb55-f5e1-4018-a8e1-d487874f7649n%40googlegroups.com.

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

[Travis Scrimshaw]

That model is not how we have worked as a community, nor do I think it is a 
productive way to run a smaller developer community such as ours. Doing 
things that way gives me a "all animals are equal, but some animals are 
more equal than others" feeling.

If you want to deploy things quickly, make them optional that those who 
want to use them can try them out to gain experience. If it is useful, then 
people will naturally take it up and want it to be standard. However, I 
still want this removed outright from the experience I already have from 
seeing it, and I see no way to gain any benefits. At the very least, can we 
agree to not make these labels automatically added. Let those who want to 
use them use them to see if people find a benefit to them.

Travis


On Friday, May 10, 2024 at 11:02:19 PM UTC+9 Matthias Koeppe wrote:

> FWIW, I suggested to implement this feature in 
> https://github.com/sagemath/sage/issues/37254; I'm thankful to Aman Moon 
> for implementing this feature and Sebastian Oehms for his help with it. 
>
> Obviously a metric such as the number of lines of changes is only a 
> one-dimensional way to express the complexity of a PR. 
> When I suggested the feature, I explained the possible positive effects:
> - A size label "tiny" could encourage quick reviews of trivial changes.
> - A size label "huge" could help flag problematic PRs.
> Personally I think that the size labels for "medium-sized" PRs do not add 
> much and could be removed.
>
> But I'll note that "developer experience" improvements like this one are 
> really best developed exactly as it was done here: By deploying them early, 
> the developer community can gain concrete experience with them -- and then 
> suggest and implement refinements based on the experience. Harsh dismissals 
> of the whole features, on the other hand, are not very helpful.
>
> Matthias
>
> On Thursday, May 9, 2024 at 2:46:17 PM UTC-7 Travis Scrimshaw wrote:
>
>> I am *very* strongly opposed to these tags. Their cutoffs are arbitrary 
>> nor they serve no useful purpose as far as I can tell. To this point, they 
>> do not reflect the difficulty of a review; in fact, they are at best 
>> counterproductive to finding reviewers because it might deter people from 
>> reviewing "large" or "huge" changes as they can include lots of trivial 
>> doctest changes. At best it is just additional clutter in all of the 
>> information for PRs.
>>
>> From a community perspective, I feel such changes should have been 
>> brought to the attention of sage-devel once the PR was at a positive 
>> review. Specifically, *before* the PR was merged. Not everyone has time 
>> to read every PR, and a small consensus of developers might not reflect the 
>> development community at-large when making changes like this.
>>
>> Best,
>> Travis
>>
>>
>> On Tuesday, May 7, 2024 at 3:12:27 PM UTC+9 seb@gmail.com wrote:
>>
>>> Dear Sage developers,
>>>
>>> You may have noticed that since yesterday a new type of labels with the 
>>> `v:` prefix has appeared on our PRs. These are automatically set to 
>>> classify PRs based on their size. For more information, see #37262 
>>> <https://github.com/sagemath/sage/pull/37262>.
>>>
>>> Sebastian
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/85cc0f0f-e719-45ec-95fa-012906a3567dn%40googlegroups.com.

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

[Travis Scrimshaw]

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

>From a community perspective, I feel such changes should have been brought 
to the attention of sage-devel once the PR was at a positive review. 
Specifically, *before* the PR was merged. Not everyone has time to read 
every PR, and a small consensus of developers might not reflect the 
development community at-large when making changes like this.

Best,
Travis


On Tuesday, May 7, 2024 at 3:12:27 PM UTC+9 seb@gmail.com wrote:

> Dear Sage developers,
>
> You may have noticed that since yesterday a new type of labels with the 
> `v:` prefix has appeared on our PRs. These are automatically set to 
> classify PRs based on their size. For more information, see #37262 
> .
>
> Sebastian
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a1904934-a31f-4ce0-83c2-76cf2d1a70f1n%40googlegroups.com.

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

[Travis Scrimshaw]

+1 for merging #37796.

Volker, I would appreciate if you could say something about how #36964 was 
merged. It would be useful to understand the process with merging this, 
rather than guessing the intent. Additionally, I thought we didn't merge 
things when the dependencies have not been merged (or merged 
simultaneously)? (This is why I am voting for reverting.)

Best,
Travis

On Friday, April 19, 2024 at 9:57:25 AM UTC+9 G. M.-S. wrote:

>
> -1
>
> If something has been done that should be undone, I very much trust Volker 
> to take care of it when he can, without the need for endless time-consuming 
> discussions and votes.
>
> Best,
>
> Guillermo
>
> On Thu, 18 Apr 2024 at 17:54, David Roe  wrote:
>
>> Hi all,
>> Sage has had a review process for over 15 years, but a combination of 
>> recent changes has led to the merging of a PR into sage-10.4.beta3 of a 
>> change (#36964 ) that I 
>> believe should not (yet) have been merged.  In #37796 
>>  I created a PR to revert 
>> the change, which was opposed by the author of the original change.  After 
>> some 
>> voting 
>>  
>> using the disputed PR policy 
>> , 
>> Matthias has asked 
>>  
>> for a vote on sage-devel about this reversion, in accordance with the 
>> section that "This process is intended as a lower-intensity method for 
>> resolving disagreements, and full votes on sage-devel override the process 
>> described below."  I am therefore asking you to vote (+1 means merge 
>> #37796  in order to revert 
>> #36964 ).
>>
>> First, here are the relevant parts of the history of this particular 
>> change:
>>
>> - #36964  was created on 
>> December 25 by Matthias, positively reviewed 
>>  
>> by Kwankyu on Decemebr 27, disputed, received enough votes 
>>  to 
>> get a positive review on April 7, and was merged 
>>  by 
>> Volker on April 12.  It had dependencies: #37667, 
>> #36951 
>> , and #36676 
>> .  While #37667 
>>  had positive review and 
>> was already been merged, the other two were still disputed: they had 
>> received an initial positive review but others objected and discussion was 
>> ongoing.
>>
>> - #37667  is not disputed.
>>
>> - #36951  was created on 
>> December 23 by Matthias, positively reviewed 
>>  
>> by Kwankyu on January 1, disputed, received enough votes 
>>  
>> (3-1) to change to positive review on April 7, had a clarification to bring 
>> back to (3-2) and remove positive review, then was included in the merge of 
>> #36964 . On April 13, John 
>> Palmieri voted in favor 
>> , 
>> so the current vote stands at 4-2, enough for the 2-1 threshold in order to 
>> get positive review under the disputed voting process.
>>
>> - #36676  was created on 
>> November 8 by Matthias, positively reviewed 
>>  by 
>> John Palmieri on November 15, and then disputed.  The most recent count was 
>> 6-4 
>> in favor 
>>  
>> (falling short of the 2-1 ratio needed under the disputed voting process); 
>> since then I voted 
>>  in 
>> favor, it was included in the merge of #36964 
>> , and then Martin voted 
>> against.
>>
>> At issue is the PR #36676 , 
>> where discussion was still ongoing when #36964 
>>  was merged.  The reversion 
>> of this PR proposed is purely for process reasons (I voted in favor of 
>> #36676  before all this 
>> happened!).  The 5 Sage developers opposed to #36676 
>>  deserve to have our 

[sage-devel] Re: UniqueRepresentation MRO Question

[Travis Scrimshaw]

Dear Enrique,
   No, that would just duplicate functionality and make things more 
complicated.

To Cython and/or Python experts,
   It would be great if someone could give some comments about this. This 
feels like a very natural thing to do, but it might lead to a very subtle 
breakage in the wild. If there is anything additional I can provide, please 
just ask.

Thank you,
Travis

On Monday, March 18, 2024 at 1:15:18 AM UTC+9 enriqu...@gmail.com wrote:

> Is there any sense to define a new class of UniqueRepresentation with the 
> same characteristics and  other name with the switch of order?  
>
> El miércoles, 13 de marzo de 2024 a las 16:58:49 UTC+1, Travis Scrimshaw 
> escribió:
>
>> Hi everyone,
>>On https://github.com/sagemath/sage/pull/37128, we find it useful to 
>> swap the order of the base classes for UniqueRepresentation. Thus, it 
>> becomes
>>
>> class UniqueRepresentation(WithEqualityById, CachedRepresentation):
>>
>> I believe this is very reasonable since we want to have objects' 
>> (typically parents, but not limited to them) comparison and hashing be 
>> first in the MRO. In particular, this is important if we have the following 
>> setup:
>>
>> class Foo(CachedRepresentation):
>> pass
>>
>> class Bar(UniqueRepresentation, Foo):
>> pass
>>
>> That way Bar gets the main benefits of being a UR (fast equality and 
>> hashing). With the current way, there is no way (that I know) to simply 
>> have the corresponding methods at the Cython level (at best, there is a 
>> Python redirect that has to be manually implemented) since WithEqualityById 
>> is a Cython cdef class.
>>
>> However, we then have a problem with unpickling, but I suspect it is a 
>> bigger issue. From combinat/root_system/cartan_type.py, the last line fails 
>> with an incompatible class order:
>>
>> sage: pg_CartanType_simple_finite = 
>> unpickle_global('sage.combinat.root_system.cartan_type', 
>> 'CartanType_simple_finite')
>> sage: si1 = unpickle_newobj(pg_CartanType_simple_finite, ())
>> sage: from sage.misc.fpickle import unpickleModule
>> sage: pg_make_integer = unpickle_global('sage.rings.integer', 
>> 'make_integer')
>> sage: si2 = pg_make_integer('4')
>> sage: unpickle_build(si1, 
>> {'tools':unpickleModule('sage.combinat.root_system.type_A'), 't':['A', 
>> si2], 'letter':'A', 'n':si2})
>>
>> Mainly, the last line does a self.__class__ = UR.__class__, where UR is 
>> an instance of a UniqueRepresentation. Granted, this is a very old pickle, 
>> but I am worried it isn't a problem with this specific pickle.
>>
>> This is beyond my knowledge of Cython. Any thoughts or advice about this 
>> issue would be appreciated.
>>
>> Thank you,
>> Travis
>>
>>

-- 
You received this message because you are subscribed 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/0966e7ed-6875-4e4a-89bc-eb043f3d9efbn%40googlegroups.com.

[sage-devel] UniqueRepresentation MRO Question

[Travis Scrimshaw]

Hi everyone,
   On https://github.com/sagemath/sage/pull/37128, we find it useful to 
swap the order of the base classes for UniqueRepresentation. Thus, it 
becomes

class UniqueRepresentation(WithEqualityById, CachedRepresentation):

I believe this is very reasonable since we want to have objects' (typically 
parents, but not limited to them) comparison and hashing be first in the 
MRO. In particular, this is important if we have the following setup:

class Foo(CachedRepresentation):
pass

class Bar(UniqueRepresentation, Foo):
pass

That way Bar gets the main benefits of being a UR (fast equality and 
hashing). With the current way, there is no way (that I know) to simply 
have the corresponding methods at the Cython level (at best, there is a 
Python redirect that has to be manually implemented) since WithEqualityById 
is a Cython cdef class.

However, we then have a problem with unpickling, but I suspect it is a 
bigger issue. From combinat/root_system/cartan_type.py, the last line fails 
with an incompatible class order:

sage: pg_CartanType_simple_finite = 
unpickle_global('sage.combinat.root_system.cartan_type', 
'CartanType_simple_finite')
sage: si1 = unpickle_newobj(pg_CartanType_simple_finite, ())
sage: from sage.misc.fpickle import unpickleModule
sage: pg_make_integer = unpickle_global('sage.rings.integer', 
'make_integer')
sage: si2 = pg_make_integer('4')
sage: unpickle_build(si1, 
{'tools':unpickleModule('sage.combinat.root_system.type_A'), 't':['A', 
si2], 'letter':'A', 'n':si2})

Mainly, the last line does a self.__class__ = UR.__class__, where UR is an 
instance of a UniqueRepresentation. Granted, this is a very old pickle, but 
I am worried it isn't a problem with this specific pickle.

This is beyond my knowledge of Cython. Any thoughts or advice about this 
issue would be appreciated.

Thank you,
Travis

-- 
You received this message because you are subscribed 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/5d3b6cdd-5253-405c-ae34-094870e15430n%40googlegroups.com.

Re: [sage-devel] Heun function support

[Travis Scrimshaw]

Not that I am aware, but it would make for a great (small) GSoC project: 
https://wiki.sagemath.org/GSoC/2024

Best,
Travis


On Sunday, March 10, 2024 at 5:52:09 PM UTC+9 Dima Pasechnik wrote:

>
>
> On 10 March 2024 05:24:31 GMT, Steve Dodge  wrote:
> >Hello, I was curious to know if there are any plans to include support 
> for Heun 
> >functions  in Sage, or if anyone knows of a 
> >reliable and well-documented implementation of them elsewhere.
>
> https://reference.wolfram.com/language/guide/HeunAndRelatedFunctions.html
>
> seem to describe an implementation
>
>
> I inquired 
> >on Zulip and David Roe suggest that I try asking here.
> >
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/69f44069-0172-41c3-bd60-deb2cf42c4f4n%40googlegroups.com.

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

[Travis Scrimshaw]

+1

On Monday, March 4, 2024 at 5:43:47 PM UTC+9 David Roe wrote:

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

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/59756d56-b8e0-4647-9e58-e5ac958bf141n%40googlegroups.com.

[sage-devel] Re: VOTE: disputed PRs

[Travis Scrimshaw]

Essentially +1

but might want to consider cases when its 2 vs 1 as requiring at least one 
other person involved. (Sorry for being late to realize this.)

Best,
Travis

On Monday, March 4, 2024 at 5:23:39 PM UTC+9 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/cbf5aad0-d826-4056-8093-a11a3d4b6e0bn%40googlegroups.com.

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

[Travis Scrimshaw]

Some quick data points:

- The general graded modules (and hence algebras) code raises an error for 
`0` since it is defined there by the direct summand the element belongs to 
(and `0` belongs to all of them.
- For polynomials, it is very useful to have a single check `f.degree() > 
k` for some `k`. Having error messages or check `f.is_zero()` first makes 
things more complicated.
- Comparisons of integers to `-infinity` is (relatively) expensive. 
Although this happening frequently seems unlikely.

Martin, note that Dima is calling degree with a min/max qualifier added in 
front. I think this is leading to some confusion and cross-talk. However, I 
think it is better to have easily separable terms "valuation" and "degree" 
(which exist for polynomials).

Best,
Travis

On Saturday, March 2, 2024 at 3:44:55 AM UTC+9 Martin R wrote:

> I don't get it - are my previous messages invisible?
>
> 1st Message: I don't understand - `degree` doesn't make much sense for 
> Laurent series - there is no way to determine the degree of a LaurentSeries 
> and no way to determine the degree of a LazyLaurentSeries with one minor 
> exception - which is when it is known that the series terminates, but 
> that's rare.
>
> 2nd Message: I am very much against this.  I realise that this is a 
> convention one uses in mathematics, but here it would be extremely 
> confusing: in the lazy series code we use valuation a lot, and it must mean 
> lowest degree, but we also use the degree of polynomials and Laurent 
> polynomials and we must distinguish between the two.
>
> I feel a bit ignored,
>
> Martin
>
>
> On Friday 1 March 2024 at 19:29:26 UTC+1 Giacomo Pope wrote:
>
> As an aside, the univariate LaurentPolynomialRing had a notion of 
> `valuation` but the multivariate one didn't...
>
> In the PR: https://github.com/sagemath/sage/pull/37490 I added random 
> elements but also a notion of valuation() for the multivariate case and 
> just made it act similarly to the univariate one.
>
> On Friday, March 1, 2024 at 6:18:01 PM UTC Nils Bruin wrote:
>
> On Friday 1 March 2024 at 09:49:15 UTC-8 Giacomo Pope wrote:
>
> Following this discussion, I have made a draft PR to change the degree for 
> *only* the LaurentPolynomialRing and I will see if the CI detects anything.
>
> https://github.com/sagemath/sage/pull/37513
>
> I agree that if we change the LaurentPolynomialRing we should also change 
> the `LaurentSeriesRing`, at the moment `LazyLaurentSeriesRing` has no 
> method `degree()` but *does* have a `valuation()` method... so this is odd.
>
>
> OK, let's keep it that way then! I don't think there is a notion on 
> LaurentSeriesRing that deserves the name "degree". Sorry about mixing that 
> one in. I thought it existed. And I think it does:
>
>  sage: R.=LaurentSeriesRing(QQ)
> sage: z=R(0)
> sage: z.valuation()
> +Infinity
> sage: z.degree()
> -1
>
> but if it's not documented, perhaps we can just ignore it.
>
>

-- 
You received this message because you are subscribed 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/6a9a6131-8c51-4760-9fad-897e220bfd1fn%40googlegroups.com.

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

[Travis Scrimshaw]

For me, big +1 on (mostly) decoupling (2) from the rest. I think Kwankyu's 
suggestion for blockers with positive review being added to all CIs is a 
good way to do this. I don't see much utility in doing this at any other 
stage.

Best,
Travis


On Tuesday, February 27, 2024 at 3:10:09 PM UTC+9 David Roe wrote:

> On Mon, Feb 26, 2024 at 8:06 PM 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.
>>
>
> I also agree that usage (2) should get a new name.  How about "CIFix?"
> David
>
>
>> 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+...@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
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed 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/11ac4c06-9ba4-46f4-b6fe-08cf1024a8c7n%40googlegroups.com.

[sage-devel] Re: int vs long in cython

[Travis Scrimshaw]

I am not sure it is purely about Python types since it gets changed into C 
code. (For reference, I changed your snippet to cpdef and got the same 
result too.)  It would be nice if there was an actual specification for 
this in Cython. I just get slightly worried after getting translated into C 
code, it then depends on the compiler. 

Anyways, such changes should be fine (this was my initial reaction too) 
except in perhaps very extraordinary circumstances...

Best,
Travis

On Monday, February 26, 2024 at 1:34:31 AM UTC+9 Nils Bruin wrote:

> Hi Travis,
>
> No, these routines are about the python types. They get used as `type(x) 
> is int` and `type(x) is long`. They are used in a different namespace from 
> `cdef int x` and `cdef long x` and cdef long long x` (well, the `x` is in 
> the cython object namespace. The C-types don't make it into the cython 
> object namespace. They are in a C type namespace).
>
>  The cython test routine above confirms that the objects `int` and `long` 
> (not the cdef type names!) are indeed the same object in cython
> The code below confirms they are the python `int` type object:
>
> sage: cython("""
> : def test(x):
> : return (x is long, x is int)
> : """)
> sage: test(int)
> (True, True)
> On Sunday 25 February 2024 at 01:48:09 UTC-8 Travis Scrimshaw wrote:
>
>> Sorry for the delayed response.
>>
>> If the C compiler can't tell the difference between an int and a long, 
>> then that suggests that there is still a difference. I am not sure that 
>> Cython has any specification that these are different. My understanding is 
>> Cython treats these as C types. Can we be certain that an int that is not a 
>> long will not find its way in? Could it also depend on someone's version of 
>> C/Python?
>>
>> Best,
>> Travis
>>
>>
>> On Thursday, February 22, 2024 at 2:52:25 PM UTC+9 Nils Bruin wrote:
>>
>>> I tried removal here:
>>> https://github.com/sagemath/sage/pull/37420
>>> and as expected it looks like it's working fine.
>>>
>>> On Wednesday 21 February 2024 at 19:06:50 UTC-8 Nils Bruin wrote:
>>>
>>>> well, I don't expect the C compiler to be smart enough to recognise the 
>>>> second is an "elif False:", so the "hurt" would be in additional code 
>>>> executed. Plus, having hidden "elif False:"s in a code base is a really 
>>>> bad 
>>>> code smell, so I think there is a penalty. What do you want to guard 
>>>> against? "int" and "long" becoming not synonyms in cython again? There 
>>>> will 
>>>> be probably other py2/3 relics in our code base. I think we should clean 
>>>> them up when encountered, unless we have a good reason not to.
>>>>
>>>> On Wednesday 21 February 2024 at 17:55:48 UTC-8 Travis Scrimshaw wrote:
>>>>
>>>>> I think so, but it might not hurt to have it.
>>>>>
>>>>> Best,
>>>>> Travis
>>>>>
>>>>> On Thursday, February 22, 2024 at 9:54:32 AM UTC+9 Nils Bruin wrote:
>>>>>
>>>>>> I noticed the following cython code
>>>>>>
>>>>>> if S is long:
>>>>>> return sage.rings.integer.long_to_Z()
>>>>>> elif S is int:
>>>>>> return sage.rings.integer.int_to_Z()
>>>>>>
>>>>>>
>>>>>> https://github.com/sagemath/sage/blob/30fecca1981087a88eb8db2cf05e18edbb50d16f/src/sage/rings/integer_ring.pyx#L589C1-L593C1
>>>>>>
>>>>>> However, in cython with python3 we now have:
>>>>>>
>>>>>> sage: cython("""
>>>>>> : def tst():
>>>>>> : return int is long
>>>>>> : """)
>>>>>> sage: tst()
>>>>>> True
>>>>>>
>>>>>> so I think the `elif` can be deleted. Is that correct?
>>>>>>
>>>>>

-- 
You received this message because you are subscribed 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/0f6ec32b-68ff-425b-81a7-05cc75e72013n%40googlegroups.com.

[sage-devel] Re: int vs long in cython

[Travis Scrimshaw]

Sorry for the delayed response.

If the C compiler can't tell the difference between an int and a long, then 
that suggests that there is still a difference. I am not sure that Cython 
has any specification that these are different. My understanding is Cython 
treats these as C types. Can we be certain that an int that is not a long 
will not find its way in? Could it also depend on someone's version of 
C/Python?

Best,
Travis


On Thursday, February 22, 2024 at 2:52:25 PM UTC+9 Nils Bruin wrote:

> I tried removal here:
> https://github.com/sagemath/sage/pull/37420
> and as expected it looks like it's working fine.
>
> On Wednesday 21 February 2024 at 19:06:50 UTC-8 Nils Bruin wrote:
>
>> well, I don't expect the C compiler to be smart enough to recognise the 
>> second is an "elif False:", so the "hurt" would be in additional code 
>> executed. Plus, having hidden "elif False:"s in a code base is a really bad 
>> code smell, so I think there is a penalty. What do you want to guard 
>> against? "int" and "long" becoming not synonyms in cython again? There will 
>> be probably other py2/3 relics in our code base. I think we should clean 
>> them up when encountered, unless we have a good reason not to.
>>
>> On Wednesday 21 February 2024 at 17:55:48 UTC-8 Travis Scrimshaw wrote:
>>
>>> I think so, but it might not hurt to have it.
>>>
>>> Best,
>>> Travis
>>>
>>> On Thursday, February 22, 2024 at 9:54:32 AM UTC+9 Nils Bruin wrote:
>>>
>>>> I noticed the following cython code
>>>>
>>>> if S is long:
>>>> return sage.rings.integer.long_to_Z()
>>>> elif S is int:
>>>> return sage.rings.integer.int_to_Z()
>>>>
>>>>
>>>> https://github.com/sagemath/sage/blob/30fecca1981087a88eb8db2cf05e18edbb50d16f/src/sage/rings/integer_ring.pyx#L589C1-L593C1
>>>>
>>>> However, in cython with python3 we now have:
>>>>
>>>> sage: cython("""
>>>> : def tst():
>>>> : return int is long
>>>> : """)
>>>> sage: tst()
>>>> True
>>>>
>>>> so I think the `elif` can be deleted. Is that correct?
>>>>
>>>

-- 
You received this message because you are subscribed 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/eaebfae5-b265-4519-95dc-a52b8b849314n%40googlegroups.com.

[sage-devel] SageMath GSoC 2024

[Travis Scrimshaw]

Hi everyone,
   SageMath has been accepted this year as a mentor organization for 
Google's Summer of Code (GSoC) 2024! You can find information regarding our 
proposed projects and information on how to apply available on

https://wiki.sagemath.org/GSoC/2024

There is still time if you want to propose a project that is not listed 
and/or if you would like to be a mentor for a project. Note that this year 
Google has 3 project lengths: small (90 hours), medium (175 hours), and 
large (350 hours).

The proposal submissions period is March 18 - April 2 (18:00 UTC). Please 
advertise to your students and other people who are new to open-source 
software if they are interested in contributing to SageMath.

Please let me know if you have any questions.

Best,
Travis

-- 
You received this message because you are subscribed 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/a78c6906-bf88-4fcf-9444-31d12df306fbn%40googlegroups.com.

[sage-devel] Re: int vs long in cython

[Travis Scrimshaw]

I think so, but it might not hurt to have it.

Best,
Travis

On Thursday, February 22, 2024 at 9:54:32 AM UTC+9 Nils Bruin wrote:

> I noticed the following cython code
>
> if S is long:
> return sage.rings.integer.long_to_Z()
> elif S is int:
> return sage.rings.integer.int_to_Z()
>
>
> https://github.com/sagemath/sage/blob/30fecca1981087a88eb8db2cf05e18edbb50d16f/src/sage/rings/integer_ring.pyx#L589C1-L593C1
>
> However, in cython with python3 we now have:
>
> sage: cython("""
> : def tst():
> : return int is long
> : """)
> sage: tst()
> True
>
> so I think the `elif` can be deleted. Is that correct?
>

-- 
You received this message because you are subscribed 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/e362d62d-975c-4654-8b19-db8c88778febn%40googlegroups.com.

[sage-devel] Re: feedback on construction functor for symmetric functions

['Travis Scrimshaw' via sage-devel]

Hi Martin,
   I plan to look closely at this this week. Unfortunately I cannot offer 
anything quick now.

Best,
Travis


On Monday, February 12, 2024 at 2:42:52 AM UTC+9 Martin R wrote:

> Apart from that, I think the last bit I need to do is to make the 
> TensorProductFunctor inherit from MultivariateConstructionFunctor, to make 
> coercion work for things like
>
> sage: h = SymmetricFunctions(ZZ).h()
> sage: T = tensor([h, h])
> sage: T.base_ring()
> Integer Ring
> sage: 1/2*T.an_element()
>
> (which currently raises TypeError: unsupported operand parent(s) for *: 
> 'Rational Field' and 'Symmetric Functions over Integer Ring in the 
> homogeneous basis # Symmetric Functions over Integer Ring in the 
> homogeneous basis')
>
> Am I on the right track?
>
> Martin
> On Sunday 11 February 2024 at 12:34:44 UTC+1 Martin R wrote:
>
>> At https://github.com/sagemath/sage/pull/37220, I implemented a (simple 
>> minded) construction functor for symmetric functions.
>>
>> The only major user visible change should be that
>>
>> sage: sZ = SymmetricFunctions(ZZ).s()
>> sage: sQ = SymmetricFunctions(QQ).s()
>> sage: sZ[1,1] + sQ[2]
>> s[1,1] + s[2]
>>
>> now works.  This, and a little bit more, is what I need for my lazy 
>> symmetric functions project.
>>
>> Under the hood, the pull request replaces `corresponding_basis_over` with 
>> a proper construction functor which, however, follows the same spirit: 
>> every basis of symmetric functions has to provide a description on how to 
>> create it, by storing the appropriate method names.
>>
>> There is a todo note by Darij Grinberg from 2013 that this is an ugly 
>> hack, and I agree, but nobody came up with anything better in the last 11 
>> years, so we might as well go with the idea which is working, at least for 
>> the moment.
>>
>> There is one more uglyness I have to mention: I describe the functor as a 
>> functor on the category of commutative rings, which is not true in 
>> general.  For example, for Macdonald polynomials, the functor really is 
>> from the category of commutative rings with two distinguished elements.  I 
>> am guessing that creating a category RingsWithDistinguishedElements is a 
>> bit much, and I wouldn't know how to do it.
>>
>> Comments (and, of course, also a review) would be greatly appreciated!
>>
>> Martin
>>
>

-- 
You received this message because you are subscribed 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/5f537ee8-c7a1-4199-bfcd-341336fd293bn%40googlegroups.com.

[sage-devel] Re: morphisms between multivariate polynomial rings

['Travis Scrimshaw' via sage-devel]

Hi Martin,
   That is coming from this:

sage: type(m)


Although I don't think we have a specific "all morphisms should inherit 
from this ABC (or generic base class)" specification. It might be easy to 
get something to work for it.

Are you thinking of the difficulty of determining a consistent way of 
setting coercions between polynomial rings? That's the only thing I know 
that is problematic.

Best,
Travis
On Sunday, February 11, 2024 at 1:08:43 AM UTC+9 Martin R wrote:

> I was a bit surprised about the following:
>
> sage: k = ZZ["q"].hom(QQ["q"])
> sage: isinstance(k, Morphism)
> True
> sage: m = ZZ["q,t"].hom(QQ["q,t"])
> sage: isinstance(m, Morphism)
> False
>
> However, I vaguely recall a discussion about morphisms between 
> multivariate polynomial rings being problematic.  Does my memory trick me?
>
> Martin
>
>

-- 
You received this message because you are subscribed 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/9e2d9d6c-042c-40cf-9871-ff2f7e7647a7n%40googlegroups.com.

[sage-devel] Re: Google Summer of Code: Organization application deadline Feb 6!

['Travis Scrimshaw' via sage-devel]

Miguel, can you add the project to the wiki page (or tell me the 
information here), even if it is not fully prepared? It will help increase 
our chances of being selected for GSoC again.

For everyone, there is a new 90 hour option for GSoC project lengths this 
year.

Best,
Travis

On Monday, February 12, 2024 at 3:36:12 AM UTC+9 Matthias Koeppe wrote:

> On Sunday, February 11, 2024 at 7:10:59 AM UTC-8 mmarco wrote:
>
> if i understand what you mean correctly, 1) would go along making it 
> easier from the sage part to implement tactics like polyrith (which right 
> now calls the sagecell server to prove equalities between expressions using 
> groebner basis)?
>
>
> Yes. 
>  
>
> In particular I would like to not depend on an internet connection, and an 
> online service, to do that kind of thing.
>
>
> Exactly, which is another motivation for improving the usability of Sage 
> as a library (-> modularization, pip-installability).
>  
>
> Are there other cases where similar things could be done (that is, 
> concrete computations in Sagemath that could be used as certificates for 
> Lean proofs)?
>
>  
> Yes, this is natural and well understood in polyhedral geometry (where 
> Sage has excellent facilities), linear optimization (where Sage has 
> reasonable interfaces) and its extensions, and graph theory / algebraic 
> topology. 
> More generally, the prospect of uses in Lean could inspire developing a 
> style of computation in Sage where not only an answer is computed but also 
> (ideally at low extra cost) a certificate that allows users to check the 
> answer. We have that for some true/false computations (methods of the form 
> "is_...(..., certificate=True)") but not very much for other computations.
>
>

-- 
You received this message because you are subscribed 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/dddc6923-8cab-4e2b-ae75-8639b1e909b1n%40googlegroups.com.

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

['Travis Scrimshaw' via sage-devel]

Question for humans: I'm planning on merging this into sage so that 
other developers can help grow it and it's not just me working on it. Would 
it be better to first wait for any bugs that people might notice and then 
add it into sage? Or should I just go ahead and start merging it in and any 
bugs can be fixed while it's in sage itself?


 The review process is designed to catch bugs. Specifically, the reviewer 
should try to make sure the code is bug-free. Part of this is done by 
writing doctests. Of course, we cannot always be perfect about this, and we 
can fix things later. I would just create the PR for adding the code into 
Sage (assuming it is in the appropriate stage for this).

Best,
Travis

-- 
You received this message because you are subscribed 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/543fd01e-9735-461f-a499-51f416b07b8an%40googlegroups.com.

Re: [sage-devel] Unify error for trying to invert non-invertible elements

['Travis Scrimshaw' via sage-devel]

You're misunderstanding what a catch-all means. It means *any* type (of 
error) is reasonable. To put it mathematically, catch-all means union (of 
sets), but the Python doc means difference (of sets).

An assertion is slightly different. It can (in principle) be turned off and 
is just used for internal checking. While there is large overlap, it is not 
quite the same (e.g., if code is assuming a certain conjecture, it should 
not use assert to check validity of assumptions).

Best,
Travis


On Friday, February 9, 2024 at 1:44:23 PM UTC+9 dmo...@deductivepress.ca 
wrote:

> Description of RunTimeError from docs.python.org: "Raised when an error 
> is detected that doesn’t fall in any of the other categories. The 
> associated value is a string indicating what precisely went wrong."
>
> It is for exceptions that cannot be categorized, so I believe it is indeed 
> just a catch-all error (but must have a description), and there is no 
> expectation that such an error is particularly serious. (A situation where 
> "an assumption that I never expected to be violated fails" can raise 
> AssertionError.)
>
> On Thursday, February 8, 2024 at 10:14:33 PM UTC-5 David Roe wrote:
>
>> On Thu, Feb 8, 2024 at 8:18 PM 'Travis Scrimshaw' via sage-devel <
>> sage-...@googlegroups.com> wrote:
>>
>>> For RuntimeError, I would make it sound like it tells you there is 
>>> serious error occurring as it doesn't fall into any other error categories. 
>>> This actually makes it the opposite of a catchall error.
>>>
>>
>> The main scenario when I use a RuntimeError is when an assumption that I 
>> never expected to be violated fails.  I agree with Travis that catchall is 
>> not the right description for this error type.
>> 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/9f55e934-d805-4153-9e4b-d633eacf975an%40googlegroups.com.

[sage-devel] Re: Help needed with UniqueRepresentation (of SymmetricFunctions)

['Travis Scrimshaw' via sage-devel]

Martin's solution is the correct one as it should be preparsing the input 
before it gets to the __init__(), which is then used as the key. This also 
is needed for HallLittlewood and Macdonald.

Best,
Travis

PS - Sorry for not responding sooner about this.

On Tuesday, February 6, 2024 at 4:16:21 PM UTC+9 Martin R wrote:

> Thank you for the explanation.
>
> I would be very surprised about `R.=S.jack()`, because the 
> *coefficients* are (usually regarded as) rational functions in `t`, and the 
> *monomials* are Jack symmetric functions.
>
> I found the following alternative solution at 
> https://doc.sagemath.org/html/en/reference/structure/sage/structure/unique_representation.html
> :
>
> class Jack(UniqueRepresentation):
> @staticmethod
> def __classcall__(cls, Sym, t='t'):
> return super().__classcall__(cls, Sym, Sym.base_ring()(t))
> 
> def __init__(self, Sym, t):
>
> I think I like it better.  Is there anything wrong with it?
> On Monday 5 February 2024 at 19:17:20 UTC+1 Nils Bruin wrote:
>
>> I second that response. More specifically, what you're running into is:
>>
>> sage: S.jack(t=t) == S.jack(t='t')
>> False
>>
>> which is indeed within UniqueRepresentation design parameters: returned 
>> values are cached on construction parameters 't' and '"t"' hash to 
>> different values. If you need better processing, you'd need to normalize 
>> the input parameters further before calling the UniqueRepresentation 
>> constructor. In your case, I think jack.Jack (which is what ends up being 
>> called) actually does expect a string. Perhaps this keyword should be 
>> renamed to "names" to comply with uses elsewhere? e.g., would 
>> R.=S.jack() make sense? If so, then the following should probably be 
>> made to work:
>>
>> sage: preparse("R.=S.jack()")
>> "R = S.jack(names=('t',)); (t,) = R._first_ngens(1)"
>> On Monday 5 February 2024 at 05:57:40 UTC-8 Martin R wrote:
>>
>>> At https://github.com/sagemath/sage/pull/37220 I am trying to provide a 
>>> construction functor for symmetric functions. I am hitting the following 
>>> bug, which I hope is easy to fix if one knows the right magic:
>>>
>>> sage: P. = QQ[]
>>> sage: S = SymmetricFunctions(P)
>>> sage: S.jack().P() == S.jack(t=t).P()
>>> False
>>>
>>> Can someone help me out?
>>>
>>> Martin
>>>
>>

-- 
You received this message because you are subscribed 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/63adb36b-d809-47d0-a98f-6cf3f70508acn%40googlegroups.com.

Re: [sage-devel] Unify error for trying to invert non-invertible elements

['Travis Scrimshaw' via sage-devel]

I would be vague about a TypeError versus a ValueError. These are used in 
various ways by different authors over different periods. It can also be 
very hard to make this rigorous. For example, for something accepting 
integer inputs, then 2/2 fails the isinstance() check but shouldn't throw 
an error. Likewise 1/2 is a bad value that cannot be tested by the 
isinstance() check alone. Actually, I might consider putting them together 
and letting the programmer decide which is most appropriate (of course, 
there are clear cases, such as a list compared to a number).

The ArithmeticError and ZeroDivisionError are fine with me.

I think NotImplementedError is obvious and should be stated in such a way: 
"the input is for a feature not yet implemented"

For RuntimeError, I would make it sound like it tells you there is serious 
error occurring as it doesn't fall into any other error categories. This 
actually makes it the opposite of a catchall error.

Best,
Travis


On Thursday, February 8, 2024 at 11:15:34 AM UTC+9 Kwankyu Lee wrote:

> A method (or function) takes objects as input and computes an output.  The 
> INPUT block defines coarsely  the intended class of mathematical objects. 
>
> TypeError: the type (that can be checked by isinstance(obj, class)) of the 
> input object does not belong to the intended class of mathematical objects
> ValueError: the particular input object is not suitable as input
> ArithmeticError: the particular input object is not suitable for 
> arithmetic (sum, product, quotient, and the like) operation 
> ZeroDivisionError: the method performs division but the input is zero
> NotImplementedError: there is no problem with the input object but the 
> method is incapable to compute appropriate output.
> RuntimeError: The method somehow cannot perform the computation. Perhaps a 
> catchall error.
>
>
> I may add the above to the developer guide. Any comments? 
>

-- 
You received this message because you are subscribed 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/fc6d3662-1d8e-41a4-98ec-4509e2547b71n%40googlegroups.com.

[sage-devel] Re: Google Summer of Code: Organization application deadline Feb 6!

['Travis Scrimshaw' via sage-devel]

Hi everyone,
   I have submitted the application.

However, we can continue to add projects (and mentors) at any point. So if 
you are interested or have any features that you want to request, please 
either add it to the wiki page, post it here, or email me.

Best,
Travis


On Tuesday, February 6, 2024 at 11:54:08 AM UTC+9 Travis Scrimshaw wrote:

> Hi Linden,
>Thank you. I added the project at the "standard" length 350 hours.
>
> Best,
> Travis
>
> On Monday, February 5, 2024 at 7:24:38 PM UTC+9 Linden Disney wrote:
>
>> I have a proposal for a project I would be willing to mentor (detailed 
>> below for completeness), but I'm unsure about how best to estimate the 
>> length (I did GSoC 2021 but estimates of length weren't around then). The 
>> initial coding would not be too challenging, but the mathematical research 
>> which is within scope may be harder (but certainly more interesting). 
>>
>> Title: Poincare normal form of Riemann matrices.
>> Areas: Algebra, Algebraic Geometry.
>> Skills: Knowledge of abstract algebra and Riemann surfaces desirable. 
>> Length: ? 
>> Difficulty: Medium-Easy, becoming harder if desired by tackling the 
>> research questions. 
>>
>> Description: Riemann surfaces are key objects in many areas of maths, 
>> from mathematical physics to algebraic and arithmetic geometry, with modern 
>> usage of Sage typically focusing around computing the Riemann matrix and 
>> calculating the associated theta function. The project would involve an 
>> implementation of Poincare reduction of the Riemann matrix which allows the 
>> theta function to be factorised, following the paper of Martens (
>> http://www.jstor.org/stable/43737152), which in turn will require some 
>> matrix methods to be implemented. There is scope for an enterprising 
>> applicant to make this into a research paper in two directions, either by 
>> analysing the improvement to complexity from computing with factorised 
>> theta functions, or by developing an algorithm to go from one reduction to 
>> a complete reduction. 
>>
>> On Monday, February 5, 2024 at 12:49:41 AM UTC Travis Scrimshaw wrote:
>>
>>> I have added it. (For reference on editing the pages, you login using 
>>> your trac credentials from the upper left corner.)
>>>
>>> Best,
>>> Travis
>>>
>>>
>>> On Monday, February 5, 2024 at 5:38:52 AM UTC+9 Martin R wrote:
>>>
>>>> I would like to propose the exact same project I had for last year 
>>>> again, but I am currently at a conference and additionally don't see how I 
>>>> could edit the page.
>>>>
>>>> Martin
>>>>
>>>> On Sunday 4 February 2024 at 05:19:17 UTC+1 Travis Scrimshaw wrote:
>>>>
>>>>> Sorry for the multiple messages.
>>>>>
>>>>> For potential mentors, there is no commitment required at this time.
>>>>>
>>>>> You can also decide later to add a project and/or be a mentor.
>>>>>
>>>>> Best,
>>>>> Travis
>>>>>
>>>>> On Sunday, February 4, 2024 at 1:17:54 PM UTC+9 Travis Scrimshaw wrote:
>>>>>
>>>>>> For the potential projects, you can either edit the corresponding 
>>>>>> wiki page in Matthias's link or directly post them here (you do not need 
>>>>>> to 
>>>>>> be the mentor).
>>>>>>
>>>>>> Also, I would like to have a list of potential mentors. Any SageMath 
>>>>>> developer can be a mentor for a GSoC project; so if you are willing to 
>>>>>> be a 
>>>>>> mentor (typically just a few hours a week), please directly email me, 
>>>>>> post 
>>>>>> it here, or put your name down as a project mentor. (You do not need to 
>>>>>> have a specific project in mind either.)
>>>>>>
>>>>>> Best,
>>>>>> Travis
>>>>>>
>>>>>> On Sunday, February 4, 2024 at 1:09:07 PM UTC+9 Travis Scrimshaw 
>>>>>> wrote:
>>>>>>
>>>>>>> Thank you for doing that. I updated my projects and removed all of 
>>>>>>> those with named mentors as they have not agreed at present (AFAIK) to 
>>>>>>> be a 
>>>>>>> potential mentor.
>>>>>>>
>>>>>>> I was expecting to be the main administrator for GSoC again this 
>>>

[sage-devel] Re: Google Summer of Code: Organization application deadline Feb 6!

['Travis Scrimshaw' via sage-devel]

Hi Linden,
   Thank you. I added the project at the "standard" length 350 hours.

Best,
Travis

On Monday, February 5, 2024 at 7:24:38 PM UTC+9 Linden Disney wrote:

> I have a proposal for a project I would be willing to mentor (detailed 
> below for completeness), but I'm unsure about how best to estimate the 
> length (I did GSoC 2021 but estimates of length weren't around then). The 
> initial coding would not be too challenging, but the mathematical research 
> which is within scope may be harder (but certainly more interesting). 
>
> Title: Poincare normal form of Riemann matrices.
> Areas: Algebra, Algebraic Geometry.
> Skills: Knowledge of abstract algebra and Riemann surfaces desirable. 
> Length: ? 
> Difficulty: Medium-Easy, becoming harder if desired by tackling the 
> research questions. 
>
> Description: Riemann surfaces are key objects in many areas of maths, from 
> mathematical physics to algebraic and arithmetic geometry, with modern 
> usage of Sage typically focusing around computing the Riemann matrix and 
> calculating the associated theta function. The project would involve an 
> implementation of Poincare reduction of the Riemann matrix which allows the 
> theta function to be factorised, following the paper of Martens (
> http://www.jstor.org/stable/43737152), which in turn will require some 
> matrix methods to be implemented. There is scope for an enterprising 
> applicant to make this into a research paper in two directions, either by 
> analysing the improvement to complexity from computing with factorised 
> theta functions, or by developing an algorithm to go from one reduction to 
> a complete reduction. 
>
> On Monday, February 5, 2024 at 12:49:41 AM UTC Travis Scrimshaw wrote:
>
>> I have added it. (For reference on editing the pages, you login using 
>> your trac credentials from the upper left corner.)
>>
>> Best,
>> Travis
>>
>>
>> On Monday, February 5, 2024 at 5:38:52 AM UTC+9 Martin R wrote:
>>
>>> I would like to propose the exact same project I had for last year 
>>> again, but I am currently at a conference and additionally don't see how I 
>>> could edit the page.
>>>
>>> Martin
>>>
>>> On Sunday 4 February 2024 at 05:19:17 UTC+1 Travis Scrimshaw wrote:
>>>
>>>> Sorry for the multiple messages.
>>>>
>>>> For potential mentors, there is no commitment required at this time.
>>>>
>>>> You can also decide later to add a project and/or be a mentor.
>>>>
>>>> Best,
>>>> Travis
>>>>
>>>> On Sunday, February 4, 2024 at 1:17:54 PM UTC+9 Travis Scrimshaw wrote:
>>>>
>>>>> For the potential projects, you can either edit the corresponding wiki 
>>>>> page in Matthias's link or directly post them here (you do not need to be 
>>>>> the mentor).
>>>>>
>>>>> Also, I would like to have a list of potential mentors. Any SageMath 
>>>>> developer can be a mentor for a GSoC project; so if you are willing to be 
>>>>> a 
>>>>> mentor (typically just a few hours a week), please directly email me, 
>>>>> post 
>>>>> it here, or put your name down as a project mentor. (You do not need to 
>>>>> have a specific project in mind either.)
>>>>>
>>>>> Best,
>>>>> Travis
>>>>>
>>>>> On Sunday, February 4, 2024 at 1:09:07 PM UTC+9 Travis Scrimshaw wrote:
>>>>>
>>>>>> Thank you for doing that. I updated my projects and removed all of 
>>>>>> those with named mentors as they have not agreed at present (AFAIK) to 
>>>>>> be a 
>>>>>> potential mentor.
>>>>>>
>>>>>> I was expecting to be the main administrator for GSoC again this 
>>>>>> year. We will discuss this on the mentors list.
>>>>>>
>>>>>> For the proposal, what we need from the community is a list of 
>>>>>> projects they are willing to mentor. There is no commitment at this 
>>>>>> time. 
>>>>>> However, it is important for our GSoC proposal that it contains a list 
>>>>>> of 
>>>>>> new projects each year.
>>>>>>
>>>>>> Best,
>>>>>> Travis
>>>>>>
>>>>>>
>>>>>> On Sunday, February 4, 2024 at 7:19:44 AM UTC+9 Matthias Koeppe wrote:
>>>>>>
>>>>>>> To get the process started for this year, I have created the page 
>>>>>>> https://wiki.sagemath.org/GSoC/2024 by copying last year's page, 
>>>>>>> removing a completed project and adding a new project that I hope to 
>>>>>>> mentor 
>>>>>>> this summer.
>>>>>>>
>>>>>>> The deadline for our project to apply as a GSoC mentoring 
>>>>>>> organization is rapidly approaching: 
>>>>>>> https://developers.google.com/open-source/gsoc/timeline#february_6_-_1800_utc
>>>>>>>
>>>>>>> Do we have any volunteers for the administrator role?
>>>>>>>
>>>>>>>

-- 
You received this message because you are subscribed 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/82f856f0-f93a-4f82-b8e6-c015f7245f08n%40googlegroups.com.

Re: [sage-devel] Unify error for trying to invert non-invertible elements

['Travis Scrimshaw' via sage-devel]

Dave, I agree that it is quite possible that not all of them are correct 
non-invertible elements in a ring. Of course, we would go through an 
examine them more individually as David suggested.

I was originally thinking ValueError as well, but, as Martin pointed out, 
ArithmeticError is a bit more specific. So that gets my vote.

Best,
Travis


On Tuesday, February 6, 2024 at 11:12:30 AM UTC+9 David Roe wrote:

> I agree that there are cases that shouldn't be changed to an 
> ArithmeticError, and that grepping for "invertible" isn't sufficient.  But 
> I think with a narrower scope this change is a good idea: if the error 
> arises from attempting to invert a non-invertible element of a ring.
>
> So +1 from me, with a manual check that the change seems appropriate.
> David
>
> On Mon, Feb 5, 2024 at 7:54 PM Dave Morris  
> wrote:
>
>> -1 from me.
>>
>> Looking at just a few uncovered some that I think are definitely not 
>> ArithmeticError.
>>
>> Examples:
>> There is an occurrence of ValueError('{} is not invertible') in 
>> the lift_isometry method of cliffordalgebra.py.  Lifting an isometry is 
>> clearly not an arithmetic operation.  ValueError is correct here.
>> There is an occurrence of TypeError('the A-basis is defined only 
>> when 2 is invertible') in the method to find an `A`-basis of an 
>> Iwahori-Hecke algebra.  Finding such a basis is clearly not an arithmetic 
>> operation.  Perhaps this should be a ValueError instead of a TypeError, 
>> though.
>> RuntimeError("morphism is not invertible").  I think that finding 
>> the inverse of a morphism between two objects of a category is clearly not 
>> an arithmetic operation.  Perhaps this should be a ValueError rather than a 
>> RuntimeError.
>>
>> If you want to unify, I think ValueError might work.  But I think they 
>> all need to be inspected, not just assume a single error type fits.
>>
>> > On Feb 5, 2024, at 4:44 AM, 'Martin R' via sage-devel <
>> sage-...@googlegroups.com> wrote:
>> > 
>> > Dear all,
>> > 
>> > currently, when trying to invert a non-invertible element, one of the 
>> following errors is raised (found using `grep -r --include=*.{py,pyx} 
>> --color -nH --null -e "Error(.*invertible" *`):
>> > • 21 ValueError('{} is not invertible')
>> > • 11 ZeroDivisionError("element is not invertible")
>> > • 10 TypeError('the A-basis is defined only when 2 is invertible')
>> > • 8 ArithmeticError("self must be invertible to have a 
>> multiplicative order")
>> > • 2 RuntimeError("morphism is not invertible")
>> > • 2 NotImplementedError("matrix must be invertible")
>> > 
>> > Travis and I would like to propose to unify these to 
>> "ArithmeticError".  If nobody objects, I would prepare a PR within the next 
>> few days.
>> > 
>> > Best wishes,
>> > 
>> > Martin
>> > 
>> > 
>> > -- 
>> > You received this message because you are subscribed 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/d0637584-4908-4101-8e1b-74ec0477ff84n%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/4A0E1F77-27A7-4DF3-BB18-636853BF4CC0%40deductivepress.ca
>> .
>>
>

-- 
You received this message because you are subscribed 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/d600a383-43a9-4105-8d81-cd2ec1db3dd1n%40googlegroups.com.

[sage-devel] Re: Google Summer of Code: Organization application deadline Feb 6!

['Travis Scrimshaw' via sage-devel]

I have added it. (For reference on editing the pages, you login using your 
trac credentials from the upper left corner.)

Best,
Travis


On Monday, February 5, 2024 at 5:38:52 AM UTC+9 Martin R wrote:

> I would like to propose the exact same project I had for last year again, 
> but I am currently at a conference and additionally don't see how I could 
> edit the page.
>
> Martin
>
> On Sunday 4 February 2024 at 05:19:17 UTC+1 Travis Scrimshaw wrote:
>
>> Sorry for the multiple messages.
>>
>> For potential mentors, there is no commitment required at this time.
>>
>> You can also decide later to add a project and/or be a mentor.
>>
>> Best,
>> Travis
>>
>> On Sunday, February 4, 2024 at 1:17:54 PM UTC+9 Travis Scrimshaw wrote:
>>
>>> For the potential projects, you can either edit the corresponding wiki 
>>> page in Matthias's link or directly post them here (you do not need to be 
>>> the mentor).
>>>
>>> Also, I would like to have a list of potential mentors. Any SageMath 
>>> developer can be a mentor for a GSoC project; so if you are willing to be a 
>>> mentor (typically just a few hours a week), please directly email me, post 
>>> it here, or put your name down as a project mentor. (You do not need to 
>>> have a specific project in mind either.)
>>>
>>> Best,
>>> Travis
>>>
>>> On Sunday, February 4, 2024 at 1:09:07 PM UTC+9 Travis Scrimshaw wrote:
>>>
>>>> Thank you for doing that. I updated my projects and removed all of 
>>>> those with named mentors as they have not agreed at present (AFAIK) to be 
>>>> a 
>>>> potential mentor.
>>>>
>>>> I was expecting to be the main administrator for GSoC again this year. 
>>>> We will discuss this on the mentors list.
>>>>
>>>> For the proposal, what we need from the community is a list of projects 
>>>> they are willing to mentor. There is no commitment at this time. However, 
>>>> it is important for our GSoC proposal that it contains a list of new 
>>>> projects each year.
>>>>
>>>> Best,
>>>> Travis
>>>>
>>>>
>>>> On Sunday, February 4, 2024 at 7:19:44 AM UTC+9 Matthias Koeppe wrote:
>>>>
>>>>> To get the process started for this year, I have created the page 
>>>>> https://wiki.sagemath.org/GSoC/2024 by copying last year's page, 
>>>>> removing a completed project and adding a new project that I hope to 
>>>>> mentor 
>>>>> this summer.
>>>>>
>>>>> The deadline for our project to apply as a GSoC mentoring organization 
>>>>> is rapidly approaching: 
>>>>> https://developers.google.com/open-source/gsoc/timeline#february_6_-_1800_utc
>>>>>
>>>>> Do we have any volunteers for the administrator role?
>>>>>
>>>>>

-- 
You received this message because you are subscribed 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/cee28f9e-255e-410f-b82d-55e8acc553d7n%40googlegroups.com.

Re: [sage-devel] Sphinx directives in upper case?

['Travis Scrimshaw' via sage-devel]

I think it is more confusing to mix the two. I vote for keeping everything 
all uppercase since everything else that is analogous uses all uppercase 
letters.

Best,
Travis

On Wednesday, January 31, 2024 at 9:20:58 PM UTC+9 TB wrote:

> On 25/01/2024 7:06, Kwankyu Lee wrote:
>
> Hi, 
>
> Our developer guide dictates to write Sphinx directives in upper case. So 
> for example, ".. MATH::" instead of ".. math::". By the way, it seems that 
> Sphinx community seems to regard lower case as norm. So my question is: why 
> do we insist upper case? Could anyone point to a discussion thread that 
> decided on this?
>
> More than 13 years ago we have 
> https://github.com/sagemath/sage/issues/10077 and 
> https://github.com/sagemath/sage/issues/10078 that have comments about 
> the case. Some further history might stem from stropping 
> ... For those looking 
> in the docs, one place is here 
> 
> .
>
>
> On 25/01/2024 10:18, Kwankyu Lee wrote:
>
> In my humble opinion,  except  
>
> ".. SEEALSO::", "..WARNING::", ".. TODO::", ".. NOTE::", ".. RUBRIC::", ".. 
> PLOT::", "..TOPIC::", which seek for reader's attention, 
>
> we should use lower case (by default) for all other directives, following 
> Sphinx community's trend. In particular, ".. MATH::" is only distracting.
>
> No strong opinion from me, except maybe for having consistency within a 
> given file. The INPUT and OUTPUT blocks are related, but they are not 
> directives. Do you think they should be?
>
>
> Regards,
>
> TB
>
>

-- 
You received this message because you are subscribed 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/e3057ac7-1c23-4bc3-ab17-1bce7570369cn%40googlegroups.com.

[sage-devel] Re: Google Summer of Code: Organization application deadline Feb 6!

['Travis Scrimshaw' via sage-devel]

Sorry for the multiple messages.

For potential mentors, there is no commitment required at this time.

You can also decide later to add a project and/or be a mentor.

Best,
Travis

On Sunday, February 4, 2024 at 1:17:54 PM UTC+9 Travis Scrimshaw wrote:

> For the potential projects, you can either edit the corresponding wiki 
> page in Matthias's link or directly post them here (you do not need to be 
> the mentor).
>
> Also, I would like to have a list of potential mentors. Any SageMath 
> developer can be a mentor for a GSoC project; so if you are willing to be a 
> mentor (typically just a few hours a week), please directly email me, post 
> it here, or put your name down as a project mentor. (You do not need to 
> have a specific project in mind either.)
>
> Best,
> Travis
>
> On Sunday, February 4, 2024 at 1:09:07 PM UTC+9 Travis Scrimshaw wrote:
>
>> Thank you for doing that. I updated my projects and removed all of those 
>> with named mentors as they have not agreed at present (AFAIK) to be a 
>> potential mentor.
>>
>> I was expecting to be the main administrator for GSoC again this year. We 
>> will discuss this on the mentors list.
>>
>> For the proposal, what we need from the community is a list of projects 
>> they are willing to mentor. There is no commitment at this time. However, 
>> it is important for our GSoC proposal that it contains a list of new 
>> projects each year.
>>
>> Best,
>> Travis
>>
>>
>> On Sunday, February 4, 2024 at 7:19:44 AM UTC+9 Matthias Koeppe wrote:
>>
>>> To get the process started for this year, I have created the page 
>>> https://wiki.sagemath.org/GSoC/2024 by copying last year's page, 
>>> removing a completed project and adding a new project that I hope to mentor 
>>> this summer.
>>>
>>> The deadline for our project to apply as a GSoC mentoring organization 
>>> is rapidly approaching: 
>>> https://developers.google.com/open-source/gsoc/timeline#february_6_-_1800_utc
>>>
>>> Do we have any volunteers for the administrator role?
>>>
>>>

-- 
You received this message because you are subscribed 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/162019c3-ba9c-4f9f-9a5c-b469b156cb58n%40googlegroups.com.

[sage-devel] Re: Google Summer of Code: Organization application deadline Feb 6!

['Travis Scrimshaw' via sage-devel]

For the potential projects, you can either edit the corresponding wiki page 
in Matthias's link or directly post them here (you do not need to be the 
mentor).

Also, I would like to have a list of potential mentors. Any SageMath 
developer can be a mentor for a GSoC project; so if you are willing to be a 
mentor (typically just a few hours a week), please directly email me, post 
it here, or put your name down as a project mentor. (You do not need to 
have a specific project in mind either.)

Best,
Travis

On Sunday, February 4, 2024 at 1:09:07 PM UTC+9 Travis Scrimshaw wrote:

> Thank you for doing that. I updated my projects and removed all of those 
> with named mentors as they have not agreed at present (AFAIK) to be a 
> potential mentor.
>
> I was expecting to be the main administrator for GSoC again this year. We 
> will discuss this on the mentors list.
>
> For the proposal, what we need from the community is a list of projects 
> they are willing to mentor. There is no commitment at this time. However, 
> it is important for our GSoC proposal that it contains a list of new 
> projects each year.
>
> Best,
> Travis
>
>
> On Sunday, February 4, 2024 at 7:19:44 AM UTC+9 Matthias Koeppe wrote:
>
>> To get the process started for this year, I have created the page 
>> https://wiki.sagemath.org/GSoC/2024 by copying last year's page, 
>> removing a completed project and adding a new project that I hope to mentor 
>> this summer.
>>
>> The deadline for our project to apply as a GSoC mentoring organization is 
>> rapidly approaching: 
>> https://developers.google.com/open-source/gsoc/timeline#february_6_-_1800_utc
>>
>> Do we have any volunteers for the administrator role?
>>
>>

-- 
You received this message because you are subscribed 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/b8badb42-659e-46a4-8ac7-13225dc1af1bn%40googlegroups.com.

[sage-devel] Re: Google Summer of Code: Organization application deadline Feb 6!

['Travis Scrimshaw' via sage-devel]

Thank you for doing that. I updated my projects and removed all of those 
with named mentors as they have not agreed at present (AFAIK) to be a 
potential mentor.

I was expecting to be the main administrator for GSoC again this year. We 
will discuss this on the mentors list.

For the proposal, what we need from the community is a list of projects 
they are willing to mentor. There is no commitment at this time. However, 
it is important for our GSoC proposal that it contains a list of new 
projects each year.

Best,
Travis


On Sunday, February 4, 2024 at 7:19:44 AM UTC+9 Matthias Koeppe wrote:

> To get the process started for this year, I have created the page 
> https://wiki.sagemath.org/GSoC/2024 by copying last year's page, removing 
> a completed project and adding a new project that I hope to mentor this 
> summer.
>
> The deadline for our project to apply as a GSoC mentoring organization is 
> rapidly approaching: 
> https://developers.google.com/open-source/gsoc/timeline#february_6_-_1800_utc
>
> Do we have any volunteers for the administrator role?
>
>

-- 
You received this message because you are subscribed 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/e7cf5e21-a7ac-4522-b110-fe52fa2ff12an%40googlegroups.com.

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

['Travis Scrimshaw' via sage-devel]

Hi John,
   None of the above. I think maintaining good programming practices is 
important for the codebase and it is a good thing to teach contributors who 
might not understand. Hence, we should spend the time having them get it 
into a format that is acceptable for Sage. In the end, it should play nice 
with the current matroid code, but I don't think that is a requirement for 
a new feature.

Best,
Travis

On Wednesday, November 22, 2023 at 8:27:31 AM UTC+9 John H Palmieri wrote:

> 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/9e9e36be-68d2-4771-b5a3-1527321f673bn%40googlegroups.com.

Re: [sage-devel] Operator Product Expansions in Lie conformal algebras

['Travis Scrimshaw' via sage-devel]

We should look at that closely sometime Reimundo. I have very strong doubts 
that it is the category formalism as that really should not be playing any 
role in creating and manipulating elements. It only comes into play when 
dealing with multiple (distinct) parents. It might also be that you need to 
directly implement some shortcuts rather than relying on some general 
machinery or you are using the wrong data structures.

Best,
Travis


On Friday, October 20, 2023 at 8:56:44 AM UTC+9 Reimundo Heluani wrote:

> There was a very large PR with a full implementation of vertex operator 
> algebras including some non-linearly generated. It got caught in review, 
> then 
> the pandemic and then the birth of a baby in the middle of it. That PR got 
> broken into several pieces, some for LCAs, another for vertex algebras, 
> then 
> another for examples and another with the main application I had at the 
> time 
> for computing classical limits and Poisson vertex algebras. 
>
> The rebasing mechanism and maintaining such a large PR for review was 
> impossible https://github.com/sagemath/sage/issues/29610
>
> I don't think that compiles not even close. The biggest problem is that 
> for 
> any serious computation Python and the overhead of all the category 
> formalism 
> of Sage makes these packages useless. Mathematica Thielemann's package was 
> orders of magnitude faster. I coded a C++ version of this that I was 
> hoping to 
> use as backend for sage. But adhering to the category formalism is 
> not-trivial. 
>
> R. 
>
> On Oct 18, Sam DeHority wrote:
> >Hi,
> >
> >Sage has a LieConformalAlgebras module which is able to compute OPEs, or
> >equivalently \lambda-brackets when those brackets close under OPEs. There
> >isn't, however, a "free" Lie Conformal Algebra which allows for OPEs of 
> fields
> >build from normally ordered products using the noncommutative Wick 
> formula.
> >
> >Is there any interest in expanding the LieConformalAlgebras package to 
> support
> >more general OPEs?
> >
> >--
> >You received this message because you are subscribed to the Google Groups
> >"sage-devel" group.
> >To unsubscribe from this group and stop receiving emails from it, send an 
> email
> >to [1]sage-devel+...@googlegroups.com.
> >To view this discussion on the web visit [2]
> https://groups.google.com/d/msgid/
> >sage-devel/d73a91f8-4082-493e-9580-b978547825c4n%40googlegroups.com.
> >
> >References:
> >
> >[1] mailto:sage-devel+...@googlegroups.com
> >[2] 
> https://groups.google.com/d/msgid/sage-devel/d73a91f8-4082-493e-9580-b978547825c4n%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/22640cd8-e1f8-40b0-aefd-4fd0bb9b8793n%40googlegroups.com.

Re: [sage-devel] change_ring for ideals

['Travis Scrimshaw' via sage-devel]

Then I will write a PR that implements the generic version I described.

This is now #36472, but I am getting a problem with large looping in 
p-adics that I cannot figure out. I haven't run other tests, but I think 
the only issues are localized to that code.

Best,
Travis

On Monday, October 16, 2023 at 3:53:05 PM UTC+9 Dima Pasechnik wrote:

>
>
> On Mon, 16 Oct 2023, 05:03 'Travis Scrimshaw' via sage-devel, <
> sage-...@googlegroups.com> wrote:
>
>> Hi everyone,
>>Is there some reason why a generic change_ring() was not implemented 
>> for all ideals? This leads to a bug with univariate Laurent polynomials:
>>
>
> I guess it was not implemented because the backend used here is not 
> Singular (where it's built-in)
>
>
>
>> sage: L. = LaurentPolynomialRing(QQ)
>> sage: I = L.ideal(0)
>> sage: I + I
>>
>> ---
>> AttributeErrorTraceback (most recent call 
>> last)
>> ...
>> AttributeError: 'Ideal_1poly_field' object has no attribute 'change_ring'
>>
>> I imagine that just calling "return 
>> self.ring().parent().ideal(self.gens())" would work in general (and I think 
>> should for that matter).
>>
>> This was noticed on PR #36368, where the author is working around it by 
>> implementing this for the class in question.
>>
>> Best,
>> Travis
>>
>> -- 
>> You received this message because you are subscribed 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/f373c92a-1f68-42ab-aec0-a22305173bacn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/f373c92a-1f68-42ab-aec0-a22305173bacn%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/d69d4e8d-b761-4351-b017-6b7ee274d3d8n%40googlegroups.com.

[sage-devel] change_ring for ideals

['Travis Scrimshaw' via sage-devel]

Hi everyone,
   Is there some reason why a generic change_ring() was not implemented for 
all ideals? This leads to a bug with univariate Laurent polynomials:

sage: L. = LaurentPolynomialRing(QQ)
sage: I = L.ideal(0)
sage: I + I
---
AttributeErrorTraceback (most recent call last)
...
AttributeError: 'Ideal_1poly_field' object has no attribute 'change_ring'

I imagine that just calling "return 
self.ring().parent().ideal(self.gens())" would work in general (and I think 
should for that matter).

This was noticed on PR #36368, where the author is working around it by 
implementing this for the class in question.

Best,
Travis

-- 
You received this message because you are subscribed 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/f373c92a-1f68-42ab-aec0-a22305173bacn%40googlegroups.com.

Re: [sage-devel] Re: New package creation - advice/help requested

['Travis Scrimshaw' via sage-devel]

Not so much, but because people working in matroids usually need more 
speed, it tends to mean more Cython code. Compare how your implementation 
is done with the matroids in Sage. (For instance, you can have a category 
(even with Cython), but there are a number of categories that are more 
meant to serve a programming role, through abstraction and avoiding 
combinatorial explosion of classes, than a mathematical one. Matroids would 
be such an example.)

Best,
Travis


On Wednesday, July 5, 2023 at 4:16:50 PM UTC+9 Aram Dermenjian wrote:

> In essence, yes we're expecting to change much of the code as the 
> structure will be changing in addition to fixes to some major bugs in the 
> code. Moreover, I'm working on this with two (undergraduate) interns that I 
> have and so they're newer to programming so I wanted them to work in a more 
> "sandbox" environment before fully integrating it into sage.
>
> I hadn't heard about a push to get more cython. Is this becoming more 
> standard? 
>
> Aram
>
> On Mon, 3 Jul 2023 at 01:56, 'Travis Scrimshaw' via sage-devel <
> sage-...@googlegroups.com> wrote:
>
>> Hi Aram,
>>Can you explain a bit more why you aren't just integrating it into 
>> Sage now? Are you're expecting to have major API changes? There would 
>> likely be a push to change to using more Cython, but it doesn't need to be 
>> feature complete to be a part of Sage and internal/implementation details 
>> are easy to change.
>>
>> Best,
>> Travis
>>
>> On Friday, June 30, 2023 at 1:27:30 AM UTC+9 Matthias Koeppe wrote:
>>
>>> On Thursday, June 29, 2023 at 3:01:58 AM UTC-7 Aram Dermenjian wrote:
>>>
>>> it seems the method I was using to create a new package is no longer 
>>> valid. For example, when I try and do an install, I get the following error:
>>>
>>>  SetuptoolsDeprecationWarning: setup.py install is deprecated. Use 
>>> build and pip and other standards-based tools.
>>>
>>>
>>> It's not an error. If you already use "pip install" to install your 
>>> package, no action is needed.
>>> But you may want to learn about pyproject.toml (see the setuptools docs)
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sage-devel+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/e5495aae-4978-41df-bc4b-f1cce649dbe7n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/e5495aae-4978-41df-bc4b-f1cce649dbe7n%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/074e5725-03a6-4626-9e55-f4c08f00524cn%40googlegroups.com.

[sage-devel] Re: issue with division in fraction field of univ poly

['Travis Scrimshaw' via sage-devel]

When I first tried Ben's OP code, it worked as there. Then when trying 
Nil's code, I get the same output as Ben, but when I immediate after run

sage: D2 / D1
...Same traceback as above...
ZeroDivisionError: fraction field element division by zero

Now in a fresh Sage session, I immediately get the zero division error for 
D2 / D1, but then running Nil's code, I now get:

sage: Kp = parent(1/D1)
sage: r = Kp(D2)
sage: s = Kp(1/D1)
sage: r.numerator().gcd(s.denominator())
a*x^3 + (-a)*x^2*y + (-a^2 + 3*a - 1)*x*y^2 + (2*a^2 - 3*a + 1)*y^3
sage: r * s
ZeroDivisionError
sage: r.numerator().gcd(s.denominator())
0

So I think Nil's correctly identified the main symptom, but Ben's diagnosis 
is almost correct. It is not something being cached but an internal 
property being changed in some place where it believes it is safe to mutate 
it. I have created a new issue 
https://github.com/sagemath/sage/issues/35886 and put some additional 
observations.

Best,
Travis
On Wednesday, June 28, 2023 at 1:42:35 AM UTC+9 Ben Hutz wrote:

> I'm not getting 0 with that code:
>
> sage: K. = Frac(QQ['a'])
> sage: P. = ProjectiveSpace(K, 1)
> sage: D2=-x^5 + (-3*a^2 + 7*a - 2)/a*x^4*y + (6*a^2 - 12*a + 4)/a*x^3*y^2 
> + (3*a^4 - 19*a^3 + 29*a^2 - 14*a + 2)/(a^2)*x^2*y^3 + (-8*a^4 + 30*a^3 - 
> 37*a^2 + 18*a - 3)/(a^2)*x*y^4 + (4*a^4 - 12*a^3 + 13*a^2 - 6*a + 
> 1)/(a^2)*y^5
> sage: D1=-x^3 + x^2*y + (a^2 - 3*a + 1)/a*x*y^2 + (-2*a^2 + 3*a - 1)/a*y^3
>
> sage: K=parent(1/D2)
> sage: r=K(D1)
> sage: s=K(1/D2)
> sage: r.numerator().gcd(s.denominator())
> a*x^3 + (-a)*x^2*y + (-a^2 + 3*a - 1)*x*y^2 + (2*a^2 - 3*a + 1)*y^3 
>
>
> However, if I run 
> sage: K. = Frac(QQ['a'])
> sage: P. = ProjectiveSpace(K, 1)
> sage: f = x^2 + (a + 1/a - 3)*x*y - (2*a + 1/a - 3)*y^2
> sage: phi = DynamicalSystem_projective([f,x^2])
> sage: phi.dynatomic_polynomial(2)
> 0
>
> and *then* run the code I get zero.
>
> sage: K. = Frac(QQ['a'])
> sage: P. = ProjectiveSpace(K, 1)
> sage: D2=-x^5 + (-3*a^2 + 7*a - 2)/a*x^4*y + (6*a^2 - 12*a + 4)/a*x^3*y^2 
> + (3*a^4 - 19*a^3 + 29*a^2 - 14*a + 2)/(a^2)*x^2*y^3 + (-8*a^4 + 30*a^3 - 
> 37*a^2 + 18*a - 3)/(a^2)*x*y^4 + (4*a^4 - 12*a^3 + 13*a^2 - 6*a + 
> 1)/(a^2)*y^5
> sage: D1=-x^3 + x^2*y + (a^2 - 3*a + 1)/a*x*y^2 + (-2*a^2 + 3*a - 1)/a*y^3
>
> sage: K=parent(1/D2)
> sage: r=K(D1)
> sage: s=K(1/D2)
> sage: r.numerator().gcd(s.denominator()) 
> 0
>
>
> So I still find that weird. Is there something being oddly cached?
> On Monday, June 26, 2023 at 4:04:18 PM UTC-5 Nils Bruin wrote:
>
>> With your data, we get:
>>
>> sage: K=parent(1/D2)
>> sage: r=K(D1)
>> sage: s=K(1/D2)
>> sage: r.numerator().gcd(s.denominator())
>> 0
>>
>> and I think that's the zero which leads to the division-by-zero error. Of 
>> course, a 0 returned as gcd is just a bug. It doesn't look like the 
>> coercion framework is really involved here.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/111d5aa6-6a17-4acf-8576-e676db709192n%40googlegroups.com.

[sage-devel] Re: New package creation - advice/help requested

['Travis Scrimshaw' via sage-devel]

Hi Aram,
   Can you explain a bit more why you aren't just integrating it into Sage 
now? Are you're expecting to have major API changes? There would likely be 
a push to change to using more Cython, but it doesn't need to be feature 
complete to be a part of Sage and internal/implementation details are easy 
to change.

Best,
Travis

On Friday, June 30, 2023 at 1:27:30 AM UTC+9 Matthias Koeppe wrote:

> On Thursday, June 29, 2023 at 3:01:58 AM UTC-7 Aram Dermenjian wrote:
>
> it seems the method I was using to create a new package is no longer 
> valid. For example, when I try and do an install, I get the following error:
>
>  SetuptoolsDeprecationWarning: setup.py install is deprecated. Use 
> build and pip and other standards-based tools.
>
>
> It's not an error. If you already use "pip install" to install your 
> package, no action is needed.
> But you may want to learn about pyproject.toml (see the setuptools docs)
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e5495aae-4978-41df-bc4b-f1cce649dbe7n%40googlegroups.com.

Re: [sage-devel] Voting: Block-scoped optional tag and the keyword

['Travis Scrimshaw' via sage-devel]

(A)

Travis


On Monday, July 3, 2023 at 2:42:10 AM UTC+9 G. M.-S. wrote:

>
> My choice is (A).
>
> Guillermo
>
> On Thu, 29 Jun 2023 at 04:40, Kwankyu Lee  wrote:
>
>> Hi,
>>
>> We spent six days for the preliminary discussion in the sage-devel thread
>>
>> https://groups.google.com/g/sage-devel/c/OUnoroIf0qc
>>
>> about choosing the keyword triggering block-scoped optional tag needed in 
>>
>> https://github.com/sagemath/sage/issues/35750
>>
>> We now start the voting with the four candidates (A), (B), (C), (D). The 
>> voting will end 7th July 23:59 KST (Korea Standard Time). During the 
>> voting, discussions can continue in the linked places but please only your 
>> vote (and, if you will, short comment) to this thread.
>>
>> (A) "needs"
>>
>> sage: # needs sage.rings.number_field
>> sage: QQbar(I)^2
>> -1
>> sage: QQbar(I)^10 # long time
>> 1
>>
>> sage: # needs sage.rings.finite_rings
>> sage: F = GF(7)
>> sage: F(1) + QQbar(1)  # needs sage.rings.number_field
>> ...
>>
>> (B) "requires"
>>
>> sage: # requires sage.rings.number_field
>> sage: QQbar(I)^2
>> -1
>> sage: QQbar(I)^10  # long time
>> 1
>>
>> sage: # requires sage.rings.finite_rings
>> sage: F = GF(7)
>> sage: F(1) + QQbar(1)  # requires sage.rings.number_field
>> ...
>>
>> (C) "uses"
>>
>> sage: # uses sage.rings.number_field
>> sage: QQbar(I)^2
>> -1
>> sage: QQbar(I)^10  # long time
>> 1
>>
>> sage: # uses sage.rings.finite_rings
>> sage: F = GF(7)
>> sage: F(1) + QQbar(1)  # uses sage.rings.number_field
>> ...
>>
>> (D) "standard"
>>
>> sage: # use standard feature - sage.rings.number_field
>> sage: QQbar(I)^2
>> -1
>> sage: QQbar(I)^10  # long time
>> 1
>>
>> sage: # use standard feature - sage.rings.finite_rings
>> sage: F = GF(7)
>> sage: F(1) + QQbar(1)  # standard - sage.rings.number_field
>> ...
>>
>> Please just focus on the keyword. Don't worry about minor details or 
>> punctuations: the keyword would be recognized, the rest would be ignored 
>> noise, in the implementation.
>>
>> Thanks for your attention. Happy voting :-)
>>
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/14588592-fadb-4c30-a32b-d44c3f161a68n%40googlegroups.com.

Re: [sage-devel] Re: Modularation doctests

['Travis Scrimshaw' via sage-devel]

On Friday, June 16, 2023 at 10:18:57 AM UTC+9 Matthias Koeppe wrote:

On Thursday, June 15, 2023 at 6:03:41 PM UTC-7 Travis Scrimshaw wrote:

 Perhaps this is the core question (for me): What do you expect most/casual 
users to download and install?

It may be the wrong question because it seems to assume there is one 
population of such users.


This is an important question because it determines a lot about how we 
package and present the software. If we expect users to be technically 
savvy and tacitly understand they can ignore "# module - sage.*" doctests, 
then we can just go ahead and plaster them everywhere. If we expect people 
to peck at their keyboards with two fingers and copy/paste examples, then 
we should make sure the doc is very clean.


The population of current Sage users and developers can continue to install 
the monolithic Sage. 
Or, in the modularized terminology, they install the distribution 
"sagemath-standard".


What is going to be "Sage" then? What is my product to tell people about at 
a SageDays?


But the point why I have been working so intensely on the modularization 
project is to open parts of Sage to new populations of users and developers 
who are at home in the Python world. In particular those who find that they 
cannot use the monolithic Sage for their needs and therefore go looking for 
other projects that do not impose such constraints.

As William said, it could be a magnitude more, but it easily could be 0. 
Yes Sage is a lot to download (although if we cut out the documentation and 
continue to use system packages, I think we cut this down immensely), but 
Sage just exists in its own Python (plus some other stuff) bubble. I have 
some doubts that this will move the needle much at the cost of putting up 
development barriers, or at least increasing the learning curve, for 
non-expert-programmer-mathematicians (I might even put myself in this 
category).
 
Best,
Travis

-- 
You received this message because you are subscribed 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/deeb3419-4aae-457a-b65c-377b553fd5a3n%40googlegroups.com.

Re: [sage-devel] Modularization project: I. The goals

['Travis Scrimshaw' via sage-devel]

On Friday, June 16, 2023 at 10:49:49 AM UTC+9 Kwankyu Lee wrote:

The Sage distribution will continue to exist. There will be no user-visible 
change coming from the modularization project for the users of the Sage 
distribution.


That is simply not true right now. The # optional sage.* doctests as a 
user-visible change.


Matthias means that all pieces (the sage library and external packages that 
the sage library depends on) are all there and available to a sage user 
after the modularization project.


It depends on what you mean by "there" because it is not been explained I 
think how a user should install and work with Sage afterwards. I agree it 
is clearly all available, but depending on how we tell a user to install, 
there could very well be changes.
 

That is why you (and most of us) didn't notice and care much about the 
modularization project up to now, until those massive `# optional ...` tags 
start to appear in the code you care about.


I've been following along with different pieces to see how it's going. You 
are right, in part I am bringing this up now because it is is affecting 
code I care about (and regularly use to promote Sage), but it is also 
starting to come with policy implications due to its scale that are not 
easy to revert.


I don't think we can dismiss `# optional ...` tags from the sage library if 
we embrace the modularization efforts of the sage library, as Matthias is 
trying to convince us. It is more productive to find ways to do it in more 
pleasing way.

I concur.

Best,
Travis

-- 
You received this message because you are subscribed 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/8c8e2626-1517-43a9-89d0-03920712c0f2n%40googlegroups.com.

Re: [sage-devel] Modularization project: I. The goals

['Travis Scrimshaw' via sage-devel]

Hi William,
   That is interesting. Although my take on that is following Matthias's 
proposal, they will just use one (or more) part of Sage as a Python 
library. So if they switch, in effect they will still be dropping Sage. I 
don't see Sage as having its own custom language other than some small 
syntactic sugar items (although I guess the ^ for ** is a big one for 
people switching to Python), but it does sit within its own environment 
(which has its pros and cons IMO). It is slightly annoying to bring 
everything into that environment, but I feel that we can get a bit of a 
smoother user experience this way.

I guess some of it comes down to what our target audience is. Even if we 
were just a normal Python package and just do "from sage import *", I think 
Sage would have a hard time competing against things like NumPy and 
matplotlib for those first year courses. They are currently too broadly 
used in many fields/industries, so universities will want to emphasize 
those. However, Sage is better equipped to do the more specialized math 
courses and research based computations. I don't think we have spent nearly 
enough time making our own set of teaching tools to compete; mostly that 
has been split off/overtaken by the Jupyter notebooks or in the libraries 
we build off of. I think we would need to have more of an influence in 
industry jobs to bring more universities around to saying "start Python, 
then do 'from sage.all import *'."

Perhaps this is the question that I am looking for an answer for, "What is 
Sage (after modularization)?"

Best,
Travis


On Friday, June 16, 2023 at 8:23:01 AM UTC+9 William Stein wrote:

> Hi Sage Devs,
>
> As further motivation for this discussion of "Modularization project:
> I. The goals", here is a quote from a discussion just now (with
> permission) from Eric Deeds, who is the vice chair for Life Sciences
> Math Courses and Professor of Integrative Biology and Physiology at
> UCLA:
>
> "I think we may also switch to using Python with libraries, rather
> than SageMath since Python is much more widely used."
>
> At UCLA they currently use SageMath (the full environment and
> language) with about 3K students per year, and are considering
> switching from Sage to normal Python, since sage is its own custom
> language and environment, which isn't exactly the Python language,
> etc. This is motivation for modularization of sage, since there is
> substantial functionality in Sage, e.g., "plotting vector fields",
> which they would like to use still. Of course, I did explain how it
> is possible to use normal Python and import sage via "from sage.all
> import ...". However, properly supporting using Sage from Python like
> any other Python citizen would be even better, and that's something
> that would result from the project Matthias is spearheading.
>
> -- William
>
> On Mon, Jun 12, 2023 at 4:54 PM Nathan Dunfield  
> wrote:
> >
> > On Monday, June 12, 2023 at 2:58:18 PM UTC-4 Matthias Koeppe wrote:
> >
> > What parts of Sage does SnapPy use?
> >
> >
> > Primarily the various rings/fields, including matrices over them and 
> basic linear algebra. Specifically, interval arithmetic 
> (Real/ComplexIntervalField), polynomial rings (in several variables, 
> including Laurent polynomials), number fields, and the basic rings ZZ, QQ, 
> GF, RealField, ComplexField, etc. Also, the ptolemy submodule uses Sage for 
> groebner_basis calculations. I suspect most of what we use would be part of 
> any initial pip-installable version of the Sage library. Right now, in the 
> stand-alone apps we backstop some of Sage's functionality (e.g. arbitrary 
> precision floats) with CyPari, which is itself an example of part of Sage 
> being modularized.
> >
> > Best,
> >
> > Nathan
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-devel+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/4b14371d-b528-4b43-b350-5920259c88e1n%40googlegroups.com
> .
>
>
>
> -- 
> William (http://wstein.org)
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/91a2c3b6-a018-4931-890f-ce3ce5ced8b8n%40googlegroups.com.

Re: [sage-devel] Modularization project: I. The goals

['Travis Scrimshaw' via sage-devel]

On Monday, June 12, 2023 at 10:53:38 AM UTC+9 Matthias Koeppe wrote:

On Sunday, June 11, 2023 at 6:20:03 PM UTC-7 Travis Scrimshaw wrote:

My understanding of William's goal (please correct me if I am wrong) was to 
put everything together so nobody was trying to build a better wheel. To 
me, by splitting everything up into these small pieces, it seems contrary 
to that goal as how is someone suppose to know the piece they want already 
exists?


The Sage distribution will continue to exist. There will be no user-visible 
change coming from the modularization project for the users of the Sage 
distribution.


That is simply not true right now. The # optional sage.* doctests as a 
user-visible change.


My reading is that your main goal is to make Sage pip-installable, but that 
seems independent of breaking Sage up into smaller parts. Even breaking up 
Sage into smaller portions for more 'precise' dependencies for these 
supposed downstream Python developers won't really fix B and C.


It works the other way around. B and C (applied to individual Cython/Python 
modules) were/are _obstacles_ to making modularized pip-installable 
distributions.


I don't follow. Separating the components of Sage won't fix B/C, nor will 
fixing B/C split Sage into smaller components (which will actually make the 
dependency web worse).

Best,
Travis

-- 
You received this message because you are subscribed 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/19987597-9875-4306-927c-4a287c70eb5fn%40googlegroups.com.

Re: [sage-devel] Re: Modularation doctests

['Travis Scrimshaw' via sage-devel]

On Thursday, June 15, 2023 at 12:23:55 AM UTC+9 Matthias Koeppe wrote:

On Wednesday, June 14, 2023 at 8:01:29 AM UTC-7 Tobias Diez wrote:

On Wednesday, 14 June 2023 at 05:37:15 UTC+8 Matthias Koeppe wrote:

- Some # optional annotations reduce the barrier for contributors, by 
clearly signaling to developers "it's OK and definitely not your fault if 
you don't understand this doctest". 


[...] As a (new) user, reading "# optional - sage.symbolic" makes me more 
think "wtf. what is this? how do I install this sage.symbolic thing so that 
I can run use this example?!" than "oh, yes, this test depends on another 
part of sage, that I have not yet encountered, so I don't need to try to 
understand this example". 


This is a documentation / user education issue, which is addressed by 
writing documentation and educating the educators first.


I don't think the answer should be "read this long, technical document' to 
understand."  Even if it is a short and easy to understand, how would a 
random casual user who just heard about Sage know to even look for it? It 
seems like you want to make the people who are doing Sage outreach do more 
selling and explaining to people (who probably won't even remember such a 
minor point when they first start playing around with things). Some of it 
can be fixed by changing the nomenclature "optional" to something else as 
that suggests something a user should *add* to the installation.

Perhaps this is the core question (for me): What do you expect most/casual 
users to download and install?

Let me expand on this more. Right now, us developers distinguish between 
sage-the-library and sage-the-distribution internally, but when we go to 
"sell" our product, there is but one Sage (to rule them all). There is no 
outward facing sign that a user needs to care about the technical 
implementation details, but I feel they shouldn't. They can treat Sage as a 
black-box until they have a reason not to (e.g., trying to fix a bug or 
prove some code is correct). I think we need to keep this end-user 
experience in the forefront of our minds.

Best,
Travis

-- 
You received this message because you are subscribed 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/8edaf240-b378-437d-9a61-d9f37a7cd9a0n%40googlegroups.com.

Re: [sage-devel] Modularization project: I. The goals

['Travis Scrimshaw' via sage-devel]

I strongly disagree with your conclusion that this is a bug, much less a 
severe one. My understanding of William's goal (please correct me if I am 
wrong) was to put everything together so nobody was trying to build a 
better wheel. To me, by splitting everything up into these small pieces, it 
seems contrary to that goal as how is someone suppose to know the piece 
they want already exists? For instance, the backend libraries all have 
existed on their own, and they aren't going to change.

What you seem to be proposing is a large maintenance burden as we have to

1) Write code that keeps the modularization both "upstream" and 
"downstream" within Sage's ecosystem.
1b) Write code in nonstandard ways to break certain dependencies that are 
there in practice.
2) Write doctests with tags (at various levels, e.g., individual, block, 
module) that will need to be updated.
2) Test the code with all of the different dependencies so we don't break 
(1) and (2).

My reading is that your main goal is to make Sage pip-installable, but that 
seems independent of breaking Sage up into smaller parts. Even breaking up 
Sage into smaller portions for more 'precise' dependencies for these 
supposed downstream Python developers won't really fix B and C. I agree 
with Dima that splitting off some of the smaller pieces into 
pip-installable projects that Sage then depends on is a good thing to do, 
but I think this is better down with a bottom-up approach by taking it away 
piece by piece.

I also would like to see an increase in the number of developers and users. 
Yet, we are still primarily math software with an eye towards research, 
which means we will always have a somewhat limited developer base. I am 
hoping you could answer the following questions in detail with your next 
post.

I) How do you expect the amount of work the average developer will have to 
put in to add a new component (e.g., a Python module on a new linear 
optimization routine) to Sage? To fix a small bug? A larger bug (say, 
requiring changing 3 or 5 files)?
II) Related to (I), but what automated tools do you expect to produce and 
when will they be available? What extend will they reduce the developer 
overhead? How accessible with their output be to read?
III) How do you expect this to bring new developers in? Do you have any 
evidence (including anecdotal) that this would increase the number of 
developers? (Since switching to GH, I have not noticed much of a change in 
the number of developers or the amount of contributions. I recall this 
being one of the claimed benefits to the switch. This feels like it should 
have had a larger impact than the proposed modularization.) Why would these 
larger-Python-ecosystem developers even contribute their code to Sage 
rather than just do their own off-shoot/one-off projects (that we wouldn't 
know about)?
IV) How would a user know what components are out there? Why don't we need 
to first have a better package-manager/distribution-platform/etc. first 
(which includes all of the downstream Sage pip-packages) before we try to 
split Sage up? I would expect this to be a requirement for modularization. 
Or are you still expecting people just to install one "Sage" thing and 
never have to worry about anything else?
V) How are we going to make sure code doesn't bitrot? In particular, who is 
responsible for fixing code that breaks "downstream"? Right now, that is 
clearly the work of the author(s), but could the following situation 
happen? Suppose we have a base Sage module A, then Bob writes his own 
separate library B that depends on A that we then include as part of the 
main "Sage" distribution. I make a change to A that breaks B. Who should 
fix it? What if Bob is no longer maintaining B?

There are many things I would like to see with your proposal included into 
Sage, and thank you for undertaking such a huge project. I have some 
reservations about the benefits over the costs, and I think it would be 
beneficial to have a more detailed plan before proceeding further.

Best,
Travis

On Friday, June 9, 2023 at 4:48:15 PM UTC+9 Matthias Koeppe wrote:

> On Friday, June 9, 2023 at 12:40:52 AM UTC-7 Dima Pasechnik wrote:
>
> some other examples of such pip-installable spin-offs of parts of 
> Sage, some with binary wheels, some without, are pplpy, cysignals, 
> primecountpy 
> (more of this should come)
>
>
> Yes! Making sure that all of these have (automatically built) binary 
> wheels would be very important work.
>  
>
> At some point we should consider fully switching to gmpy2 to provide 
> interfaces for gmp, mpfr, etc.
>
>
> Indeed. This idea is tracked in 
> https://github.com/sagemath/sage/issues/35559 and if this can be done 
> without sacrificing performance, this would be a welcome simplification.
>
>  
>

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

[sage-devel] Re: Modularation doctests

['Travis Scrimshaw' via sage-devel]

Hi Matthias,

Happy to see that you are curious regarding the modularization project, but 
I don't think it's a good approach to start this discussion with claims 
that sound authoritative ("nobody will actually maintain", "does not 
scale", "nearly all end users", etc.) and a policy proposal. 


Yes, you're right. I do not have any hard analytic data to support what 
users want and are doing, and that observation is based solely on my years 
of experience with working with Sage, going to and speaking at SageDays, 
and convincing people to start using Sage. However, there is clear evidence 
that the current approach is not scaling by the amount of work that is 
going in and frequent updates/fixed that is needed to be done. Currently, 
only you are the one doing this. Some of that is the lack of discussion 
(which I would like to have seen given the large scale nature of this 
change, which is implicitly setting policy by default). You can disagree 
with my conclusions and proposal, but I want to actually talk about that 
rather than having dismissive comments. Can you provide any specific 
counterpoints and your expectations? What you posted on the other thread 
does not address any of these.

Best,
Travis

-- 
You received this message because you are subscribed 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/84fbc2ed-00c8-4ca6-8aa7-d4c74e8c2455n%40googlegroups.com.

[sage-devel] Modularation doctests

['Travis Scrimshaw' via sage-devel]

Dear everyone,
   I would first like to thank the people who are working to improve the 
Sage development and build process. However, I am starting to become 
concerned about what is being done about the modularization of SageMath. 
Specifically, it is involving the patchbombs (e.g., 
https://github.com/sagemath/sage/pull/35742) with labeling doctests that 
nobody will actually maintain beyond possibly Matthias. Furthermore, the 
large amount of optional labels, especially with no actual optional 
packages, is starting to scare some users. I tell them they can ignore it, 
but I feel that is not giving off a good impression. It is even more 
confounding for people who are starting to develop (e.g., the GSoC 
students).

In short, the current approach to modularization and doctests does not 
scale. I also feel the cost-benefit ratio is too high.

I think we need a new approach, something that is both hidden from the 
end-user (who will essentially never care about anything that is supposed 
to be in the "standard" distribution of Sage) and allows developers much 
more ease to actually develop (including Matthias who will largely be the 
one who will have to fix these).

My proposal is that we *only* have top-of-the-file indicators for doctests 
unless there is a very compelling reason not to. That is, always do

# sage.doctest: optional - sage.modules sage.rings.finite_rings

at the beginning of files. This will hide what should be unnecessary 
details from nearly all end users (for example, who really would not 
install symbolics with Sage on a general install?), make the public 
documentation cleaner, reduce the maintenance for modularization, be an 
easy paradigm for all developers, and have a specific location for all 
relevant information regarding dependencies.

I think there is general consensus that we should make Sage better in terms 
of being a distribution (albeit with some personal reservations with ending 
up at the "grass is greener on the other side" feeling). Yet, I really do 
not see the benefit to having such optional markings localized to 
individual doctests, which often then have to propagate to subsequent ones.

Best,
Travis

-- 
You received this message because you are subscribed 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/247a2ac0-47c4-4126-afc0-fc95cf0cba56n%40googlegroups.com.

[sage-devel] Re: Ideals in LaurentPolynomialRing

['Travis Scrimshaw' via sage-devel]

Dear Enrique,
   I am having a bit of trouble understanding exactly what computations are 
slow and fast from your description. As Nils said, can you give us some 
explicit code (with some comments about which parts are slow)?

Best,
Travis

On Tuesday, May 30, 2023 at 3:28:39 AM UTC+9 Nils Bruin wrote:

> Dear Enrique,
>
> From what you write I get the impression you may be talking about a 
> regression in performance relative to earlier versions of sage. If you want 
> to make an actionable item out of this, you'll probably have to file a 
> ticket with explicit code on it that can be profiled; preferably with an 
> indication why you think the performance could be significantly improved. 
> That doesn't guarantee someone will work on it but it at least gives them a 
> place to start if they want to, including you yourself! You could file it 
> as an "enhancement" or even as a "bug" if you can convincingly show it's a 
> regression. In the latter case you would probably end up identifying a 
> version in which performance was significantly better. A git diff on some 
> of the relevant files could then perhaps very quickly show what's happening.
>
>
>
> On Monday, 29 May 2023 at 09:07:07 UTC-7 enriqu...@gmail.com wrote:
>
>> Some time ago I had some computations on ideals in Laurent polynomial 
>> rings, namely looking for minimal associated primes. Basically, I converted 
>> any generator into a polynomial, study the ideal in the polynomial ring, 
>> and forget the prime ideals containing monomials. From some time ago, it is 
>> much easier since it can be done directly in the ring of Laurent 
>> polynomials. 
>> Yesterday these computations on an ideal with 80 generators were really 
>> slow, but for some reason I checked that if the generators were converted 
>> to elements in the associated polynomial ring, and then the ideal in the 
>> Laurent polynomial ring is constructed, then those computations were solved 
>> really fast. 
>> I checked the code but I was not able to isolate the reason. Best, 
>> Enrique.
>>
>

-- 
You received this message because you are subscribed 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/0783cb4b-1485-4b98-b651-99bb4e6677dbn%40googlegroups.com.

[sage-devel] SageMath is part of GSoC 2023!

['Travis Scrimshaw' via sage-devel]

Hi everyone,
   We were accepted as a mentor organization this year for Google's Summer 
of Code!

For those who were not previously added as a mentor last year (and want to 
be this year), please email me or respond here.

Best,
Travis

PS - Sorry for being slightly delayed on the announcement here.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/cbfcc346-3b35-47a6-a4c1-9c1882db2812n%40googlegroups.com.

[sage-devel] Re: SkewTableaux are not hashable?

['Travis Scrimshaw' via sage-devel]

Fixed in https://github.com/sagemath/sage/pull/35138

Best,
Travis


On Wednesday, February 15, 2023 at 12:31:54 PM UTC+9 Travis Scrimshaw wrote:

> Hi Martin,
>This happens because it overrides __eq__. It probably would be better 
> to replace it by a __richcmp__ anyways, which might even fix this problem. 
> It has a few easy solutions. I will try to do a PR today for it.
>
> Best,
> Travis
>
> On Wednesday, February 15, 2023 at 3:06:58 AM UTC+9 Martin R wrote:
>
>> sage: hash(SkewTableau([[1]]))
>>
>> ---
>> TypeError Traceback (most recent call 
>> last)
>> Cell In [48], line 1
>> > 1 hash(SkewTableau([[Integer(1)]]))
>>
>> TypeError: unhashable type: 'SkewTableaux_with_category.element_class'
>>
>> It inherits from ClonableList, I would have thought that this 
>> automatically provides a hash.  But of course:
>>
>> # __hash__ is not properly inherited if comparison is changed
>> # see <http://groups.google.com/group/cython-users/t/e89a9bd2ff20fd5a
>> >
>>
>> :-(
>>
>> Martin
>>
>

-- 
You received this message because you are subscribed 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/6e8b8d5d-09a5-4a8b-a6dc-07affad9b11dn%40googlegroups.com.

[sage-devel] Ticket (now issue/PR) tag

['Travis Scrimshaw' via sage-devel]

To the github transition team,

Is there a sphinx tag for issues to replace :trac:`12345`?

Travis

-- 
You received this message because you are subscribed 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/0c1e254a-5e05-46e5-8dfb-bd9eef1a88cfn%40googlegroups.com.

[sage-devel] Re: SkewTableaux are not hashable?

['Travis Scrimshaw' via sage-devel]

Hi Martin,
   This happens because it overrides __eq__. It probably would be better to 
replace it by a __richcmp__ anyways, which might even fix this problem. It 
has a few easy solutions. I will try to do a PR today for it.

Best,
Travis

On Wednesday, February 15, 2023 at 3:06:58 AM UTC+9 Martin R wrote:

> sage: hash(SkewTableau([[1]]))
> ---
> TypeError Traceback (most recent call last)
> Cell In [48], line 1
> > 1 hash(SkewTableau([[Integer(1)]]))
>
> TypeError: unhashable type: 'SkewTableaux_with_category.element_class'
>
> It inherits from ClonableList, I would have thought that this 
> automatically provides a hash.  But of course:
>
> # __hash__ is not properly inherited if comparison is changed
> # see 
>
> :-(
>
> Martin
>

-- 
You received this message because you are subscribed 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/346e2dd4-bca2-4e12-9e33-e66de840a805n%40googlegroups.com.

[sage-devel] Re: The definition of one blankline

['Travis Scrimshaw' via sage-devel]

Okay, so mostly this ticket is just noise by me as the specification is 
highly misleading. It is really looking for an end-of-line character \n at 
the end of the file, which does not give a blankline. It would be good if 
we could somehow explain this somewhere, especially in how the linter 
fails. Although I guess we don't have much choice about that... *sigh*

Best,
Travis


On Monday, February 13, 2023 at 4:33:36 PM UTC+9 Travis Scrimshaw wrote:

> Hi everyone,
>To me, the title seems obvious, but I hold a different opinion than the 
> linter that has become an enforced code style. I want to see what the 
> consensus of the community is on this.
>
> Paraphrasing slightly from https://www.flake8rules.com/rules/W391.html, 
> there should be one and exactly one blank line. Not zero, not two.
>
> To me, a blank line at the end of a file would be
>
> "
> blah
>
> "
>
> In particular, there is a "\n" at the end of "blah" with nothing else 
> beyond it exact the EOF character. However, our linter is currently trying 
> to enforce that files end as
>
> "
> blah
> "
>
> In particular, immediately after "blah" is the EOF. In my mind, this is 
> zero blanklines. Otherwise I see no way to obtain zero blanklines as per 
> the specification.
>
> My 2 cents, I enjoy having that blankline as additional separation of the 
> code from the bottom of my screen, although it is a bit of a more 
> historical artifact from what I found by reading SE and SO. If we agree 
> that we want to keep enforcing the current linter specification (which I 
> don't recall we agreed to as a community, but I do really appreciate all of 
> the work Frédéric has done to standardize the code) but also agree that it 
> is not enforcing one blankline, can we change the output somehow to not 
> suggest a contradiction?
>
> Best,
> Travis
>
>
>
>

-- 
You received this message because you are subscribed 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/ab8fb914-13ae-4b8f-b7d2-0ddf63bee545n%40googlegroups.com.

[sage-devel] The definition of one blankline

['Travis Scrimshaw' via sage-devel]

Hi everyone,
   To me, the title seems obvious, but I hold a different opinion than the 
linter that has become an enforced code style. I want to see what the 
consensus of the community is on this.

Paraphrasing slightly from https://www.flake8rules.com/rules/W391.html, 
there should be one and exactly one blank line. Not zero, not two.

To me, a blank line at the end of a file would be

"
blah

"

In particular, there is a "\n" at the end of "blah" with nothing else 
beyond it exact the EOF character. However, our linter is currently trying 
to enforce that files end as

"
blah
"

In particular, immediately after "blah" is the EOF. In my mind, this is 
zero blanklines. Otherwise I see no way to obtain zero blanklines as per 
the specification.

My 2 cents, I enjoy having that blankline as additional separation of the 
code from the bottom of my screen, although it is a bit of a more 
historical artifact from what I found by reading SE and SO. If we agree 
that we want to keep enforcing the current linter specification (which I 
don't recall we agreed to as a community, but I do really appreciate all of 
the work Frédéric has done to standardize the code) but also agree that it 
is not enforcing one blankline, can we change the output somehow to not 
suggest a contradiction?

Best,
Travis



-- 
You received this message because you are subscribed 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/493c92d7-cf77-4be5-b59c-ce07b74299f9n%40googlegroups.com.

Re: [sage-devel] Re: positively reviewed tickets on trac - do they need PRs?

['Travis Scrimshaw' via sage-devel]

It's a logical bug that didn't have a doctest; it was found when doing a 
computation further down (beyond the use-cases it was tested for). It would 
be much easier just to change it for the ticket/issue/PR/etc. It wasn't 
long after setting a positive review, but we did find it in the transition 
window.

Travis


On Thursday, February 9, 2023 at 4:56:40 PM UTC+9 dim...@gmail.com wrote:

>
>
> On Thu, 9 Feb 2023, 06:46 'Travis Scrimshaw' via sage-devel, <
> sage-...@googlegroups.com> wrote:
>
>> So we don't have PR for all of the positive reviewed tickets. They are 
>> just going to be merged? What happens if we found a problem with one of the 
>> +rev tickets and want to change something?
>>
>
> I hope Volker checks the respective issue on GitHub, whether it says 
> "positive review", or not.
>
>
>
>> Best,
>> Travis
>>
>>
>> On Thursday, February 9, 2023 at 8:43:28 AM UTC+9 Volker Braun wrote:
>>
>>> But also: Please don't merge branches into develop until it is 
>>> absolutely necessary for the github transition (issue templates or ci setup)
>>>
>>> On Tuesday, February 7, 2023 at 6:23:54 PM UTC+1 Dima Pasechnik wrote:
>>>
>>>> We have positively reviewed tickets on trac - do we need to do 
>>>> anything, or just wait for the release manager to merge them? 
>>>>
>>>> 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/009d68e2-ef36-4cf3-ba5d-2af3b9f7a1afn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/009d68e2-ef36-4cf3-ba5d-2af3b9f7a1afn%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/61cf909b-0ef2-4ce2-a715-7bf9ed7cfce4n%40googlegroups.com.

[sage-devel] Re: GH Notifications

['Travis Scrimshaw' via sage-devel]

No, not that. I have set that up, but I want email notifications via GH 
anytime someone does, say, @tscrim or modifies an issue/PR I am involved 
in. I have subscribed myself and changed my GH settings to send emails. 
However, there are other repos I am involved with that I do *not* want 
emails from. All I see is an all-or-nothing for getting emails. I don't 
want to ignore GH notifications from certain repos, but I don't want to get 
emails from them either. Of course I can setup an email filter to look for 
"Sage", but I would much rather do this on the GH side.

Travis


On Thursday, February 9, 2023 at 5:04:36 PM UTC+9 Kwankyu Lee wrote:

> The "Watch" menu at the upper right corner does what you want?
>
> On Thursday, February 9, 2023 at 3:54:07 PM UTC+9 Travis Scrimshaw wrote:
>
>> I liked getting emails from trac when changes to tickets I cared about 
>> happened. However, I only want emails from notifications related to 
>> SageMath. I see that there is a routing to chose which account it will go 
>> to. Yet, I don't see a way to say "only from Sage I want email 
>> notifications".
>>
>> Is there any way to do this or do I have to set up an email filter?
>>
>> Travis
>>
>>

-- 
You received this message because you are subscribed 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/04cb4596-9619-4387-b5b1-684274c44fcdn%40googlegroups.com.

[sage-devel] GH Notifications

['Travis Scrimshaw' via sage-devel]

I liked getting emails from trac when changes to tickets I cared about 
happened. However, I only want emails from notifications related to 
SageMath. I see that there is a routing to chose which account it will go 
to. Yet, I don't see a way to say "only from Sage I want email 
notifications".

Is there any way to do this or do I have to set up an email filter?

Travis

-- 
You received this message because you are subscribed 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/86daa446-adbc-43f0-bbbd-d120b10f5ce5n%40googlegroups.com.

[sage-devel] Re: positively reviewed tickets on trac - do they need PRs?

['Travis Scrimshaw' via sage-devel]

So we don't have PR for all of the positive reviewed tickets. They are just 
going to be merged? What happens if we found a problem with one of the +rev 
tickets and want to change something?

Best,
Travis


On Thursday, February 9, 2023 at 8:43:28 AM UTC+9 Volker Braun wrote:

> But also: Please don't merge branches into develop until it is absolutely 
> necessary for the github transition (issue templates or ci setup)
>
> On Tuesday, February 7, 2023 at 6:23:54 PM UTC+1 Dima Pasechnik wrote:
>
>> We have positively reviewed tickets on trac - do we need to do
>> anything, or just wait for the release manager to merge them?
>>
>> 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/009d68e2-ef36-4cf3-ba5d-2af3b9f7a1afn%40googlegroups.com.

[sage-devel] Re: Sage GSoC2023 Ideas Page

['Travis Scrimshaw' via sage-devel]

Hi everyone,
   I know things are a bit hectic with the transition right now. However, 
the deadline for submitting our GSoC proposal is tomorrow (at least for 
me). I would appreciate it if you could add a project (you don't have to 
agree to be a mentor) or let me know if you are willing to mentor a project 
(you do not need to have a specific project in mind/written). The GSoC 
rules this year seem to indicate that the duration of the project is 
somewhat variable, and as such, can be more focused on implementing more 
targeted features. Let me know if you have any questions.

Best,
Travis


On Tuesday, January 31, 2023 at 11:42:48 AM UTC+9 Travis Scrimshaw wrote:

> Hi everyone,
>The deadline for SageMath to submit its GSoC organization application 
> is February 7th, 18:00 UTC. If you are interested in mentoring a project, 
> please post it to the ideas page:
>
> https://wiki.sagemath.org/GSoC/2023
>
> Best,
> Travis
>
>

-- 
You received this message because you are subscribed 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/83d8f2c9-0bd5-446e-8e83-a71196c6c41fn%40googlegroups.com.

[sage-devel] Re: Sage GSoC2023 Ideas Page

['Travis Scrimshaw' via sage-devel]

Hi Martin,
   I think that would be a good project. I can put in a quick sketch on the 
ideas page. It doesn't need to be anything fully thought out (that is 
really for the applicant to do in some sense).

Thanks,
Travis


On Thursday, February 2, 2023 at 6:17:30 PM UTC+9 axio...@yahoo.de wrote:

> I would be interested in continuing our work on combinatorial species, but 
> I am away until the 6th of February, and it is not clear to me whether it 
> would make a good project.  What do you think?  Are improvements to 
> existing code welcome?
>
> Martin
>
> On Tuesday, 31 January 2023 at 03:42:48 UTC+1 Travis Scrimshaw wrote:
>
>> Hi everyone,
>>The deadline for SageMath to submit its GSoC organization application 
>> is February 7th, 18:00 UTC. If you are interested in mentoring a project, 
>> please post it to the ideas page:
>>
>> https://wiki.sagemath.org/GSoC/2023
>>
>> Best,
>> Travis
>>
>>

-- 
You received this message because you are subscribed 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/e9688e4f-a90b-4187-8cef-f027182a7e30n%40googlegroups.com.

[sage-devel] Sage GSoC2023 Ideas Page

['Travis Scrimshaw' via sage-devel]

Hi everyone,
   The deadline for SageMath to submit its GSoC organization application is 
February 7th, 18:00 UTC. If you are interested in mentoring a project, 
please post it to the ideas page:

https://wiki.sagemath.org/GSoC/2023

Best,
Travis

-- 
You received this message because you are subscribed 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/991d6ac2-06a1-46a2-b920-d60879468fabn%40googlegroups.com.

Re: [sage-devel] Re: containment in a set different from containment in a set - help needed

['Travis Scrimshaw' via sage-devel]

> I must admit that I do not understand the philosophy.
>

Which part? 

>
> But apart from that: for classes inheriting from ClonableArray, which have 
> to implement equality (because there is no coercion to a common parent), do 
> they have to implement _richcmp_ or __richcmp__ or _eq_ or __eq__?  (The 
> amount of magic in python / sagemath is extremely confusing to me.)
>

Double underscore stuff is usually Python (sometimes Cython; or mimicked 
with __richcmp__). Single underscores tend to be hooks that Sage (or a 
particular class) has set up to either avoid inheritance issues and/or 
allow more flexibility in subclasses.

Best,
Travis


> On Tuesday, 13 December 2022 at 01:09:52 UTC+1 Travis Scrimshaw wrote:
>
>> +1 on what Nils said; I only find it slightly surprising initially. 
>> Compare this with comparing a list to a Partition as well. Equality is a 
>> bit different as a programming concept than a mathematical one. When you 
>> implement a custom __eq__, then you are separating that class from the 
>> coercion-based equality.
>>
>> +1 on removing the parent from the hash of ClonableArray and its family 
>> tree.
>>
>> Best,
>> Travis
>>
>> On Tuesday, December 13, 2022 at 1:56:46 AM UTC+9 Nils Bruin wrote:
>>
>>> On Monday, 12 December 2022 at 00:22:30 UTC-8 axio...@yahoo.de wrote:
>>>
>>>> Ah, thank you so much!
>>>>
>>>> Just to make sure that I understand the philosophy: if two elements are 
>>>> supposed to compare equal, they should have parents which can be coerced 
>>>> to 
>>>> a common parent, right?  For example, the following (which is current 
>>>> behaviour) is not really what we want:
>>>>
>>>> sage: A = SetPartitions(3)([[1,2],[3]])
>>>> sage: B = SetPartition([[1,2],[3]])
>>>> sage: A == B
>>>> True
>>>> sage: coercion_model.common_parent(A, B)
>>>>
>>> TypeError: no common canonical parent for objects with parents: 'Set 
>>>> partitions of {1, 2, 3}' and 'Set partitions'
>>>>
>>>
>>>> I think that is a bit surprising, but if SetPartitions don't really 
>>> occur much in binary operations I think it will be a hardly visible quirk. 
>>> One has to be careful generalizing principles about how to implement 
>>> coercion/equality/hashing because we a;ready know that some of the things 
>>> we want lead to inconsistencies.
>>>
>>> When in doubt, the safe thing is definitely to NOT install coercions (it 
>>> can always be done later), so I'd hesitate to recommend to change the 
>>> behaviour above. I think you'd want at least a practical use case to 
>>> justify it.
>>>
>>> Note that the relevant conversions: A.parent()(B) and B.parent()(A) do 
>>> work.
>>>
>>> It seems to me the converse implication, if for two elements the 
>>> coercion framework is happy to find a common parent in which they compare 
>>> equal, then they should be equal in the first place, sounds a little more 
>>> probable, but I suspect one can get problematic situations from that too.
>>>
>>

-- 
You received this message because you are subscribed 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/5bb18894-a83f-4f3e-b3dd-b90687aaacc6n%40googlegroups.com.

Re: [sage-devel] Re: containment in a set different from containment in a set - help needed

['Travis Scrimshaw' via sage-devel]

+1 on what Nils said; I only find it slightly surprising initially. Compare 
this with comparing a list to a Partition as well. Equality is a bit 
different as a programming concept than a mathematical one. When you 
implement a custom __eq__, then you are separating that class from the 
coercion-based equality.

+1 on removing the parent from the hash of ClonableArray and its family 
tree.

Best,
Travis

On Tuesday, December 13, 2022 at 1:56:46 AM UTC+9 Nils Bruin wrote:

> On Monday, 12 December 2022 at 00:22:30 UTC-8 axio...@yahoo.de wrote:
>
>> Ah, thank you so much!
>>
>> Just to make sure that I understand the philosophy: if two elements are 
>> supposed to compare equal, they should have parents which can be coerced to 
>> a common parent, right?  For example, the following (which is current 
>> behaviour) is not really what we want:
>>
>> sage: A = SetPartitions(3)([[1,2],[3]])
>> sage: B = SetPartition([[1,2],[3]])
>> sage: A == B
>> True
>> sage: coercion_model.common_parent(A, B)
>>
> TypeError: no common canonical parent for objects with parents: 'Set 
>> partitions of {1, 2, 3}' and 'Set partitions'
>>
>
>> I think that is a bit surprising, but if SetPartitions don't really occur 
> much in binary operations I think it will be a hardly visible quirk. One 
> has to be careful generalizing principles about how to implement 
> coercion/equality/hashing because we a;ready know that some of the things 
> we want lead to inconsistencies.
>
> When in doubt, the safe thing is definitely to NOT install coercions (it 
> can always be done later), so I'd hesitate to recommend to change the 
> behaviour above. I think you'd want at least a practical use case to 
> justify it.
>
> Note that the relevant conversions: A.parent()(B) and B.parent()(A) do 
> work.
>
> It seems to me the converse implication, if for two elements the coercion 
> framework is happy to find a common parent in which they compare equal, 
> then they should be equal in the first place, sounds a little more 
> probable, but I suspect one can get problematic situations from that too.
>

-- 
You received this message because you are subscribed 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/b91b40db-760e-4df4-bbb8-7e1c144f9f56n%40googlegroups.com.

Re: [sage-devel] Re: GAPError when using .molien_series()

['Travis Scrimshaw' via sage-devel]

The entire computation in PermutationGroup.molien_series() all appears to 
be done in libgap. Sage's wrapper around characters is never really invoked 
at all AFAICS. Here is a curious data point:

sage: PG = PermutationGroup(["(1,2,3,4,5,6,7)","(5,6,7)"])
sage: g = PG._libgap_()
sage: pi = g.NaturalCharacter()
sage: pi += g.TrivialCharacter() * len(PG.fixed_points())
sage: pi2 = libgap.VirtualCharacter(g.CharacterTable(), pi)
sage: pi2.MolienSeries()
( 1-z^3+z^6-z^9+z^12-z^15+z^18 ) / ( 
(1-z^7)*(1-z^5)*(1-z^4)*(1-z^3)^2*(1-z^2)*(1-z) )
sage: PG.molien_series()
(-x^18 + x^15 - x^12 + x^9 - x^6 + x^3 - 1)/(x^25 - x^24 - x^23 - x^22 + 
x^21 + 2*x^20 + x^19 - x^17 - x^16 - x^15 - x^13 + x^12 + x^10 + x^9 + x^8 
- x^6 - 2*x^5 - x^4 + x^3 + x^2 + x - 1)

I just ran the code in PG.molien_series() directly first, and then calling 
it now works.

Best,
Travis

On Friday, December 9, 2022 at 8:49:55 PM UTC+9 dim...@gmail.com wrote:

> On Fri, Dec 9, 2022 at 2:55 AM 'Travis Scrimshaw' via sage-devel
>  wrote:
> >
> > By running the code in molien_series() directly in Sage, I can do the 
> computation, but not by calling the method. So it seems to be something 
> within Sage with the interface with libgap.
>
> not really, it's just the character tables in Sage that need work, for
> a proper conversion to use libgap - they cause the issue with
> moilen_series.
> The following (avoiding Sage's characters all together) works just fine:
>
> sage: p=PermutationGroup(["(1,2,3,4,5,6,7)","(5,6,7)"])
> sage: 
> ms=libgap(p).PermutationCharacter([1..7],libgap.OnPoints).MolienSeries();
> ms
> ( 1-z^3+z^6-z^9+z^12-z^15+z^18 ) / (
> (1-z^7)*(1-z^5)*(1-z^4)*(1-z^3)^2*(1-z^2)*(1-z) )
> sage: type(ms)
> 
> sage: ms.sage()
> (x_1^18 - x_1^15 + x_1^12 - x_1^9 + x_1^6 - x_1^3 + 1)/(-x_1^25 +
> x_1^24 + x_1^23 + x_1^22 - x_1^21 - 2*x_1^20 - x_1^19 + x_1^17 +
> x_1^16 + x_1^15 + x_1^13 - x_1^12 - x_1^10 - x_1^9 - x_1^8 + x_1^6 +
> 2*x_1^5 + x_1^4 - x_1^3 - x_1^2 - x_1 + 1)
> sage: type(ms.sage())
> 
>
> I'm working on https://trac.sagemath.org/ticket/26902 (fixing
> character tables would be a part of it) - and it needs more hands.
> Dima
> >
> > Best,
> > Travis
> >
> >
> > On Friday, December 9, 2022 at 8:55:15 AM UTC+9 guru@gmail.com 
> wrote:
> >>
> >> Hi,
> >> i ran into a bug while trying to compute the molien series of a 
> permutation group.
> >>
> >> SageMath version 9.3, Release Date: 2021-05-09, Using Python 3.7.10.
> >> Operating system: Windows 11, 64-bit
> >>
> >> It works fine for most permutation groups but calling:
> >>
> >> PermutationGroup(["(1,2,3,4,5,6,7)","(5,6,7)"]).molien_series()
> >>
> >> gives an GAP Error which doesn't make sense to me in the given context.
> >>
> >> GAPError: Error, ^ cannot be used here to compute roots (use `RootInt' 
> instead?)
> >>
> >> Similar examples which also produce the same bug are:
> >>
> >> PermutationGroup(["(1,2,3,4,5,7)","(5,6,7)"]).molien_series()
> >> PermutationGroup(["(1,2,3,4,7)","(5,6,7)"]).molien_series()
> >> PermutationGroup(["(1,2,3,4,7)","(5,7,8)"]).molien_series()
> >>
> >> Thanks for looking into it.
> >> Kind regards,
> >> Jonas
> >>
> >>
> > --
> > You received this message because you are subscribed 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/2c1fcce4-946f-43cd-9ae4-a04c73434192n%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/42c6be87-614e-4a21-9273-91948f0c6216n%40googlegroups.com.

Re: [sage-devel] Re: containment in a set different from containment in a set - help needed

['Travis Scrimshaw' via sage-devel]

Let me mostly rephrase what Nils said above with a bit more of specific 
information. I would say this issue comes from a "feature" of 
ClonableArray. The default hashing of ClonableArray is to also hash in the 
parent and have elements in different parents not (by default) compare 
equal. A coercion needs to get involved for "natural" equality (i.e., 
ignoring the parent), which is a general issue within Sage.

Best,
Travis


On Monday, December 5, 2022 at 6:03:53 PM UTC+9 Nils Bruin wrote:

> On Sunday, 4 December 2022 at 23:45:00 UTC-8 j...@aims.ac.za wrote:
>
>> Note sage 9.2 (debian package) gives an error (sage 9.7 does not):
>>
>>  
> Probably the following ticket then (Scrimshaw/Chapoton):
>  
> https://trac.sagemath.org/ticket/15216 
>
>
>

-- 
You received this message because you are subscribed 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/d16d8237-e625-4256-80df-97a23528b79dn%40googlegroups.com.

[sage-devel] Re: GAPError when using .molien_series()

['Travis Scrimshaw' via sage-devel]

By running the code in molien_series() directly in Sage, I can do the 
computation, but not by calling the method. So it seems to be something 
within Sage with the interface with libgap.

Best,
Travis


On Friday, December 9, 2022 at 8:55:15 AM UTC+9 guru@gmail.com wrote:

> Hi, 
> i ran into a bug while trying to compute the molien series of a 
> permutation group. 
>
> SageMath version 9.3, Release Date: 2021-05-09,  Using Python 3.7.10. 
> Operating system: Windows 11, 64-bit
>
> It works fine for most permutation groups but calling: 
>
> PermutationGroup(["(1,2,3,4,5,6,7)","(5,6,7)"]).molien_series()
>
> gives an GAP Error which doesn't make sense to me in the given context. 
>
> GAPError: Error, ^ cannot be used here to compute roots (use `RootInt' 
> instead?)
>
> Similar examples which also produce the same bug are:
>
> PermutationGroup(["(1,2,3,4,5,7)","(5,6,7)"]).molien_series()
> PermutationGroup(["(1,2,3,4,7)","(5,6,7)"]).molien_series()
> PermutationGroup(["(1,2,3,4,7)","(5,7,8)"]).molien_series()
>   
> Thanks for looking into it. 
> Kind regards, 
> Jonas
>
>
>

-- 
You received this message because you are subscribed 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/2c1fcce4-946f-43cd-9ae4-a04c73434192n%40googlegroups.com.

[sage-devel] Re: Is this a bug?

['Travis Scrimshaw' via sage-devel]

No, it is not. The generic fraction field can only reduce something up to a 
unit since the gcd is defined up to a unit. I agree it looks funny, but I 
don't see a sensible way to code to get a negative sign in the numerator. 
Compare with

sage: ~F(-q+1)
1/(-q + 1)
sage: ~F(q-1)
1/(q - 1)
sage: -1 / F(-q+1)
(-1)/(-q + 1)
sage: -1 / F(q-1)
(-1)/(q - 1)

Of course, there are two distinct elements here, but which ones are the 
"correct" way to print stuff? Not to mention if we are doing something in a 
more general integral domain (or polynomials with a completely different 
implementation).

Something could be done when the denominator is a unit not equal to one 
though. Possibly only in the printing however (i.e., not in the reduce() 
method and its internal representation) in order to reduce the amount of 
computations when manipulating such elements.

Best,
Travis


On Wednesday, September 21, 2022 at 10:22:30 PM UTC+9 axio...@yahoo.de 
wrote:

> sage: R. = QQ[]
> sage: F = R.fraction_field()
> sage: ~F(-1)
> 1/(-1)
> sage: 1/F(-1)
> -1
> sage: R. = QQ[]
> sage: F = R.fraction_field()
> sage: ~F(-1)
> -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/8b17a45a-c067-45b6-a2e5-5cbd80f8d6f6n%40googlegroups.com.

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

['Travis Scrimshaw' via sage-devel]

-1

On Thursday, September 22, 2022 at 11:50:56 AM UTC+9 dev@gmail.com 
wrote:

> +1 for Github
>
> 在2022年9月22日星期四 UTC+8 06:01:46 写道：
>
>> +1 for Github
>>
>> Op wo 21 sep. 2022 19:23 schreef David Roe :
>>
>>> Dear Sage developers,
>>> Following extensive discussion, both recently 
>>>  
>>> (prompted 
>>> by issues upgrading the trac server) and over 
>>>  
>>> the 
>>>  
>>> last 
>>>  
>>> decade 
>>> , 
>>> we are calling a vote on switching Sage development from Trac 
>>>  to Github .  
>>> We've created a summary of the pros and cons of each system 
>>> , a 
>>> description 
>>> of the development model to be used on github 
>>> , 
>>> and a trac ticket  for 
>>> coordinating work on the transition.  More work will need to be done to 
>>> carry out the actual transition once voting is complete.
>>>
>>> The voting will last until noon Eastern time (16:00 UTC) on Wednesday, 
>>> October 5.  Please use this thread only for sending votes, to make it 
>>> easier to count them afterward; there is a parallel thread where you can 
>>> make arguments in favor of either system.
>>>
>>> Finally, I will close with a plea to be involved in this vote and 
>>> discussion even if you are not a core Sage developer.  By definition, core 
>>> Sage developers have become comfortable with trac, and I think that one of 
>>> the major arguments in favor of github is that it will help bring in new 
>>> contributors who are not familiar with Sage's development workfow 
>>> .  Anyone who 
>>> has ever contributed to the Sage code base or who maintains a Sage user 
>>> package is welcome to vote.
>>> 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_%3DyvZ869L66E1tFmziWDirbawSEABf_uc_j9Dy8VBFW8w%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/1c0794e1-d4e8-4592-bcfe-cbcdd9496654n%40googlegroups.com.

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

['Travis Scrimshaw' via sage-devel]

On Tuesday, September 13, 2022 at 4:14:26 PM UTC+9 Matthias Koeppe wrote:

> On Tuesday, September 13, 2022 at 12:10:28 AM UTC-7 Travis Scrimshaw wrote:
>
>> How is the workflow that our current developers sometimes use irrelevant? 
>>> Granted, this is a less used feature, but I believe it makes it harder to 
>>> share branches privately. It has been useful for me in the past to have 
>>> this (e.g., some hacked together code meant only to be shared with 
>>> collaborators).
>>>
>>
> I think you'll have to explain what workflow is what you are talking 
> about, and what your concern is.
>

Let's say I want to solve the really hard problem of 2 + 2 for a paper we 
are writing. So I write a branch that does the computation by repeatedly 
adding 1: doing the computation 2 + 1 + 1. We don't plan to include this 
into Sage as it is a horrible hack nor make it public because it will lead 
to a proof of the Riemann Hypothesis (don't want to be scooped). Now you 
also want to run computations or build some code off of it. How do you get 
the code? We do not want to do a PR. With our current setup, I could push 
the branch to the server, email you the branch name, and you could pull it. 
Using GH, my understanding is we would have to share a repo and/or setup 
push/pull rights, which seems more complicated (and what if I want to get 
stuff back from you too?).

Does that clarify things? Admittedly I don't use it that often (and I am 
willing to deal with such issues as they might arise later), but I don't 
know about other practitioners at-large.

-- 
You received this message because you are subscribed 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/05414f99-c449-4951-9f76-1d73175932c8n%40googlegroups.com.

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

['Travis Scrimshaw' via sage-devel]

On Tuesday, September 13, 2022 at 3:30:19 PM UTC+9 Matthias Koeppe wrote:

> On Monday, September 12, 2022 at 10:25:57 PM UTC-7 Travis Scrimshaw wrote:
>
>> whereas with trac, things are highly concentrated on tickets, which are a 
>>>> single point of reference. Using the GH/GL model, we have all of these 
>>>> forks
>>>>
>>>
>>> Irrelevant because in the proposed workflow you never look at another 
>>> developer's fork.
>>>
>>
>> This is not true. You do not have a central point for branch access. Now 
>> because of PRs that get attached to the main project, they do become 
>> centralized.
>>
>
> Yes, in the proposed workflow everything goes through PRs. 
>
> Yes, GitHub, like git, can also be used for other development workflows, 
> but such other workflows are not part of the proposal. Hence irrelevant.
>
> How is the workflow that our current developers sometimes use irrelevant? 
Granted, this is a less used feature, but I believe it makes it harder to 
share branches privately. It has been useful for me in the past to have 
this (e.g., some hacked together code meant only to be shared with 
collaborators).
 

-- 
You received this message because you are subscribed 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/3fb68342-7efb-42d6-8163-89905bb557e3n%40googlegroups.com.

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

['Travis Scrimshaw' via sage-devel]

On Tuesday, September 13, 2022 at 3:36:18 PM UTC+9 Matthias Koeppe wrote:

> On Monday, September 12, 2022 at 10:36:06 PM UTC-7 Travis Scrimshaw wrote:
>
>> Last I remember, using https instead of ssh meant I had to input my UN/PW 
>> every time I did a push or a pull
>>
>
>
> https://docs.github.com/en/get-started/getting-started-with-git/caching-your-github-credentials-in-git
>  
>
I was not aware of that. I don't remember that being there when I first 
started using git and GH (some 10+ years ago I think). Perhaps I should 
have checked this more thoroughly. Nevertheless, good to know.

-- 
You received this message because you are subscribed 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/6f3dc6ec-036d-4941-a684-8e726753b0dfn%40googlegroups.com.

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

['Travis Scrimshaw' via sage-devel]

On Tuesday, September 13, 2022 at 3:42:58 PM UTC+9 Matthias Koeppe wrote:

> On Monday, September 12, 2022 at 10:30:39 PM UTC-7 Travis Scrimshaw wrote:
>
>> Please, Travis, the high activity that you see here is in response to the 
>>> requests for having a fleshed out plan before a discussion can even happen. 
>>> So we fleshed out the plan. 
>>> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
>>>
>>> Maybe I am reading too much into some of the other things that have been 
>> happening, but I got the impression that things are being written as "this 
>> is happening".
>>
>
> Yes, you are mistaken. The description of the proposed workflow has 
> "*Proposed* Workflow" in the heading.
>
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#proposed-workflow-on-github-with-transition-guide-from-trac
> It is the draft of the transition guide to the proposed workflow.
> Of course, the transition guide itself is written from the perspective of 
> how to work with the workflow -- and working with the workflow only makes 
> sense after it has been adopted.
>

>From a number of trac tickets (mainly #30363) and the GitHub UN link thread 
coming across more as a demand to me with the imposed deadline, it gave off 
this impression. Sorry for the overstatement. 

-- 
You received this message because you are subscribed 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/664781bf-19a2-41d4-9c2d-600062d16176n%40googlegroups.com.

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

['Travis Scrimshaw' via sage-devel]

On Tuesday, September 13, 2022 at 2:10:12 PM UTC+9 Matthias Koeppe wrote:

> On Monday, September 12, 2022 at 8:39:50 PM UTC-7 Travis Scrimshaw wrote:
>
>> But people nowadays who start with GitHub never have to go through 
>>> archaic setup steps such as those that we document at 
>>> https://doc.sagemath.org/html/en/developer/trac.html#trac-authentication-through-ssh,
>>>  
>>> which --- even when it is working --- is major friction for the project.
>>>
>>
>> I think it has been just far too long since you uploaded your ssh key to 
>> GH. The server cannot magically know your ssh public key. Yes, we don't 
>> have https support, but other than the most casual of contributors will use 
>> that for push/pull. I highly doubt anyone will use that feature with any 
>> serious commits.
>>
>
> You are guessing wrong. I do not use ssh with GitHub. It works perfectly 
> with https.
>

Last I remember, using https instead of ssh meant I had to input my UN/PW 
every time I did a push or a pull (or maybe it gave me 5 minutes when I 
didn't have to do it). I always felt that was clunky and after having done 
that for a week, I got sick and tired of it and Googled how to store that 
and got to the ssh approach. I figured most other people who make regular 
contributions would enjoy that convenience as well.

I am curious why you use https instead of ssh. Can you explain a bit?

-- 
You received this message because you are subscribed 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/effa7e51-d7aa-4d65-ad4d-24a68ae15386n%40googlegroups.com.

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

['Travis Scrimshaw' via sage-devel]

>
>
> What happens when Bob works on a ticket, but then stops (say, it doesn't 
>> find a reviewer in time). Now Alice wants to make changes on top of that 
>> branch. How does Alice do that? I am particularly thinking about when this 
>> is *not* meant to be a PR review commit (say, it is working with a more 
>> substantial change or just cherry-picking some of the commits). When she is 
>> done, does she do a new PR? After doing quite a bit of digging, I finally 
>> found the answer:
>>
>>
>> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally
>>
>
> Yes, this is one of the links in our document 
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
>

It was buried a bit in there though. I am wanting to avoid "see the fine 
print" type statements.

-- 
You received this message because you are subscribed 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/cbca0c73-c011-450d-b1d8-c111df6a7b87n%40googlegroups.com.

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

['Travis Scrimshaw' via sage-devel]

On Tuesday, September 13, 2022 at 1:39:38 PM UTC+9 Matthias Koeppe wrote:

> On Monday, September 12, 2022 at 8:39:50 PM UTC-7 Travis Scrimshaw wrote:
>
>> First off, we need to slow down significantly as we do not have an 
>> general clear consensus about doing this move.
>>
>
> Please, Travis, the high activity that you see here is in response to the 
> requests for having a fleshed out plan before a discussion can even happen. 
> So we fleshed out the plan. 
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
>
> Maybe I am reading too much into some of the other things that have been 
happening, but I got the impression that things are being written as "this 
is happening". Some of it probably is a mixing of a discussion about 
"should we do the move" versus "how we do the move (should we agree to it)."

-- 
You received this message because you are subscribed 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/5db45a5a-7607-41b3-81fe-607a957c2162n%40googlegroups.com.

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

['Travis Scrimshaw' via sage-devel]

>
>
> The downside (that will always remain to me) with GH/GL is anything with 
>> their web interface is highly decentralized, 
>>
>
> No, no such thing.
>

The fact that PRs and issues are on two completely different pages is 
already decentralized. There is no clear single place for discussion, with 
multiple PRs that can have their own threads.

>  
>
>> whereas with trac, things are highly concentrated on tickets, which are a 
>> single point of reference. Using the GH/GL model, we have all of these forks
>>
>
> Irrelevant because in the proposed workflow you never look at another 
> developer's fork.
>

This is not true. You do not have a central point for branch access. Now 
because of PRs that get attached to the main project, they do become 
centralized. However, I cannot easily share or get a branch from another 
developer that is not linked by a PR.

>
> (which we have to tell newbies are not the same as branches and should not 
>> be used as such).
>>
> There is also more manual things we have to type and sync subject to human 
>> (typo) error. This is likely manageable to me compared to some of the other 
>> benefits (although I will personally experience none of those). Despite 
>> this, I still have reservations about the increased pains of development 
>> from trying to fit a mostly square peg into a round hole, and subsequently 
>> am still opposed to the move
>>
>
> Sorry, this is just a rant based on nothing
>

Matthias, your dismissive attitude is not helpful. I am even starting to 
come around that this move could have benefits that outweigh the costs.

The linking of issues to PRs is something that a human has to manually type 
in, right? (Just today I mistyped a ticket number on trac.) For trac 
tickets, you would have had to not realized you were on the wrong page, 
which is far less subtle. My opposition also based on how easy it is to 
share and manage different branches and communication of things involving a 
single issue.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/32822474-46cd-4965-a777-a949cf541e1an%40googlegroups.com.

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

['Travis Scrimshaw' via sage-devel]

>
>
> But people nowadays who start with GitHub never have to go through archaic 
>>> setup steps such as those that we document at 
>>> https://doc.sagemath.org/html/en/developer/trac.html#trac-authentication-through-ssh,
>>>  
>>> which --- even when it is working --- is major friction for the project.
>>>
>>
>> I think it has been just far too long since you uploaded your ssh key to 
>> GH. The server cannot magically know your ssh public key. 
>>
>
> You are missing that the new contributors will already have set up their 
> GitHub for virtual everything else that they work on. There is no 
> additional such cost for starting to work on a new project that's also 
> hosted on GitHub. 
> This is a just tiny bit of the big network effects that will come.
>

This is true, they do have to do it for our separate project. However, your 
characterization that the current setup is archaic is false unless you want 
to call what GH does archaic too. I also don't agree that it is a major 
friction point; all of my experience/feedback has been people have the most 
trouble getting user names to access trac and dealing with our coding/doc 
standards.

-- 
You received this message because you are subscribed 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/68256bda-39ec-473a-9afb-3f026132377en%40googlegroups.com.

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

['Travis Scrimshaw' via sage-devel]

>
> A few people are yelling 
>>
>
> Travis, this is inappropriate
>  
>
Matthias, then let me rephrase, a few people are speaking somewhat 
forcefully and frequently.
 

-- 
You received this message because you are subscribed 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/2f42b729-f346-4050-93ed-29e5c3af6c3cn%40googlegroups.com.

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

['Travis Scrimshaw' via sage-devel]

First off, we need to slow down significantly as we do not have an general 
clear consensus about doing this move. A few people are yelling we should 
move to GH, and a lot of the same people are acting like has been decided 
when it has not. We should make a formal vote once a more concrete proposal 
has been placed forward.

On Tuesday, September 13, 2022 at 4:36:04 AM UTC+9 Matthias Koeppe wrote:

> On Saturday, September 10, 2022 at 7:39:10 AM UTC-7 Travis Scrimshaw wrote:
>
>> [] There are lots of technical issues and questions I have that 
>>> [I cannot] easily find after skimming through things for a few minutes.
>>>
>>
> Everything about GitHub has excellent documentation, and we have an 
> executive summary now at 
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b, with 
> pointers to the relevant bits.
>

This is still does not contain much of any details about the collaboration 
process. It is basically contains the simple single-author--single-reviewer 
model (that is easy to find) and a thesaurus of terms.

What happens when Bob works on a ticket, but then stops (say, it doesn't 
find a reviewer in time). Now Alice wants to make changes on top of that 
branch. How does Alice do that? I am particularly thinking about when this 
is *not* meant to be a PR review commit (say, it is working with a more 
substantial change or just cherry-picking some of the commits). When she is 
done, does she do a new PR? After doing quite a bit of digging, I finally 
found the answer:

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

So there is a mechanism for it, but it is not as straightforward as before. 
How do we deal with the PR pollution?

 
>
>> It stays there even if the user GitHub account is closed (the latter 
>>> triggers an automatic closure of the PR, but the underlying
>>> branch remains in the repo, it can be worked on just the same using git)
>>>
>>
>> Which repo? Either way, this seems like a regression compared to our 
>> current setup, where if a user quits, then branch, ticket, and everything 
>> remains.
>>
>
> No, this is an imaginary problem. The branch of the pull request persists 
> in the sagemath repo (see 
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b, 
> which explains the name of the branch) even if the user and their repo 
> disappears.
>

Okay, thanks. The extra information clarifies things.

>
> Getting the login credentials was the biggest barrier; everything else is 
>>>> mostly straightforward and based on very simple git commands.  
>>>>
>>>
>>>> Right now, I find there are way too many practical questions and 
>>>> barriers for how we develop that make moving to Git**b a much bigger pain 
>>>> that people will think it is.
>>>>
>>>  
>>> Travis, many people nowadays never used git without GitHub or GitLab. 
>>> For such a person it's a major pain to 
>>> learn our workflow.
>>>
>>
>> Do you really believe that everyone is using the web interface to make 
>> edits to the code and not using some form of git locally (either command 
>> line or GUI based)? 
>>
> The web interface has major problems, such as not being able to run tests 
>> locally, in addition to being unwieldy with a project on the scale of Sage. 
>> Honestly, people really don't use "git pull", "git push", "git commit" when 
>> working with *Git*hub?
>>
>
> Nothing like this is being proposed. No, GitHub is not a replacement for 
> git. Yes, you will continue to use git commands to pull, push, commit.
>
> But people nowadays who start with GitHub never have to go through archaic 
> setup steps such as those that we document at 
> https://doc.sagemath.org/html/en/developer/trac.html#trac-authentication-through-ssh,
>  
> which --- even when it is working --- is major friction for the project.
>

I think it has been just far too long since you uploaded your ssh key to 
GH. The server cannot magically know your ssh public key. Yes, we don't 
have https support, but other than the most casual of contributors will use 
that for push/pull. I highly doubt anyone will use that feature with any 
serious commits.

It seems like there are just as many one-time setup costs needing to be 
done from the proposal document that require more explanation of what they 
do. I think you are making a distinction without a difference here.
 

> And people can use modern IDEs, in particular VS Code, which have 
> excellent integration with GitHub: see for example 
> https://code.visualstudio.com

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

['Travis Scrimshaw' via sage-devel]

;>
>> migration gitlhub->gitlab is easy, and the latter can be selfhosted on 
>> opensource code, so a migration to selfhosted gitlab should not be a 
>> problem, if needed.
>>
>>
>>>
>>> I don't think the move is so urgent though, but it should probably 
>>> happen in the next year or so.
>>>
>>
>> I don't see how the current ssh keys issue is not urgent. I think it is 
>> very urgent.
>> And in general, as I said, potential contributors look at the shabby 
>> state of our devops and stay away.
>>
>> Dima
>>
>>
>>> For the lulz:
>>> https://imgs.xkcd.com/comics/git_2x.png
>>>
>>> Regards,
>>> Jan
>>>
>>>
>>>
>>> On Sat, 10 Sept 2022 at 11:02, Aram Dermenjian  
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm only an occasional developer with sage, but I wanted to also bring 
>>>> up one (minor) positive for moving to github which is less technical. 
>>>> Moving to github would be a motivating factor for people to contribute to 
>>>> sagemath as it gives a pathway to work in industry (programming) if they 
>>>> chose to leave academia. In particular, github shows contributions made by 
>>>> a user to various projects. This could be a valuable tool for someone on 
>>>> the job market who would prefer (or has no choice) to move to industry and 
>>>> get a programming job. Sure, one can already currently say that one 
>>>> develops for sagemath, but by putting it on github it creates a unified 
>>>> location for future employers to look. As mentioned, this is just a minor 
>>>> positive, but could be a motivating factor for some.
>>>>
>>>> Also, I concur with Vincent in that we should have somewhere with a 
>>>> list of pros/cons for either side in some kind of list fashion as 
>>>> currently 
>>>> it's a little hard to keep track of whether people are making the same 
>>>> arguments or new arguments.
>>>>
>>>> Kindly,
>>>> Aram Dermenjian
>>>>
>>>> On Sat, 10 Sept 2022 at 09:35, Vincent Delecroix <20100.d...@gmail.com> 
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I am in the same mood as Travis : if I was to consider a move to
>>>>> github I would like to have a clear and complete overview of the
>>>>> changes in the workflow (how do we set ticket dependencies? how
>>>>> reviews will work? management of releases? etc). For me the discussion
>>>>> in this thread is very premature as there is no proposal of this sort.
>>>>> The "moving to github" does not specify how things will work.
>>>>>
>>>>> I see clear advantages of moving to github. The first being trac
>>>>> maintenance and a second example that William mentioned is that it
>>>>> might lower the barrier for newcomers. But there are also plenty of
>>>>> reasons not to migrate. The first one I think is that we might loose
>>>>> active developers. Let me recall that the move from mercurial to git
>>>>> some 10 years ago made many active developers quit.
>>>>>
>>>>> So I would like to propose that ticket #30363 instead of being
>>>>> technical (ie how do we do the move) explains
>>>>> - a concrete proposal for a github workflow (there might be several of 
>>>>> them)
>>>>> - list the pros
>>>>> - list the cons
>>>>> Then we could proceed with a reasonable discussion on whether we will
>>>>> do such move.
>>>>>
>>>>> Ideally (if we had illimited developer time) I would like to encourage
>>>>> the possibility of having both trac and github. If I recall correctly,
>>>>> it was possible to authenticate to trac with github account and make
>>>>> PR on github that automatically transformed into a ticket on trac.
>>>>>
>>>>> Best
>>>>> Vincent
>>>>>
>>>>> On Sat, 10 Sept 2022 at 09:54, Dima Pasechnik  
>>>>> wrote:
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Sat, 10 Sep 2022, 05:48 Matthias Koeppe,  
>>>>> wrote:
>>>>> >>
>>>>> >> On Friday, September 9, 2022 at 9:34:16 PM U

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

['Travis Scrimshaw' via sage-devel]

>
>
> I really dislike Github's decentralized approach with PR and having to 
>> have separate clones of the repo within each user. My understanding is if 
>> two people have different fixes, then they individually submit PRs that are 
>> not explicitly linked with each other, much less with a specific bug report 
>> issue. It is not so uncommon that people end up working on competing 
>> proposals or on the same branch, both of which are not natural using 
>> Githubs PR system (I am not even entirely sure how I should do this either; 
>> Do I have to clone from their repo? Is it the same remote? Where is the 
>> documentation on this? Can I still access the branch if someone deletes 
>> their account?). How do other projects at the scale of Sage deal with this?
>
>
> It seems you never reviewed a non-trivial PR on GitHub, no?
>

Not at the scale of some of the tickets for Sage (most of it has been 
fairly small patches), and that is the problem. It is not at all clear how 
I should do that unlike our current setup.
 

> Well, you can go and have a look how e.g. CPython does it, or SciPy. 
>

Thank you for the pointer. You wouldn't happen to have specific cases that 
would make for good examples of the behaviors I mentioned above?

>
> The PR process and the underlying structure is very well-documented.
>

The basics, yes. I didn't see examples of anything beyond "contributor 
contributes code, then reviewer with project repo permissions reviews and 
merges it."
 

> A PR creates a branch in the git repo of the "main"
> project. This is really not much different from what we do on trac, except 
> that the branch name
> satisfied different rules.
>

There is a big difference you aren't even mentioning: You need to fork the 
repo locally to your UN, which has some additional setup that needs to be 
done.

Have a look at 
> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally
>

That sure looks like what you do when you are a developer for the project, 
and you get the PRs. It doesn't talk about what to do with someone else"s 
repo. The key title words are "*your* repository."

>
> E.g. using https://github.com/scipy/scipy/pull/14786 as an example, the 
> underlying branch in the repo of scipy is
> named pull/14786. 
>
> To examine it locally on your machine you can use plain git to fetch it, 
> or you can use GitHub's
> tool called cli (its functionality is close to what git-trac does, not 
> sure if you use or used git-trac, though).
>

It is not clear that if I can pull the branch from origin. There are lots 
of technical issues and questions I have that are not documented, or at 
least that I can easily find after skimming through things for a few 
minutes.

It stays there even if the user GitHub account is closed (the latter 
> triggers an automatic closure of the PR, but the underlying
> branch remains in the repo, it can be worked on just the same using git)
>

Which repo? Either way, this seems like a regression compared to our 
current setup, where if a user quits, then branch, ticket, and everything 
remains.

>
> Besides, nobody forces you to use a PR to review something. You can open 
> an issue, and ask for a specific branch somewhere (in a fork, or even in a 
> completely unrelated git branch hosted outside of GitHub) to be reviewed, 
> and only do a PR once the branch in question is stabilized.
>

At the end of the day, all paths lead to PRs. A rose by any other name 
still has thorns one needs to be careful of. 

Honestly, I doubt we are loosing that many quality contributors by not 
>> using Github's system since we can have people with GH login's to access 
>> trac.
>>
>
> except that this is broken now, (along with automatic management of ssh 
> keys in general) and one needs
> a tricky manual process (modifying a special gitolite git repo used by 
> trac) by one of trac admins
> to add/modify ssh keys.
> (and I am not even sure whether this manual process does not lead to an 
> eventual breakage of the ssh keystore, it's all tied up
> with trac in a rather arcane way).
>

This is a definite problem. 

>
> Getting the login credentials was the biggest barrier; everything else is 
>> mostly straightforward and based on very simple git commands.  
>>
>
>> Right now, I find there are way too many practical questions and barriers 
>> for how we develop that make moving to Git**b a much bigger pain that 
>> people will think it is.
>>
>  
> Travis, many people nowadays never used git without GitHub or GitLab. For 
> such a person it's a major pain to 
> learn our workflow.
>

Do you really believe that everyone is using the web interface to make 
edits to the code and not using some form of git locally (either command 
line or GUI based)? The web interface has major problems, such as not being 
able to run tests locally, in addition to being unwieldy with a project on 
the scale of Sage. Honestly, people 

Re: [sage-devel] Re: docstring of _element_constructor_

['Travis Scrimshaw' via sage-devel]

I try to make sure the ways (I first typed methods, but then realized this 
was confusing) to construct the elements is available either in the parent 
and/or element level documentation by way of examples (maybe saying, "We 
can construct a foo by giving it a list::").

Best,
Travis

On Saturday, September 10, 2022 at 1:07:27 AM UTC+9 dim...@gmail.com wrote:

> On Fri, Sep 9, 2022 at 4:43 PM davida...@gmail.com
>  wrote:
> >
> > I believe that the functionalities given by the method 
> _element_constructor_ should be at least mentioned in the main docstring of 
> the Parent.
> >
> > For example, when typing:
> >
> > sage: QQ?
> >
> > Then, the ouput explains to the user how to construct a rational number. 
> This is how I always used Sage. The documentation of _element_constructor_ 
> would be there for the developers that need to understand and modify it.
>
> Well, _things are internal, and not required to be documented.
>
> >
> > Le vendredi 9 septembre 2022 à 05:16:27 UTC-4, axio...@yahoo.de a écrit 
> :
> >>
> >> Dear all,
> >>
> >> as a user, how am I supposed to access the docstring of an 
> _element_constructor_?
> >>
> >> For example,
> >>
> >> sage: P. = QQ[]
> >> sage: P?
> >>
> >> does not give me any hint about the various ways to construct a 
> polynomial.
> >>
> >> If this is not possible other than "R._element_constructor_?", then, as 
> developers, how should we make this documentation accessible?
> >>
> >> Martin
> >
> > --
> > You received this message because you are subscribed 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/ecf3daf3-0050-4255-84cc-472881a37e0en%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/16f92c24-d12d-475e-a4a5-ed291c357ae9n%40googlegroups.com.

[sage-devel] Re: BROADCAST MESSAGE

['Travis Scrimshaw' via sage-devel]

Thank you to everyone who has worked on getting this fixed and working 
again. A big special thanks to Frédéric for taking point (or at least 
willing to do the public relations).

Best,
Travis

On Monday, September 5, 2022 at 3:30:55 AM UTC+9 Eric Gourgoulhon wrote:

> Thank you so much Frédéric at al. for all the work in setting up the new 
> Trac!
>
> Eric.
>
>
> Le dimanche 4 septembre 2022 à 09:32:42 UTC+2, Frédéric Chapoton a écrit :
>
>> Trac 1.2 comes with various changes, including display of full names and 
>> internationalisation. You may want to look in your user preferences to 
>> customize some of these if you prefer.
>>
>> Le dimanche 4 septembre 2022 à 01:32:35 UTC+2, Kwankyu Lee a écrit :
>>
>>> Trac is now in version 1.2. Thanks!
>>
>>

-- 
You received this message because you are subscribed 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/0898a968-1440-415e-a155-a47d4b40b7efn%40googlegroups.com.

[sage-devel] Re: tensor products of symmetric functions and PartitionTuples

['Travis Scrimshaw' via sage-devel]

Short version: no but with implementation caveats.

Longer version: It gores through generic tensor product code:

sage: s = SymmetricFunctions(QQ).s()
sage: s2 = tensor([s, s])
sage: s2.__class__


In order to have it return partition tuples (which didn't exist at the time 
this was written either), there would need to be at least a little work 
done. Nobody has had an interest in doing it as nobody has seen a benefit 
for it. However, I am +1 for the change provided it doesn't slow things 
down significantly (note that hashing, construction of the elements, and 
comparisons are done a lot in manipulating the elements in the tensor 
algebra).

Best,
Travis


On Saturday, August 27, 2022 at 4:24:18 AM UTC+9 axio...@yahoo.de wrote:

>
> Is there any good reason that the basis keys in tensor products of 
> symmetric functions are tuples of partitions and not `PartitionTuples`?
>
> Martin
>
> sage: h = SymmetricFunctions(QQ).h()
> sage: t = tensor([3*h[3], 11*h[1,1]+2*h[2]])
> sage: t
> 33*h[3] # h[1, 1] + 6*h[3] # h[2]
> sage: [(mu, c) for mu, c in t]
> [(([3], [1, 1]), 33), (([3], [2]), 6)]
> sage: type(_[0][0])
> 
>

-- 
You received this message because you are subscribed 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/467b33de-1359-4b91-aea7-a3258a8f0a34n%40googlegroups.com.

[sage-devel] Re: AlphabeticStrings()

['Travis Scrimshaw' via sage-devel]

Hi Doris,
   What would their images be in this monoid? Their capital letter versions 
are not generators of the monoid. If you would like to work in a different 
(free) monoid, then you would need to implement it (not necessarily within 
Sage). If you just want to extend the encoding, say have ß -> SS and ü -> 
U, then you are probably best writing your own encoding function to handle 
these additional cases.

Best,
Travis


On Thursday, August 25, 2022 at 3:28:52 PM UTC+9 dantetante wrote:

> Hi list,
>
> this
>
> A=AlphabeticStrings()
> s='hellowörld'
> A.encoding(s)
>
> is throwing an error. Is there any possibility of enlarging the alphabet 
> set by some chosen characters like german ü, ä, ö, ß?
> I understand that it makes no sense to enlarge to the whole ASCII 
> character set in *this* case, but I really would appreciate to have german 
> umlauts.
>
>
> Thanks in advance ...
>
> Doris
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/536f7a35-0cb7-4e3c-8452-2edb4c874e08n%40googlegroups.com.

[sage-devel] Re: If I run make twice in a row, shouldn't the second run be instant?

['Travis Scrimshaw' via sage-devel]

However, I don't think it should take 30 minutes, that seems far too long 
to me to check everything, even on a slow system. The longest part to me 
always seems to be checking the documentation part.

Samuel, how long does "make build" take for you?

Best,
Travis


On Thursday, August 25, 2022 at 4:45:13 AM UTC+9 Matthias Koeppe wrote:

> Our build system does not know the precise dependence of sagelib on its 
> source files and other components. 
> To know if it needs to be rebuilt, we just invoke sagelib's build system. 
> This is akin to https://trac.sagemath.org/ticket/29711
>
> Likewise for the docbuild: It kind of depends on source files and on the 
> built Sage library, but our build system does not know how it depends.
> So we just invoke the docbuild's build system and rely on its incremental 
> work to be as fast as it can be.
>
>
> On Wednesday, August 24, 2022 at 12:19:59 PM UTC-7 Samuel Lelievre wrote:
>
>> Dear sage-devel,
>>
>> Having built Sage successfully from source with the command
>> `make configure && make`, if I then immediately run `make`
>> a second time in the same shell session, shouldn't that second
>> run have nothing to build, and thus terminate almost instantly?
>>
>> Here is an example of building Sage successfully:
>>
>> ```
>> $ source .homebrew-build-env # recommended on macOS
>> $ make -s V=0 configure
>> $ make -s V=0
>>
>> ...
>>
>> [sage_conf-9.7.beta8] installing. Log file:
>> /opt/s/sage-9-7b8-fresh-clone/logs/pkgs/sage_conf-9.7.beta8.log
>> [sage_conf-9.7.beta8] successfully installed.
>> [sagelib-9.7.beta8] installing. Log file:
>> /opt/s/sage-9-7b8-fresh-clone/logs/pkgs/sagelib-9.7.beta8.log
>> [sagelib-9.7.beta8] successfully installed.
>> [sagemath_doc_html-none] installing. Log file:
>> /opt/s/sage-9-7b8-fresh-clone/logs/pkgs/sagemath_doc_html-none.log
>> [sagemath_doc_html-none] successfully installed.
>>
>> real 31m44.059s
>> user 23m35.949s
>> sys 4m3.652s
>> Sage build/upgrade complete!
>> ```
>>
>> Immediately after that, in the same session,
>> without having modified any file:
>>
>> ```
>> $ make -s V=0
>>
>> ...
>>
>> [sagelib-9.7.beta8] installing. Log file:
>> /opt/s/sage-9-7b8-fresh-clone/logs/pkgs/sagelib-9.7.beta8.log
>> [sagelib-9.7.beta8] successfully installed.
>> [sagemath_doc_html-none] installing. Log file:
>> /opt/s/sage-9-7b8-fresh-clone/logs/pkgs/sagemath_doc_html-none.log
>> [sagemath_doc_html-none] successfully installed.
>>
>> real 31m28.059s
>> user 22m3.713s
>> sys 4m12.429s
>> Sage build/upgrade complete!
>> ```
>>
>> I would have hoped for this to complete in a few seconds
>> and I find it surprising that it takes half an hour.
>>
>> Has that been reported and discussed already, either on
>> Sage Trac or on mailing lists?
>>
>> Doesn't that create problems for our Docker images?
>>
>> Apologies if I have already asked and forgotten, in which case
>> please refresh my memory. --Samuel
>>
>

-- 
You received this message because you are subscribed 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/aeef69c4-a362-4053-9226-4f6f048a8e32n%40googlegroups.com.

[sage-devel] Re: Useful methods for graphics objects

['Travis Scrimshaw' via sage-devel]

Yes we do, otherwise it doesn't make sense mathematically. There are lots 
of different metrics I can use on 2D vectors that make sense. Otherwise any 
(physical paper) maps would be very impractical. I think it is generally 
bad practice to assign mathematical significant things to classes that are 
not used for mathematical purposes.

I have no idea what your argument is for the second part. Separations of 
concerns means object A (in this case, an object for drawing something in 
3D) only does things that are meant for object A (drawing stuff) and not do 
things that are meant for object B (a vector or line segment in Euclidean 
space). It has nothing to do with what you use to actually do the 
implementation. If you are worried about linking together stuff that 
shouldn't be needed, that to me is a code smell.

Best,
Travis

On Wednesday, August 24, 2022 at 10:14:22 AM UTC+9 Kwankyu Lee wrote:

> On Wednesday, August 24, 2022 at 9:18:06 AM UTC+9 Travis Scrimshaw wrote:
>
>> Éric, what do you think about adding such things to SageManifolds? Could 
>> this be feasible?
>>
>
> It is embarrassing that  an idea of attaching ".length()" method to a line 
> segment graphics object leads to SageManifolds. We don't need vectors and 
> inner products to compute the length of a line segment.
>
> If we ever implement the idea, then it should be done with basic python 
> only for "separations-of-concerns" and for modularization of sage.
>
>  
>

-- 
You received this message because you are subscribed 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/f7e92932-0704-47dd-b6d9-0504bb612fe3n%40googlegroups.com.

[sage-devel] Re: Trac only displaying some comments

['Travis Scrimshaw' via sage-devel]

Ah, I see. That fixed it. Thanks. I never knew about that as I never paid 
any attention to that box. it is annoying that changed on a Firefox 
update...Oh well.

Best,
Travis


On Wednesday, August 24, 2022 at 10:06:05 AM UTC+9 Matthias Koeppe wrote:

> Try the checkbox "Show property changes" on the ticket?
>
> On Tuesday, August 23, 2022 at 6:02:53 PM UTC-7 Travis Scrimshaw wrote:
>
>> I think this is something that has to do with more recent versions of 
>> Firefox, as I can see everything in Chrome, but I only see the changes to 
>> the ticket that have comments. So if someone, say, changes only the branch 
>> field or the milestone, I do not see these. Is there something that can be 
>> done to trac to fix this? This has been annoying me for a while now, but I 
>> am now tired to the wasted time working around it.
>>
>> Best,
>> Travis
>>
>>

-- 
You received this message because you are subscribed 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/ce3a0dbe-bdca-4a51-b527-209be58eceban%40googlegroups.com.

[sage-devel] Trac only displaying some comments

['Travis Scrimshaw' via sage-devel]

I think this is something that has to do with more recent versions of 
Firefox, as I can see everything in Chrome, but I only see the changes to 
the ticket that have comments. So if someone, say, changes only the branch 
field or the milestone, I do not see these. Is there something that can be 
done to trac to fix this? This has been annoying me for a while now, but I 
am now tired to the wasted time working around it.

Best,
Travis

-- 
You received this message because you are subscribed 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/cacfec4d-87b8-4012-a724-d39e8bd99c5en%40googlegroups.com.

[sage-devel] Re: Trac #34152 needs you (to vote)!

['Travis Scrimshaw' via sage-devel]

hybrid > sage psuedo > copy files package

I think we should be mindful that there can be people who build from source 
who are not developers. So not having a dependency on git is a small bonus, 
but I think almost everyone who has a non-Windows machine has git installed 
on their computer by default. I also fully agree with Dima that gnulib has 
no business being in Sage's git tree, and if I understand the hybrid 
approach, it remains separate as a separate (cloned) git repo.

Best,
Travis


On Wednesday, August 24, 2022 at 9:04:58 AM UTC+9 Matthias Koeppe wrote:

> Thanks for sending out the poll, Francois.
>
> I endorse the "hybrid" variant.
>
> On Tuesday, August 23, 2022 at 4:38:40 PM UTC-7 François Bissey wrote:
>
>> Hi all,
>>
>> https://trac.sagemath.org/ticket/34152 needs help to decide what 
>> solution we implement going forward.
>>
>> The ticket is concerned with updating the bootstrap process by removing 
>> the current need for gettext and replacing it with gnulib (
>> https://www.gnu.org/software/gnulib). gnulib is not a regular software 
>> library but a collection of bits and pieces to help portability across 
>> platforms.
>>
>> The issue at hand is how do we include and use gnulib in sagemath.
>> Matthias Koeppe and Dima Pasechnik have been arguing for several weeks 
>> and across most of the ~250 comments of the ticket about the way to 
>> proceed. At some point it became clear that they would not agree and would 
>> need arbitration. This is what this post is about, I am inviting the 
>> sagemath community to weigh in and decide the issue.
>>
>> The ticket summary has been updated with summaries of the problem and of 
>> both options along with links to branches implementing them. I would not 
>> recommend diving in the comment section.
>>
>> There are 3 (three) options to choose from, one from Matthias, one from 
>> Dima and a hybrid approach they tried to create.
>>
>> -- copy files --
>>
>>- Follows approach 3 of the Gnulib manual section 'Integration with 
>>Version Control Systems' 
>>
>>.
>>- 5 files, in config/ and m4/, total 112 KB, have been imported by 
>>using `gnulib-tool import iconv` 
>>
>>  
>> and 
>>committed to the branch.
>>- Matches our practice with imported files `m4/ax_*.m4` 
>> from 
>>autoconf-archive 
>>. 
>>Different from our practice with SPKGs because the files are needed to 
>>generate the configure script.
>>- Introduces no new dependency.
>>- Burden on a developer who authors an update ticket for these files: 
>>Obtain gnulib by cloning the repo, then re-run gnulib-tool import, 
>>remove unneeded files (that's where #29549 
>> went wrong), commit the 
>>changes. (Updates are expected to be necessary only very rarely.)
>>- Burden on users and other developers: None.
>>- dimpase's criticism of this approach: "gnulib's code is not Sage's 
>>code, it has no place in Sage git tree; this way, updating the imported 
>>gnulib files is tricky and error-prone by design".
>>
>> -- sage pseudo package --
>>
>>- Follows approach 2(C) of the Gnulib manual section 'Integration 
>>with Version Control Systems' 
>>, 
>>but instead of using Gnulib's Programs for developing in Git checkouts 
>>
>> , 
>>implements its own script (making checkout much faster, as full gnulib 
>> checkout 
>>is 250 MB).
>>- Introduces a new (although one can't really do Sage development 
>>without git installed) dependency on git and on availability of 
>>internet connection at the first run of ./bootstrap in a tree, to 
>>pull 83 MB (fair to say that internet is needed for Sage development a 
>> lot, 
>>anyway).
>>- Burden on a developer who authors an update ticket for these files: 
>>Edit the bootstrap file to change the commit hash, verify that the 
>>list of files removed by make bootstrap-clean is still correct, 
>>commit this change
>>- Burden on other users: a pseudo-package needs to be installed once 
>>(and updated, automatically)
>>- mkoeppe's criticism of this approach: "Having bootstrap operate a 
>>multi-megabyte git clone (on the 1st install and when there's a change of 
>>the gnulib commit hash) in the upstream/ directory increases 
>>complexity for no benefit."
>>
>> -- hybrid --
>>
>>- Resolves the criticism on the "copy files" approach: "updating the 
>>imported gnulib files" is now assisted by the spkg-src script 
>>(adapted from dimpase's 

[sage-devel] Re: source and build artifacts mixed ?

['Travis Scrimshaw' via sage-devel]

Could it be easily possible to get something inbetween? I like having the 
.c files there next to the file (although I have to retrain myself a bit 
with typing) rather than having to hunt for them in some obscure 
not-well-documented directory. However, I would like that when I make 
changes to py files, I do not reload my Sage with these (potentially 
broken) changes and want the current behavior. I have had to do a lot of 
stashing when writing tests to make sure behavior doesn't change.

Best,
Travis


On Wednesday, August 24, 2022 at 2:59:19 AM UTC+9 Nils Bruin wrote:

> That's probably due to
>
> https://trac.sagemath.org/ticket/32406 'Make "./configure 
> --enable-editable" the default'
>
> among other things, sys.path now has '$SAGE_ROOT/src' in it. That explains 
> why the "so" files are there, and the .c files are probably a consequence 
> of how cython compiles under those conditions.
>
> On Tuesday, 23 August 2022 at 10:43:53 UTC-7 Thierry 
> (sage-googlesucks@xxx) wrote:
>
>> Hi,
>>
>> i recently found that the src/sage directory was cluttered with some .c
>> and some .so files, and that the build artifacts were back in the src/
>> directory. What is the rationale behind this move ?
>>
>> Ciao,
>> Thierry
>>
>>

-- 
You received this message because you are subscribed 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/d97b71e9-9b5a-4601-a646-d7f53266032an%40googlegroups.com.

[sage-devel] Re: Useful methods for graphics objects

['Travis Scrimshaw' via sage-devel]

In general, I think we are best leaving the drawing classes to just drawing 
as a separations-of-concerns. It sounds like we need better integration 
between our algebraic objects/implementations and the drawing/plotting 
tools. This might include more plot_* functions or specialized 
mixin-/sub-classes for small dimensional (sub)spaces. Likewise we might 
want to add some general tools for inner product spaces, such as 
"ind_closest_point() or shortest_distance(), with an assumption of course 
that we can do calculus on the vector space.

As an alternative, if we want to think of objects specifically living in 
Euclidean space, we have the EuclideanSpace(n) for this with specialized 
subclasses for 2d and 3d. Perhaps we should implement some of the features 
you want using objects there, such as line (segment) as a subclass of the 
curve? For piecewise differentiable curves, this might require some more 
programming.

Éric, what do you think about adding such things to SageManifolds? Could 
this be feasible?

Best,
Travis

On Tuesday, August 23, 2022 at 4:26:11 PM UTC+9 Kwankyu Lee wrote:

> On Monday, August 22, 2022 at 12:04:57 PM UTC+9 Travis Scrimshaw wrote:
>
>> I am not sure how much I support that because there is no metric. 
>>
>
> It is of course euclidean, as you say
>  
>
>> you can do
>>
>> sage: l = line3d([(1,2,3), (4,5,6)])
>> sage: V = RR^3
>> sage: (V(l.points[1]) - V(l.points[0])).norm()
>> 5.19615242270663
>>
>
> My point is to attach methods to graphics objects for handy computation. I 
> am not sure if this is technically doable. 
>  
>
>> There could also be other natural interpretations of length here, such as 
>> the number of (non-colinear) segments.
>>
>
> (1) .length() could be an alias of .line3d_euclidean_length() as this is 
> most useful. 
>
> (2) .line3d_combinatorial_length(): I doubt if this is useful for drawing.
>
> Is this more pedagogical or are you using 3d line segments in some 
>> meaningful way?
>>
>
> Pedagogical and meaningful :) I thought of this idea while drawing 
> graphics to prepare lecture notes for a class next semester. 
> If graphics objects get more powered, then drawing (2d or 3d) mathematical 
> pictures, which is always difficult, would get less difficult. 
>
> For another example,  we may implement a method to compute the 
> intersection point given two line segments (as tikz can do in latex)
>

-- 
You received this message because you are subscribed 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/13870a33-c3d8-45cc-865d-48a918002e03n%40googlegroups.com.

[sage-devel] Re: sage.combinat.integer_vector_weighted.iterator_fast arguments

['Travis Scrimshaw' via sage-devel]

I thought it produced wrong results when it was for some composition? 
Perhaps I am mistaken or that was some older version of the code. If the 
logic is valid for any composition, then we can change the doc.

Best,
Travis


On Monday, August 22, 2022 at 7:59:22 PM UTC+9 axio...@yahoo.de wrote:

> The docstring of iterator_fast says that the weights should be weakly 
> decreasing.
>
> It seems to me that the code actually works for any composition, or am I 
> missing something?
>
> Martin
>
> def iterator_fast(n, l):
> """
> Iterate over all ``l`` weighted integer vectors with total weight 
> ``n``.
>
> INPUT:
>
> - ``n`` -- an integer
> - ``l`` -- the weights in weakly decreasing order

-- 
You received this message because you are subscribed 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/6d53a93a-fa65-43f2-b2a8-f4d55e7a500cn%40googlegroups.com.

Re: [sage-devel] Graph([(0,'a')]).vertices() raises exception

['Travis Scrimshaw' via sage-devel]

I think it is a very bad idea to have default sorting based upon hashing. 
This could make a lot of output appear seemingly random (despite having a 
natural order), nor there is no way to deal consistently with hash 
collisions. This would cause far more problems than it would solve when 
working with incomparable objects.

Best,
Travis


On Friday, August 19, 2022 at 9:05:23 PM UTC+9 ggun...@gmail.com wrote:

> On Wed, Jul 13, 2022 at 5:46 PM John H Palmieri  
> wrote:
> >
> > "Fix your old code" could just mean using `vertices(sort=False)`. See 
> also https://trac.sagemath.org/ticket/22349.
> >
>
> fixing the sort() appears easy:
>
> >>> li=['a',0]
> >>> li.sort(key=hash);li
> [0, 'a']
>

-- 
You received this message because you are subscribed 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/7891a0c7-8a26-47e5-be9d-0dbb8775b060n%40googlegroups.com.

[sage-devel] Re: Useful methods for graphics objects

['Travis Scrimshaw' via sage-devel]

I am not sure how much I support that because there is no metric. If you 
are working with the Euclidean metric (the usual one you are used to), then 
you can do

sage: l = line3d([(1,2,3), (4,5,6)])
sage: V = RR^3
sage: (V(l.points[1]) - V(l.points[0])).norm()
5.19615242270663

There could also be other natural interpretations of length here, such as 
the number of (non-colinear) segments.

Is this more pedagogical or are you using 3d line segments in some 
meaningful way?

Best,
Travis

On Friday, August 19, 2022 at 6:26:31 PM UTC+9 Kwankyu Lee wrote:

> Hi,
>
> I wish  that this would work:
>
> sage: l = line3d([(1,2,3),(2,2,3)])
> sage: l.length()
> 1
>
> Is there already a handy way to get the same result in Sage?
>
> You can image other useful methods attached to a graphics object.
>
>
>
>

-- 
You received this message because you are subscribed 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/7ba749b5-e6d2-4024-973f-ff9832b36e12n%40googlegroups.com.

Re: [sage-devel] Re: LazyPowerSeriesRing Replacement

['Travis Scrimshaw' via sage-devel]

I will let Martin discuss the naming as I think the is attached to the name 
LazyTaylorSeries(Ring). A quick counterpoint to Kwankyu's claim, the power 
series "is" a function (well, formally), we just usually think of it as 
being equal to an "easier" function.

However, it is meant to be a complete replacement with removing the old 
LazyPowerSeriesRing code. This new version should be faster, more robust, 
and have more functionality.

Best,
Travis


On Monday, August 15, 2022 at 5:06:29 PM UTC+9 vdelecroix wrote:

> On Mon, 15 Aug 2022 at 09:50, John Cremona  wrote:
> >
> > On Mon, 15 Aug 2022 at 08:21, Kwankyu Lee  wrote:
> > >
> > > If LazyTaylorSeriesRing could be a complete replacement of 
> LazyPowerSeriesRing, then I think we should remove the old 
> LazyPowerSeriesRing
> > > and rename LazyTaylorSeriesRing to LazyPowerSeriesRing. Do you mean 
> this?
> > >
> > > Mathematically, Taylor series means power series derived from a 
> function. So aTaylor series is always attached to a function. The name 
> LazyTaylorSeriesRing seems a misnomer.
> >
> > I agree with all these points!
>
> Me too.
>

-- 
You received this message because you are subscribed 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/5e4f1036-1898-41ba-80b4-6fbba24bca37n%40googlegroups.com.

[sage-devel] LazyPowerSeriesRing Replacement

['Travis Scrimshaw' via sage-devel]

Hi everyone,
   Now that https://trac.sagemath.org/ticket/32324 is positively reviewed, 
I was wondering if there would be any opposition to replacing the current 
LazyPowerSeriesRing with the next LazyTaylorSeriesRing. This is already 
happening as the backend for species in 
https://trac.sagemath.org/ticket/32367. Are there any features missing that 
people want from LazyPowerSeries?

I should also point out that the framework on 
https://trac.sagemath.org/ticket/32324 also easily allows us to work with 
formal infinite series over any graded algebra (at least where each graded 
piece is a finite sum of elements). I plan on doing the slight refactoring 
and adding a noncommutative Cauchy product stream to the code to support 
this somewhat soon for some computations I need.

Best,
Travis

PS - Side question: Do we have q-commuting polynomials as a graded algebra 
in Sage? I don't think so, but perhaps there is an easy way to construct 
it. I know in 2 variables, I can build it as a SkewPolynomialRing in y over 
R['x'], but this it doesn't have the right grading.

-- 
You received this message because you are subscribed 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/ae105d3b-cab5-4cb7-85df-fec395e485ben%40googlegroups.com.

[sage-devel] Re: MSC-2020 -- Class 52: Convex and Discrete Geometry -- CAS Citations from 2000 to 2021

['Travis Scrimshaw' via sage-devel]

Indeed, it is not only great to see that Sage is increasing in the number 
of citations* but also the total number of papers citing mathematics 
software.

Best,
Travis

* In algebraic combinatorics, I sometimes notice that people give an 
acknowledgement that they have used Sage to help with their paper without 
actually citing Sage. This makes it harder for simple data mining tools to 
pick up I think. I also know of some papers that have used Sage to 
construct examples without even an acknowledgement... So there work to do 
on making sure the broader math community does properly cite (or at least 
acknowledge) the use of a CAS. (As I say this, I think I forgot to cite 
Mathematica in one of my papers that one of my coauthors used somewhat 
extensively...)


On Friday, August 12, 2022 at 2:44:10 PM UTC+9 kcrisman wrote:

> I take this opportunity to thank the Sage community and the developers of 
>> related softwares integrated for this Huge effort and to let you know of 
>> the positive comments that I receive form the research community in MSC-52. 
>> THANK YOU SO MUCH!
>>
>> If you are interested in a deeper analysis, I produced detailed graphics 
>> and provide the raw data in a Jupyter notebook on my webpage:
>>
>> https://jplab.github.io/sage_cite.html
>
>
> Great post! 
>

-- 
You received this message because you are subscribed 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/dc80e2fa-a1d8-4fc4-832f-82746b8193d8n%40googlegroups.com.

[sage-devel] Re: Proposal: downgrade some packages to experimental

['Travis Scrimshaw' via sage-devel]

I would like to see the p_group_cohomology fixed. Progress got stalled on 
that, but I am happy to work on that (while I have time for August).

Best,
Travis


On Sunday, August 7, 2022 at 5:23:46 AM UTC+9 Matthias Koeppe wrote:

> The sage_numerical_backends_* packages are on their way out anyway.
> Coin support will switch to go through CVXPy in 
> https://trac.sagemath.org/ticket/34251, and Gurobi/CPLEX likewise in a 
> follow up ticket
>
> On Saturday, August 6, 2022 at 1:09:37 PM UTC-7 John H Palmieri wrote:
>
>> Thank you for the link. With this ticket, the gurobi and cplex backends 
>> still fail because I don't have gurobi and cplex installed. It would be 
>> nice if that was detected earlier in the process and the build failed right 
>> away. Actually, it is detected early in the process:
>>
>>   /bin/sh: gurobi.sh: No such file or directory
>>   GUROBI_HOME is not set, or it does not point to a directory with a 
>> Gurobi installation.  Trying to link against -lgurobi
>>
>> but the installation proceeds anyway. But this is a separate issue.
>>
>> On Saturday, August 6, 2022 at 12:39:00 PM UTC-7 Matthias Koeppe wrote:
>>
>>> This one is https://trac.sagemath.org/ticket/34221
>>>
>>> On Saturday, August 6, 2022 at 11:55:36 AM UTC-7 John H Palmieri wrote:
>>>
 Also, the various sage_numerical_backend_* packages fail to build, with 
 errors like


   Error compiling Cython file:
   
   ...
   from sage.numerical.backends.generic_backend cimport GenericBackend
   ^
   

   check_add_col_untyped_args.pyx:1:0: 
 'sage/numerical/backends/generic_backend.pxd' not found


 Also downgrade? Is there a ticket for this?

 On Friday, August 5, 2022 at 11:07:51 PM UTC-7 Matthias Koeppe wrote:

> On Friday, August 5, 2022 at 9:49:21 PM UTC-7 John H Palmieri wrote:
>
>> The following packages do not build for me on OS X 12.5 (Monterrey), 
>> Intel chip:
>>
>>- polylib (#33758)
>>- symengine_py (#34141)
>>- p_group_cohomology (#30787)
>>- r_jupyter
>>- rubiks
>>
>> I propose that these be downgraded from optional to experimental 
>> until the issues are fixed. What do people think?
>>
>>
> Also on various Linux platforms (
> https://github.com/sagemath/sage/actions/runs/204587) I see 
> failures for
> symengine_py, 
> p_group_cohomology, 
> r_jupyter
>
> So these 3 definitely need to be changed to "experimental".
>
>
>  
>


-- 
You received this message because you are subscribed 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/975cb633-de43-4cba-8c67-286c413c4ceen%40googlegroups.com.