Re: [sage-devel] Re: Error building Sage on Arch

On May 26, 2025 2:34:39 AM CDT, Antonio Rojas wrote: >Right, the headers were reorganized in version 4.0 so the configure.spkg >test is broken. Try `configure --with-system-planarity=force` this will only work on the branch of > >El lunes, 26 de

Re: [sage-devel] Re: Error building Sage on Arch

Right, the headers were reorganized in version 4.0 so the configure.spkg test is broken. Try `configure --with-system-planarity=force` El lunes, 26 de mayo de 2025 a las 4:24:14 UTC+2, benjami...@gmail.com escribió: > I installed planarity from Arch's repository. It still doesn't compile. > I t

Re: [sage-devel] Re: Error building Sage on Arch

This should work, provided you have libplanarity.so installed with its headers. You probably forgot to run ./configure after you installed it. On May 25, 2025 9:08:07 PM CDT, Benjamin Moraga Baeza wrote: >I installed planarity from Arch's repository. It still doesn't compile. >I think, the co

Re: [sage-devel] Re: Error building Sage on Arch

I installed planarity from Arch's repository. It still doesn't compile. I think, the compiler doesn't recognize de system version of planarity, because it tries to compile it anyway. Benjamín M. Moraga El vie, 23 may 2025 a las 13:47, Dima Pasechnik () escribió: > On Fri, May 23, 2025 at 11:46 

Re: [sage-devel] Re: Another problem building Sage on 25.04

On 5/23/25 3:43 PM, Antonio Rojas wrote: Ubuntu 25.04 is shipping a broken version of m4ri, use the bundled version. Following Antonio's suggestion I tried a clean install with ./configure --with-system-m4ri=no  and everything worked perfectly. -- You received this message because you are su

Re: [sage-devel] Re: Error building Sage on Arch

On Fri, May 23, 2025 at 11:46 AM Antonio Rojas wrote: > > Arch ships version 4.0 which builds fine with GCC 15, no patching needed. https://github.com/sagemath/sage/pull/40153 updates it to 4.0.0.0, please review > > El viernes, 23 de mayo de 2025 a las 17:38:00 UTC+2, dim...@gmail.com > escribió

Re: [sage-devel] Re: Error building Sage on Arch

Arch ships version 4.0 which builds fine with GCC 15, no patching needed. El viernes, 23 de mayo de 2025 a las 17:38:00 UTC+2, dim...@gmail.com escribió: > Hi, can we get arch's patch into Sage? > > > On May 23, 2025 3:19:22 AM CDT, Antonio Rojas wrote: > >> Install planarity from the Arch repo

Re: [sage-devel] Re: Error building Sage on Arch

Hi, can we get arch's patch into Sage? On May 23, 2025 3:19:22 AM CDT, Antonio Rojas wrote: >Install planarity from the Arch repos. The bundled version is not >compatible with GCC 15 > >El viernes, 23 de mayo de 2025 a las 9:39:36 UTC+2, benjami...@gmail.com >escribió: > >> I get and error whil

Re: [sage-devel] Re: should I manually adapt meson.build?

On 2025-05-16 06:38:39, 'tobia...@gmx.de' via sage-devel wrote: > You have to (pip)install `meson`. Not sure what's the sage-the-distro way > of doing this (or why meson is not automatically installed in the venv). Maybe it just needs ./sage -sh first? -- You received this message because you a

Re: [sage-devel] Re: dropping numpy 1 support?

Well, numpy 1 isn't going to be be supported well on Python 3.13, so that's a bit moot one way or another. I don't think Debian is working on updating their SageMath package (and Ubuntu never had its own SageMath effort, I think) We have only ourselves to blame for stalling on Debian effort. Until

Re: [sage-devel] Re: C++ Error building Sage

Hi David, I already mentioned that 10.6 release is broken. Please use the latest beta (and perhaps you will need more not yet merged patches) Dima On 1 May 2025 15:06:17 GMT-05:00, David Kohel wrote: >Hi everyone, > >Indeed, here is the relevant error line: > >../../src/sage/graphs/base/boost_i

Re: [sage-devel] Re: role of file Pipfile

