[sage-devel] Re: documentation of parents and elements

Hi Martin, Indeed this is a tricky issue because there are two competing forces: 1 - The construction of elements should lie with the elements, which would be accessible via the published html doc and "elt?". 2 - The parsing of input to pass to the element is done by the parent. >From purely

Re: [sage-devel] Chinese Translations and Xelatex

> 1. Are we allowed to have the latex engine set for xelatex and assume the user has this feature (if they care about compiling the pdf doc)? (The only other exception is uplatex for the Japanese docs.) If not, do we want to make that a dependency specifically for the Chinese translation pdf

[sage-devel] Chinese Translations and Xelatex

Hi everyone, There has been a PR giving a Chinese (simplified) translation of the Sage tour: https://github.com/sagemath/sage/pull/39792 We have had a long-standing problem of getting the pdf docs to compile, but the author was apparently able to solve the issue by using xelatex. However, I

[sage-devel] Re: Proposal for GSoC 2025 – Fixing direct_product and Related Methods in Permutation Groups (Issue #34504)

Dear Sudarshan, Thank you for your interest in GSoC. However, this mailing list is for issues related to development of Sage, not for GSoC proposal discussions. Please post such messages to the sage-gsoc list. Thank you, Travis On Monday, March 31, 2025 at 5:08:53 AM UTC+9 dandgawal...@gmail

[sage-devel] Urgent - wiki.sagemath is down

To whom it may concern, The wiki page has been down for a while now it seems: https://wiki.sagemath.org/ Is someone able to get this restarted? We need this for the GSoC currently (hence, the urgent in the title). We cannot even port it to GH without the data there; which would require a fair

Re: [sage-devel] Re: WeylGroup question

Sorry for not responding earlier about this. I posted on the GH issue, but in short, you can use `W.domain().roots()` or passing it the explicit space that has the roots that you want to use, e.g., sage: W = WeylGroup(RootSystem(['G',2]).root_lattice()) sage: list(W) [ [1 0] [ 1 0] [-1 3] [

[sage-devel] SageMath is a GSoC 2025 Mentor Organization

Hi everyone, Thank you everyone who added a project idea. If you have already been a mentor, then please log in again and agree to the terms for 2025. If you have not been, then please send me an email (tcscrims {} gmail.com) with a Google-type email address so I can add you as a mentor. App

Re: [sage-devel] Re: On plotting frac(x^2+y^2) as complex and implicit plot

I concur that it is just a moiré pattern and issues from sampling. Once you get sufficiently far from the origin, the interval of r for frac(r^2) = (0,1) gets very small (in fact, very quickly). Contrast this with f(x,y) = frac(sqrt(x^2+y^2)) It comes down to the sampling being done to make the

Re: [sage-devel] Re: GSoC 2025 Ideas

h and others in the C-library flint or SageMath library > > >> ore_algebra). The goal of this project is to write an interface to > > >> these SageMath tools using the standardized names from genfun. > > >> Additionally, there we expect the developer to write a document >

Re: [sage-devel] Re: GSoC 2025 Ideas

Additionally, I would like to propose that "SageMath subprojects" (such as ore_algebra, admcycles, sage-flatsurf, slabbe, ...) could make GSOC proposal under the SageMath umbrella. I believe it is easier for a newcomer to be able to contribute to a smaller standalone project. What do you thin

Re: [sage-devel] Re: GSoC 2025 Ideas

nfun can be replaced by >> > standard SageMath computations. >> > In the course of the project, it is likely that the developer has to >> > implement additional interface to the C-library flint. We also expect >> > the developer to identify critical features that

[sage-devel] Re: GSoC 2025 Ideas

this. Best, Travis On Friday, February 7, 2025 at 10:02:04 AM UTC+9 Travis Scrimshaw wrote: > Thanks, I've added you as a potential mentor there. > > Best, > Travis > > On Thursday, February 6, 2025 at 7:04:19 PM UTC+9 axio...@yahoo.de wrote: > >> I'd be h

[sage-devel] Re: GSoC 2025 Ideas

urs / >> week. This depends on the student, how you mentor, and how much time you >> want to spend. >> - You do not have to be listed as the mentor on any idea you propose. >> >> Best, >> Travis >> >> On Thursday, February 6, 2025 at 8:31:59 AM UTC+9 Tr

[sage-devel] Re: GSoC 2025 Ideas

at 8:31:59 AM UTC+9 Travis Scrimshaw wrote: > Hi everyone, >I have submitted the application for SageMath to be involved with this > year's GSoC program. In order to make our participation in the program > successful and rewarding, as well as an important part of being

[sage-devel] GSoC 2025 Ideas

Hi everyone, I have submitted the application for SageMath to be involved with this year's GSoC program. In order to make our participation in the program successful and rewarding, as well as an important part of being selected as a mentor organization, I need you to submit project ideas on o

Re: [sage-devel] GSoC 2025 Applications

Indeed, I am drafting the post about that now. Best, Travis On Thursday, February 6, 2025 at 4:22:14 AM UTC+9 dim...@gmail.com wrote: > Hi, > > Travis is taking care of this, as usual. Contact him if you want to get > involved. > > Dima > > On 5 February 2025 03:18:15 GMT-06:00, Gareth Ma wro

Re: [sage-devel] Policy for closing abandoned PRs

Short version is I am strongly opposed to such a policy, automated or not. It's good to see what code has been contributed but not merged for different issues. We also should not assume unresponsive authors means they have abandoned their PR too since I would say most of us have more limited ti

Re: [sage-devel] Re: [debian-science] Modularized sagemath packages: proof of concept

We are observing disadvantage of a long thread. It is also very useful to have it all in one thread though. it's more work with the modularised system, not less On the project level, It takes more work to provide more products (distribution packages) to users. I completely agree with

Re: [sage-devel] Re: Vote: Removing Automatic PR Size Labels

Matthias, let me very explicitly address your points to make sure that you recognized that I did address them (as per your remark 5). 0: That is a misrepresentation of my point: before changes are implemented that affect all developers, some outreach effort to all developers should be done. I a

Re: [sage-devel] Re: Vote: Removing Automatic PR Size Labels

a discussion with you on how to improve things, but I think we should start with the status quo. Additionally, IMO this change really should have had a proper discussion on sage-devel before it was merged. Best, Travis On Monday, July 1, 2024 at 7:21:34 PM UTC-7 Travis Scrimshaw wrote: Sorry

[sage-devel] Re: Invitation to Participate in Survey: Governance and Community building

Thank you for taking the time to make and review the results of this survey. Best, Travis On Friday, June 28, 2024 at 1:08:02 PM UTC+9 Anne Schilling wrote: > Thank you for taking the initiative! > > Best wishes, > > Anne > > On Thursday, June 27, 2024 at 4:46:21 AM UTC-7 Sébastien Labbé wrote:

Re: [sage-devel] Re: Vote: Removing Automatic PR Size Labels

Sorry for the delayed response due to conference travel. Vote count: (A1) 5 (A3) 1 (B) 1ish As such, please remove this automatic labeling of PR sizes. We can have a proper discussion about how to make it easier for newcommers to find good PRs to review, but we should actually have that discus

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

The vote is now https://groups.google.com/g/sage-devel/c/3PLZD-4UFIA/m/bRgiaa11AQAJ Although, again, the original adding of labels should have also had a vote... On Wednesday, June 12, 2024 at 11:05:16 AM UTC+9 Kwankyu Lee wrote: You may want to take a second look. This article does not presc

[sage-devel] Vote: Removing Automatic PR Size Labels

PR labels are being automatically added to roughly indicate their size. There are three options besides keeping the current behavior: (A1) Remove the automatic adding of labels; the must be added manually (like most other labels). (A2) Have a "whitelist" of contributors who want to have this aut

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

Or instead you have a whitelist for those that want it. I think at least one of these changes (whitelist or blacklist) should just be done in the same general way that these labels were introduced: no vote and just do it. This really should have had a vote, or at least a notification on sage-de

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

chrieb am Freitag, 10. Mai 2024 um 07:45:13 UTC+2: > >> I fully agree with Travis. I do not see the added value of these >> additional tags. >> >> On Thu, 9 May 2024 at 23:46, Travis Scrimshaw wrote: >> > >> > I am *very* strongly opposed to these tags

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

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

[sage-devel] CI Is (Generally) Broken

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 -

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

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

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

rete 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 *

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

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 revie

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

+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 (o

[sage-devel] Re: UniqueRepresentation MRO Question

tch 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 UniqueRepresentati

[sage-devel] UniqueRepresentation MRO Question

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'

Re: [sage-devel] Heun function support

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 an

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

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

[sage-devel] Re: VOTE: disputed PRs

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 >

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

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

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

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 Da

[sage-devel] Re: int vs long in 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

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

l >> 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 h

[sage-devel] SageMath GSoC 2024

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 pro

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

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

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

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 Multiv

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

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

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

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

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

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

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

uary 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

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

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

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

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 e

[sage-devel] Re: Google Summer of Code: Organization application deadline Feb 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 fo

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

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

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

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 mor

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

t 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 r

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

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 devel

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

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

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

lling 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: > T

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

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

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

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 p

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

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

Re: [sage-devel] change_ring for ideals

er 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 implemen

[sage-devel] change_ring for ideals

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 -

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

t;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> wro

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

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 th

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

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 detail

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

(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/

Re: [sage-devel] Re: Modularation doctests

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

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

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

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

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 smal

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

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 m

Re: [sage-devel] Re: Modularation doctests

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

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

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 se

[sage-devel] Re: Modularation doctests

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

[sage-devel] Modularation doctests

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://githu

[sage-devel] Re: Ideals in LaurentPolynomialRing

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 w

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

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 her

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

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

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

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

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

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

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

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 enfor

[sage-devel] The definition of one blankline

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 ex

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

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

[sage-devel] Re: GH Notifications

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 t

[sage-devel] GH Notifications

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

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

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 d

[sage-devel] Re: Sage GSoC2023 Ideas Page

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 idea

[sage-devel] Re: Sage GSoC2023 Ideas Page

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

[sage-devel] Sage GSoC2023 Ideas Page

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 subsc

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

d 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 a

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

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

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

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

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

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 coerci

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

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

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

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

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

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

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

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

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

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

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

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 p

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

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 pla

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

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 d

  1   2   3   4   5   6   7   8   9   10   >