[sage-devel] Re: Feature request: Flatpak

2025-02-09 Thread Marc Culler
On Sunday, April 25, 2021 at 1:53:03 PM UTC-5 Samuel Lelievre wrote: Marc Culler's SageMath-macOS app could provide inspiration for that. After having done some research on this, my preference would be to package Sage as an AppImage, and I have plans for doing that. An AppImage needs to be

Re: [sage-devel] Re: Linker failure for gap_packages on arm64 macOS 15.3

2025-01-29 Thread Marc Culler
Correction: The first two bullets were for arm, not for intel. I.e. On macOS, arm64: * the gap executable loads libgap in SageMath 10.4, 10.5 and 10.6. * crypting.so loads libgap in SageMath 10.4 and 10.6 but not 10.5. On macOS x86_64 : * the gap executable loads libgap in SageMath 10.4, 10.5

Re: [sage-devel] Re: Linker failure for gap_packages on arm64 macOS 15.3

2025-01-29 Thread Marc Culler
SageMath 10.4 and 10.5, but not 10.6. - Marc On Wednesday, January 29, 2025 at 5:25:18 PM UTC-6 dim...@gmail.com wrote: > On Wed, Jan 29, 2025 at 4:35 PM Marc Culler wrote: > > > > Looking back at the failed command I actually think this is a clang bug > which has nothing to do with

Re: [sage-devel] Re: Linker failure for gap_packages on arm64 macOS 15.3

2025-01-29 Thread Marc Culler
On Wed, Jan 29, 2025 at 1:33 PM Dima Pasechnik wrote: > > libgap is not really involved here; > cypring's GAP kernel module > (that's what's compiled here) can be loaded either in libgap, or in > gap executable - and the latter > isn't linked to libgap. I am no expert in GAP. But the code in

Re: [sage-devel] Re: Linker failure for gap_packages on arm64 macOS 15.3

2025-01-29 Thread Marc Culler
AP_ROOT" sdh_make -j1 - Marc On Wed, Jan 29, 2025 at 11:42 AM Dima Pasechnik wrote: > On Wed, Jan 29, 2025 at 11:39 AM Marc Culler > wrote: > > > > The missing symbols are defined in libgap and I was able to build > gap_packages after adding -lgap to LDFLAGS in spkg-i

[sage-devel] Re: Linker failure for gap_packages on arm64 macOS 15.3

2025-01-29 Thread Marc Culler
The missing symbols are defined in libgap and I was able to build gap_packages after adding -lgap to LDFLAGS in spkg-install.in. - Marc On Wednesday, January 29, 2025 at 10:16:23 AM UTC-6 Marc Culler wrote: > Wish Sage 10.6beta4 On an M1 macOS 15.3 system with CommandLineTo

[sage-devel] Linker failure for gap_packages on arm64 macOS 15.3

2025-01-29 Thread Marc Culler
Wish Sage 10.6beta4 On an M1 macOS 15.3 system with CommandLineTools 16.2.0.0.1.1733547573, the gap_packages-14.13.1 build is failing for me. (The build worked on an Intel system with XCode 16.0.0.0.1.1726343358). The linker errors are (full log attached): [spkg-install] gcc -o bin/aarch64-apple

Re: [sage-devel] Cython extension modules in optional spkgs

2025-01-26 Thread Marc Culler
OK. But clearly it is a bug that the CoxeterGroup package raises: RuntimeError: coxeter3 must be installed when coxeter3 *is* installed but sagemath_coxeter3 is not installed. - Marc On Sun, Jan 26, 2025 at 1:28 PM wrote: > On Sun, Jan 26, 2025 at 11:03:42AM -0800, Marc Culler wr

Re: [sage-devel] Cython extension modules in optional spkgs

2025-01-26 Thread Marc Culler
arc On Sunday, January 26, 2025 at 1:03:42 PM UTC-6 Marc Culler wrote: > Yes, I have a log file for coxeter3 which built fine. > > The problem turned out to be that I had to use BOTH ---enable-coxeter3 AND > -enable-sagemath_coxeter3. With the latter option, the .so file gets build

Re: [sage-devel] Cython extension modules in optional spkgs

2025-01-26 Thread Marc Culler
user to install the coxeter3 package when the coxeter3 package is installed already and what is really needed is the sagemath_coxeter3 package? - Marc On Sunday, January 26, 2025 at 12:49:02 PM UTC-6 dim...@gmail.com wrote: > On Sun, Jan 26, 2025 at 11:51 AM Marc Culler wrote: > > &

[sage-devel] Re: Cython extension modules in optional spkgs

