GAP 4.13.0-alpha1

[fingolfin]

Dear all,

I plan to release GAP 4.13.0 in February (current aim: ~2 weeks) assuming all goes well. Based on the experience in the 4.11.x and 4.12.x release cycles, I've decided to make a prerelease available again.

Version 4.13.0-alpha1 is mostly intended for use by people who package GAP for Linux distributions, or similar things (Homebrew, FreeBSD ports, Conda, SageMath, ...). The idea is to iron out issues related to packaging before the final release.

That said, everyone else is of course also welcome to give it a try. I don't expect major changes in the final release, though we'll still merge PRs and package updates if they don't appear "risky".

You can find this pre-release at https://github.com/gap-system/gap/releases/tag/v4.13.0-alpha1

If you want all GAP sources and all packages, you need gap-4.13.0-alpha1.tar.gz.

Here is a list of known issues (and solutions) for this prerelease

• buildsys: let 'make clean' remove libgap.9.{dylib,so} #5626
• buildsys: don't set -rpath when doing 'make install' #5628

Some people who I know package GAP and might be interested in this include @antonio-rojas @isuruf @saraedum @jamesjer @orlitzky @collares @AndreasEnge @yurivict

[orlitzky]

and @kiwifb

[orlitzky]

You mean for GAP itself? All we are doing there is make install. Can you give me an example of what's missing / not working?

[dimpase]

many GAP packages use legacy documentation system, which needs convert.pl, tex macros, etc.

e.g. if you install the sources of such a package foo in ~/.gap/pkg/, and want to rebuild its docs, you can't do it with GAP installed by "make install"

[orlitzky]

convert.pl is installed as /usr/share/gap/etc/convert.pl but I'm not sure how a package in ~/.gap would be supposed to know that. Do you have an example? How does it work when it does work? If these packages are expecting you to be doing development from within the GAP install, it may simply not be possible (without extra steps) when using the system GAP.

[fingolfin]

Here is how I deal with building the manuals of git versions of these packages (which do not live in the pkg dir of my git clone of the gap.git repository); I'll describe a simplified version of my setup:

Create a directory gap-packages, in there create a subdirectory pkg, and in there put all your GAP package clones. Then add symlinks into gap-packages to the doc and etc directory of GAP (where convert.pl, gapmacro.tex etc. live). Afterwards you can build the manuals just fine.

I guess someone who wanted to could submit patches to packages to allow e.g. the make_doc script to optional take the path to the GAP root dir as argument, and then use that instead of ../../...

However, that does not immediately help with the tex files doing \input ../../../doc/gapmacro, or with \UseReferences{../../../doc/ref}. Of course there are ways to deal with this (simplified: patch the file to use the proper path. of course we all know it's a bit more complicated but let's not dwell on these details, they are trivial). However, the resulting pdf and html files will now reference to that alternative absolute or relative path to the gap root. Which is fine and even desirable for local consumption, but not for package releases. Those should always use the default relative path to GAP.

So this is not useful for package developers anyway, and hence I never went down this road. The symlink trick was always enough for me personally.

[dimpase]

The alternative to this is to install TeX macros properly, and make sure that scripts like convert.pl are installed into places where PATH points at. This would mean that packages can get rid of these relative paths. I can volunteer to look into this.

[yurivict]

I tested 4.13.0-alpha1 in the FreeBSD ports framework, and it builds fine.

Thank you.

[antonio-rojas]

Hi,
The xgap package fails to build:

make[1]: Leaving directory '/build/gap/src/gap/pkg/xgap/bin/x86_64-pc-linux-gnu-gcc'
cp xgap.sh bin/xgap.sh
cp: cannot stat 'xgap.sh': No such file or directory
make: *** [Makefile:48: compile] Error 1

The failure is introduced in commit 3c3da2b, where xgap starts using the run_configure_and_make function instead of the previous manual configure and make steps. I think the commit is OK, but it uncovers a bug in run_configure_and_make: in https://github.com/gap-system/gap/blob/v4.13.0-alpha1/bin/BuildPackages.sh#L205 make clean is run after configure, which deletes all configuration files created by configure. This issue is fixed in https://github.com/gap-system/gap/blob/v4.13.0-alpha1/bin/BuildPackages.sh#L214 by running configure again, the same needs to be done in the other code path.

[fingolfin]

Thanks for the report.

I don't quite agree with the analysis that this is an issue in BuildPackages.sh, but rather I consider this to be a bug in the xgap build system -- make clean there removes too much. I actually thought I had fixed all of this in 4.31, but clearly I overlooked a case.

Anyway I made gap-packages/xgap#30 now. There are actually bunch of other unreleased tweaks in the xgap repo, so there'll be xgap 4.32 soonish.

[fingolfin]

xgap 4.32 has been released and should fix this.

[jamesjer]

The new version lets me simplify the RPM spec file somewhat. That's great! I will note that there used to be an icon, cnf/cygwin/gapicon.bmp. We actually use that (converted to PNG images of various sizes) to show an icon for those desktops that know how to read a desktop file (e.g., in Gnome Software). I have poked around in the 4.13.0-alpha1 tarball and haven't found an icon file yet. Is it there somewhere and I am just overlooking it? If not, can you bring back gapicon.bmp?

I have not tried building packages yet, but will do so over the next day or two.

[fingolfin]

The icon is gone, it never was an official GAP icon to start with.

[dimpase]

I'd also like gap-packages/ace#36 making it to the release, and if possible #5630 fixed.

[orlitzky]

Mostly smooth so far:

1. When run inside our package manager, the GAP test suite is now hanging and clobbering the terminal if Browse is installed. This is almost guaranteed to be the same issue for which we have a workaround already in the package test suites, and for the hang in the SageMath test suite. I can hide it by piping the test suite through tee.
2. When GAP has memory-checking enabled, the digraphs test suite crashes:

testing: /var/lib/portage/tmp/portage/dev-gap/digraphs-1.6.3-r1/temp/pkg/digra\
phs-1.6.3/tst/standard/attr.tst
########> Diff in /var/lib/portage/tmp/portage/dev-gap/digraphs-1.6.3-r1/\
temp/pkg/digraphs-1.6.3/tst/standard/attr.tst:1897
# Input is:
Number(D, d -> StrongOrientation(d) <> fail);
# Expected output:
11
# But found:
0
########
########> Diff in /var/lib/portage/tmp/portage/dev-gap/digraphs-1.6.3-r1/\
temp/pkg/digraphs-1.6.3/tst/standard/attr.tst:1899
# Input is:
Number(D, IsBridgelessDigraph);
# Expected output:
11
# But found:
0
########
/var/lib/portage/tmp/portage/dev-gap/digraphs-1.6.3-r1/temp/environment: line 1518:    25 Segmentation fault      ${gapcmd}

This is a regression from 4.12.2, but is probably due to gap-packages/io#124 and not actually a digraphs issue.

[fingolfin]

@orlitzky why do you think this is the same bug as in io and not another bug specific to digraphs?

@ChrisJefferson maybe you are interested in some "fun" memory issue debugging? ;-)

[orlitzky]

Only because digraphs loads io before it segfaults.

[dimpase]

I tried the build and teststandard on OpenBSD 7.4 amd64, with system-wide GMP, all good, all teststandard pass.

[orlitzky]

One more tiny detail: if possible, could you create the ./configure script with autoconf-2.72? That will future-proof it with newer compilers.

[fingolfin]

We use whatever autoconf is installed on the GitHub VMs.

Do you have any concrete change in autoconf 2.72 in mind that you think could be relevant? Otherwise I wouldn't want to invest energy into this (esp. since a recent autoconf update in my experience is just as likely to break things that worked for years as it is to fix something.... YMMV)

[orlitzky]

Yes, from https://lists.gnu.org/archive/html/autotools-announce/2023-12/msg00003.html:

This change was necessary in order to support the upcoming 2024
edition of the C standard (often referred to as "C23"), which will
officially remove the function declaration syntax used by
AC_CHECK_FUNC in Autoconf 2.71 and earlier. We feel that support
for compilers that support only C 2024 is more useful, nowadays,
than support for compilers that don't implement a core feature of
C 1989.

It's a "nice to have" but we can always regenerate it on-the-fly in Gentoo if it will be a headache for you.

[fingolfin]

Let me put it this way: if someone provides code for installing that newer autoconf in the GitHub Ubuntu VMs (or even provides a PR to do that), we can use it :-)