That's a different Pipfile, added in a9f8401ef643 On Wed, Apr 30, 2025 at 11:48 AM 'tobia...@gmx.de' via sage-devel < sage-devel@googlegroups.com> wrote: > I'd already removed this in a merged PR > https://github.com/sagemath/sage/pull/39031. No idea why this file is now > back. Feel free to open

Re: [sage-devel] Re: Devel version

ve. > > > >> Or is there something else in particular? >> >> On Thu, 24 Apr 2025 at 23:15, Dima Pasechnik wrote: >> >>> >>> >>> -- Forwarded message - >>> From: Dima Pasechnik >>> Date: Thu, Apr 24, 2

Re: [sage-devel] Re: Devel version

On Thu, Apr 24, 2025 at 4:01 PM Aram Dermenjian < aram.dermenjian.m...@gmail.com> wrote: > I ran gap and it said it's version 4.13.1, so it theoretically should be > ok? > what does this mean, exactly, you ran GAP? How? Did you run Sage's GAP, or a system-wide GAP? > > I ran the `ldd` code you

Re: [sage-devel] Re: Devel version

I ran gap and it said it's version 4.13.1, so it theoretically should be ok? I ran the `ldd` code you said, but I'm not sure how to read the output. Here's what I get: (sage-sh) aram@Cali-Alien:sd$ ldd /sage/sd/src/sage/libs/gap/ libgap.cpython-312-x86_64-linux-gnu.so linux-vdso.so.1 (0x0

Re: [sage-devel] Re: Devel version

On Thu, Apr 24, 2025 at 12:02 PM Aram Dermenjian < aram.dermenjian.m...@gmail.com> wrote: > Yeah a few times I tried doing make after and there seemed to be *some* > success sometimes. Anyway, my internet is a little more stable so it seemed > to download everything correctly. > > Now I seem to be

Re: [sage-devel] Re: Devel version

Yeah a few times I tried doing make after and there seemed to be *some* success sometimes. Anyway, my internet is a little more stable so it seemed to download everything correctly. Now I seem to be getting a sagemath_doc_html error (log attached). It looks like something to do with trying to impo

Re: [sage-devel] Re: Devel version

The matplotib vs meson-python issue is pure madness, see https://github.com/sagemath/sage/pull/39789 The problem is not that one cannot build matplotlib spkg. It does work on systems we tested, and the release manager agreed. That something does not match on PyPI is not an argument. We don't use

Re: [sage-devel] Re: Devel version

You can try to restart make after you hit ctrl-C. Sometimes it just works. > Also, I'm thinking I should create a ticket along the lines of "if unable to download xxx, then an error should be thrown instead of just hanging and waiting forever", it might help to trim the list of mirrors in upstrea

Re: [sage-devel] Re: Devel version

I have run into a similar issue with the matplotlib spkg. I don't think the issue is with the download. The log file shows a few 404's but eventually the download works and the hash is correct. I think the real issue is that the matplotlib package requires a version of meson-python which is

Re: [sage-devel] Re: Devel version

On Thu, Apr 24, 2025 at 1:26 AM Aram Dermenjian < aram.dermenjian.m...@gmail.com> wrote: > Yes, that's what I'm currently trying to do, but finding all the packages > with wrong checksums is turning out to not be so fun. Have to keep > rerunning `make` to try and see which package breaks next. > >

Re: [sage-devel] Re: Devel version

Yes, that's what I'm currently trying to do, but finding all the packages with wrong checksums is turning out to not be so fun. Have to keep rerunning `make` to try and see which package breaks next. 2 questions though: 1. Is there not currently a way to do a "check integrity" run or something? Wh

Re: [sage-devel] Re: Devel version

If I am not wrong this is caused because sometimes downloading files fail. In my experience a direct download of the files, copied in the folder upstream, and restarting make is enough. El miércoles, 23 de abril de 2025 a las 19:17:15 UTC+2, aram.derme...@gmail.com escribió: > This definitely

Re: [sage-devel] Re: Devel version

