Re: [sage-devel] Re: VOTE: disputed PRs

[David Roe]

The vote has passed.  There are currently 36 open disputed PRs
.

Given the extensive comments on some of these PRs, I would agree that we
should follow some version of Karl-Dieter's suggestion.  In particular,
while the author of the PR remains automatically in favor, I'll ask that
people who gave positive reviews affirm their continued support for the PR
by commenting (or forwarding their vote to someone who can comment).  With
such a large set of disputed tickets, while we give people a chance to make
their opinions known please wait until the end of the day Friday (say,
US/Pacific time) before changing status to positive review or needs review
as described in the policy.  Volker will hopefully not merge any of these
disputed tickets for a little while while we work through the new policy.

If there are snags in the process, we can work through them here on
sage-devel.

Also note that I do not anticipate this new process to be a magic bullet
that resolves all of our disagreements that underlie these disputes.  We
will be announcing the results of the vote for new members of the Sage Code
of Conduct committee soon, and I hope that the new committee can discuss
ways to continue to resolve the disagreements.  In the meantime, please be
respectful of each other, both here and on github.

I am not going to have time to encode this policy into our Developer's
Guide for a couple weeks; anyone else is welcome to do so and I'd be happy
to offer a review.
David

On Mon, Mar 11, 2024 at 1:44 PM kcrisman  wrote:

>
> It would be helpful for anyone explicitly voting +/-1 to either link to a
> previous comment or make a new actual comment (beyond the vote) to
> clarify.  This is particularly if there have been new commits since the
> initial dispute, because for an outside reviewer it can be hard to untangle
> all the various comments before the disputed tag is placed on the PR.
>
> (Which would apply to any emailed requests as well.)
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/bb229d60-d204-4d04-bc3d-2c88515a389dn%40googlegroups.com
> 
> .
>

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

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[Giacomo Pope]

Thanks so much for the context

Oh interesting. In this case I wonder whether we should work on and include 
a new class (maybe something as simple as a WeightedProjectiveSpace and a 
curve from this) mirroring the implementation for the plane curves. 
Alternatively I could go into the old plane curve code and write these 
useful functions specifically for the hyperelliptic curves (and here even 
gain that these algorithms can be optimised). For example, I already had to 
include a `dimension()` method on the curve to properly compute the 
Jacobian. Potentially AlgebraicScheme_subscheme_toric is indeed the wrong 
inheritance

On Wednesday, March 13, 2024 at 6:18:12 PM UTC Nils Bruin wrote:

> One thing that may deserve a cursory check is the overhead involved in 
> inheriting from AlgebraicScheme_subscheme_toric class . Some parent 
> structures are optimized for prolonged use *after* creation and may do a 
> lot of caching/precomputation. There may be scenarios where one wants to 
> construct *lots* of hyperelliptic curves (for instance, when computing 
> reductions of hyperelliptic curves mod lots of primes). An expensive parent 
> may then add undue overhead. In that case it may be better to spin off the 
> functionality required into a "lightweight" structure that gets wrapped in 
> the expensive, full functionality parent. After all, for core algorithms a 
> hyperelliptic curve is just a 3*g+5 length sequence of ring/field elements: 
> the coefficients of the defining equation.
>
> There are of course also odd genus hyperelliptic curves that cover a genus 
> 0 curve that is not isomorphic to a P^1, but computing in their Jacobians 
> has its own problems, so you should probably not try to include them in 
> your current design.
>
> One thing that may be worthwhile: hyperelliptic curves do inherit some 
> interesting functionality from plane curves (particularly via their affine 
> patch) in the form of "riemann_surface". It may be worth keeping that, even 
> if the particular code there could be expanded to work much more 
> efficiently on hyperelliptic curves.
>
> On Wednesday 13 March 2024 at 10:32:08 UTC-7 Giacomo Pope wrote:
>
>> Thanks David, there's a bunch of nice things we could do for genus two in 
>> various cases which would be worth including. The inert case, where all 
>> degree zero divisors (except the identity element) have u with degree 2 
>> would probably allow something particularly nice. 
>>
>> As another update I have done a fairly brutish refactoring of the proof 
>> of concept code to follow the design decisions of the previous 
>> implementation. https://github.com/GiacomoPope/HyperellipticCurves
>>
>> Hyperelliptic curves are created from a dynamic class constructor on top 
>> of the AlgebraicScheme_subscheme_toric class (before this was a curve over 
>> the plane projective curves)
>> A generic class offers most features, but other classes will cover the 
>> case of finite fields, rational fields and padic fields
>> The Jacobian is a small class built on top of `jacobian_generic` which is 
>> built from the curve
>> The set of rational points of the Jacobian is built on top of 
>> SchemeHomSet and the elements (divisors) are morphisms built on top of 
>> SchemeMorphism
>>
>> I will do my best to clean up and refactor code to the standard of code 
>> which is included into Sage now, but I would love to know any feedback 
>> advice on whether this structure is still the one to use. The older version 
>> of this code dates back to the beginning of Sage so it's very possible we 
>> have new ideas of how things should be done and if we're doing the work or 
>> rewriting the whole set of classes I may as well do a good job.
>>
>> Giacomo
>>
>> On Wednesday, March 13, 2024 at 3:36:09 AM UTC David Roe wrote:
>>
>>> There is also this old trac ticket 
>>>  about implementing fast 
>>> arithmetic in genus 2 Jacobians, which never made it into Sage.  I've CCed 
>>> Mike Jabobson, who worked on it.
>>> David
>>>
>>>
>>> On Tue, Mar 12, 2024 at 12:10 PM Giacomo Pope  
>>> wrote:
>>>
 Thank you for linking this and I agree this is a great way to 
 cross-compare the work we have been doing. I am not an expert in this area 
 so I am not sure I should do a full review but I'm happy to look over it 
 if 
 this helps.

 As a small update on this work, I now have 

 class HyperellipticCurveSmoothModel(AlgebraicScheme_subscheme_toric)

 So this new class builds on top of AlgebraicScheme_subscheme_toric and 
 the smooth projective model is built using a toric variety. The points on 
 the curve are currently SchemeMorphism_point_toric_field, potentially I 
 will need to make a child class of these if methods on the points 
 themselves are required.

 With the working arithmetic and this new inheritance my work is now 
 going to be the rather slow and painful rewrite of all 

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[Nils Bruin]

One thing that may deserve a cursory check is the overhead involved in 
inheriting from AlgebraicScheme_subscheme_toric class . Some parent 
structures are optimized for prolonged use *after* creation and may do a 
lot of caching/precomputation. There may be scenarios where one wants to 
construct *lots* of hyperelliptic curves (for instance, when computing 
reductions of hyperelliptic curves mod lots of primes). An expensive parent 
may then add undue overhead. In that case it may be better to spin off the 
functionality required into a "lightweight" structure that gets wrapped in 
the expensive, full functionality parent. After all, for core algorithms a 
hyperelliptic curve is just a 3*g+5 length sequence of ring/field elements: 
the coefficients of the defining equation.

There are of course also odd genus hyperelliptic curves that cover a genus 
0 curve that is not isomorphic to a P^1, but computing in their Jacobians 
has its own problems, so you should probably not try to include them in 
your current design.

One thing that may be worthwhile: hyperelliptic curves do inherit some 
interesting functionality from plane curves (particularly via their affine 
patch) in the form of "riemann_surface". It may be worth keeping that, even 
if the particular code there could be expanded to work much more 
efficiently on hyperelliptic curves.

On Wednesday 13 March 2024 at 10:32:08 UTC-7 Giacomo Pope wrote:

> Thanks David, there's a bunch of nice things we could do for genus two in 
> various cases which would be worth including. The inert case, where all 
> degree zero divisors (except the identity element) have u with degree 2 
> would probably allow something particularly nice. 
>
> As another update I have done a fairly brutish refactoring of the proof of 
> concept code to follow the design decisions of the previous implementation. 
> https://github.com/GiacomoPope/HyperellipticCurves
>
> Hyperelliptic curves are created from a dynamic class constructor on top 
> of the AlgebraicScheme_subscheme_toric class (before this was a curve over 
> the plane projective curves)
> A generic class offers most features, but other classes will cover the 
> case of finite fields, rational fields and padic fields
> The Jacobian is a small class built on top of `jacobian_generic` which is 
> built from the curve
> The set of rational points of the Jacobian is built on top of SchemeHomSet 
> and the elements (divisors) are morphisms built on top of SchemeMorphism
>
> I will do my best to clean up and refactor code to the standard of code 
> which is included into Sage now, but I would love to know any feedback 
> advice on whether this structure is still the one to use. The older version 
> of this code dates back to the beginning of Sage so it's very possible we 
> have new ideas of how things should be done and if we're doing the work or 
> rewriting the whole set of classes I may as well do a good job.
>
> Giacomo
>
> On Wednesday, March 13, 2024 at 3:36:09 AM UTC David Roe wrote:
>
>> There is also this old trac ticket 
>>  about implementing fast 
>> arithmetic in genus 2 Jacobians, which never made it into Sage.  I've CCed 
>> Mike Jabobson, who worked on it.
>> David
>>
>>
>> On Tue, Mar 12, 2024 at 12:10 PM Giacomo Pope  wrote:
>>
>>> Thank you for linking this and I agree this is a great way to 
>>> cross-compare the work we have been doing. I am not an expert in this area 
>>> so I am not sure I should do a full review but I'm happy to look over it if 
>>> this helps.
>>>
>>> As a small update on this work, I now have 
>>>
>>> class HyperellipticCurveSmoothModel(AlgebraicScheme_subscheme_toric)
>>>
>>> So this new class builds on top of AlgebraicScheme_subscheme_toric and 
>>> the smooth projective model is built using a toric variety. The points on 
>>> the curve are currently SchemeMorphism_point_toric_field, potentially I 
>>> will need to make a child class of these if methods on the points 
>>> themselves are required.
>>>
>>> With the working arithmetic and this new inheritance my work is now 
>>> going to be the rather slow and painful rewrite of all hyperelliptic 
>>> methods from the current implementation to ensure everything works on the 
>>> smooth degree model.
>>>
>>> On Monday, March 11, 2024 at 6:23:38 AM UTC Kwankyu Lee wrote:
>>>
 On Friday, March 8, 2024 at 7:37:04 PM UTC+9 Giacomo Pope wrote:

 As a small update, the repository now contains code to

 - perform arithmetic for
   - the imaginary model (ramified, one point at infinity) for all cases
   - the real model (split, two points at infinity) for all cases
   - the real model (inert, zero points at infinity) for even genus
   Which allows us to do "as much" as Magma does for Jacobians of 
 hyperellipticc curves from the perspective of arithmetic. 

 My current "test" for the arithmetic is that D - D = 0 for all cases, 
 that jacobian_order 

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[Giacomo Pope]

Thanks David, there's a bunch of nice things we could do for genus two in 
various cases which would be worth including. The inert case, where all 
degree zero divisors (except the identity element) have u with degree 2 
would probably allow something particularly nice. 

As another update I have done a fairly brutish refactoring of the proof of 
concept code to follow the design decisions of the previous 
implementation. https://github.com/GiacomoPope/HyperellipticCurves

Hyperelliptic curves are created from a dynamic class constructor on top of 
the AlgebraicScheme_subscheme_toric class (before this was a curve over the 
plane projective curves)
A generic class offers most features, but other classes will cover the case 
of finite fields, rational fields and padic fields
The Jacobian is a small class built on top of `jacobian_generic` which is 
built from the curve
The set of rational points of the Jacobian is built on top of SchemeHomSet 
and the elements (divisors) are morphisms built on top of SchemeMorphism

I will do my best to clean up and refactor code to the standard of code 
which is included into Sage now, but I would love to know any feedback 
advice on whether this structure is still the one to use. The older version 
of this code dates back to the beginning of Sage so it's very possible we 
have new ideas of how things should be done and if we're doing the work or 
rewriting the whole set of classes I may as well do a good job.

Giacomo

On Wednesday, March 13, 2024 at 3:36:09 AM UTC David Roe wrote:

> There is also this old trac ticket 
>  about implementing fast 
> arithmetic in genus 2 Jacobians, which never made it into Sage.  I've CCed 
> Mike Jabobson, who worked on it.
> David
>
>
> On Tue, Mar 12, 2024 at 12:10 PM Giacomo Pope  wrote:
>
>> Thank you for linking this and I agree this is a great way to 
>> cross-compare the work we have been doing. I am not an expert in this area 
>> so I am not sure I should do a full review but I'm happy to look over it if 
>> this helps.
>>
>> As a small update on this work, I now have 
>>
>> class HyperellipticCurveSmoothModel(AlgebraicScheme_subscheme_toric)
>>
>> So this new class builds on top of AlgebraicScheme_subscheme_toric and 
>> the smooth projective model is built using a toric variety. The points on 
>> the curve are currently SchemeMorphism_point_toric_field, potentially I 
>> will need to make a child class of these if methods on the points 
>> themselves are required.
>>
>> With the working arithmetic and this new inheritance my work is now going 
>> to be the rather slow and painful rewrite of all hyperelliptic methods from 
>> the current implementation to ensure everything works on the smooth degree 
>> model.
>>
>> On Monday, March 11, 2024 at 6:23:38 AM UTC Kwankyu Lee wrote:
>>
>>> On Friday, March 8, 2024 at 7:37:04 PM UTC+9 Giacomo Pope wrote:
>>>
>>> As a small update, the repository now contains code to
>>>
>>> - perform arithmetic for
>>>   - the imaginary model (ramified, one point at infinity) for all cases
>>>   - the real model (split, two points at infinity) for all cases
>>>   - the real model (inert, zero points at infinity) for even genus
>>>   Which allows us to do "as much" as Magma does for Jacobians of 
>>> hyperellipticc curves from the perspective of arithmetic. 
>>>
>>> My current "test" for the arithmetic is that D - D = 0 for all cases, 
>>> that jacobian_order * D = zero and that order_from_multiple(D) works. If 
>>> people have other ideas for tests, please let me know. Of course at the 
>>> moment these tests are over finite fields but you can reasonable use other 
>>> fields (as Sabrina's message shows) but I am less sure about how to do 
>>> randomised testing here.
>>>
>>>
>>> I just set https://github.com/sagemath/sage/pull/35467 to "needs 
>>> review" status. The PR implements Jacobian arithmetic for general 
>>> projective curves.
>>>
>>> It is slow compared with Jacobian arithmetic using Mumford 
>>> representation, but could be used to crosscheck the 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+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/7f646c6d-bd0b-452d-a730-30144415f590n%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 

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

[John H Palmieri]

Dear all,

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

Second, voting closes tomorrow. Please vote!

Regards,
  John



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

> On Thursday, March 7, 2024 at 6:13:42 PM UTC David Roe wrote:
>
> Dear Sage developers,
> Thank you for those you nominated people for the committee following my 
> request 
> , 
> and thank you for those of you willing to serve.  The nominees are
>
> Nils Braun (nbr...@sfu.ca)
>
>
> Braun? Or Bruin ?
>
> I didn't notice when I voted (noticed only last night), as I blindly 
> assumed it's Bruin,
> and just went and searched for Nils Braun at SFU, (nobody found)
> but that's too big a typo to let this unnoticed.
>
> It can very well be that someone looked at Nils Braun ()
> and was unable to figure out who this is - and just skipped.
>
> Note that Nils Bruin has a github handle: https://github.com/nbruin
> but it was not listed.
>
> I think the vote shoud be re-done - if it's indeed not a mystical Nils 
> Braun
> on the ballot, and not Nils Bruin
>
> Cheers,
> Dima
>
>
>
>
>
>  
>
> J-P Labbé (jeanphil...@gmail.com, jplab on github)
> John Palmieri (jhpalm...@gmail.com, jhpalmieri on github)
> Viviane Pons (vivia...@gmail.com, VivianePons on github)
> David Roe (roed...@gmail.com, roed314 on github)
> Julian Rüth (julian...@fsfe.org, saraedum on github)
> William Stein (wst...@gmail.com, williamstein on github)
> Yuan Zhou (xiaoy...@gmail.com, yuan-zhou on github)
>
> Please send votes to sage-c...@googlegroups.com* by Thursday, March 14.  
> We are using approval voting 
> , so you can vote 
> for as many candidates as you like.  The committee will include at least 
> the top 5 candidates, and will be enlarged to include all tied candidates 
> if there is a tie for 5th place.  Note that you can choose to vote for more 
> or less than 5 candidates if you like.
>
> Discussion of candidates is allowed (feel free to continue this thread), 
> but please be respectful.  If you want to see the participation of these 
> candidates in the Sage community, you can search by name on sage-devel 
>  and on github 
> .
>
> Thanks for voting,
> David
> for the Sage Code of Conduct Committee
>
> * We are replacing sage-...@googlegroups.com with 
> sage-c...@googlegroups.com; they currently have the same membership.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/fd4b3d24-51a6-49fc-a59c-6167e7c05654n%40googlegroups.com.

Re: [sage-devel] Re: conda sage

[William Stein]

With switching to Miniforge it is now working for me extremely well.  I’m
going to be making a new video and tutorial about this soon.  Thanks for
all you do Isuru!

-- William Stein


On Wed, Mar 13, 2024 at 9:11 AM Isuru Fernando  wrote:

> Hi William,
>
> Let me know if you have any questions regarding conda installation of sage.
> It'd be great to have more visibility towards conda installation to
> attract more
> users and developers in particular who can help out.
>
> Thanks,
> Isuru
>
> On Sun, Mar 10, 2024 at 7:37 PM William Stein  wrote:
>
>> Minor correction -- they say "Given its wide usage, there are no plans to
>> deprecate Mambaforge."  So Mambaforge isn't deprecated as I incorrectly
>> wrote.  It's just "discouraged".
>>
>> I'm sorry for the noise, but the *conda* packaging ecosystem makes me
>> dizzy...
>>
>> On Sun, Mar 10, 2024 at 5:31 PM William Stein  wrote:
>>
>>> I was just carefully reading the page about Mambaforge linked to from
>>> Sage, i.e., this page
>>>
>>> https://github.com/conda-forge/miniforge
>>>
>>> and it says that Mambaforge is deprecated and no longer recommended, and
>>> instead people should install Miniforge, i.e., "(Discouraged as of
>>> September 2023)".  We should update the instructions at
>>>
>>>
>>> https://deploy-livedoc--sagemath.netlify.app/html/en/installation/conda#install-from-conda-forge
>>>
>>> since they recommend the now discouraged Mambaforge.
>>>
>>> The page https://github.com/conda-forge/miniforge suggests that
>>> Mambaforge is somehow "just as good", but when I tried doing clean
>>> installs, then installing Sage, I had the best experience (i.e., completely
>>> perfect!) with Miniforge, which is what they recommend.  Basically, we
>>> should instead recommend:
>>>
>>> curl -L -O
>>> https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-$(uname)-$(uname
>>> -m).sh
>>>
>>> sh Miniforge3-$(uname)-$(uname -m).sh -b -u -p /conda
>>>
>>> -- William
>>>
>>> On Sun, Mar 10, 2024 at 4:05 PM William Stein  wrote:
>>>
 Hi,

 So I was using MicroMamba, whereas that page says Sage only
 supports Mambaforge, Miniforge, Miniconda or Anaconda.I tried with
 Mambaforge (as recommended there) and everything works perfectly, with
 sage-10.2 being available, and nicely integrated with the conda ecosystem,
 and also it's easy to switch Python versions.  So I'll switch from using
 MicroMamba to Mambaforge.  Problem solved.

 William

 On Sun, Mar 10, 2024 at 1:47 PM William Stein  wrote:

>
>
> On Sun, Mar 10, 2024 at 1:39 PM Matthias Koeppe <
> matthiaskoe...@gmail.com> wrote:
>
>> William, do the instructions in our Installation Guide work for you?
>>
>> https://deploy-livedoc--sagemath.netlify.app/html/en/installation/conda#install-from-conda-forge
>>
>>
>
>> Note in particular this step: "Change channel priority to strict:
>> conda config --set channel_priority strict"
>>
>
> I'm using micromamba, which is supposed to be a drop in replacement
> for conda, but it just gives an error for the above, so maybe it is 
> missing
> critical features needed to install sage:
>
> ---
>
> (compute-server-1540) ~/anaconda$ micromamba config --set
> channel_priority strict
> The following arguments were not expected: strict channel_priority
> --set
> Run with --help for more information.
>
> ---
>
> I'll revisit whether I need to switch to another conda...
>
> That said micromamba has strict by default:
> https://github.com/mamba-org/provision-with-micromamba/issues/33
>
> (compute-server-1540) ~/anaconda$ micromamba config --set
> channel_priority strict --help
> Configuration of micromamba
> Usage: /usr/local/bin/micromamba config [OPTIONS] [SUBCOMMAND]
>
> Options:
>   -h,--help   Print this help message and exit
>
>
> Configuration options:
>   --rc-file TEXT ...  Paths to the configuration files to use
>   --no-rc Disable the use of configuration files
>   --no-envDisable the use of environment variables
>
>
> Global options:
>   -v,--verboseSet verbosity (higher verbosity with
> multiple -v, e.g. -vvv)
>   --log-level ENUM:value in
> {critical->5,debug->1,error->4,info->2,off->6,trace->0,warning->3} OR
> {5,1,4,2,6,0,3}
>   Set the log level
>   -q,--quiet  Set quiet mode (print less output)
>   -y,--yesAutomatically answer yes on prompted
> questions
>   --json  Report all output as json
>   --offline   Force use cached repodata
>   --dry-run   Only display what would have been done
>   --download-only Only download and extract 

