Re: [sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

the warnings when doctesting. -- John On Thursday, April 25, 2024 at 1:19:50 PM UTC-7 John H Palmieri wrote: > Take a look at the discussion at > https://github.com/sagemath/sage/pull/36337, in particular > https://github.com/sagemath/sage/pull/36337#issuecomment-1741293729. I > saw bot

Re: [sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

he "duplicate libraries" warnings are caused by duplicate > rpath entries in the mach files. I will try to test that hypothesis. > > Do you have any idea what could cause those duplicate rpaths? Are there > multiple -rpath options being passed to the compiler? > > - Mar

[sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

Hi Marc, I just tried building Sage without `-ld-classic`. It builds, but I get warnings about "ignoring duplicate libraries", and those cause doctest failures. The lines could be modified to test whether xcode-select is present and executable first, or since Sage now does indeed build without

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

+1 to the inclusion of the package, in case anyone views the voting as still open. François, thank you for letting us know about how the ongoing disputes are affecting you. I feel your pain. Regards, John On Monday, April 15, 2024 at 2:01:43 PM UTC-7 François Bissey wrote: > > > On

Re: [sage-devel] Mysterious .sage behavior

I searched for "ipython-5.0.0" in the source and found this: if [ -z "$IPYTHONDIR" ]; then # We hardcode a version number in the directory name. The idea is # that we keep using the same version number as long as that is # possible. Only when some future IPython version really

[sage-devel] Vote: changes to Sage's Code of Conduct

Dear Sage community, As announced at https://groups.google.com/g/sage-devel/c/Xf6dbPLmKPY/m/p88auKlBAwAJ, I propose some changes to the Code of Conduct. Those changes have been discussed and modified based on feedback from several developers: visit https://github.com/sagemath/sage/pull/37501

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

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

Re: [sage-devel] Google Season of Docs – org application deadline April 2

Dima's suggestion is appealing, and somewhat along those lines, I like the idea changing Sage to use some standard documentation style (https://github.com/sagemath/sage/issues/31044). If the program provides a technical writer, though, those may not be suitable goals. A quick glance at least

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

Dear all, Voting continues until Thursday. We have been acknowledging each vote as it comes in, so if you think you voted but have not received an acknowledgment, please email sage-conduct at googlegroups.com. Regards, John On Thursday, March 7, 2024 at 10:46:03 AM UTC-8 John H Palmieri

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

On Thursday 7 March 2024 at 19:39:14 UTC+1 John H Palmieri wrote: > >> Martin: it's "sage-conduct" at googlegroups.com. >> >> On Thursday, March 7, 2024 at 10:29:58 AM UTC-8 Martin R wrote: >> >>> For some reason, I cannot see the name of the n

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

Martin: it's "sage-conduct" at googlegroups.com. On Thursday, March 7, 2024 at 10:29:58 AM UTC-8 Martin R wrote: > For some reason, I cannot see the name of the newsgroup I should be > sending my vote to. (I am using the google groups webinterface) > > Martin > On Thursday 7 March 2024 at

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

+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 the web visit

[sage-devel] Re: VOTE: disputed PRs

+1 On Monday, March 4, 2024 at 12:23:39 AM UTC-8 David Roe wrote: > With no further discussion on this thread > , I'm calling a > vote on a new process for resolving disagreements on a PR. > > *Proposal* > It is now allowed to vote on

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". On Monday, March 4,

Re: [sage-devel] Re: Sage's Code of Conduct: proposed changes

There are suggestions along maybe similar lines at https://github.com/sagemath/sage/pull/36844, and I am trying to think of how we might incorporate your suggestions and the other ones. I've had the thought before about other documents (like our department's by-laws) that there should be two

[sage-devel] Sage's Code of Conduct: proposed changes

Dear colleagues, I am working on some changes to Sage's Code of Conduct, and I am asking for comments. Once the draft has stabilized, then we will hold a vote on sage-devel to approve (or not) the changes. Please visit https://github.com/sagemath/sage/pull/37501 to see the proposal. The

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

ruary 2024 20:44:50 GMT, John H Palmieri > wrote: > >Sentences like "At the moment you are actively breaking down the precious > >project fabric, all in the name of you having your way" are personal > >attacks. Please stop. > > Blocking on GitHub membe

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

MT, Matthias Koeppe > wrote: > >On Tuesday, February 27, 2024 at 10:50:55 AM UTC-8 John H Palmieri wrote: > > > >A pretty safe second choice would be to have "make download" also > download > >the relevant files for pip installation and tell pip wher

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

Regarding the proposal to allow standard packages to be pip packages, no one really knows how much people rely on the all-in-one tarball that we currently distribute. No one really knows how often the "make download" option is used for people who just clone the git repo and want to do all of

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

(and Tobias also proposed in https://github.com/sagemath/sage/issues/37428) On Monday, February 26, 2024 at 5:05:56 PM UTC-8 John H Palmieri wrote: > I think that usage (1) is the correct use of "blocker," and usage (3) is > not. Usage (2) should have a new name, as Vincent p

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

I think that usage (1) is the correct use of "blocker," and usage (3) is not. Usage (2) should have a new name, as Vincent proposes. Failing that, this new use of "blocker" must be documented in https://doc.sagemath.org/html/en/developer/review.html. On Monday, February 26, 2024 at 4:21:58 PM

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

You're right, plus I was confusing "./bootstrap -d" (which is run by "make configure") with "./bootstrap -D" which forces the download. On Monday, February 19, 2024 at 3:17:11 PM UTC-8 Matthias Koeppe wrote: > On Monday, February 19, 2024 at 3:09:

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

irectory. > > > an option to ./bootstrap then would be logical > > >> >> Another possible direction: I've been thinking about creating a "./sage >> worktree" command, see https://github.com/sagemath/sage/issues/34744 >> >> >> On Monday,

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

" another time is > overkill as it creates another copy of the .git directory. And there is no > point in having multiple copies of the "upstream" directory, as the > filenames of the tarballs change whenever the contents change. > > On Monday, February 19, 2024

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

On Monday, February 19, 2024 at 12:10:49 PM UTC-8 Dima Pasechnik wrote: On Mon, Feb 19, 2024 at 7:42 PM John H Palmieri wrote: This (A and B below) has the advantage of being quite explicit. The original proposal 1) allow standard packages to be pip packages 2) drop the contents

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

This (A and B below) has the advantage of being quite explicit. The original proposal 1) allow standard packages to be pip packages 2) drop the contents of upstream/ from the Sage source tarballs. sounds explicit, but the more the discussion goes on, the more I feel that there are hidden

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

