-
-
Notifications
You must be signed in to change notification settings - Fork 528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
spkg-configure.m4 for gap #29644
Comments
Attachment: spkg-configure.m4.gz spkg-configure.m4 to be copied under build/pkgs/gap/ |
comment:1
system package information also needs to be added |
Changed author from gh-thierry-FreeBSD to Thierry Thomas |
comment:3
Which systems have a usable gap? |
comment:4
I'm using it in the distro sage package with no issues, with the patch from #29314. The only potential problem I'm aware of is that our gap-packages contains all packages shipped in the upstream tarball - this can cause high memory usage if it's installed. |
comment:5
Replying to @antonio-rojas:
I don't think having all the GAP packages used causes any memory problems - the majority are not loaded by GAP by default (and even if they are, their memory footprint is very small). |
This comment has been minimized.
This comment has been minimized.
comment:7
Thierry, can you push a branch here? The file
with name and email found from your previous contributions using:
|
Changed author from Thierry Thomas to Thierry Thomas, Samuel Lelièvre |
Commit: |
Branch: public/29644 |
comment:10
Replying to @dimpase:
They are not loaded by GAP, but they are by Sage and it does cause problems - see #31761 |
comment:13
We could get the gap root from
The code in Maybe: a.
I'm not completely sure how to do (a) and (b) but it's probably easy for someone who understands autoconf. Note that when not using system gap, |
comment:14
Replying to @tornaria:
Doesn't work for me on Debian 11:
|
comment:15
In case, here is my GAP_ROOT_PATHS:
|
comment:16
What are Here I get:
Using Which one is the "real" gap root? I think it should be either the one containing Alternatively, use the whole list of To get the complete list for
For me it gives the same since I only have one path in the system gap root, but for you it should give all of them. |
comment:17
Something like that seems to work as a fallback in case
The drawback is that this will launch and keep running the gap interpreter. Maybe better to do a one-time run of gap just for this purpose (or run it at configure time as I proposed above). |
comment:18
Maybe this is better:
Also, Simple fix:
OTOH, there's Finally, there's a test in
I also changed
|
comment:19
How about asking GAP people (or doing a PR) to provide an appropriate feature? Which one does really matter? The one with Did you look at how this is done in https://github.com/embray/gappy ? |
comment:20
Replying to @dimpase:
TL;DR: if the shared library for gap is in This seems ok to me, in principle the path to the gap library is in |
comment:21
For |
comment:23
Notes about
Maybe the |
Has anything improved in the past year and a half? @tobiasdiez is working on a meson build for sagelib that uses only gap = cc.find_library('gap') to find GAP. If it's that easy now, we could finally write the |
Resurrect sagemath#29644 and add an `spkg-configure.m4` for GAP. Some other changes were made to make this possible / nicer: 1. `GAP_LIB_DIR` and `GAP_SHARE_DIR` are merged into `GAP_ROOT_PATHS`. This was suggested by @tornaria and is the right approach, especially now that `GAP_SO` has been removed. Nothing else needs those two directories and GAP itself doesn't care about them -- it only cares about the package search path, i.e. `GAP_ROOT_PATHS`. So changing the variable(s) brings us in line with the way GAP works. 2. We no longer pass the `-r` flag to GAP. Particularly when using the system GAP, we do want the user to be able to install his own packages and run his own initialization. 3. We begin to pass `-A` to GAP. This tells GAP not to autoload the big set of "recommended" packages at start-up, which avoids the inevitable error messages when those packages are not installed on the system GAP. We could check for all of them in `spkg-configure.m4`, but it's a long list, and loading them slows down GAP initialization for no benefit -- Sage itself uses only one such package. Users can autoload them via gaprc or gap.ini in light of (2). 4. After adding `-A` to the initialization, we try to load the PolyCyclic package if it's installed. This is the one "recommended" package that Sage itself uses. 5. The "recommended" packages are all moved from the gap SPKG to gap_packages because we no longer need them, except (maybe) for PolyCyclic. Should keep polycyclic installed by default? The tests all pass without it, but it is used a few places in sagelib. 6. Various stale doctest fixes. 7. The expected output from a few tests has changed. Where possible, I've made the test more robust. In one case I had to drop the printing of a matrix, because if you dig into the source code for GAP's `NormalSubgroups()`, it chooses a `Representative()` inconsistently, and that eventually affects the entries of the matrix. All tests are passing afterwards... except one, a heisenbug: ``` sage -t --warn-long 187.7 --random- seed=96688270013898650573232209016248663009 src/sage/groups/matrix_gps/finitely_generated_gap.py ********************************************************************** File "src/sage/groups/matrix_gps/finitely_generated_gap.py", line 123, in sage.groups.matrix_gps.finitely_generated_gap.FinitelyGeneratedMatrix Group_gap.as_permutation_group Failed example: P == Psmaller Expected: False Got: True ********************************************************************** ``` If anyone knows what's going on there, I'd be grateful. The GAP docs for `SmallerDegreePermutationRepresentation()` say, > The methods used might involve the use of random elements and the permutation representation (or even the degree of the representation) is not guaranteed to be the same for different calls of SmallerDegreePermutationRepresentation. So maybe this isn't really a bug, but I would find it strange if that randomness could mean that sometimes the smaller degree option just wouldn't work at all. Anyway, have at it, and let me know what you think. URL: sagemath#36792 Reported by: Michael Orlitzky Reviewer(s): Dima Pasechnik, François Bissey, Gonzalo Tornaría, Matthias Köppe, Michael Orlitzky, Tobias Diez
Fixed in #36792 |
This ticket adds an spkg-configure.m4 for gap, in order to use it from a system package if possible (see #27330).
With this, the installed gap is well detected, but for sagelib and gap packages to built, several paths must be modified:
GAP_ROOT_DIR in src/sage/env.py
GAP_ROOT in build/pkgs/gap_packages/spkg-install.in
gap directory in src/sage/libs/gap/util.pyx
Moreover, the dependency on SAGE_LOCAL needs to be removed. Without it, one currently gets the following error
CC: @dimpase @orlitzky @slel @isuruf @antonio-rojas
Component: build: configure
Keywords: gap, system packages
Author: Thierry Thomas, Samuel Lelièvre
Branch/Commit: public/29644 @
2a41f49
Issue created by migration from https://trac.sagemath.org/ticket/29644
The text was updated successfully, but these errors were encountered: