Update to GAP 4.15.0

[lgoettgens]

The steps to actually do the update once the GAP release is there is the following:

1. Build GAP_jll using [GAP] Update to 4.15.0 JuliaPackaging/Yggdrasil#11987
2. Build GAP_lib_jll using [GAP_lib] Update to 4.15.0 JuliaPackaging/Yggdrasil#11988
3. Merge the changes to common.jl and update.jl from [Gap_pkg_*] Update to gap 4.15.0 and new versioning scheme JuliaPackaging/Yggdrasil#12032 with [skip build] [skip ci].
4. Split all changes to packages (except juliainterface) off of [Gap_pkg_*] Update to gap 4.15.0 and new versioning scheme JuliaPackaging/Yggdrasil#12032 into several small PRs and merge them.
5. Build GAP_pkg_juliainterface_jll. (Two options: 1. Merge Prepare juliainterface for GAP 4.15 #1239 and update [Gap_pkg_*] Update to gap 4.15.0 and new versioning scheme JuliaPackaging/Yggdrasil#12032 to use the new merge commit. 2. Build using a branch commit from Prepare juliainterface for GAP 4.15 #1239. Option 1 leaves the master branch temporarily broken, while option 2 builds from a temporary branch. I am not sure which of the two is preferable.)
6. Merge this PR.

[lgoettgens]

In the following, I list all errors that occurred while running the GAP.jl and Oscar.jl tests with locally built binaries (all deployed at https://github.com/lgoettgens/NameOfTheJll.jl), with julia 1.11.6 on munk:

1. compilation on macos: On macos, the on-the-fly compilation of juliainterface fails. See Prepare juliainterface for GAP 4.15 #1239 (comment) for the error log (resolved with 00b09a2)
2. is_finite known too early: https://github.com/oscar-system/Oscar.jl/blob/b99b05560554386d1104fb6372859d609b741696/test/Groups/quotients.jl#L178 fails. But if I understand correctly, the actual thing that is tested there is that after calling quo the has_is_finite is set. So this is just a case where gap learns too many things about an object too early, and the testcase there needs to be adapted to something gap does not know things about.
3. logging output???: Some output of the form julia(36724) MallocStackLogging: can't turn off malloc stack logging because it was not enabled. (with increasing numbers in the beginning) in various doctests. One example with several of these outputs is https://github.com/oscar-system/Oscar.jl/blob/0a759cdefa61d38c9c1b17f8e1edf990043e5362/src/AlgebraicGeometry/ToricVarieties/ToricMorphisms/attributes.jl#L180. This didn't happen in the first half of doctests, but in the second half occurred in almost every one. Googling a bit, this seems to be some macos thing and should be unrelated of the gap update (I just never ran so many things at the same time on munk, so this could be some oom printing?)
4. primgrp 4.0.0: https://github.com/oscar-system/Oscar.jl/blob/f6cf559f1d1a757060ff03b71355e1c567ba8c07/src/Groups/libraries/primitivegroups.jl#L33 fails. I found Integrate the primitive groups of degree 4096 to 8191 into PrimGrp gap-packages/primgrp#52 which added support for primitive groups up to order 8191, but only using zenodo (and so is a similar case as Transitive groups as lazy artifact?  Oscar.jl#2850). We should decide if we want to answer has_primitive_groups(n) with true if we don't actually have it but it needs to be downloaded from zenodo. Related failure in https://github.com/oscar-system/Oscar.jl/blob/f6cf559f1d1a757060ff03b71355e1c567ba8c07/src/Groups/libraries/primitivegroups.jl#L138, and a few more that test errors when supplying to large orders.
5. Changed order in character tables: https://github.com/oscar-system/Oscar.jl/blob/cc27a3dd3604b667c16389a47ebbf30d2ea931cd/src/Groups/group_characters.jl#L2868 fails (it now returns [1,2,4,3]). Many failures in https://github.com/oscar-system/Oscar.jl/blob/cc27a3dd3604b667c16389a47ebbf30d2ea931cd/test/Groups/group_characters.jl#L7-L741, but I think all are just a permutation of rows/cols.
6. GITFans: https://github.com/oscar-system/Oscar.jl/blob/bf99b15a39d67c4495386e164abae900d7675caa/test/book/specialized/boehm-breuer-git-fans/explG25_5.jlcon#L10 has changed output:

  julia> rays(c)
  5-element SubObjectIterator{RayVector{QQFieldElem}}:
+  [0, 1, -1, 0, 0]
+  [0, 1, 0, -1, 0]
   [0, 1, 0, 0, -1]
-  [1, 0, 1, 1, 0]
   [1, 1, 0, 0, 0]
-  [1, 1, 0, 1, 0]
-  [1, 1, 1, 0, 0]
+  [1, 2, 0, 0, 0]

7. Character table of M: https://github.com/oscar-system/Oscar.jl/blob/cc27a3dd3604b667c16389a47ebbf30d2ea931cd/src/Groups/group_characters.jl#L1084 now returns false

This list is now complete (ping @ThomasBreuer @fingolfin)

[ThomasBreuer]

@lgoettgens Thanks.
I will adjust the tests from 2. and 5.-7. above.

[lgoettgens]

@lgoettgens Thanks. I will adjust the tests from 2. and 5. above.

The list is still growing while my tests run. The main point here is that we (I'll also ping max once the list is final) can decide which of the failures just need a test adaption later in Oscar, and which ones need to be addressed in GAP (before the release at best).

[ThomasBreuer]

Concerning the changed ordering of character tables, we had the same problem in GAP tests. The best solution is to change the tests such that they do not depend on a particular ordering, hence these changes are actually independent of switching to the new GAP version; the new tests will look less suggestive (and more ugly).

[lgoettgens]

The primgrp stuff should be fixed once gap-packages/primgrp#59 is resolved.

[ThomasBreuer]

Concerning 6. (the changed output in the test/book/specialized/boehm-breuer-git-fans/explG25_5.jlcon example),
I cannot reproduce this locally.

(I am running Julia 1.10.9 with the master branch of GAP (4.16dev). For that, I have used the instructions from GAP.jl/etc/README.md, section "Using GAP.jl with a different version of GAP than what GAP_jll provides". In a fresh Oscar session, the examples from the book chapter are entered, and I do not get the different rays(c) output shown above.)

[lgoettgens]

Concerning 6. (the changed output in the test/book/specialized/boehm-breuer-git-fans/explG25_5.jlcon example), I cannot reproduce this locally.

(I am running Julia 1.10.9 with the master branch of GAP (4.16dev). For that, I have used the instructions from GAP.jl/etc/README.md, section "Using GAP.jl with a different version of GAP than what GAP_jll provides". In a fresh Oscar session, the examples from the book chapter are entered, and I do not get the different rays(c) output shown above.)

I am currently in the process of upgrading all of my local jlls to the beta2. Once that is done, I will try to see if I am still able to reproduce it.

[lgoettgens]

I am happy to announce that the GITFans thing (point 6 of the above list), does no longer happen with a clean gap 4.15.0-beta2 rebuild. I have no idea why it showed up in the first place, I would assume that I somehow used some incompatible jlls.

[lgoettgens]

It looks like there is an issue with the cryst sources. I'll investigate later if this is a problem of the artifact setup or their server

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.71%. Comparing base (907ae36) to head (af6b47c).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1244   +/-   ##
=======================================
  Coverage   76.71%   76.71%           
=======================================
  Files          61       61           
  Lines        4887     4887           
=======================================
  Hits         3749     3749           
  Misses       1138     1138           

Files with missing lines	Coverage Δ
src/setup.jl	99.15% <100.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lgoettgens]

CI seems to be happy now. I added one exception for one of the two new distro packages to the distro CI. Its tests pass but the CI job still fails. My current guess is that this packages uses yet another way to exit gap after running its tests that we currently don't accommodate for. I'll look into enabling that job again once I am back in office next week

[ThomasBreuer]

Thanks.

[ThomasBreuer]

CI seems to be happy now. I added one exception for one of the two new distro packages to the distro CI. Its tests pass but the CI job still fails. My current guess is that this packages uses yet another way to exit gap after running its tests that we currently don't accommodate for. I'll look into enabling that job again once I am back in office next week

Most packages call FORCE_QUIT_GAP(1) in the end of their testall.g files.
In smallclassnr/tst/testall.g, we have FORCE_QUIT_GAP( pass ) where pass is true or false.
According to the documentation, both integers and booleans are allowed as argument of FORCE_QUIT_GAP.
(And one should use the documented ForceQuitGap instead of FORCE_QUIT_GAP.)

Does the boolean return value cause problems for the CI job?
Then also the tests of the package twistedconjugacy should show the same problem.