Re: [sage-devel] "Copy" vs "Refactor"

Hi, Thank you for your responses. > Yes, in modern Python packaging, all installation goes through building wheels -- so the final installation location is not known at build time. > (Although in the Sage distribution, we are not quite there yet -- see https://trac.sagemath.org/ticket/32874) >

[sage-devel] Sage binary for macOS

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 writing to ask people with Apple computers to test the app and report problems as github issues. So far there have

Re: [sage-devel] "Copy" vs "Refactor"

On Sat, 23 Apr 2022, 19:00 ph h, wrote: > Hi, > > Thank you for your response. > > > Note: the ".in" suffix doesn't mean "include," by convention it roughly > > means "a file that will be processed by ./configure". So, for example, > > Makefile.in gets turned into Makefile when you run

Re: [sage-devel] "Copy" vs "Refactor"

On Saturday, April 23, 2022 at 9:08:55 AM UTC-7 Michael Orlitzky wrote: > 1. The python build system apparently can't make the right path > substitutions (like autotools could), and we use the python > build system for the bits relevant to these files. > Yes, in modern Python packaging, all

Re: [sage-devel] "Copy" vs "Refactor"

Hi, Thank you for your response. > Note: the ".in" suffix doesn't mean "include," by convention it roughly > means "a file that will be processed by ./configure". So, for example, > Makefile.in gets turned into Makefile when you run ./configure. So, to avoid confusion, ".in" should be ".src",

[sage-devel] Memory Leak in canonical_label with bliss?

Dear all, there seems to be a memory leak in canonical_label(...), using bliss. Here is a test script to demonstrate the problem: - import os, psutil from sage.all import * process = psutil.Process(os.getpid()) oldmem = process.memory_info().rss for i in range(100): G

Re: [sage-devel] "Copy" vs "Refactor"

On Sat, 2022-04-23 at 08:28 -0400, ph h wrote: > Dear All, > > If the three files: > >1. sage/sage >2. sage/src/bin/sage >3. sage/src/bin/sage-env > > are to be factored out into > >1. sage/resolvelinks.in >2. sage/sage.sage.in >3. sage/sage.src.bin.sage.in >4.

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

Neither approach assumes anything, but using “make” is at least familiar to anyone who has built any unix software in the past 30 years This is a null measure set of Windows users (and probably of Mac users). Especially of undergrad students, which are (or should be) a very sizable portion

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] "Copy" vs "Refactor"

Dear All, If the three files: 1. sage/sage 2. sage/src/bin/sage 3. sage/src/bin/sage-env are to be factored out into 1. sage/resolvelinks.in 2. sage/sage.sage.in 3. sage/sage.src.bin.sage.in 4. sage/sage.src.bin.sage-env.in and 1. sage/sage (sourcing

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

On Sat, Apr 23, 2022 at 2:08 AM Ray Rogers wrote: > > Do you still (?) want reports of successes/failures/hick-ups. I always seem > to find the last :) Sure, we do. Needless to say, it's better be triaged against known bugs. > > rrogers > > On 4/22/22 11:16, seb@gmail.com wrote: > >