2025-01-26 Thread Marc Culler
my configure command. I have no idea what would cause an optional package to be there. But whatever the mechanism may be, it also seems to cause the extension module for such an optional package not to get built. - Marc On Sunday, January 26, 2025 at 11:50:57 AM UTC-6 Marc Culler wrote: >

[sage-devel] Cython extension modules in optional spkgs

2025-01-26 Thread Marc Culler
In the venv of my recently built SageMath-10.6beta4 I find: % ls lib/python3.12/site-packages/sage/libs/coxeter3 __init__.py coxeter.pxd decl.pxd __pycache__ coxeter.pyx all__sagemath_coxeter3.py coxeter_group.py In other subdirectories of sage/libs, such as flint, one finds that every .pyx fi

Re: [sage-devel] The SageMath app for macOS

2024-12-01 Thread Marc Culler
macOS. > >> > >> And I continue to hope for something similar on Microsoft Windows… > >> > >> Of course, big thanks too to all contributors to SageMath which is such > a great project. > >> > >> Guillermo > >> > >> On Sat, 30

[sage-devel] The SageMath app for macOS

2024-11-30 Thread Marc Culler
As we approach the release of Sage 10.5, I thought it might be of interest to some people on this list that the macOS app for Sage 10.4 has been downloaded 25,744 times since its release on July 28. (That number combines the Intel and Arm disk images and is based on querying the github API.)

Re: [sage-devel] Threading and cypari

2024-11-21 Thread Marc Culler
The problematic bullet point in that PR is: * Don't copy everything from the PARI stack. During the 2018 PARI/GP atelier, I talked to Karim Belabas about a strategy to achieve this. The basic idea is that we need to have a linked list containing the Gens which live on the PARI stack. When the t

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

2024-11-20 Thread Marc Culler
On Wednesday, November 20, 2024 at 1:06:39 AM UTC-6 tobia...@gmx.de wrote: The new version of cysignals, released just a couple of hours ago, now builds using Meson and works fine on Windows. @Marc, Nathan & collaborators: I've seen that CyPari has some Windows-specific signal handling. Wo

[sage-devel] Re: proposal: new optional package Eigen (C++, headers only)

2024-10-29 Thread Marc Culler
I am fine with adding Eigen as an optional spkg. - Marc On Tue, Oct 29, 2024 at 7:15 AM Dima Pasechnik wrote: > Dear all, > > We'd like to add a new optional package Eigen (https://eigen.tuxfamily.org > ). > It will improve performance of at least one of the optional packages > (semigroup) > of

Re: [sage-devel] sage.graphs.bliss disappeared in SageMath 10.4

2024-10-26 Thread Marc Culler
Thanks. - Marc On Saturday, October 26, 2024 at 8:54:53 PM UTC-5 François Bissey wrote: > It is now a separate optional package > https://pypi.org/project/sagemath-bliss/ > > On 27/10/24 14:52, Marc Culler wrote: > > A Sage_macOS user pointed out that > > from

[sage-devel] sage.graphs.bliss disappeared in SageMath 10.4

2024-10-26 Thread Marc Culler
A Sage_macOS user pointed out that from sage.graphs import bliss produces a "Module not found" error. In SageMath 10.3 the directory sage/venv/lib/python3.11/site-packages/sage/graphs contained both bliss.pyx and bliss.cpython-311-darwin.so. But in 10.4 and 10.5 the corresponding director

[sage-devel] Re: A new logo?

2024-10-20 Thread Marc Culler
I think that is an interesting start. However, I think it would be a good idea (and also very helpful to me) for you to read this: https://developer.apple.com/design/human-interface-guidelines/app-icons (Because I would hope to be able to use the new logo as the Application Icon for the SageMa

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

2024-10-09 Thread Marc Culler
On Wednesday, October 9, 2024 at 9:32:27 AM UTC-6 Gonzalo Tornaría wrote: As far as I know, cysignals is another instance of a component originally developed for sagemath, about maybe 20 years ago, then separated into a standalone package. In theory, this separation should make it easier to sup

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

2024-10-08 Thread Marc Culler
On Tue, Oct 8, 2024 at 8:52 PM 'Gonzalo Tornaría' via sage-devel wrote: > For me cypari2 works really nice and it's not particularly difficult to > package (except it broke with pari 2.17, but of course having this as a > standalone package makes it much easier to fix it). What is the problem w

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

2024-10-08 Thread Marc Culler
On Tuesday, October 8, 2024 at 1:23:55 PM UTC-6 Nils Bruin wrote: - the examples we have of bits of software developed as part of sage that ended up as library components of other projects are peripheral, interfacing parts that were spun off into independent libraries. - we don't have exampl

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