This definitely solves the sci-py problem! Thanks. I'm still getting hung up on the 2nd issue though where for some reason matplotlib just won't install. The terminal goes to something like: ``` [sagenb_export-3.3] [spkg-pipinst] Installing collected packages: sagenb_export [sagenb_export-3.3] [sp

Re: [sage-devel] Re:

On Tuesday, 15 April 2025 at 08:45:53 UTC-7 Nils Bruin wrote: Note that AA was bolted onto QQbar at a later stage. Root finding over AA is currently probably implemented by root finding over QQbar and then seeing which roots lie in AA. In principle it's possible to not do it that way but I dou

Re: [sage-devel] Re:

See the documentation on QQbar . While I'm sure there are related bugs, I agree with Nils that in this case it's working as intended. If you need a very small nonzero number, the system will compute with enough precisi

Re: [sage-devel] Re:

On Tuesday, 15 April 2025 at 03:48:25 UTC-7 Georgi Guninski wrote: Just trying to show that real roots can be easily computed, not relying on the bugs in roots over QQbar. I don't see way to control the precision in the spectrum. The trick with QQbar: there IS no precision to control. The sys

Re: [sage-devel] Re:

Just trying to show that real roots can be easily computed, not relying on the bugs in roots over QQbar. I don't see way to control the precision in the spectrum. Who decides that small algebraic number is real, is it user's responsibility, discarding visual non-zero? e-60 is zero is e-58 zero or j

Re: [sage-devel] Re:

On Monday, 14 April 2025 at 10:05:20 UTC-7 Georgi Guninski wrote: I continue to think this is at least one bug. There is an easy fix via change_ring(): sage: M=F.adjacency_matrix();f=M.characteristic_polynomial();f=f.change_ring(AA) : ;ro=f.roots();sum(e for _,e in ro) 90 I'm not

Re: [sage-devel] Re:

I continue to think this is at least one bug. There is an easy fix via change_ring(): sage: M=F.adjacency_matrix();f=M.characteristic_polynomial();f=f.change_ring(AA) : ;ro=f.roots();sum(e for _,e in ro) 90 -- You received this message because you are subscribed to the Google Groups "sage-

Re: [sage-devel] Re:

On Monday, 14 April 2025 at 09:16:49 UTC-7 dim...@gmail.com wrote: One would wish there was a way to tell the system from the beginning that this particular polynomial has only real roots. Perhaps there is an easy way to implement is (a class of real-rooted polynomials), no? Dima Well, the

Re: [sage-devel] Re:

On Mon, Apr 14, 2025 at 10:58 AM Nils Bruin wrote: > > It looks like a is an element of "Qbar". Elements there are tracked by > keeping track of a way to compute a polynomial it is a root of as well as a > complex "ball" that allows one to distinguish it from other roots of the > polynomial. Ce

Re: [sage-devel] Re: PROPOSAL: remove python3 spkg from Sage

If a user does not already have python3 installed on their system, this proposal would make installing python3 a prerequisite for installing Sage right? Is that something that we want to make users do? On Monday, March 31, 2025 at 9:29:27 AM UTC-5 dim...@gmail.com wrote: > On Mon, Mar 31, 2025 a

Re: [sage-devel] Re: PROPOSAL: remove python3 spkg from Sage

On 31 March 2025 14:36:30 GMT-05:00, Trevor Karn <> wrote: >If a user does not already have python3 installed on their system, this >proposal would make installing python3 a prerequisite for installing Sage >right? Is that something that we want to make users do? Well, Sage cannot be installe

Re: [sage-devel] Re: PROPOSAL: remove python3 spkg from Sage

On Mon, Mar 31, 2025 at 7:55 AM Emmanuel Charpentier wrote: > > Wouldn't that entail to have to maintain support for a wider selection of > Python versions ? Not bigger than at present. > > Le lundi 31 mars 2025 à 05:05:51 UTC+2, dim...@gmail.com a écrit : >> >> I propose to remove python3 (an

Re: [sage-devel] Re: WeylGroup question

Sorry for not responding earlier about this. I posted on the GH issue, but in short, you can use `W.domain().roots()` or passing it the explicit space that has the roots that you want to use, e.g., sage: W = WeylGroup(RootSystem(['G',2]).root_lattice()) sage: list(W) [ [1 0] [ 1 0] [-1 3] [

Re: [sage-devel] Re: WeylGroup question

I have opened issue #39656 for further discussion, and expect to post a comment there soon, but questions like this will probably get a better response from other forums. On Tuesday, March 4, 2025 at 5:42:38 PM UTC-7 dmo...@deductivepress.ca wrote

Re: [sage-devel] Re: WeylGroup question

Since this is related to development, you can open an issue at https://github.com/sagemath/sage/issues. If another question comes up that isn't being answered, you could ask here on sage-devel, but the answer and discussion would continue on the issue site. Anyway, I think an answer to your ori

Re: [sage-devel] Re: WeylGroup question

On Tue, Mar 4, 2025 at 11:48 AM dmo...@deductivepress.ca wrote: > > This is a question about how to use sagemath, not an issue about sagemath > development, so you should post it on a different forum, such as > ask.sagemath.org. The people there are very knowledgeable. Another option is sage-su

Re: [sage-devel] Re: WeylGroup question

Hi both, Sorry, perhaps I haven't as much detail as I should have. I am using this to develop the following package: https://github.com/Robbie-H/CompGIT/ on computing GIT quotients, which I hope it will be of use to the Sage community. I am not sure if that makes it simply an issue on how to use S

Re: [sage-devel] Re: On plotting frac(x^2+y^2) as complex and implicit plot

I concur that it is just a moiré pattern and issues from sampling. Once you get sufficiently far from the origin, the interval of r for frac(r^2) = (0,1) gets very small (in fact, very quickly). Contrast this with f(x,y) = frac(sqrt(x^2+y^2)) It comes down to the sampling being done to make the

Re: [sage-devel] Re: On plotting frac(x^2+y^2) as complex and implicit plot

Thanks for the plots. Are you sure that the example with implicit_plot and plot_points=800 doesn't have patterns? I suspect that precision issues (float?) together with small "pixel" size incorrectly kill the pattern. implicit_plot(lambda u, v:frac(u^2+v^2)-0.5, (13, 14), (13, 14), plot_points=800

Re: [sage-devel] Re: RFC: demote giac to optional

Don't worry, I won't try to convince sage maintainers that they should not downgrade giac, it seems we do have too incompatible views and probably not the same target audience (which may explain that some people here believe giac is about solving a few more integrals than maxima or sympy). Howev

Re: [sage-devel] Re: Any interest in making building from source on Mac more robust?

Is your branch on the PR branch of https://github.com/sagemath/sage/pull/39571 ? It should be for the current release. I'll take the incremental testing approach. As a first set of questions: - On the Install from Source Code p

Re: [sage-devel] Re: Any interest in making building from source on Mac more robust?

Thanks, Kwankyu,, I'll take the incremental testing approach. As a first set of questions: - On the Install from Source Code page, the "macOS package installation" paragraph advises the installation of a long list of binary

Re: [sage-devel] Re: Any interest in making building from source on Mac more robust?

https://github.com/sagemath/sage/pull/39571 is needed for successful build with the latest release. On Saturday, February 22, 2025 at 10:27:40 PM UTC+9 mwi...@gmail.com wrote: Thank you, Volker, for that proof of viability of building Sage on Apple silicon (an M2 Mini) and to Kwankyu on both a

Re: [sage-devel] Re: GSoC 2025 Ideas

Hi Dima, We can still add projects. We can add projects up until the student submission deadline. However, for us to be accepted as a mentor org, we need sufficiently many new project ideas. Can you add this to the wiki page? Best, Travis On Sunday, February 23, 2025 at 8:47:12 AM UTC+9 dim.

Re: [sage-devel] Re: GSoC 2025 Ideas

On Sat, Feb 22, 2025 at 09:29:35AM -0800, 'Martin R' via sage-devel wrote: > That would be awesome! Maybe it is not completely impossible to find a > suitable Lisp student, if we advertise it in the right places? well, we can add a project, still, not too late? explore and implement Python/Pyth

Re: [sage-devel] Re: GSoC 2025 Ideas

That would be awesome! Maybe it is not completely impossible to find a suitable Lisp student, if we advertise it in the right places? Martin On Thursday, 20 February 2025 at 02:56:52 UTC+1 dim...@gmail.com wrote: On 19 February 2025 09:25:12 GMT-06:00, 'Martin R' via sage-devel < sage-...@go

Re: [sage-devel] Re: Any interest in making building from source on Mac more robust?

Thank you, Volker, for that proof of viability of building Sage on Apple silicon (an M2 Mini) and to Kwankyu on both an M4 and Intel, all with macOS 15.3.1 (I assume). I would be happy to try again as suggested. But I expect I need to do some *cleaning of accumulated crud on my system* first to e

Re: [sage-devel] Re: RFC: demote giac to optional

On Fri, Feb 21, 2025 at 03:45:17PM +0100, Vincent Delecroix wrote: > I think it would be more productive to make two PRs: one for making > the package which is likely to create a consensus and one for demoting > to optional which might be controversial. The package is already done, it's in https:/

Re: [sage-devel] Re: RFC: demote giac to optional

On 2025-02-21 15:45:17, Vincent Delecroix wrote: > I think it would be more productive to make two PRs: one for making > the package which is likely to create a consensus and one for demoting > to optional which might be controversial. While generally a good idea, in this case it would create more

Re: [sage-devel] Re: RFC: demote giac to optional

Giac has always segfaulted on my M2 Mac Mini buildbot, so it never got *worse* when merging a ticket. As far as I know it only works on Intel macs (endangered species as they are). For the record, +1 to making giac optional. On Friday, February 21, 2025 at 3:57:53 AM UTC+1 Dima Pasechnik wrot

Re: [sage-devel] Re: RFC: demote giac to optional

I think it would be more productive to make two PRs: one for making the package which is likely to create a consensus and one for demoting to optional which might be controversial. One important argument against optional packages is that they are rarely available in linux system pacakges (on a sys

Re: [sage-devel] Re: RFC: demote giac to optional

On Thu, Feb 20, 2025 at 1:25 PM John H Palmieri wrote: > > For what it's worth, on my macos M2 machine, giac builds but it fails its > test suite: Given that macOS is a supported platform, one has to have jolly good reasons for keeping giac standard - while it fails self-tests. If Volker would b

Re: [sage-devel] Re: A PR making changes to CI needs your attention

#39467 eliminates "minimal" CI testing: test building sage from source on platforms with minimal required system packages installed. See the relevant section on our installation guide: https://doc-release--sagemath.netlify.app/html/en/installation/source#software-prerequisites-and-recommended-p

Re: [sage-devel] Re: A PR making changes to CI needs your attention

I am for #39467 - it finally makes our CI somewhat useful and more orientated to the needs of Sage users, instead of spending KWts of electricity and lots of CPU hours on testing configurations no humans use. On 20 February 2025 05:45:08 GMT-06:00, Kwankyu Lee wrote: >I object to the PR #39467

Re: [sage-devel] Re: GSoC 2025 Ideas

On 19 February 2025 09:25:12 GMT-06:00, 'Martin R' via sage-devel wrote: >I would like to remark that, as far as I know, the guessing facilities of >gfun have a reasonable replacement which is available in sage through >fricas. The last time I checked, this was more general and at least as

Re: [sage-devel] Re: GSoC 2025 Ideas

I couldn't find a way to register to this wiki, so could someone please update the page with the following info? Thanks! (Maybe for next time use https://github.com/sagemath/sage/wiki) Project: Lie group actions on manifolds Mentor: Tobias Diez, Erik? Area: Differential Geometry Skills: Knowl

Re: [sage-devel] Re: GSoC 2025 Ideas

Thanks Martin for the suggestion. I think it would be nice to improve the fricas interface as part of the project! (hint: you can help with mentoring). On Wed, 19 Feb 2025 at 16:25, 'Martin R' via sage-devel wrote: > > I would like to remark that, as far as I know, the guessing facilities of > g

Re: [sage-devel] Re: GSoC 2025 Ideas

I would like to remark that, as far as I know, the guessing facilities of gfun have a reasonable replacement which is available in sage through fricas. The last time I checked, this was more general and at least as fast than it's maple counterpart. The one thing that would dramatically improve

Re: [sage-devel] Re: GSoC 2025 Ideas

Additionally, I would like to propose that "SageMath subprojects" (such as ore_algebra, admcycles, sage-flatsurf, slabbe, ...) could make GSOC proposal under the SageMath umbrella. I believe it is easier for a newcomer to be able to contribute to a smaller standalone project. What do you thin

Re: [sage-devel] Re: GSoC 2025 Ideas

Hi Vincent^2, Thank you for the ideas and adding them to the ideas page. Best, Travis On Wednesday, February 19, 2025 at 12:18:29 AM UTC+9 Vincent Neiger wrote: > Hello, > > I just added to the wiki the two projects suggested above. Could you > please have a look to make sure I did not intro

Re: [sage-devel] Re: GSoC 2025 Ideas

Hello, I just added to the wiki the two projects suggested above. Could you please have a look to make sure I did not introduce any typo and such? In particular for the second project, as I created some title and I changed "genfun" into "gfun" which seems to be the usual name for the Maple libr

Re: [sage-devel] Re: GSoC 2025 Ideas

Additionally, I would like to propose that "SageMath subprojects" (such as ore_algebra, admcycles, sage-flatsurf, slabbe, ...) could make GSOC proposal under the SageMath umbrella. I believe it is easier for a newcomer to be able to contribute to a smaller standalone project. What do you think? On

Re: [sage-devel] Re: GSoC 2025 Ideas

I lost my wiki password but I am willing to propose to mentor on the following topics. I would welcome in anyone assisting me in the mentoring. 1) Zariski closures of finitely generated matrix groups Mentor: Vincent Delecroix + (?) Area: Algebra Skills: Group theory, Lie algebras, Number fields,

Re: [sage-devel] Re: Is automatic documentation from doctests a thing?

To add a generic Python explainer: generation of documentation from docstrings and function/class signatures is normally done by a Python package sphinx, and Sage is not much of an exception to it (although it's accumulated a lot of outdated "improvements" to it, which we ought to streamline as

Re: [sage-devel] Re: Possibly insecure verification of sage source downloaded from a mirror

On 2025-02-12 10:22:14, Nils Bruin wrote: > In my opinion, this problem is commonly solved nowadays by curated software > distributions (through stores, trusted package repositories, etc.) with > keys that are predistributed with the operating system used. The integrity > control is then offload

Re: [sage-devel] Re: Feature request: Flatpak

On Sun, Feb 9, 2025 at 11:30 AM Jerry Caligiure wrote: > > Hello! I'd really like to get this working on flatpak. I'm trying to sandbox > off applications from the system in Linux, and flatpak is an easy way to do > that. > I'm thinking we could use electron (https://www.electronjs.org/) to crea

Re: [sage-devel] Re: GSoC 2025 Ideas

Thanks Travis for setting that up again! On Thu, 6 Feb 2025 at 11:04, 'Martin R' via sage-devel wrote: > > I'd be happy to co-mentor the diagram algebra project (where I know a little > bit of the mathematics), and also the free module project. > > Martin > On Thursday, 6 February 2025 at 00:38:

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

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

On macOS, with both arm64: and x86_64 * 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 and 10.6. * crypting.so loads libgap in SageMath

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

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 GAP. The relevant option is: > -bundle_loader /private/var/tmp/sage-10.6-current/local/bin/gap > I think that option is broken in the late

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

On Wed, Jan 29, 2025 at 3:16 PM Antonio Rojas wrote: > > See > https://web.archive.org/web/20201218114127/https://trac.sagemath.org/ticket/27372 > for some previous discussion about this This discussion in #27372 (more up to date copy: https://github.com/sagemath/sage/issues/27372) is misleadin

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

See https://web.archive.org/web/20201218114127/https://trac.sagemath.org/ticket/27372 for some previous discussion about this El miércoles, 29 de enero de 2025 a las 21:43:36 UTC+1, marc@gmail.com escribió: > On Wed, Jan 29, 2025 at 1:33 PM Dima Pasechnik wrote: > >> >> libgap is not re

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

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

On Wed, Jan 29, 2025 at 11:52 AM Marc Culler wrote: > > I don't have time for that right now. But I will provide a patch for the > 1-line fix that I used: > > diff --git a/build/pkgs/gap_packages/spkg-install.in > b/build/pkgs/gap_packages/spkg-install.in > index 7005cc3d322..157e093d86b 100644

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

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-install.in. yes, I can reproduce this with the latest beta5, on Apple clang version 16.0.0 (clang-1600.0.26.4), on an arm6

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

I don't have time for that right now. But I will provide a patch for the 1-line fix that I used: diff --git a/build/pkgs/gap_packages/spkg-install.in b/build/pkgs/gap_packages/spkg-install.in index 7005cc3d322..157e093d86b 100644 --- a/build/pkgs/gap_packages/spkg-install.in +++ b/build/pkgs/gap_

Re: [sage-devel] Re: How to find the exact version of giac used in sagemath 10.5 binary?

Instead of "readelf", use "ldd -r" - it will show you the path to the libgiac used which - given there was no such file in your list - should turn out to be the system one. On 6/01/25 04:23, 'Nasser M. Abbasi' via sage-devel wrote: And here is the content of   sagemath giac lib that is listed i

Re: [sage-devel] Re: How to find the exact version of giac used in sagemath 10.5 binary?

"If you are using arch sagemath, then you are not using sage-the-distro and so you are using arch giac as well." This is good to know. I am new to using arch and was not sure. I am actually using EOS distro which is arch based, not arch itself. I just found the info I wanted is online: https:/

Re: [sage-devel] Re: How to find the exact version of giac used in sagemath 10.5 binary?

January 5, 2025 12:07 PM, "Nasser M. Abbasi' via sage-devel" wrote: > This link shows the Arch sagemath package info that I installed > > https://archlinux.org/packages/extra/x86_64/sagemath/ If you are using arch sagemath, then you are not using sage-the-distro and so you are using arch giac

Re: [sage-devel] Re: How to find the exact version of giac used in sagemath 10.5 binary?

And here is the content of sagemath giac lib that is listed in the sagemath package files >ls -l /usr/lib/python3.13/site-packages/sage/libs/giac/ total 3572 -rw-r--r-- 1 root root 676302 Dec 22 06:23 auto-methods.pxi -rwxr-xr-x 1 root root 2840360 Dec 22 06:23 giac.cpython-313-x86_64-linu

Re: [sage-devel] Re: How to find the exact version of giac used in sagemath 10.5 binary?

This link shows the Arch sagemath package info that I installed https://archlinux.org/packages/extra/x86_64/sagemath/ There is link at bottom of this page to show list of all files also (click on package content) I see number of files with giac in them. Here is the list from my linux using the

Re: [sage-devel] Re: How to find the exact version of giac used in sagemath 10.5 binary?

You can use one of the changes in behaviour that are in sagemath history (in the form of doctests that we have to change as we upgrade giac). For instance: --- With giac 1.9.0-998: sage: libgiac.solve('sin(3*x)>2*sin(x)', libgiac('x')) Inequation on periodic expression without assumptions on v

Re: [sage-devel] Re: meson build doesn't find cysignals?

This is really strange. It actually reports that cysignals is found: Running command: /home/grhkm/miniforge3/envs/sage-dev-2/bin/python3.11 -c 'import cysignals print(cysignals.__file__.replace('"'"'__init__.py'"'"', '"'"''"'"'))' --- stdout --- /home/grhkm/miniforge3/envs/sage-dev-2/lib/pyth

Re: [sage-devel] Re: How to find the exact version of giac used in sagemath 10.5 binary?

It is very likely that sagemath installed by pacman from AUR uses the system giac. But you can check the list of files installed by pacman for sagemath. pacman -Ql $package_name if it includes a private copy of giac, it should appear in the list. François On 5/01/25 18:48, 'Nasser M. Abbasi' v

Re: [sage-devel] Re: meson build doesn't find cysignals?

Content of /home/grhkm/git/sage/build/cp311/meson-logs/meson-log.txt: https://gist.github.com/grhkm21/21dea0c9b2f3b712f91f926757863045 (The conda environment is now called `sage-dev-2`) Yes, importing `cysignals.signals` works in the conda python. I guess because it's installed in `$CONDA_PREFIX