Re: [sage-devel] Re: conda sage

[Isuru Fernando]

Hi William,

Let me know if you have any questions regarding conda installation of sage.
It'd be great to have more visibility towards conda installation to attract
more
users and developers in particular who can help out.

Thanks,
Isuru

On Sun, Mar 10, 2024 at 7:37 PM William Stein  wrote:

> Minor correction -- they say "Given its wide usage, there are no plans to
> deprecate Mambaforge."  So Mambaforge isn't deprecated as I incorrectly
> wrote.  It's just "discouraged".
>
> I'm sorry for the noise, but the *conda* packaging ecosystem makes me
> dizzy...
>
> On Sun, Mar 10, 2024 at 5:31 PM William Stein  wrote:
>
>> I was just carefully reading the page about Mambaforge linked to from
>> Sage, i.e., this page
>>
>> https://github.com/conda-forge/miniforge
>>
>> and it says that Mambaforge is deprecated and no longer recommended, and
>> instead people should install Miniforge, i.e., "(Discouraged as of
>> September 2023)".  We should update the instructions at
>>
>>
>> https://deploy-livedoc--sagemath.netlify.app/html/en/installation/conda#install-from-conda-forge
>>
>> since they recommend the now discouraged Mambaforge.
>>
>> The page https://github.com/conda-forge/miniforge suggests that
>> Mambaforge is somehow "just as good", but when I tried doing clean
>> installs, then installing Sage, I had the best experience (i.e., completely
>> perfect!) with Miniforge, which is what they recommend.  Basically, we
>> should instead recommend:
>>
>> curl -L -O
>> https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-$(uname)-$(uname
>> -m).sh
>>
>> sh Miniforge3-$(uname)-$(uname -m).sh -b -u -p /conda
>>
>> -- William
>>
>> On Sun, Mar 10, 2024 at 4:05 PM William Stein  wrote:
>>
>>> Hi,
>>>
>>> So I was using MicroMamba, whereas that page says Sage only
>>> supports Mambaforge, Miniforge, Miniconda or Anaconda.I tried with
>>> Mambaforge (as recommended there) and everything works perfectly, with
>>> sage-10.2 being available, and nicely integrated with the conda ecosystem,
>>> and also it's easy to switch Python versions.  So I'll switch from using
>>> MicroMamba to Mambaforge.  Problem solved.
>>>
>>> William
>>>
>>> On Sun, Mar 10, 2024 at 1:47 PM William Stein  wrote:
>>>


 On Sun, Mar 10, 2024 at 1:39 PM Matthias Koeppe <
 matthiaskoe...@gmail.com> wrote:

> William, do the instructions in our Installation Guide work for you?
>
> https://deploy-livedoc--sagemath.netlify.app/html/en/installation/conda#install-from-conda-forge
>
>

> Note in particular this step: "Change channel priority to strict:
> conda config --set channel_priority strict"
>

 I'm using micromamba, which is supposed to be a drop in replacement for
 conda, but it just gives an error for the above, so maybe it is missing
 critical features needed to install sage:

 ---

 (compute-server-1540) ~/anaconda$ micromamba config --set
 channel_priority strict
 The following arguments were not expected: strict channel_priority --set
 Run with --help for more information.

 ---

 I'll revisit whether I need to switch to another conda...

 That said micromamba has strict by default:
 https://github.com/mamba-org/provision-with-micromamba/issues/33

 (compute-server-1540) ~/anaconda$ micromamba config --set
 channel_priority strict --help
 Configuration of micromamba
 Usage: /usr/local/bin/micromamba config [OPTIONS] [SUBCOMMAND]

 Options:
   -h,--help   Print this help message and exit


 Configuration options:
   --rc-file TEXT ...  Paths to the configuration files to use
   --no-rc Disable the use of configuration files
   --no-envDisable the use of environment variables


 Global options:
   -v,--verboseSet verbosity (higher verbosity with
 multiple -v, e.g. -vvv)
   --log-level ENUM:value in
 {critical->5,debug->1,error->4,info->2,off->6,trace->0,warning->3} OR
 {5,1,4,2,6,0,3}
   Set the log level
   -q,--quiet  Set quiet mode (print less output)
   -y,--yesAutomatically answer yes on prompted
 questions
   --json  Report all output as json
   --offline   Force use cached repodata
   --dry-run   Only display what would have been done
   --download-only Only download and extract packages, do
 not link them into environment.
   --experimental  Enable experimental features


 Prefix options:
   -r,--root-prefix TEXT   Path to the root prefix
   -p,--prefix TEXTPath to the target prefix
   --relocate-prefix TEXT  Path to the relocation prefix
   -n,--name TEXT  Name of the target prefix

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

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

[Dima Pasechnik]

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

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

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


Braun? Or Bruin ?

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

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

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

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

Cheers,
Dima





 

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

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

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

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2a96cd6e-2509-4541-a3b5-8226c5ff2493n%40googlegroups.com.

Re: [sage-devel] Re: stopping cypari2, pari-jupyter and pplpy maintenance

[Vincent Delecroix]

Thanks Matthias. You are now an owner on PyPI.

On Tue, 12 Mar 2024 at 22:59, Matthias Koeppe  wrote:
>
> Thanks, Vincent, for all your work on these projects in the past, and for 
> letting us know about your decision.
> As https://github.com/sagemath/cypari2/issues/131 indicates (and previously 
> raised in 
> https://groups.google.com/g/sage-devel/c/JBFbtUNhqNU/m/2PvzZbS8AQAJ), we will 
> need to document development workflow, governance, release management process 
> for these projects (and others in the sagemath org).
>
> You can add me on PyPI for these projects, then I'll use the same deployment 
> key that the other sagemath projects use for pushing releases to PyPI.
> https://github.com/sagemath/cypari2/pull/141 is already prepared for this, 
> and I can add the same for the other projects.
>
> Matthias
>
> On Tuesday, March 12, 2024 at 10:44:08 AM UTC-7 Vincent Delecroix wrote:
>>
>> Dear all,
>>
>> I used to be the maintainer of cypari2, pari-jupyter and pplpy. I will
>> not work anymore on any of them from now on. The three projects are
>> under the sagemath organization on github so that any administrator
>> can take over. Concerning the access to PyPI to push releases I can
>> promote anybody who wants access (do we have a policy for this?).
>>
>> Best
>> Vincent
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/f174964b-692c-498a-be21-45a0b192e2f4n%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/CAGEwAA%3Dd3ZL4-gStcg7%3DmHSpPxY%2BhABBtaXDFB4SZXORuT0F_Q%40mail.gmail.com.