2024-10-07 Thread Marc Culler
On Monday, October 7, 2024 at 12:05:25 AM UTC-5 Kwankyu Lee wrote: On the other hand, who would be the users of the distribution packages for whatever need? I wonder how they overlap with sage developers. A concrete example of a useful standalone Sage module is CyPari2. By including CyPari

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

2024-10-06 Thread Marc Culler
On Thursday, October 3, 2024 at 8:05:09 PM UTC-5 Kwankyu Lee wrote: The motivation of the modularization project is to reduce the burden who only needs some portion of the sage library, and wants to use and develop the portion within the python ecosystem. I would say that the motivation is to

[sage-devel] The e_antic spkg doesn't build with XCode 16 on macOS Sequoia

2024-10-03 Thread Marc Culler
This was the only other problem package besides gfortran. The issue seems to be that one of the e_antic files includes a boost header which triggers a warning about assigning out-of-range values to an enum. That warning was promoted to an error in clang 16. Boost actually already has a worka

Re: [sage-devel] gfortran 13.3.0 does not build for x86_64 with XCode 16 ...

2024-10-03 Thread Marc Culler
. - Marc On Thursday, October 3, 2024 at 3:19:13 PM UTC-5 dim...@gmail.com wrote: > Hi Marc, > does Homebrew's gfortran work for you? > Dima > > > On 3 October 2024 19:02:49 BST, Marc Culler wrote: > >> ... as I learned the hard way, after updating my build system to m

[sage-devel] gfortran 13.3.0 does not build for x86_64 with XCode 16 ...

2024-10-03 Thread Marc Culler
... as I learned the hard way, after updating my build system to macOS 15. The cause is this bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 for which a patch exists. - Marc -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe

Re: [sage-devel] Re: Memory leak in `NumberField().class_group().order()`

2024-09-15 Thread Marc Culler
> You can grab one of those objects on the heap and look at its backreference > graph How does one do that? - Marc On Sun, Sep 15, 2024 at 11:17 AM Nils Bruin wrote: > > On Sunday 15 September 2024 at 10:08:18 UTC-7 dim...@gmail.com wrote: > > For me this code is rather unpredictable, as ipyth

Re: [sage-devel] Re: Memory leak in `NumberField().class_group().order()`

2024-09-08 Thread Marc Culler
As I said above this does not happen with either cypari or cypari2 when using getno. This is not a cypari issue. The issue is that Sage creates a "unique" object for each new number field, where new means that the input parameters for the NumberField function have not been used before. The number

Re: [sage-devel] Re: Memory leak in `NumberField().class_group().order()`

2024-09-08 Thread Marc Culler
sage: pari.getheap() [201, 4265] sage: On Sunday, September 8, 2024 at 9:12:14 AM UTC-6 Marc Culler wrote: > I agree that this is a bug. I do not think it is the same issue as the > leak you reported involving elliptic curves. The reason I don't think so > is that it is possibl

Re: [sage-devel] Re: Memory leak in `NumberField().class_group().order()`

2024-09-08 Thread Marc Culler
I agree that this is a bug. I do not think it is the same issue as the leak you reported involving elliptic curves. The reason I don't think so is that it is possible to compute class numbers with no memory leak using the PARI getno function in either cypari or cypari 2. There are many thing

Re: [sage-devel] Re: Memory leak in `NumberField().class_group().order()`

2024-09-05 Thread Marc Culler
i Guninski wrote: On Wed, Sep 4, 2024 at 11:13 PM Marc Culler wrote: > > I think that here you are seeing caching taking place, rather than a memory leak. This is what I tried: > > You call this caching, I call it leak, it can be both ways. It is natural to compute the class n

Re: [sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

2024-09-04 Thread Marc Culler
On Monday, September 2, 2024 at 11:13:43 AM UTC-6 dima wrote: It appears that all these gunclone_deep() etc aren't documented in any proper way (and this is a root cause of this; same applies to memleaks we have in libsingular interface). Can you post a link to docs you are reading? I can only f

[sage-devel] Re: Memory leak in `NumberField().class_group().order()`

2024-09-04 Thread Marc Culler
I think that here you are seeing caching taking place, rather than a memory leak. This is what I tried: sage: import cypari2 sage: pari = cypari2.Pari() sage: def test(N): : for a in range(1, N): : K = NumberField(x^2+a, 'w') : m = K.class_group().order :

Re: [sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

2024-09-03 Thread Marc Culler
Georgi, sorry for misspelling your name. - Marc On Tuesday, September 3, 2024 at 12:56:49 PM UTC-5 Marc Culler wrote: > That is a pretty interesting exchange, it indicates that this memory leak > has been known to exist for 6 years, and the remedy is also discussed > there. De

Re: [sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

2024-09-03 Thread Marc Culler
o explicitly call a destructor [ e.g. > obj_free ] any time a function such as 'ellinit' was used > > > It's not easy if the list of functions "such as 'ellinit'" is not known. > > <https://pari.math.u-bordeaux.fr/archives/pari-dev-1808/msg

Re: [sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

2024-09-01 Thread Marc Culler
s. prev_size in fastbins". I won't force this list to participate in the full debugging experience. The basic problem has been identified. The remedy is far from clear. - Marc On Sun, Sep 1, 2024, 5:37 PM Marc Culler wrote: > This is now fixed in cypari. The fix consisted of replacing

Re: [sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

2024-09-01 Thread Marc Culler
ext of the peculiar memory model used by cypari and cypari2. I tested the cypari fix on linux ubuntu using the test function described earlier in this thread. With 10**8 iterations it never used over 8.4MB of memory. - Marc On Sunday, September 1, 2024 at 12:07:26 PM UTC-6 Marc Culler wr

Re: [sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

2024-09-01 Thread Marc Culler
the call to ellrootno and is not uncloning all of those GENs. But it only does that with a newly created curve. - Marc On Sunday, September 1, 2024 at 10:24:33 AM UTC-6 Marc Culler wrote: > I would say that the getheap behavior is a symptom of the same memory > management bug(s). Also,

Re: [sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

2024-09-01 Thread Marc Culler
...@gmail.com wrote: > On Sat, Aug 31, 2024 at 4:35 AM Marc Culler wrote: > > > > As Dima says, and as the issue he mentions supports, the current cypari2 > code which attempts to keep Pari Gens on the Pari stack as much as possible > is badly broken. There are many si

Re: [sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

2024-08-30 Thread Marc Culler
As Dima says, and as the issue he mentions supports, the current cypari2 code which attempts to keep Pari Gens on the Pari stack as much as possible is badly broken. There are many situations where Python Gen objects cannot be garbage-collected after being destroyed. I am sure that is a big pa

Re: [sage-devel] Re: (I’m failing to build a working binary) Please provide a snapcraft package/container as now all but one Linux distributions no longer package Sagemath.

2024-08-25 Thread Marc Culler
Dear Laël, On Sunday, August 25, 2024 at 2:29:44 AM UTC-5 "Dima" wrote: CertIainly Sage does build and run on all sorts of Linux systems. But it's getting more and more bloated to support macOS, and this gets in the way of Linux. It is true that Sage builds on linux, of course. It is false t

Re: [sage-devel] Re: Proposal: Demote jupyter-jsmol and tachyon to optional

2024-08-21 Thread Marc Culler
On Wed, Aug 21, 2024 at 12:35 PM Dima Pasechnik wrote: > what if you have a version mismatch between the toolchain used to build > the shipped binary, > and XCode you installed locally? I'd expect trouble, in particular with > C++. > When I tested the %%cython magic command I was running a beta

[sage-devel] Re: Proposal: Demote jupyter-jsmol and tachyon to optional

2024-08-21 Thread Marc Culler
, users of Sage, building from source is a bad idea. - Marc On Wednesday, August 21, 2024 at 12:03:29 PM UTC-5 Marc Culler wrote: > Using cython within Sage via the %%cython magic command definitely does* > not *require building Sage from source. That magic command works fine in &g

[sage-devel] Re: Proposal: Demote jupyter-jsmol and tachyon to optional

2024-08-21 Thread Marc Culler
Using cython within Sage via the %%cython magic command definitely does* not *require building Sage from source. That magic command works fine in the Sage_macOS binary distribution of SageMath. The cython pip package is included in that binary distribution, because it gets built and installed

[sage-devel] Re: Proposal: Demote jupyter-jsmol and tachyon to optional

2024-08-21 Thread Marc Culler
On Tuesday, August 20, 2024 at 8:22:35 PM UTC-5 Kwankyu Lee wrote: it is not a bad idea for a non-developer user to install sage from source. I disagree. It *is* a bad idea, for so many reasons: * It requires a lot of time and work which is completely unrelated to using Sage. * It will almos

Re: [sage-devel] Proposal: Policy for standard packages from binary wheelsall

2024-08-11 Thread Marc Culler
tions being IPython and its dependencies. - Marc PS I am also delegating the choice of version for many image processing libraries to the Pillow project, and trusting them to compile the libraries. On Sat, Aug 10, 2024 at 10:40 PM Matthias Koeppe wrote: > On Friday, August 9, 2024 at 7:37:34 AM

Re: [sage-devel] Proposal: Policy for standard packages from binary wheelsall

2024-08-09 Thread Marc Culler
x27;t know if this scheme will end up being simpler than installing Rust in the Sage build directory (which involves very little more than downloading and running rustup.sh). I hope it will. - Marc On Friday, August 9, 2024 at 8:54:48 AM UTC-5 Nathan Dunfield wrote: > On Thursday, August

Re: [sage-devel] Proposal: Policy for standard packages from binary wheels

2024-08-08 Thread Marc Culler
I think it would be possible to use a single spkg for all of the additional binary wheels, where the main content of that spkg is a requirements.txt file listing versions and hashes. I also think that would be easier to maintain than many spkg directories, one for each binary wheel. The only

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

2024-07-01 Thread Marc Culler
Thank you Sébastien for standing up for users, for distinguishing between users and developers, and for recognizing that those two groups have different needs. May your Karma increase exponentially! - Marc On Monday, July 1, 2024 at 8:18:36 AM UTC-5 Sébastien Labbé wrote: > I don't visit ask.

[sage-devel] Misleading message from sage

2024-07-01 Thread Marc Culler
I think it would be good to replace misleading messages in sage by accurate messages. I offer as an example the following message which occurs if I run sage after first running: export DOT_SAGE="~/Library/Application Support/SageMath-10-4"" The message I got was: Your home directory has a

[sage-devel] Re: command not found errors from configure

2024-05-04 Thread Marc Culler
Oh. And I think the default value should probably be set with: PYTHON_FOR_VENV=/usr/bin/false - Marc On Saturday, May 4, 2024 at 5:54:55 PM UTC-5 Marc Culler wrote: > It is disturbing when one sees "command not found" errors in a configure > script. That is what happens

[sage-devel] command not found errors from configure

2024-05-04 Thread Marc Culler
It is disturbing when one sees "command not found" errors in a configure script. That is what happens with 10.4.beta5. After tracing it down I found that they are coming from lines like: *if "${PYTHON_FOR_VENV}" -c "import sys; sys.exit(sys.version_info.minor < 11)"* *then :* The variab

[sage-devel] testing optional packages

2024-04-29 Thread Marc Culler
I don't know what the expectations are for testing optional packages, but in 10.4.beta4 when I run: ./sage -t venv/lib/python3.11/site-packages/symengine I get the exception: NameError: name 'test_sage_conversions' is not defined - Marc -- You received this message because you are subscribed

Re: [sage-devel] Re: help menu in jupyter notebook

2024-04-26 Thread Marc Culler
Yes, I was only talking about really just running Sage locally. - Marc. On Friday, April 26, 2024 at 7:54:38 PM UTC-5 Nils Bruin wrote: > On Friday 26 April 2024 at 15:44:22 UTC-7 marc@gmail.com wrote: > > I don't see what difference the choice of port makes to a user. It is not > possible

Re: [sage-devel] Re: help menu in jupyter notebook

2024-04-26 Thread Marc Culler
The jupyter server operates on the loopback interface which has IP address 127.0.0.1 and IP name localhost. The cocoserver uses that same interface. Jupyter tries to get port and if that is busy it hunts for a nearby port that is not in use. The cocoserver uses an arbitrary system-assig

Re: [sage-devel] Re: help menu in jupyter notebook

2024-04-26 Thread Marc Culler
Yes, I meant MB. Thanks. There are other issues with viewing local documentation files in a browser. On Ubuntu, Chrome and Firefox are packaged as snaps. A snap is not allowed to read a file:// url which is not in the user's home directory. As long as sage is installed in the user's home direc

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

2024-04-26 Thread Marc Culler
variable is not used in those cases, but I don't know why not. - Marc On Thursday, April 25, 2024 at 11:30:52 PM UTC-5 Marc Culler wrote: > This looks pretty complicated. > > I used XCode 15.0.1 to build the macOS SageMath-10-3 app for Arm and XCode > 13.4 for Intel. I got "

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

2024-04-26 Thread Marc Culler
On Fri, Apr 26, 2024 at 8:02 AM Dima Pasechnik wrote: > On Thu, Apr 25, 2024 at 4:36 PM wrote: > > you might also like to know that in 2000 I asked whether we can have > libgap :P > > https://www.gap-system.org/ForumArchive/Pasechni.1/Dmitrii.1/using_GA.1/1.html > It > Thank you! It is a strug

[sage-devel] Re: help menu in jupyter notebook

2024-04-26 Thread Marc Culler
Another drawback of linking to online documentation is that the online documentation is always for the current release version of Sage, not the Sage that the user happens to be running,. I have a suggestion to improve the situation, which is to do what the Sage_macOS app does. The app provides

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

2024-04-25 Thread Marc Culler
oying and/or >>>> alarming to someone with no plans to do anything involving compilation of >>>> C >>>> code. >>>> >>>> The calls to xcode-select were added in PR#36599 >>>> <https://github.com/sagemath/sage/pull/36599>

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

2024-04-25 Thread Marc Culler
s not open the dialog. The error message appears in >>>>> the terminal when running sage in a command line, which is annoying >>>>> and/or >>>>> alarming to someone with no plans to do anything involving compilation of >>>>> C >>>&

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

2024-04-25 Thread Marc Culler
ker instead of ld when their new version of ld >> was totally broken. This is done by adding -ld_classic to LDFLAGS. >> >> *Note to people who worked on PR #36599* (@jhpalmieri and @mkoeppe): I >> think Apple's new linker is working now, so it is probably no longer >>

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

2024-04-25 Thread Marc Culler
April 25, 2024 at 9:17:35 AM UTC-5 Marc Culler wrote: > Another amusing quote, this time from the sbrk man page on macOS: > > > The brk and sbrk functions are historical curiosities left over from > > earlier days before the advent of virtual memory management. > > That s

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

2024-04-25 Thread Marc Culler
systems). - Marc On Thursday, April 25, 2024 at 9:03:30 AM UTC-5 Marc Culler wrote: > On Thursday, April 25, 2024 at 8:28:48 AM UTC-5 Dima Pasechnik wrote: > > Essential components of sagelib such as GAP, Singular, don't run on > native Windows > > > I was amused to find the

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

2024-04-25 Thread Marc Culler
On Thursday, April 25, 2024 at 8:28:48 AM UTC-5 Dima Pasechnik wrote: Essential components of sagelib such as GAP, Singular, don't run on native Windows I was amused to find the following statement on the GAP forum from 2005: > W

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

2024-04-25 Thread Marc Culler
On Thu, Apr 25, 2024 at 8:28 AM Dima Pasechnik wrote: > On Thu, Apr 25, 2024 at 1:28 PM Nathan Dunfield > wrote: > > > > On Wednesday, April 24, 2024 at 10:14:09 PM UTC-5 Matthias Koeppe wrote: > > > > Yes, native Windows would clearly be a very important target. > > > > > > As a data point, dow

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

2024-04-24 Thread Marc Culler
to LDFLAGS. *Note to people who worked on PR #36599* (@jhpalmieri and @mkoeppe): I think Apple's new linker is working now, so it is probably no longer necessary and not a good idea to force use of ld_classic. - Marc On Tuesday, April 23, 2024 at 10:45:54 PM UTC-5 Marc Culler wrote: Tha

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

2024-04-24 Thread Marc Culler
On Wed, Apr 24, 2024 at 2:26 PM Oscar Benjamin wrote: > Presumably though a hypothetical person who wants CyPari2 but not all of > Sage can already just use CyPari so that person is already well served. > That hypothetical person could also use CyPari2 if they didn't care about memory leaks and

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

2024-04-24 Thread Marc Culler
e, 23 Apr 2024 at 15:27, Marc Culler wrote: > > > > The projects that will really benefit from modularization will be those > that provide their own limited mathematical context. Developers of such > projects will be able to choose which parts of Sage are relevant to their > s

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

2024-04-24 Thread Marc Culler
On Wednesday, April 24, 2024 at 8:05:15 AM UTC-5 Dima Pasechnik wrote: running Cython in sage prompt or in Sage Jupyter notebook has nothing to do with -i option. I realize that. But it looked to me like those variables are being set in the sage-env script *primarily* to support sage -i. Per

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

2024-04-24 Thread Marc Culler
On Tuesday, April 23, 2024 at 11:17:49 PM UTC-5 Marc Culler wrote: I wonder if the Sage community would be willing to reconsider the idea of having one entry point for every function provided by SageMath, I won't speak for the community, but I reconsidered this and I decided that it wou

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

2024-04-23 Thread Marc Culler
On Tuesday, April 23, 2024 at 8:58:58 PM UTC-5 Dima Pasechnik wrot It's not quite correct to say that a C, or other, compiler is not required to run Sage. Sage allows you to define, build, load, and run Cython extensions without leaving Sage, thus, it needs to call a compiler after cythonisati

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

2024-04-23 Thread Marc Culler
ub.com/sagemath/sage/commit/69213d74ead4e93687cf61f214b0d96dd3f9885a > > Maybe you can workaround this by setting AS=as and LD=ld in > sage-env-config. > > HTH, > Gonzalo > > > On Tuesday, April 23, 2024 at 3:48:18 PM UTC-3 Marc Culler wrote: > >> I discover

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

2024-04-23 Thread Marc Culler
I discovered, by installing the Sage_macOS app on a pristine macOS system, that somehow, somewhere, in Sage's startup sequence there is a call to gcc. This is true whether Sage is being started from a command line or a notebook. On such a macOS system /usr/bin/gcc exists, but calling it causes

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

2024-04-23 Thread Marc Culler
On Tuesday, April 23, 2024 at 4:07:37 AM UTC-5 Tobias wrote: In reply to the comment ( https://github.com/sagemath/sage/pull/36676#issuecomment-2067371677) once the modularization is in place, it will impose wide-ranging constraints on what functions from other modules you are able to use. C

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

2024-04-21 Thread Marc Culler
On Sunday, April 21, 2024 at 9:42:24 AM UTC-5 Nathan Dunfield wrote: For the statements in this thread, I don't see any contradictions about the definition of the "normal Python way of doing things". My understanding of that term is to post *self-contained* binary wheels to PyPI for all suppo

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

2024-04-18 Thread Marc Culler
On Thursday, April 18, 2024 at 12:47:36 PM UTC-5 David Roe wrote: On Thu, Apr 18, 2024 at 1:43 PM Matthias Koeppe wrote: I will first note that the title of this post is misleading. Everything that was merged has been reviewed -- as noted, many months ago. I agree that everything was reviewed

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

2024-04-16 Thread Marc Culler
+1 on making python_build a standard package. - Marc On Tuesday, April 9, 2024 at 10:44:36 PM UTC-5 Matthias Koeppe wrote: > We added python_build as an optional "pip" package (see > https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types > for > the terminology

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

2024-04-15 Thread Marc Culler
On Monday, April 15, 2024 at 7:03:27 AM UTC-5 Michael Orlitzky wrote: The solution for users is pretty simple. You should be able to install a sage that works and will remain working with one command using homebrew, conda, guix, etc. The reason you can't is ... I would just mention that macOS

Re: [sage-devel] Mysterious .sage behavior

2024-04-01 Thread Marc Culler
t; > > I must say I don't know what kind of problems these versioned names are > meant to solve. > > > > >On 31 March 2024 15:23:24 CEST, Marc Culler <https://groups.google.com/>> wrote : > > >if [ -z "$IPYTHONDIR" ]; then > > # W

[sage-devel] Mysterious .sage behavior

2024-03-31 Thread Marc Culler
This is a follow-up to a user's query in a Sage_macOS issue. The current sage-env script contains the excerpt below. It seems pretty confusing that Sage would create a directory named .sage/ipython-5.0.0 when Sage is shipping IPython 8.18.1. What would be wrong with calling the directory .s

Re: [sage-devel] Re: xz/liblzma has been compromised

2024-03-30 Thread Marc Culler
n general, just ssh on certain linux distros. I would NOT suggest that "for your security" Sage should stop supporting linux. - Marc On Saturday, March 30, 2024 at 9:08:45 AM UTC-5 Marc Culler wrote: > > Potentially, any tarfile we host may contain an exploit. > > Poten

Re: [sage-devel] Re: xz/liblzma has been compromised

2024-03-30 Thread Marc Culler
> Potentially, any tarfile we host may contain an exploit. Potentially, any file may contain an exploit. This hack specifically targeted ssh. When used by ssh to verify keys, the hacked liblzma would validate certain invalid keys, allowing a "back door" for a particular bad actor to login to

[sage-devel] Downloads

2024-03-26 Thread Marc Culler
In case anyone is interested ... The SageMath 10.3 app for macOS has been downloaded 684 times since it was released on Sunday. The SageMath 10.2 app was downloaded 8685 times since its release about 4 months ago. For both versions, Arm downloads outnumber Intel by about 2 to 1. Source: https

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

2024-03-22 Thread Marc Culler
rt is writing? Is there a reason why he is writing a kernel when one already exists? Obviously I have no idea what I am talking about and am publicly revealing my ignorance. - Marc On Friday, March 22, 2024 at 12:29:56 PM UTC-5 Marc Culler wrote: > I wasn't advocating anyth

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

2024-03-22 Thread Marc Culler
I wasn't advocating anything like that. Certainly I don't think that pari-jupyter should be "killed". I am assuming that pari-jupyter is or will be a package that can be installed with pip. And I am also assuming that it has no direct interaction with Sage. Are those assumptions wrong? If

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

2024-03-22 Thread Marc Culler
If one has Sage installed with the pari-jupyter package installed in Sage and one wants to run pari-jupyter, what does one do? Is it equivalent to just installing pari-jupyter with pip and starting it up in the normal way? Does pari-jupyter use any components of Sage? If the answers are "yes

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

2024-03-22 Thread Marc Culler
+1 On Thursday, March 21, 2024 at 11:51:40 AM UTC-5 John H Palmieri wrote: > 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 o

[sage-devel] Re: Jupyter Lab Sage menu

2024-03-06 Thread Marc Culler
It would also be a good idea to open the javascript console and see if there are errors being reported around the time when the menu disappears. - Marc On Wednesday, March 6, 2024 at 8:20:00 PM UTC-6 Marc Culler wrote: > Viviane, > > If you do a shift-reload (or whatever makes you

[sage-devel] Re: Jupyter Lab Sage menu

2024-03-06 Thread Marc Culler
Viviane, If you do a shift-reload (or whatever makes your browser clear its cache) does that make the menu come back? - Marc On Wednesday, March 6, 2024 at 8:11:45 AM UTC-6 Viviane Pons wrote: > Dear all, > > I am working on a conda distribution of sage with jupyter lab. My conda > environnem

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

2024-02-28 Thread Marc Culler
I see. Thanks. - Marc On Wed, Feb 28, 2024 at 6:49 PM Kwankyu Lee wrote: > > > On Thursday, February 29, 2024 at 8:35:24 AM UTC+9 Marc Culler wrote: > > I have a proposal: It should be forbidden to call for a vote on a proposal > before there has been a discussion. > &g

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

2024-02-28 Thread Marc Culler
I have a proposal: It should be forbidden to call for a vote on a proposal before there has been a discussion. Without a chair, it would be impossible for this group to follow Robert's Rules of Order, even approximately. But the basic process should still be the same. The rules are designed to

[sage-devel] Re: Question about the sage venv.

2023-12-07 Thread Marc Culler
On Thursday, December 7, 2023 at 5:04:25 PM UTC-6 Matthias Koeppe wrote: Sure, but that would preclude using the same SAGE_LOCAL for an installation with venv over a system python and an installation of SPKG python. I don't understand. The bash script sage/venv/bin/sage calls sage/venv/bin/

[sage-devel] Re: Question about the sage venv.

2023-12-07 Thread Marc Culler
On Thursday, December 7, 2023 at 2:31:24 PM UTC-6 Matthias Koeppe wrote: > The venv would always contain a pyvenv.cfg file. Could you explain why this matters for what you have in mind? It is not essential. It is just cleaner and more uniform. I think it is misleading to have something calle

[sage-devel] Re: Question about the sage venv.

2023-12-07 Thread Marc Culler
ptions because they already set the rpaths, to a subdirectory of the python package named .dylibs. - Marc On Thursday, December 7, 2023 at 12:17:00 PM UTC-6 Matthias Koeppe wrote: > On Thursday, December 7, 2023 at 10:04:14 AM UTC-8 Marc Culler wrote: > > I have a very narrow techical

[sage-devel] Question about the sage venv.

2023-12-07 Thread Marc Culler
I have a very narrow techical question. I am hoping for a narrow technical answer, preferably from someone who was involved in designing the Sage venv. QUESTION: Why doesn't the Sage venv contain a pyvenv.cfg file? When you read PEP 405 you learn that the py

Re: [sage-devel] Pillow built without jpeg support in Sage 10.2.rc3

2023-11-17 Thread Marc Culler
I should also have mentioned that macOS is an example of a system which does not come with libjpeg. On Fri, Nov 17, 2023 at 12:53 PM Marc Culler wrote: > No, I meant both "normal" and "standard". I am sure I will master this > terminology sooner or later. > > On

Re: [sage-devel] Pillow built without jpeg support in Sage 10.2.rc3

2023-11-17 Thread Marc Culler
No, I meant both "normal" and "standard". I am sure I will master this terminology sooner or later. On Friday, November 17, 2023 at 12:51:48 PM UTC-6 Marc Culler wrote: > I meant "normal" when I said "standard". > > On Friday, November 17, 20

  1   2   >