Re: [sage-devel] Re: cached methods in symmetric_group_representations

Thanks for the tips. Some changes have been made and now (almost) all tests are passing. On Wed, Dec 11, 2024 at 7:37 PM Nils Bruin wrote: > Read on for the other failures. If you look up line 1953, you'll see it's > inside a try/except. You're triggering the KeyError, so it's the outer one > fo

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

Replying here in case readers of this thread are interested -- a **not really finished** PR has now been made to Sage with a lot of the changes we describe above. I kind of want people to look at it and give rough opinions to move the project forward to the point where we can merge it and start

Re: [sage-devel] Re: Example of an UFD in Sage for which is_unit is significantly slower than is_one

On Fri, Dec 13, 2024 at 3:04 PM 'Martin R' via sage-devel wrote: > > Well, only if the ring of integers is just a subset of K. > > Essentially, that means that we cannot really compute with O - eg., compute > the gcd of two polynomials over O. polynomials over rings are tricky. sage: P.=O[] sage

Re: [sage-devel] Re: Example of an UFD in Sage for which is_unit is significantly slower than is_one

Well, only if the ring of integers is just a subset of K. Essentially, that means that we cannot really compute with O - eg., compute the gcd of two polynomials over O. Martin On Friday, 13 December 2024 at 21:07:50 UTC+1 dim...@gmail.com wrote: > On Fri, Dec 13, 2024 at 1:38 PM 'Martin R' via

