Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

By choosing to be an exception in the Python world, Sage obviously does something quite wrong. Can someone who is not Dima or Matthias explain to us how it is possible that they both are claiming to represent the normal Python way of doing things? There have been numerous statements by

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

It would be fun to continue the conversation with Dima, but clutter things up here too much, as David points out. Suffice to say that certainly What would really simplify things here is creation of a Windows based installer, not mere a document on dozens of things to be done to set it all up.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

Pyenv is easier than sage distro, much easier. I meant *using* pyenv. I just don't want to be bothered when I really just use Sage. But this is quite orthogonal to the actual discussion, sorry for bringing up my 3.9 issues :-) Well, depending on a legacy (3.9) Python version isn't the

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

We (not just Sage, but you and I!) have been discussing this for almost 15 years. Haha, true! SageMath has several other long-term contributors who also package software. We're all roughly on the same page about what it would take to fix the sage installation for end users. And some

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

I understand that some macOS users are very comfortable with Sage the distro playing the role of a missing macOS package manager, The real question is about *users* in this case, not developers. I just got messed up the other day brew updating something which killed my Python 3.9 I need in

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

Please don't! +1 for sure > The modularization project (making pip-installation packages that contain portions of the sage library) started years ago with a general consensus of the sage community. Matthias led the project and did most of hard works. Many others did not care much about

[sage-devel] Re: Downloads

Thanks very much for this important service. Looks like the homebrew cask that provides your app has also been updated already. +1 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails

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

The anonymized votes are here , in case anyone wants to do further analysis. Thanks, David. This actually confirms that, as such elections go, it's remarkably non-controversial; a third

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

I also want to thank Vincent Delecroix, David Joyner, Harald Schilly, and William Stein for their service on the committee up until this year. Amen! -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop

[sage-devel] Re: VOTE: disputed PRs

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

[sage-devel] Re: VOTE: disputed PRs

Having just encountered this "in action", I have a suggestion: "There is no scheduled vote, but rather an ongoing poll based on opinions expressed by developers on the PR (these opinions can be expressed via previous positive reviews or explicit comments giving approval). The PR author is

Re: [sage-devel] Re: Application for NumFOCUS affiliation of SageMath

On Tuesday, March 5, 2024 at 2:08:07 PM UTC-5 William Stein wrote: Hi, Related to NumFOCUS, this new proposal for Jupyter to restructure their relationship with NumFocus is possibly relevant: https://jupyter.org/governance/linux-proposal.html Interesting, and certainly relevant. It's a

Re: [sage-devel] VOTE: disputed PRs

Dima, I think that if anyone is incapable of posting to a particular PR, they should send email to someone who can post and ask them to record the person's vote, resulting in a comment like "I am posting to record 1 negative vote from X, 2 positive votes from Y and Z". Yes, that would also

[sage-devel] Re: VOTE: use "blocker" label only for PRs; use "critical" label for Issues

On Wednesday, February 28, 2024 at 1:45:03 AM UTC-5 Kwankyu Lee wrote: Hi, Here I withdraw the early premature "giving up" on my recent proposal, since afterwards there were some positive comments. Hence I open a voting for Proposal: 1. Do not use "blocker" label for Issues, as

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

As part of this thread, I'd again ask for a discussion of the following situation I asked in the other thread. Dima had some interesting points about a less-vendored approach saving disk space etc., but it would be helpful to have input from people who have had to install Sage in these kinds

Re: [sage-devel] Proposal: Make pytest, pytest_xdist, pytest_mock, python_build standard packages

I believe I'm the person who introduced that long standing policy. It was indeed motivated by a significant paying customer's requirement to install Sage entirely from source, and without an external network. I believe no such customers have supported the Sage project for about a decade, so

Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

> I don't think it's off-topic to once again point out that this way of phrasing it is very developer-centric. That's not a wrong way to look at it, but an end-user-centric way of looking at it is also valid. It seems to me that "developer" here refers to a very different kind of

Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