[jamesjer]

That's too bad about the icon. If there ever is an official one, let me know.

I'm running through my gap bootstrap procedure today, and got this error while running the transgrp test suite:

testing: /builddir/build/BUILDROOT/gap-pkg-transgrp-3.6.5-5.fc40.x86_64/usr/sh\
are/gap/pkg/transgrp/tst/trans.tst
########> Diff in /builddir/build/BUILDROOT/gap-pkg-transgrp-3.6.5-5.fc40\
.x86_64/usr/share/gap/pkg/transgrp/tst/trans.tst:48
# Input is:
for n in [2..15] do
  for i in [1..NrTransitiveGroups(n)] do
     s := Random(SymmetricGroup(n));
     if TransitiveIdentification(TransitiveGroup(n,i)^s) <> i then
       Print("TransitiveIdentification error for TransitiveGroup(",
             n,",",i,") and s=", s, "\n");
     fi;
  od;
od;
# Expected output:
# But found:
Error, the Small Groups identification is required but not installed
########
########> Diff in /builddir/build/BUILDROOT/gap-pkg-transgrp-3.6.5-5.fc40\
.x86_64/usr/share/gap/pkg/transgrp/tst/trans.tst:64
# Input is:
i=List(h,TransitiveIdentification);
# Expected output:
true
# But found:
Error, the Small Groups identification is required but not installed
########

The Dependencies section of transgrp's PackageInfo.g does not list smallgrp. Running the test manually yields the following backtrace:

brk> Where(10);
IdGroup( classaut ) at /usr/share/gap/grp/simple.gi:1161 called from
DataAboutSimpleGroup( id ) at /usr/share/gap/grp/simple.gi:887 called from
DataAboutSimpleGroup( PerfectResiduum( G ) ) at /usr/share/gap/lib/clashom.gi:28 called from
ClassesFromClassical( F ) at /usr/share/gap/lib/clashom.gi:1223 called from
ConjugacyClassesFittingFreeGroup( f ) at /usr/share/gap/lib/clashom.gi:2384 called from
ConjugacyClassesViaRadical( G ) at /usr/share/gap/lib/clashom.gi:3068 called from
ConjugacyClasses( g ) at /usr/share/gap/lib/grpperm.gi:1938 called from
CycleStructuresGroup( grp 
 ) at /builddir/build/BUILDROOT/gap-pkg-transgrp-3.6.5-5.fc40.x86_64/usr/share/gap/pkg/transgrp/lib/trans.grp:714 called from
TransitiveIdentification( TransitiveGroup( n, i ) ^ s ) at *stdin*:40 called from
<function "unknown">( <arguments> )
 called from read-eval loop at *errin*:1

Attempting to see the values of n, i, and s does not go well:

brk> UpEnv(8);
brk> s;
Small Groups identification
brk> n;
Error, Variable: <debug-variable-0-10> must have a value in
  Error( "the ", s, " is required but not installed" ); at /usr/share/gap/lib/init.g:315 called from 
IdGroup( classaut ) at /usr/share/gap/grp/simple.gi:1161 called from
DataAboutSimpleGroup( id ) at /usr/share/gap/grp/simple.gi:887 called from
DataAboutSimpleGroup( PerfectResiduum( G ) ) at /usr/share/gap/lib/clashom.gi:28 called from
ClassesFromClassical( F ) at /usr/share/gap/lib/clashom.gi:1223 called from
ConjugacyClassesFittingFreeGroup( f ) at /usr/share/gap/lib/clashom.gi:2384 called from
...  at *errin*:4
#I  Options stack has been reset
brk> i;
Error, Variable: <debug-variable-0-10> must have a value in
  Error( "the ", s, " is required but not installed" ); at /usr/share/gap/lib/init.g:315 called from 
IdGroup( classaut ) at /usr/share/gap/grp/simple.gi:1161 called from
DataAboutSimpleGroup( id ) at /usr/share/gap/grp/simple.gi:887 called from
DataAboutSimpleGroup( PerfectResiduum( G ) ) at /usr/share/gap/lib/clashom.gi:28 called from
ClassesFromClassical( F ) at /usr/share/gap/lib/clashom.gi:1223 called from
ConjugacyClassesFittingFreeGroup( f ) at /usr/share/gap/lib/clashom.gi:2384 called from
...  at *errin*:5