What does this (a discussion of how Sage specifies version restrictions) have to do with the proposal? If it's relevant, that was not clear in the original proposal, so please clarify. It sounds like you might be proposing removing version checks on many of the packages Sage uses, or at least

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

The original proposal allows for anyone to post to sage-devel to try to raise awareness ("Also note that an objector is welcome to attempt to bring others into the discussion on their side if they remain firmly opposed"). I prefer allowing the various participants the freedom to decide whether

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

I agree that we need a policy, and I am happy with David's proposal. A tangential follow-up to Matthias: I think that our code of conduct should be part of the distributed documentation. Should it be in the Developer's Guide? In some other existing documentation? As a standalone document? --

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

This post concerns https://github.com/sagemath/sage/pull/36492. The main topic of that PR is matroids about which I know almost nothing, so I am not the right person to review it. The structure of the PR perhaps opens up broader questions. The author has some new code, along with a PDF

[sage-devel] Re: Errors with make on macOS

Try: % make distclean # remove all progress, just in case % brew install cddlib fplll gsl maxima python3 singular suite-sparse # as recommended at the end of `./configure` % ./configure Then read the output and see if it still recommends installing gsl. I hope not. Then % make On Sunday,

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

t; read Python docs, as it's much less fun. > > Get a life. > > > > On Tue, 14 Nov 2023, 23:19 John H Palmieri, wrote: > >> Not all Americans like to verb things so profligately. >> >> On Tuesday, November 14, 2023 at 1:15:07 PM UTC-8 Dima Pasechnik wrote: &

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

Not all Americans like to verb things so profligately. On Tuesday, November 14, 2023 at 1:15:07 PM UTC-8 Dima Pasechnik wrote: > > > On Tue, 14 Nov 2023, 20:39 Matthias Koeppe, wrote: > >> On Tuesday, November 14, 2023 at 11:39:52 AM UTC-8 Dima Pasechnik wrote: >> >> On Tue, Nov 14, 2023 at

[sage-devel] Re: https://github.com/sagemath/sage/wiki/Sage-10.2-Release-Tour