Re: [sage-devel] Re: Example of an UFD in Sage for which is_unit is significantly slower than is_one

On Fri, Dec 13, 2024 at 2:38 PM 'Martin R' via sage-devel < sage-devel@googlegroups.com> wrote: > This does not look right, does it? > > sage: K. = NumberField(x^2-3) > sage: O = K.ring_of_integers() > sage: c = O(2*a + 4) > sage: isinstance(O, Field) > False > sage: isinstance(c, FieldElement) >

Re: [sage-devel] Re: Example of an UFD in Sage for which is_unit is significantly slower than is_one

On Fri, Dec 13, 2024 at 1:38 PM 'Martin R' via sage-devel wrote: > > This does not look right, does it? > > sage: K. = NumberField(x^2-3) > sage: O = K.ring_of_integers() > sage: c = O(2*a + 4) > sage: isinstance(O, Field) > False > sage: isinstance(c, FieldElement) > True c is an element of K, b

Re: [sage-devel] Re: Time to show off your contributions in Sage 10.5 Release Tour

On Fri, Dec 13, 2024 at 3:54 AM Eric Gourgoulhon wrote: > > It seems that there is no longer any link towards the Release Tour from the > front page > https://www.sagemath.org/ > Is this intended? No, it's a bug. See https://github.com/sagemath/website/issues/484 for the missing link > > Eric. >