But we can see the argument passed to TransitiveIdentification:

brk> DownEnv(1);
brk> ogrp;
Group([ (3,6)(4,5)(9,14), (1,13,4,9,10,3,2)(5,14,12,6,8,11,7), (1,2,10)(3,4,9)(5,14,6)(8,12,11), (1,12)(2,8)(3,6)
  (4,14)(5,9)(10,11) ])

[jamesjer]

Hmmm, I've misunderstood something. Adding smallgrp to the build root does not help. What is this "Small Groups identification" that provides IdGroup?

[jamesjer]

Ah, I see. The way we have been invoking the test won't load the smallgrp package. I can modify that. Are the difficulties examining the values of s, i, and n expected? That seems to be the only issue.

[orlitzky]

As for loading SmallGrp: hulpke/transgrp#47

[dimpase]

@orlitzky

convert.pl is installed as /usr/share/gap/etc/convert.pl but I'm not sure how a package in ~/.gap would be supposed to know that. Do you have an example? How does it work when it does work? If these packages are expecting you to be doing development from within the GAP install, it may simply not be possible (without extra steps) when using the system GAP.

I overlooked installed convert.pl, but as far as I can tell, Gentoo's gap does not install anything from doc/, e.g. no gapmacro.tex
Without them one cannot build docs of quite a number of packages, as you can see by doing grep -R gapmacro pkg/, on a fully installed GAP source tree with all packages.

Indeed, most packages just assume that these macros can be imported using a relative path, e.g.

pkg/nilmat/doc/manual.tex:\input ../../../doc/gapmacro

Some use a saner, from TeX point of view, \input gapmacro (one can tell TeX where to look).

Some packages just ship copies of gapmacro, e.g. Sonata does it.

[AndreasEnge]

Hello, Am Mon, Feb 05, 2024 at 06:50:36AM -0800 schrieb Max Horn:

I plan to release GAP 4.13.0 in February (current aim: ~2 weeks) assuming all goes well. Based on the experience in the 4.11.x and 4.12.x release cycles, I've decided to make a prerelease available again.

thanks for the pre-release! Building it within Guix through the command guix build gap --with-source=gap=https://github.com/gap-system/gap/releases/download/v4.13.0-alpha1/gap-4.13.0-alpha1.tar.gz does not show any problems. Andreas

[fingolfin]

I've now made a second alpha release, see https://github.com/gap-system/gap/releases/tag/v4.13.0-alpha2 which includes the fixes listed above and a few more, and also some package updates (e.g. newer xgap).

No fix for the io / digraphs / whatever crash reported by @orlitzky but I think that can be dealt with in GAP 4.13.1

[jamesjer]

The second alpha release builds without trouble on Fedora.

[orlitzky]

I hit another minor issue today upgrading GAP with packages installed:

testing: /var/lib/portage/tmp/portage/sci-mathematics/gap-4.13.0_alpha2/work/gap-4.13.0-alpha2/tst/testinstall/ctblmaps.tst
########> Diff in /var/lib/portage/tmp/portage/sci-mathematics/gap-4.13.0_alpha2/work/gap-4.13.0-alpha2/tst/testinstall/ctblmaps.tst:6
# Input is:
if TestPackageAvailability("ctbllib") <> fail and
      LoadPackage("ctbllib", false) <> fail then
     s:= CharacterTable( "2.A6" );;
     t:= CharacterTable( "Co3" );;
     maps:= [ [ 1, 2, 8, 4, 11, 4, 13, 18, 18, 9, 22, 9, 22 ],
              [ 1, 2, 8, 4, 11, 4, 13, 17, 17, 9, 22, 9, 22 ] ];;
     if Length( ConsiderStructureConstants( s, t, maps, true ) ) <> 0 then
       Error( "test of ConsiderStructureConstants failed" );
     fi;
   fi;
# Expected output:
# But found:
Error, LOAD_DYN: kernel module /usr/lib64/gap/pkg/io//bin/amd64/io.so built for older version of GAP
Error, was not in any namespace
########
      45 ms (42 ms GC) and 278KB allocated for ctblmaps.tst

