[sage-devel] Re: SageMath GSoC 2024

2024-02-21 Thread Matthias Koeppe
Thanks, Travis, for sharing this great news here.

One recent change in the GSoC program, perhaps important for the Sage 
project, may have been overlooked in the past.

GSoC is open not just to "students" but also to "open source beginners" -- 
without any age limit or any restriction regarding the career stage. (Just 
"professional software engineers" are excluded from the 
program.) 
https://developers.google.com/open-source/gsoc/faq#what_are_the_eligibility_requirements_for_participation

So here's our opportunity to rope in postdocs on 9-month salaries, or our 
faculty colleagues close to retirement who clearly need a hobby besides 
gardening, etc.


On Wednesday, February 21, 2024 at 5:55:48 PM UTC-8 Travis Scrimshaw wrote:

> 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/4f9c6540-9907-4f41-8f5c-e1efbcecf722n%40googlegroups.com.


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

2024-02-21 Thread Nils Bruin
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/c1bc68c4-8b5a-47f1-9a53-39528aa852b4n%40googlegroups.com.


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

2024-02-21 Thread Nils Bruin
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/c6fe238f-9640-4c97-a861-d56fe6e87494n%40googlegroups.com.


[sage-devel] SageMath GSoC 2024

2024-02-21 Thread 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

2024-02-21 Thread 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] int vs long in cython

2024-02-21 Thread Nils Bruin
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/29f587a2-d399-4e0c-a38a-49a6781de877n%40googlegroups.com.


Re: [sage-devel] Re: One year of Sage development on GitHub

2024-02-21 Thread Sebastian Oehms
> *By the way, an author of a PR needs also the ability to remove "needs
work". Hence the author needs to be in the Triage team anyway in our
workflow. *

Not necessarily! If the *synchronizing trigger* is enabled then the bot
would change needs work to  needs review on a non draft PR each time a new
commit is pushed to the branch.

On Wed, Feb 21, 2024 at 10:01 AM Kwankyu Lee  wrote:

>
>
> On Tuesday, February 20, 2024 at 12:26:50 PM UTC+9 Matthias Koeppe wrote:
>
> Can the status label sync workflow help with this transition, without
> getting in the way? For example, when the _author_ removes the "needs
> review" label (without setting "positive review"), set the PR to "draft"?
>
>
> sync workflow seems not yet ready for the transition because of the bug.
>
> By the way, an author of a PR needs also the ability to remove "needs
> work". Hence the author needs to be in the Triage team anyway in our
> workflow.
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/sulCa-6EZRA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/268e5d1c-5ff4-4d88-8ea4-7aaef77973cfn%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/CAPEyD1C7Fi6AtuVDAjgLuiTLbHMJmUF3s6_j4vAMxg6SK3xZDA%40mail.gmail.com.


[sage-devel] Re: One year of Sage development on GitHub

2024-02-21 Thread Kwankyu Lee


On Tuesday, February 20, 2024 at 12:26:50 PM UTC+9 Matthias Koeppe wrote:

Can the status label sync workflow help with this transition, without 
getting in the way? For example, when the _author_ removes the "needs 
review" label (without setting "positive review"), set the PR to "draft"? 


sync workflow seems not yet ready for the transition because of the bug.

By the way, an author of a PR needs also the ability to remove "needs 
work". Hence the author needs to be in the Triage team anyway in our 
workflow.
 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/268e5d1c-5ff4-4d88-8ea4-7aaef77973cfn%40googlegroups.com.