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 sure

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

ience 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 *v

[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

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

[sage-devel] Re: UniqueRepresentation MRO Question

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

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

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

[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

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

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

quot;" > : 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 th

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

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

[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

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

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

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

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 occu

[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

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

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

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

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

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

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

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

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

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

[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

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

Re: [sage-devel] change_ring for ideals

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

[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

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,

[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

[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

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

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

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

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 me

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

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

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

[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

[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

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

[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 enforced c

[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

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

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 ticke

[sage-devel] Re: GH Notifications

n 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

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

[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

[sage-devel] Re: Sage GSoC2023 Ideas Page

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

[sage-devel] Re: Sage GSoC2023 Ideas Page

y, 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: &

[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

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

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 Partitio

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

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

ecember 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. S

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 cann

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

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

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

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

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

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,

[sage-devel] Re: BROADCAST MESSAGE

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

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

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

[sage-devel] Re: AlphabeticStrings()

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 ß

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

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

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

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()" met

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

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 ticke

[sage-devel] Trac only displaying some comments

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

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

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

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

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

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

urves, 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: &

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

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

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

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

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

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

Re: [sage-devel] Re: LazyPowerSeriesRing Replacement

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

[sage-devel] LazyPowerSeriesRing Replacement

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

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

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

  1   2   3   4   5   6   7   8   9   10   >