Re: [sage-devel] Re: using libgap in source

> > You could hold a vote to make "forms" a standard package and then > require it, but your new code would have to be pretty awesome for > that to be worth it. > > Instead, I would suggest leaving it optional and marking the tests > with "# optional - gap_package_forms". People using the system

Re: [sage-devel] Re: using libgap in source

On 2024-12-05 20:31:40, Jackson Walters wrote: > > It would be nice to just have these installed. This isn't something I can > do, right? I should mention that locally this is all working in my > installation, where I have installed `forms`. > You could hold a vote to make "forms" a standard pac

Re: [sage-devel] Re: using libgap in source

Right, confirmed separately from Travis: So the Forms package is a GAP package that has been included since GAP > v4.9, but it is not included by our default installation nor in > gap_packages We are debating whether to just implement the necessary methods in Sage. I'm going to begin tomorrow.

Re: [sage-devel] Re: using libgap in source

On 2024-12-05 15:23:35, Jackson Walters wrote: > > Ah, thank you. Any idea if loading packages via libgap.LoadPackage("forms") > is > expected to work? Yes, but only if the GAP package you're trying to load is installed. The only ones that are guaranteed to be installed are gapdoc, primgrp, sma

Re: [sage-devel] Re: using libgap in source

On 5 December 2024 17:23:35 GMT-06:00, Jackson Walters wrote: > >Ah, thank you. Any idea if loading packages via libgap.LoadPackage("forms") is >expected to work? absolutely. As I said elsewhere, look at how things involving libgap are done in e.g. src/sage/graphs/. > >Jackson >On Thursday, De

  1   2   3   4   5   6   7   8   9   10   >