Many of these are disputed for the same underlying reasons. Appointing a different editor for each PR is not likely to help. If you pick an editor from Camp A, he or she will always rule in favor of Camp A; pick an editor from Camp B... The camps are roughly split across the question

[sage-devel] Re: Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

We do not have much time to devote to Sage development. And this is a great time to thank Volker for continuing to serve as release manager for the vast majority of Sage tickets which are not about the design philosophy, despite his (and William's) lack of time. Thank you! -- You

Re: [sage-devel] how to enter a bug in the future for sagemath in github with no github account?

It is already the norm that when people report bugs to sage-devel, when appropriate, a relevant GitHub issue is created. I can only handle login using account+password. If I have to do more to login to a web site, I am not going to bother and not interested. If sagemath can setup either

Re: [sage-devel] Re: Policy for disputed PRs: discussion

Relevant to both the overall issue of project direction *and* the specific one about Sage-as-distribution, I would just add keeping in mind the Sage mission (at least, as it currently stands): Mission: *Creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab*.

Re: [sage-devel] Re: Policy for disputed PRs: discussion

To the extent that this specific PR is emblematic of a particular approach to Sage development (a flawed approach in Dima's view, if I understand right), then the whole approach should be discussed here. Probably many of these issues in Sage development have been discussed already, but it's

Re: [sage-devel] Re: Question about make dependencies

To John C's point, and perhaps with the humor that John P intended: https://daily.jstor.org/in-which-we-science-why-nouns-become-verbs-because-language/ -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop

[sage-devel] Re: Reviewer tools

I created a wiki page that contains simple bash scripts that may be useful to reviewers: https://github.com/sagemath/sage/wiki/Reviewer-Tools that may cure the heart missing "git trac". Thanks! -- You received this message because you are subscribed to the Google Groups "sage-devel"

Re: [sage-devel] Powers of 2

Congratulations and warmest thanks to all contributors! Agreed! -- 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

[sage-devel] Re: Poll: deprecate backslash operator

Though I am sympathetic to the pro-deprecation arguments and recognize they will win, I vote do not deprecate, as mission includes Matlab, and for backwards compatibility. As an example, the first edition of the AMS-published "Sage for Undergraduates" used the backslash operator in a number

Re: [sage-devel] Re: keywords in github

On Thursday, September 28, 2023 at 3:52:30 PM UTC-4 Dima Pasechnik wrote: it should be possible to search for patterns in commit messages across PRs - this info is in the git tree. GitHub metadata is harder to search, and I am quite surprised how limited their search options are. GitHub

Re: [sage-devel] Discussion and poll: should Sage Integers have a backslash operator?

On Wednesday, September 27, 2023 at 6:19:16 PM UTC-4 William Stein wrote: Hi, I'm the guilty party who added \ to Sage notation in the first place, and I would definitely vote to *remove* it. I wish I had never added it in the first place. Nils has some very good points! I do think it's

[sage-devel] Re: DeprecationWarning on sagecell in Graph([(0,1)]).vertices()

On Saturday, June 24, 2023 at 9:20:39 AM UTC-4 Georgi Guninski wrote: https://sagecell.sagemath.org/ Graph([(0,1)]).vertices() /tmp/ipykernel_1853928/1298164553.py:1: DeprecationWarning: parameter 'sort' will be set to False by default in the future See

[sage-devel] Re: Modularation doctests

Just ... wow. I know I don't get much of a say given my lack of recent development activity, but this level of granularity does seem absurd. It would certainly be a (psychological) barrier to development - how do you know which modules some random doctest you want to include depends on? - as

Re: [sage-devel] Re: ping - please cast you vote: VOTE: Follow NEP 29: Recommended Python version

Anyway, we need you. Both of you. +1 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on

Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?

(I'm planning upgrades in the next year or two, but it will be to relatively low power RISC-V hardware. There are moral, legal, environmental, and other non-financial reasons why people use "old" hardware. But of course the financial reasons are very real too.) Agreed on all points.

[sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?

As of today, it is plausible that such situations still exist. I am wondering about such situations existing in less-resourced areas globally (which would include less-resourced parts of developed countries). One big advantage of Sage-the-distribution historically was the ability to make

Re: [sage-devel] RealField isn't doing it right

Alpha: enter "e^1.1", press "more digits" 3.0041660239464331120584079535886723932826810260162727621297528605... Sage: RealLazyField()((e^1.1)).numerical_approx(200) 3.004166023946433394797850269242189824581146240234375000 Sage is not Wolfram Alpha, and neither is Mathematica. Alpha is

Re: [sage-devel] RealField isn't doing it right

Just to say a big *Thank You!* to you all for being utterly patient and polite and positive +100 -- 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

Re: [sage-devel] RealField isn't doing it right

This has been an interesting discussion, because it brings up again the inherent tradeoffs present in writing general-purpose software. We (not just Sage, but other similar systems) want something that is usable by those who need floating-point to do what it must do, as well as be

Re: [sage-devel] Github Discussions

Personal feeling is that a lot of people who have Sage *questions* are less likely to have GH accounts. I mean, some will. But a lot won't. So the friction for them would be similar to the other options - though sage-support maybe less so, as probably more people have Google accounts. And

Re: [sage-devel] online talk about the github workflow

My recording of the talk is now available at: https://www.youtube.com/watch?v=p3-W43ijTUg Great, thanks! See https://github.com/sagemath/website/issues/453 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and

Re: [sage-devel] online talk about the github workflow

For people who for some reason cannot get such an address, we can make an exception, on an individual basis (we are not in business of providing free email access, you know) and provide such persons with @sagemath.org emails - email server runs on Unix VM, accessible via ssh and hosted in

[sage-devel] Re: Migration to GitHub complete

https://github.com/sagemath/sage See https://github.com/sagemath/trac-to-github/blob/master/docs/Migration-Trac-to-Github.md for a transition guide from Trac to GitHub. Gratuliere and congratulations to all the many people who made this huge task possible! -- You received this message

Re: [sage-devel] online talk about the github workflow

On Thursday, February 2, 2023 at 4:36:35 PM UTC-5 François Bissey wrote: On 3/02/23 10:30, David Joyner wrote: > Hi Vincent: > Will this be recorded and posted on youtube, > or something like that? > - David > I am seconding that request. That time is 5:30am in my time zone. And I and

[sage-devel] Re: Closing the old Sage wiki

10:57:59 AM UTC-8 kcrisman wrote: > >> Query: What is the final decision on these pages (not Trac wiki) >> vis-a-vis the vote to move development to GH? I don't find at least some >> of that material on the sample GH wiki, e.g. >> https://wiki.sagemath.org/interact/

[sage-devel] Re: Closing the old Sage wiki

Query: What is the final decision on these pages (not Trac wiki) vis-a-vis the vote to move development to GH? I don't find at least some of that material on the sample GH wiki, e.g. https://wiki.sagemath.org/interact/ or https://wiki.sagemath.org/Workshops but I presume there is a plan.

[sage-devel] Re: Help wanted: Trac wiki migration, improve markup conversion code

Question (which I am unfortunately unable to assess): Is it possible that Trac ticket link of the form #xyzwv could automatically become links to the same GH issues once all migration is complete? I'm thinking of pages like https://github.com/sagemath/trac_to_gh/wiki/symbolics - the Trac

[sage-devel] Re: Different results for numerical and symbolic integration

> please post here the link to your report > >> https://sourceforge.net/p/maxima/bugs/4037/ -- 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

Re: [sage-devel] Re: Democratic issue: rushing decisions

> If we limit such powers, e.g. allowing just one delaying request per year > per person, then another vote can be called on a slightly different > question, effectively overruling the delaying request. > Whether two requests are two similar is the sort of thing a parliamentarian decides in

[sage-devel] Re: Democratic issue: rushing decisions

several developers asked for delays, to respect people with a busy > schedule, > [6] Thierry : "one month break is a bare minimum." > https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/STo_AT9qFgAJ > > In general I am very sympathetic to having "all deliberate speed" on big decisions

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

On Sunday, October 2, 2022 at 2:16:00 PM UTC-4 Nils Bruin wrote: > Speaking of backups ... do we backup the sage-devel, sage-support news > groups? It contains a lot of stuff that loses relevance with time, but > every now and again there are discussions that contain important bits of >

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

> I think part of a solution could be PR templates, which add structure to > the PR description (= the first comment). That could be a way of adding > Authors (and Reviewers) to a PR. If there's a way to (lightly) enforce that via some kind of bot, that sounds very reasonable. On another

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

Not sure where to ask this - here? On the GH page documenting the transition and new workflow proposal, I don't see a way to have multiple AUTHORs in the way we usually kept track of it. Note that often there were people who were authors who didn't show up on a specific commit, but which the

Re: [sage-devel] Re: is it intentional that prod does not stop when it hits 0?

On Thursday, September 22, 2022 at 6:06:19 PM UTC-4 wst...@gmail.com wrote: > Note also that prod(range(1,n)) does *NOT* just multiple 1 times 2 > times 3 in order. Instead, it uses a tree approach so that the > multiplications involve objects with more balanced sizes, which is > Thanks for

[sage-devel] Re: is it intentional that prod does not stop when it hits 0?

I'm not sure what you were expecting. It does return 0, but it does so after all the print statements are done. Remember, your "test" function just returns the input, so the map function just returns a list (well, a map object, but ...) and then we prod everything in the list. But that

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

> Given the tensions, I'd be more careful here. We're really not too > interested in opinions of random subscribers to sage-devel > (I don't have enough rights to see who's there). > That's a plausible argument, but as with most real-life elections in countries without compulsory voting, I

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

> "Subscribed to sage-devel" might not be a good criteria. For example, >> Harald Schilly has been the webmaster of Sage since 2007 and likely >> cares about this switch since it can impact him, but I don't think he >> reads sage-devel. >> > >> If we're going to talk about previous practice, I

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

> I think the 1st vote should be on moving from trac to Git**b; besides it > appears that, technically, move to Github is much easier than to Gitlab > (while there are migration tools available for trac->github, I could not > find anything for trac->gitlab). > > On the other hand

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

> I'd rather focus the vote primarily on the move away from trac, not > specifying whether it's GitHub or GitLab. > > > > > Given that, we face Arrow's theorem in picking a voting system > (especially if we also want to allow people to abstain). I'm normally in > favor of a Borda count

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

> > Consensus ?! Hmm - consensus means that everyone is for. I don't think > we will have it. So we can stop now, no? I think a simple majority is a > meaningful way to vote here. > Also, given the level of activity here, a separate thread for voting on this (whenever that becomes

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

> While I strongly support the shift to github, I also agree with Travis > that we should vote on a change this major, and give the community enough > time to weigh in. I would also encourage people on both sides of the > debate to give everyone the benefit of the doubt. To those who have

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

basis exports to GL, and that we can point people to that. I'm not sure how contributions from folks who on principle do not want to support GH would work, but doubtless we aren't the only project to have that problem. - kcrisman -- You received this message because you are subs

[sage-devel] Re: BROADCAST MESSAGE

And let's all broadcast a hearty thanks to the many people working hard to figure out what's going on and keep Sage development going!!! On Friday, September 2, 2022 at 2:47:04 AM UTC-4 Frédéric Chapoton wrote: > Dear Sage developers, > > in order to try to fix the recent upgrade, the *trac web

Re: [sage-devel] Solving quintics

For reference, is there a Trac ticket for this? (But don't look now, wait until the current outage is resolved!) On Tuesday, August 30, 2022 at 6:01:35 AM UTC-4 achi...@gmail.com wrote: > Hello all, > > with the described class library, it is now possible to solve irreducible > solvable

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

> let me take the opportunity to promote the use of the get_systems > function from sage.misc.citation which allows to see and acknowledge > which upstream packages were used by Sage for some computation, e.g. > > +1 -- You received this message because you are subscribed to the Google

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

> I take this opportunity to thank the Sage community and the developers of > related softwares integrated for this Huge effort and to let you know of > the positive comments that I receive form the research community in MSC-52. > THANK YOU SO MUCH! > > If you are interested in a deeper

[sage-devel] Re: Display of scale multiplier in scientific notation (the e notation for powers of ten) is missing for plots starting with 0

es-in-python-with-matplotlib > > https://github.com/matplotlib/matplotlib/blob/4f5cacfde9024076d9ab0cb6ad1c9a7cf352d5f9/lib/matplotlib/ticker.py > > > On Saturday, July 30, 2022 at 12:05:24 AM UTC+5:30 kcrisman wrote: > >> Time being solution would be to drop use of Selective

[sage-devel] Re: Display of scale multiplier in scientific notation (the e notation for powers of ten) is missing for plots starting with 0

> Time being solution would be to drop use of SelectiveFormatter to get > rid of 0 tick label if the axes cross. Let the origin be visible for some > time. > My guess is that this would not be seen as a great fix, but let's put images and other followup on the ticket. -- You received this

[sage-devel] Re: Display of scale multiplier in scientific notation (the e notation for powers of ten) is missing for plots starting with 0

This is now https://trac.sagemath.org/ticket/34233 -- 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

[sage-devel] Re: Display of scale multiplier in scientific notation (the e notation for powers of ten) is missing for plots starting with 0

Thanks for the continued conversation. I hope it was clear that "we would be grateful" implied that there was no compulsion on your part, as well as on the part of any other contributor. I did notice the mathtext option, but since our previous version had used the e notation, changing that

[sage-devel] Re: Display of scale multiplier in scientific notation (the e notation for powers of ten) is missing for plots starting with 0

This is a good question, and one that has been around for a while in some form, unfortunately; see https://trac.sagemath.org/ticket/7964 for a related ticket. See https://trac.sagemath.org/ticket/30983 for a ticket that complains instead about something else but which is closely related. We

Re: [sage-devel] Introduction to differentiable manifolds in SageMath

By the way, addressing the original topic, there is still the possibility of adapting these to the Sage tutorials at https://doc.sagemath.org/html/en/thematic_tutorials/index.html which would be a great contribution - just a suggestion in case the authors are interested. -- You received this

Re: [sage-devel] orbit decompositions

On Tuesday, May 3, 2022 at 7:48:07 AM UTC-4 axio...@yahoo.de wrote: > Won't you be better off thinking of it as a representation, then? > > Correct, but I don't know how to construct those on arbitrary vector spaces in Sage. That is to say, if I know the vector space, and I know the action,

Re: [sage-devel] orbit decompositions

On Monday, May 2, 2022 at 11:24:44 AM UTC-4 axio...@yahoo.de wrote: > I am actually not sure anymore, which methods or functionality this class > should provide. > > Would it possibly be better to enhance PermutationGroup with an additional > optional "from_action" and "from_cyclic_action"

Re: [sage-devel] orbit decompositions

On Sunday, May 1, 2022 at 7:32:01 PM UTC-4 Travis Scrimshaw wrote: > Sorry, I don't know an easy way. I've always just defined them by hand >>> whenever needed. >>> However, I agree with you that a better way is needed. >>> >> >> I would love for there to be some standard way to define a

Re: [sage-devel] orbit decompositions

On Thursday, April 28, 2022 at 11:26:12 AM UTC-4 David Joyner wrote: > On Thu, Apr 28, 2022 at 9:35 AM 'Martin R' via sage-devel > wrote: > > > > I don't know about OrbitDomains, how does it work / how do you use it? > > > > The documentation has an example: >

Re: [sage-devel] Re: [sage-release] Re: Sage 9.5 released

On Tuesday, April 26, 2022 at 10:31:17 PM UTC-4 Matthias Koeppe wrote: > An update: The latest version of the installation manual (from > https://trac.sagemath.org/ticket/33655) is available here: >

Re: [sage-devel] Re: [sage-release] Re: Sage 9.5 released

If we're moving away from providing binaries, then this is a good way to go, well organized. Below a few minor notes about the sagemath-tobias link, I hope they are helpful. My apologies in advance for any bike shedding, though I tried to be pretty concrete. 1. Is it possible to have a short

[sage-devel] Re: Sage binary for macOS

Thanks for all your work on this! On Saturday, April 23, 2022 at 6:39:16 PM UTC-4 marc@gmail.com wrote: > A prelease version of the macOS Sagemath app based on Sage 9.6.rc0 has > been available on > github for about a week now. I am

Re: [sage-devel] Re: [sage-release] Re: Sage 9.5 released

> Everyone agrees on that part, but how to go about it is a religious > matter. Truth. > I've been using sage, teaching with sage, writing papers that > cite sage, and giving presentations about my research that use sage for > about fifteen years. I have literally never met someone

Re: [sage-devel] Re: [sage-release] Re: Sage 9.5 released

On Friday, April 22, 2022 at 2:10:45 PM UTC-4 David Roe wrote: > I haven't been following the copy and paste thread, but I'm in favor of > keeping sage -i xyz functional, even at the cost of some hacks in our > codebase. There are a lot of existing Sage users who are familiar with > that

Re: [sage-devel] divmod() vs .quo_rem()

Just for reference, Sage already has divmod() (e.g. https://sagecell.sagemath.org/?q=owmsez) and returns a tuple of Sage integers, so maybe we already do? I don't know about the magic method though. quo_rem() was the one new to me, and doesn't actually appear to be defined - did you maybe

[sage-devel] Re: _SAGE_VAR_minus and Maxima limit direction

https://trac.sagemath.org/ticket/33692 On Monday, April 11, 2022 at 6:38:28 PM UTC-4 Nils Bruin wrote: > That's a fairly straightforward thing to fix: it just means that the > sage-to-maxima interface needs to learn how to translate "plus" and "minus" > in limit expressions. > > The easiest

[sage-devel] default interact widget for single value

Thanks to a lot of good work a few years back, we have fairly close alignment between historic @interact behavior on the Jupyter notebook (from ipywidgets) and the previous sagenb behavior. Sage cell server and CoCalc Sage worksheets are very close indeed. One fairly glaring difference I'm

[sage-devel] Re: Proposal: make Jupyterlab a standard package

Sorry for a tangential question - the overview page seems to imply that *everything* from a (current) Jupyter notebook will work in a Jupyterlab instance (and, by extension, presumably can easily be imported). Would that include the widgets we use for @interact? (Tail wagging the dog here is

[sage-devel] Re: arctanh vs. artanh

In terms of the missions statement, apparently we aren't the only ones, so consistency might be more important in any case: https://reference.wolfram.com/language/ref/ArcTanh.html Note e.g. sympy uses atanh as the "ordinary":

Re: [sage-devel] Can we restore `mean`?

al CAS." On Saturday, February 12, 2022 at 10:28:43 PM UTC-5 wst...@gmail.com wrote: > This happened in https://trac.sagemath.org/ticket/29662, as requested > by kcrisman. I just looked at that > ticket and added a comment about several additional examples where > deprecating

Re: [sage-devel] Re: 32768

> In addition, for me its a matter of sustainability to use things as long > as they work. +1 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [sage-devel] trac.sagemath.org down

On Sunday, December 12, 2021 at 12:41:39 PM UTC-5 Matthias Koeppe wrote: > Many thanks to all who are keeping our project infrastructure going! > >> +100 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop

[sage-devel] Re: ask.sagemath.org issues - do we need it?

Some hopefully-useful comments: Overall, I am not sure why the project is running this server. I think we > are spreading ourselves pretty thin here. There is also: > - https://groups.google.com/g/sage-support > - https://stackoverflow.com/questions/tagged/sage > 50 questions in last 6 months -

[sage-devel] Re: Demote SageTeX to an optional package?

Having a *standard* way to integrate Sage’s results in a document is > **crucial*. > > Since Sage is not (yet) in the position of R to have many user packages in a standardized place like CRAN, and since things like knitr are (hah!) crucial in that ecosystem, we almost certainly should

Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

> > > The way to spoil users of Sage on MacOS (or anywhere) is to create a > binary installer that work really well, > Correct. This is what all this discussion should be aiming toward - including a binary installer that *allows for compiling/installing of optional packages and Cython*. (Or

Re: [sage-devel] Re: Outdated instructions in "git the hard way"

> Also a brief explanation of that "git trac" magic does in terms of > plain git should be helpful. > > That is a very good point that might lead people starting with git trac to use "standard" git. -- You received this message because you are subscribed to the Google Groups "sage-devel"

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

> > How are these integrals above computed by Sage? Via Maxima, or in some > > other way? > > When I implemented this, they were all computed in Maxima by default, > unless otherwise requested. Thus symbolic integration may be > orthogonal to the pynac vs symengine discussion. > That is

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

> E.g. it looks like integration is not there. > If I recall correctly, we use ginac/pynac only for symbolics proper (i.e. not calculus), as well as for differentiation. I don't know if symengine is something to switch to (and Matthias is surely right about developer time, given the

Re: [sage-devel] Re: proposal - remove gcc, gfortran, python building/spkgs

My biggest concern on this is how flexible things like conda (which I don't know much about) is for different versions of Mac. I presume that: * If you are on Linux, you know how to use a package manager (though there may be some Ubuntu users who do not, I have known some) * If you are on

Re: [sage-devel] attempting Sage build on M1

On what appears to be a completely different note, I cannot use Jupyter. I can do sage -n and it opens the GUI in the browser, but actually attempting to start a worksheet leads to a massive failure. $ ./sage -n ┌┐ │

Re: [sage-devel] attempting Sage build on M1

> >> Perhaps you need to run >>> >>> brew install openjpeg >>> >>> (or brew reinstall openjpeg) >>> >>> >> Apparently doing this and sage -f pillow (+ its dependencies) fixed this >> problem. I'm not sure why it was a problem in the first place, though. >> > > basically, openjpeg install

Re: [sage-devel] attempting Sage build on M1

> Perhaps you need to run > > brew install openjpeg > > (or brew reinstall openjpeg) > > Apparently doing this and sage -f pillow (+ its dependencies) fixed this problem. I'm not sure why it was a problem in the first place, though. Think we need to add openjpeg to the brew list at

Re: [sage-devel] attempting Sage build on M1

On Thursday, June 3, 2021 at 1:05:17 PM UTC-4 dim...@gmail.com wrote: > For cvxopt, you need to patch its setup.py (we already patch it, but > not this bit), > which at the moment says > if sys.platform.startswith("darwin"): > SUITESPARSE_LIB_DIR = '/usr/local/lib' > SUITESPARSE_INC_DIR =

Re: [sage-devel] attempting Sage build on M1

> Update: It still is looking in /usr/local even though > /opt/homebrew/Cellar/openjpeg/2.4.0/ exists (and probably already did). It > also looks for little-cms2 in /usr/local/Cellar even though that also > exists in /opt/homebrew. Everything else it is looking for in > /opt/homebrew, it

Re: [sage-devel] attempting Sage build on M1

Update: It still is looking in /usr/local even though /opt/homebrew/Cellar/openjpeg/2.4.0/ exists (and probably already did). It also looks for little-cms2 in /usr/local/Cellar even though that also exists in /opt/homebrew. Everything else it is looking for in /opt/homebrew, it seems. --

Re: [sage-devel] attempting Sage build on M1

> apparently _imaging.cpython-39-darwin.so does not link to the right > libraries. > What's the output of > > otool -L > /Users/karl.crisman/Downloads/BrewSage/sage-9.4.beta0/local/lib/python3.9/site-packages/PIL/_ > imaging.cpython-39-darwin.so >

  1   2   3   4   5   6   7   8   9   10   >