...

testing: /var/lib/portage/tmp/portage/sci-mathematics/gap-4.13.0_alpha2/work/gap-4.13.0-alpha2/tst/testinstall/method-reordering.tst
########> Diff in /var/lib/portage/tmp/portage/sci-mathematics/gap-4.13.0_alpha2/work/gap-4.13.0-alpha2/tst/testinstall/method-reordering.tst:27
# Input is:
CheckReorder(false);
# Expected output:
true
# But found:
false
########

The fact that io is unloadable is not surprising because we haven't had a chance to rebuild it yet (we're still installing the new GAP at this point). But what is a little surprising is that Error, LOAD_DYN: ... built for older version of GAP isn't fatal. The remaining test failure is a red herring because both go away if I uninstall io before upgrading GAP.

The first error should probably fail the test suite? In addition it would be a nice if GAP could skip tests that utilize outdated kernel modules, but I understand completely if that's hard or not something you want to deal with right now.

[fingolfin]

We deliberately do not stop after the first error, just as compilers like gcc and clang do not stop after the first error, and for the similar reasons.

In addition it would be a nice if GAP could skip tests that utilize outdated kernel modules

But one of the two primary purposes of the test suite is to detect broken system state, which it does here... How would we decide which failures are "acceptable" and which aren't, and when? For 99% of user, this issue would indicate a genuine problem.

[orlitzky]

We deliberately do not stop after the first error, just as compilers like gcc and clang do not stop after the first error, and for the similar reasons.

That was a bad example then. When the module version error is the only error, the test suite passes:

 ┌───────┐   GAP 4.12.2 of 2022-12-18
 │  GAP  │   https://www.gap-system.org
 └───────┘   Architecture: amd64
 Configuration:  gmp 6.3.0, GASMAN
 Loading the library and packages ...
 Packages:   GAPDoc 1.6.6, PrimGrp 3.4.4, SmallGrp 1.5.3, TransGrp 3.6.5
 Try '??help' for help. See also '?copyright', '?cite' and '?authors'
─────────────────────────────────────────────────────────────────────────────
Loading  datastructures 0.3.0 (datastructures - GAP Data Structures)
by Markus Pfeiffer (http://www.morphism.de/~markusp),
   Max Horn (https://www.quendi.de/math),
   Christopher Jefferson (http://caj.host.cs.st-andrews.ac.uk/), and
   Steve Linton (http://sl4.host.cs.st-andrews.ac.uk/).
Homepage: https://gap-packages.github.io/datastructures
Report issues at https://github.com/gap-packages/datastructures/issues
─────────────────────────────────────────────────────────────────────────────
Error, LOAD_DYN: kernel module /usr/lib64/gap/pkg/io/bin/amd64/io.so built for newer \
version 9000 of GAP
Error, was not in any namespace
>>> Completed testing dev-gap/digraphs-1.6.3-r2

>>> Install dev-gap/digraphs-1.6.3-r2 into /var/lib/portage/tmp/portage/dev-gap/digraphs-1.6.3-r2/image
...

In addition it would be a nice if GAP could skip tests that utilize outdated kernel modules

But one of the two primary purposes of the test suite is to detect broken system state, which it does here... How would we decide which failures are "acceptable" and which aren't, and when? For 99% of user, this issue would indicate a genuine problem.

I see your point. I guess my high level request then (and no longer for this release) would be to gradually move the tests that require additional packages out of GAP and into those packages? In this case, the problem arises for us because GAP is running tests for ctbllib, but ctbllib indirectly uses io, and io depends on GAP. As a result there's no "right order" in which to perform the upgrades.

Moving those tests out of GAP and into ctbllib would eliminate the circular dependency. GAP would finish upgrading, and then we could rebuild io, and possibly ctbllib after that. By the time we rebuild ctbllib and run those tests, the module version incompatibility would be resolved.

It's not too hard to tell people "disable the tests before you upgrade" once a year, though, so it's a pretty minor issue all things considered.

[fingolfin]

Just as a heads up, GAP 4.13.0 has now been released. Thanks to all of you who tested the alphas and also thanks for the helpful feedback!

[jamesjer]

Thanks for the heads up. Final freeze for Fedora 40 is very near. I will update gap and its packages before then.