Where might changes to the Sage library go? I might want to highlight #36310. On Friday, November 10, 2023 at 10:38:00 AM UTC-8 Matthias Koeppe wrote: > So far we have: > > Sage 10.2 Release Tour > > >- Live Documentation >

[sage-devel] Re: Need Some guidance

Read the Sage Developer's Guide (https://doc.sagemath.org/html/en/developer/) and take a look at the current issues for the project (https://github.com/sagemath/sage/issues). On Tuesday, October 17, 2023 at 10:54:25 AM UTC-7 Himanshu Sharma wrote: > Hello everyone I am currently new to open

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

Right. According to the Sage Developer's Guide, "Deprecated code can only be removed one year after the first stable release in which it appeared," so it will work for at least a year, and then someone would have to take further action to remove it completely. On Wednesday, October 4, 2023 at

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

By the way, see https://github.com/sagemath/sage/issues/36194 for a bug related to the preparser and "\". On Tuesday, October 3, 2023 at 9:59:47 PM UTC-7 John H Palmieri wrote: > The votes are overwhelmingly in favor of deprecating. I have opened > https://github.com/sagemath

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

The votes are overwhelmingly in favor of deprecating. I have opened https://github.com/sagemath/sage/pull/36394 for this. On Monday, October 2, 2023 at 3:42:38 AM UTC-7 kcrisman wrote: > Though I am sympathetic to the pro-deprecation arguments and recognize > they will win, I vote do not

[sage-devel] Poll: deprecate backslash operator

I asked this already but with a different subject heading, so people may have missed it. BackslashOperator is defined in "sage/misc/misc.py", and the preparser converts "A \ b" to the appropriate Python code. The docstring for BackslashOperator says "Implements Matlab-style backslash operator

Re: [sage-devel] What's the point of GF(2, impl='ntl')?

On Friday, September 29, 2023 at 12:32:14 AM UTC-7 Vincent Delecroix wrote: > What is your sage version? How did you install it? Did you open an > issue on github? > > Best > Vincent > > On Tue, 26 Sept 2023 at 07:00, John H Palmieri > wrote: > > > > Setup: >

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

so extinguishing it should be doable. We > should definitely not entrench its use further. > > If you want to write your denominator first, you can already do ~2 * 3 . I > think that's already sufficiently perverse that we don't need another way > to spell that. > On Wednesday,

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

The github issue #36060 (https://github.com/sagemath/sage/issues/36060) proposes adding a backslash operator for Sage integers, so that "2 \ 3" will return the same as "3 / 2". Do you support this? BackslashOperator is defined in "sage/misc/misc.py", and the preparser converts "A \ b" to the

[sage-devel] What's the point of GF(2, impl='ntl')?

Setup: sage: F = GF(2, impl='ntl') sage: m_ntl = identity_matrix(1, F) sage: v_ntl = vector(F, (1,)) Now consider sage: m_ntl * v_ntl sage: v_ntl * m_ntl I'm trying to multiply a 1x1 matrix by a 1-dimensional vector, in one order or the other. Here's what happens: the first line fails with a

[sage-devel] Remove unnecessary docstring warnings?

When running Sage, if I look at some docststrings by doing foo.bar?, I see at the top WARNING: the enclosing module is marked 'needs sage.graphs', so doctests may not pass. Of course my copy of Sage has (as far as I know!) a working copy of sage.graphs. Should this warning only be printed

Re: [sage-devel] Python return types

I tried using mypy, and I also just ran "sage --tox -e pyright", and neither seems to flag the conflict between the signature "def signature(self) -> Integer:" and the output, which is some arithmetic with "len(...)" and hence a Python int. (And both mypy and pyright produce a ton of warnings,

[sage-devel] Python return types

For a while now, Python has allowed return types to be specified in signatures: def f() -> int: It is my understanding that this doesn't actually do any error-checking or type-checking — see https://docs.python.org/3/library/typing.html. So this works without error: def f() -> float:

[sage-devel] Re: opinions requested on x + y behaviour for polynomials

In principle it seems okay, but to be honest, I don't think I understand Sage's polynomial rings. It seems like anything goes: sage: R. = GF(2)[] sage: S. = R[] sage: S sage: R.0 + S.0 x + x Why am I allowed to construct S? With your proposed changes, what happens in the

Re: [sage-devel] why sagemath creates so many file in TMPDIR and how to prevent this?

For what it's worth, the `alarm` function (provided by the cysignals package) allows for interrupting a command after a given amount of time. sage: alarm? Signature: alarm(seconds) Call signature: alarm(*args, **kwargs) Type: cython_function_or_method String form: File:

[sage-devel] Re: Can we get rid of the "Consider using a block-scoped tag" warning?

> developer's guide - > https://sagemath-tobias.netlify.app/developer/doctesting.html#the-doctest-fixer > > On Friday, August 4, 2023 at 2:45:21 PM UTC-7 John H Palmieri wrote: > >> I appreciate the description of the changes in `sage --fixdoctests` in >> the releas

[sage-devel] Re: Can we get rid of the "Consider using a block-scoped tag" warning?

I appreciate the description of the changes in `sage --fixdoctests` in the release tour, but are these features described anywhere in Sage's documentation? I didn't see anything at #35749 or #36024. On Thursday, August 3, 2023 at 11:31:25 AM UTC-7 Matthias Koeppe wrote: > On Thursday, August

[sage-devel] Re: strange error from integrate command with maxima 5.47 and sagemath 10.1 beta 6

I get the same error when evaluating this integral in Sage with its own Maxima. (version 5.46.0). On Sunday, July 16, 2023 at 10:30:53 AM UTC-7 Matthias Koeppe wrote: > On Sunday, July 16, 2023 at 5:48:00 AM UTC-7 Nasser M. Abbasi wrote: > > After some struggle, build sagemath with maxima

[sage-devel] IPython magic commands, automagic, and conflicts

IPython comes with various "magic" commands, for example "%ls" which runs the shell command "ls". The default mode in Sage is "Automagic is ON, % prefix IS NOT needed for line magics." This means that running "ls" within Sage does the same thing as running "%ls". So far so good. There are,

Re: [sage-devel] Graphics files in Sage documentation

nce those are basically the only things I have tinkered > with. > > Can you verify that you do not see any image files in the top level of, > say: > local/share/doc/sage/html/en/reference/manifolds/sage/manifolds ? > > - Marc > > On Wed, Jun 28, 2023 at 3:23 PM John H

Re: [sage-devel] Graphics files in Sage documentation

By the way, on my machine, local/share/doc/sage are almost identical sizes in 10.1.beta3 and 10.1.beta4. I don't know what explains the difference you're seeing. On Wednesday, June 28, 2023 at 12:51:38 PM UTC-7 John H Palmieri wrote: > This change should produce only the .svg files: >

Re: [sage-devel] Graphics files in Sage documentation

This change should produce only the .svg files: diff --git a/src/sage_docbuild/conf.py b/src/sage_docbuild/conf.py index 9b6b37480b..b5d6815c76 100644 --- a/src/sage_docbuild/conf.py +++ b/src/sage_docbuild/conf.py @@ -128,7 +128,7 @@ from sage.all_cmdline import * """ plot_html_show_formats

Re: [sage-devel] Graphics files in Sage documentation

I tried making this change (which would affect each ".. PLOT:" directive) but the documentation failed to build: diff --git a/src/sage_docbuild/conf.py b/src/sage_docbuild/conf.py index 9b6b37480b..db33c4b1d6 100644 --- a/src/sage_docbuild/conf.py +++ b/src/sage_docbuild/conf.py @@ -115,7 +115,7

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

Just do a global search-and-replace: change ".vertices()" to ".vertices(sort=True, key=id)" or ".vertices(sort=True, key=str)". This is not a new change; the deprecation warning has been in place almost a year, and there was discussion leading up to it. See

[sage-devel] Re: Graph([('A',1)]).adjacency_matrix() raises exception

By the way, I see this error message: TypeError: Vertex labels are not comparable. You must specify an ordering using parameter ``vertices`` Indeed, this works: g.adjacency_matrix(vertices=['A', 1]) On Monday, June 26, 2023 at 11:32:56 AM UTC-7 John H Palmieri wrote: > Please r

[sage-devel] Re: Graph([('A',1)]).adjacency_matrix() raises exception

Please read the help message for adjaceny_matrix. g = Graph([('A',1)]) g.adjacency_matrix? prints, among other things: * "vertices" -- list (default: "None"); the ordering of the vertices defining how they should appear in the matrix. By default, the ordering given by

Re: [sage-devel] Re: Cup Product and Wedge Product of Cochains

in the Sage library. In any case, feel > free to create a pull request to fix and improve it. > >> > >> On Saturday, June 17, 2023 at 9:28:05 PM UTC-7 Ezra Akresh wrote: > >>> > >>> We have provided an example inside this Cocalc notebook: > https://coca

[sage-devel] Re: Cup Product and Wedge Product of Cochains

at 9:28:05 PM UTC-7 Ezra Akresh wrote: > We have provided an example inside this Cocalc notebook: > https://cocalc.com/share/public_paths/9a10e579b445d6b489fe88dd6ad4e4375d4f5fba > > On Friday, June 16, 2023 at 5:50:24 PM UTC-5 John H Palmieri wrote: > >> Can you please pro

[sage-devel] Re: Cup Product and Wedge Product of Cochains

Can you please provide an example where things do not work? Are you talking about manifolds or cell complexes or some other classes? On Friday, June 16, 2023 at 1:14:32 PM UTC-7 Ezra Akresh wrote: > In a recent project, my team and I developed functions for the cup product > and wedge product

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

On Tuesday, May 30, 2023 at 12:59:54 PM UTC-7 G. M.-S. wrote: Dima and Matthias, I completely agree with Nils. Could you (both of you) take a short vacation from SageMath, please? More globally, I propose to stop this discussion completely for a few days. +100 It's time for this

[sage-devel] Re: Can I build Sage via MacPorts under MacOS 10.9?

In principle this should work. See https://github.com/sagemath/sage/issues/31505 for some relevant information. Others might have direct experience with it. On Friday, May 5, 2023 at 11:24:07 AM UTC-7 Louis Deaett wrote: > I'm interested in Sage development (and contributing some enhancements)

[sage-devel] Simons Software Research Faculty award

Dear US-based Sage developers, The Simons Foundation has announced a Scientific Software Research Faculty Award — https://www.simonsfoundation.org/grant/scientific-software-research-faculty-award/ — and it might be appropriate for Sage development. -- John -- You received this message

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

On Thursday, April 27, 2023 at 2:54:47 PM UTC-7 Isuru Fernando wrote: I guess there are several requirements we need 1. Support for all major OS/architecture combinations 2. Easy to build for rare OS/architecture combinations 3. Possible to install as a non-root user 4. Binaries are available

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

In an attempt to make this less of a religious war and more akin to something like a rational discussion: - The status quo is that we include Python3 and gcc. If you want to argue for their removal, you need to provide evidence that this will not cause problems for people on supported

[sage-devel] Re: Why SR('expression') fail on some but not others?

While sage_eval('sin(x)') does not work, sage_eval('sin(x)', {'x': x}) does work. sage_eval needs to know the context (which variables have been defined, etc.) in which to evaluate. I am not an expert, but sage_eval('sin(x)', locals=locals()) might work pretty reliably, without

[sage-devel] Re: bug in realfield when passing float literals

"2*1.1" is not a float literal. Note that RR(2.2) does what you want. On Monday, April 10, 2023 at 1:42:21 PM UTC-7 aw wrote: > sage version: 9.4 > operating system: fedora 35 > > float literals passed to realfield can yield wrong answers > > example: > > RR=RealField(200) > > print(RR(1.1)) >

[sage-devel] git question/request

Would it be a good idea for Sage tarballs, at least the development versions, to come with `upstream` defined already? With a fresh 10.0.beta6 tarball: % git remote -v trac https://github.com/sagemath/sagetrac-mirror.git (fetch) trac ssh://g...@trac.sagemath.org:/sage.git (push) Should

Re: [sage-devel] Breakage on OS X

they went through with > > make -j1 > > The usual macOS parallel docbuilder blues, it seems. > > > > On Tue, 28 Mar 2023, 19:35 John H Palmieri, wrote: >> >> I ran "brew upgrade" recently on two different Macs, one Intel and one Apple

[sage-devel] Breakage on OS X

I ran "brew upgrade" recently on two different Macs, one Intel and one Apple Silicon, and now the Sage documentation fails to build: [hyperboli] from

[sage-devel] Re: What happened to Mathematica magics ?

e stack... > > Le mercredi 1 mars 2023 à 04:24:36 UTC+1, John H Palmieri a écrit : > >> I think it's due to https://github.com/sagemath/sage/issues/34547. That >> ticket was created because with the old behavior in Sage, instance of >> Octave(), Mathematica(), etc. were cre

[sage-devel] Re: What happened to Mathematica magics ?

I think it's due to https://github.com/sagemath/sage/issues/34547. That ticket was created because with the old behavior in Sage, instance of Octave(), Mathematica(), etc. were created when Sage started up, regardless of the availability of the corresponding software. Once those became lazy

[sage-devel] Re: MIgration to GitHub: Heads-up on org invitations

Can we be proactive and request membership somewhere through GitHub, or do we have to receive an invitation? On Wednesday, February 1, 2023 at 3:57:51 PM UTC-8 Andrew wrote: > Thank you for all of your work on this! > Andrew > > On Thursday, 2 February 2023 at 10:10:01 am UTC+11 Matthias Koeppe

Re: URGENT: Re: [sage-devel] Jan 30 to Feb 4: Trac downtime, migration to GitHub

Is there going to be one more round of (presumably automatic) additions to trac, providing a link from each trac ticket to the corresponding GH issue? On Monday, January 30, 2023 at 2:06:34 PM UTC-8 dim...@gmail.com wrote: > On Mon, Jan 30, 2023 at 9:56 PM Kwankyu Lee wrote: > > > > On

[sage-devel] Re: Final call for GitHub user names

"palmieri" and "palmiery" and "jpalmieri" appear (probably from mistakes with cc entries), and they should all be changed to match my correct trac name "jhpalmieri" (same as my github id). On Wednesday, January 18, 2023 at 6:14:16 PM UTC-8 Kwankyu Lee wrote: > Dear readers, > > Attached

[sage-devel] Re: Determinant of a SR matrix substituted by a floating number is not numerical stable

Your current code has fragments like this: weighted_load = load_obj(f'./sym.sobj') print(f'weighted == weighted_load {weighted == weighted_load}') save(weighted, f'./sym.sobj') In particular, "sym.sobj" is read before it is written, so 'weighted_load' will be None. If I put the "save" lines

[sage-devel] Re: SageMath 9.8 beta 4: Error building a wheel for scipy-1.9.2

What OS? I'm guessing Mac OS, in which case you need the fix at https://trac.sagemath.org/ticket/34658, or build 9.8.beta3 or wait for a later beta release that includes the fix. -- John On Saturday, November 26, 2022 at 12:40:30 PM UTC-8 beingn...@gmail.com wrote: > Dear SageMath, > >

[sage-devel] Re: The documentation built for #34730 needs your attention for checking

I think the use of Tachyon instead of Jmol must be particular to that setup. When I build the docs with #34730, it looks the same as in the develop branch, same as on sagemath.org. On Wednesday, November 9, 2022 at 1:24:38 PM UTC-8 Eric Gourgoulhon wrote: > PS: the loss of text3d is

Re: [sage-devel] Re: polynomial coefficients -- sparse=True default -- why?

See https://trac.sagemath.org/ticket/33813 for a somewhat related issue, by the way. On Wednesday, October 19, 2022 at 1:18:56 PM UTC-7 john.c...@gmail.com wrote: > My suggestion was only for univariate polynomials. I am certainly not > proposing this for multivariate polynomials. I still

[sage-devel] Re: Help wanted: Issue and PR templates, replacement for ticket dependencies

I think it's okay to not make things mandatory. For labels, I propose a simple approach first: "Blocker" or not, "Bug" or not. (Currently, the "Task" type isn't used much, so the major distinction is between "Defect" and "Enhancement". Changing to "Bug" or not captures this.) I like the

[sage-devel] Re: Help wanted: Issue and PR templates, replacement for ticket dependencies

I like the idea of mimicking the trac setup, but moving away from trac also lets us reconsider parts of the trac interface. I personally do not find the "Priority" label very helpful, other than whether it's a blocker or not. What do others think? We could just ask people to label "Blocker" if

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

all vote" can be upgraded to a "big vote". In this case, all previously > handed-in votes are invalid and a discussion thread has to be opened. > > On Friday, 7 October 2022 at 17:43:02 UTC+2 John H Palmieri wrote: > >> I apologize for being indirect. I was responding

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

particular person who had advocated for a delay. We should be able to discuss general policy issues without this kind of derailing. On Friday, October 7, 2022 at 8:43:02 AM UTC-7 John H Palmieri wrote: > I apologize for being indirect. I was responding to Dima's sentence, "... > the delay wa

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

On Friday, October 7, 2022 at 3:45:27 AM UTC-7 dim...@gmail.com wrote: > On Fri, Oct 7, 2022 at 12:19 AM Kwankyu Lee wrote: > > > > > > > > On Friday, October 7, 2022 at 7:05:38 AM UTC+9 John H Palmieri wrote: > >> > >> Dima, presumably you're not talk

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

he request as our policy dictates. On Thursday, October 6, 2022 at 12:42:17 PM UTC-7 dim...@gmail.com wrote: > > > On Thu, 6 Oct 2022, 20:21 Jonathan Thornburg, wrote: > >> On Thu, Oct 6, 2022 at 8:45 AM John H Palmieri >> wrote: >> > There is nothing in our

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

wst...@gmail.com wrote: > On Wed, Oct 5, 2022 at 8:09 PM John H Palmieri > wrote: > > > > The main response I saw to the requests for a slower process was from > David Roe, saying, "Finally, since we're just voting on trac vs github I > don't think there's a need to

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

The main response I saw to the requests for a slower process was from David Roe, saying, "Finally, since we're just voting on trac vs github I don't think there's a need to draw out the discussion until October 1, and several people (William and Dima) have made arguments for making a decision

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

You would think that this would be a solved problem: others in the open source community must have be in the practice of backing up their GitHub info. On Thursday, September 29, 2022 at 6:55:44 PM UTC-7 Nils Bruin wrote: > A fair point made: an "exit strategy" from Github should exist and

Re: [sage-devel] View issues

If you do `view(G, debug=True)`, it will first print out the entire LaTeX file that it's using. You could paste that into an actual file and see if you can pin down what the error is, and whether it's coming from your TeX installation or somewhere else. On Tuesday, September 27, 2022 at

Re: [sage-devel] Temporary files problems

I created https://trac.sagemath.org/ticket/34593: we should document how to change the location of the temporary directory, and maybe we should create a `.tmpreaper` file. On Tuesday, September 27, 2022 at 11:06:01 AM UTC-7 Michael Orlitzky wrote: > On Tue, 2022-09-27 at 18:10 +0100, Dima

Re: [sage-devel] Temporary files problems

On Tuesday, September 27, 2022 at 10:11:00 AM UTC-7 dim...@gmail.com wrote: > Basically, we should deprecate and remove tmp_dir() and tmp_filename() > from Sage. > Does Sagecell use them? It should not, Python3 has perfectly good > replacements... > As long as we test everything on a

Re: [sage-devel] Temporary files problems

On Tuesday, September 27, 2022 at 8:33:01 AM UTC-7 dim...@gmail.com wrote: > > > On Tue, 27 Sep 2022, 15:45 John H Palmieri, wrote: > >> One of the issues is that code in Sage is using this temporary directory >> in the background; the user is not doing it

Re: [sage-devel] Temporary files problems

One of the issues is that code in Sage is using this temporary directory in the background; the user is not doing it and has no control over it. Regardless of the context manager approach, apparently some browsers refuse to open local files that are not in the user's home directory, so this

[sage-devel] Re: Temporary files problems

See also https://ask.sagemath.org/question/64192/temporary-html-files-location-in-sage-97/ — some browsers can't access local files in /tmp from the notebook, so plots do not appear. Perhaps TMP_DIR_FILENAME_BASE could be customizable. Other options? On Monday, September 26, 2022 at 7:58:01

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

e-trac-wiki-to-github > > now > > On Saturday, September 24, 2022 at 5:46:15 PM UTC-7 Matthias Koeppe wrote: > >> On Saturday, September 24, 2022 at 5:15:11 PM UTC-7 John H Palmieri wrote: >> >>> I think I'm missing part of this. What is the actual path to

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

I think I'm missing part of this. What is the actual path to switching to GitHub? I've seen pages describing how individual development tasks will be converted from trac to GitHub, but what does the overall transition look like? - Do we just say, before November 1 (or whenever) we're doing

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

On Sunday, September 18, 2022 at 2:55:34 PM UTC-7 dim...@gmail.com wrote: > > > On Sun, 18 Sep 2022, 22:44 John H Palmieri, wrote: > >> William, this is exactly why I search in the sage-trac Google group >> rather than on the trac website. > > > it's looks

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

William, this is exactly why I search in the sage-trac Google group rather than on the trac website. The sage-trac group is also good for browsing to see recent activity. On Sunday, September 18, 2022 at 11:12:59 AM UTC-7 wst...@gmail.com wrote: > On Sun, Sep 18, 2022 at 10:27 AM Matthias

  1   2   3   4   5   6   7   8   9   10   >