Can't delete Carat directory on Windows

[ChrisJefferson]

If you (all from Windows explorer):

1. Download gap-4.9.1.zip
2. Unzip it
3. Try to delete the resulting directory

You'll find you can't delete the directory. The problem is files which are called 'Con', from carat.

[olexandr-konovalov]

Thanks for reporting. This is something which escapes attention in batch tests, when the directory is removed by other means. I can reproduce this in Win7 too.

The file which causes that seems to be an innocent carat/carat/tex/progs/Con.html. If I delete it from Cygwin shell, then deleting the directory works. Maybe there is some Windows setting that needs to be adjusted to avoid it being treated specially?

[ChrisJefferson]

No, we need to remove that file from the distribution.

[olexandr-konovalov]

Ah, I see. Even browser refuses to show file:///C:/gap-4.9.2/pkg/carat/carat/tex/progs/Con.html. Found some explanations on Stackoverflow.

Can't delete it in the Windows command prompt either:

C:\gap-4.10.0\pkg\carat\carat\tex\progs>del Con.html
The filename, directory name, or volume label syntax is incorrect.

I've found the solution here : one should call del in Windows command prompt specifying the full path as below (\\.\ before the drive name is essential):

del \\.\C:\gap-4.9.2\pkg\carat\carat\tex\progs\Con.html
del \\.\C:\gap-4.9.2\pkg\carat\carat\src\con.c

as soon as these two files are removed, the rest of the directory can be easily removed.

[olexandr-konovalov]

Cross-posted in Carat (as GAP package) issue tracker at gap-packages/CaratInterface#5

[gaehler]

I do not understand how one can run into this problem. The problematic files are hidden in a gzipped tarball with the carat sources. The README clearly states that this package - Interface to Carat - is an interface package to a collecttion of UNIX-only standalone programs. There is absolutely no reason to unpack it on Windows, especially since unpacking requires a lot more disk space. Or does your file manager unpack recursively? I would consider that a bug.

[olexandr-konovalov]

Thanks for the comment - I now understood what happened. We are now attempting to build as many packages on Windows as possible by running bin/BuildPackages.sh. The build of Carat fails (as shown below), but the archive is unpacked, and then the win.zip archive with binaries for GAP and packages is wrapped. A quick fix would be to delete the unpacked carat directory before wrapping. I am not very happy with it since it makes carat non compliant with the standard procedure, it still will cause problems to users who may unpack it on Windows at least just to study the code, and potentially for users who may even get it running with Windows 10 Linux subsystem. So in the long run renaming it in Carat would still be preferable.

In file included from base.c:36:0:
/cygdrive/c/gap-4.9.2/pkg/carat/carat/include/tools.h:51:13: error: conflicting types for ‘itoa’
extern void itoa(int n, char s[]);
^
In file included from /usr/include/stdio.h:29:0,
from /cygdrive/c/gap-4.9.2/pkg/carat/carat/include/typedef.h:29,
from base.c:32:
/usr/include/stdlib.h:183:8: note: previous declaration of ‘itoa’ was here
char * _EXFUN(itoa,(int, char *, int));
^
Makefile:20: recipe for target 'base.o' failed
make[2]: *** [base.o] Error 1
make[2]: Leaving directory '/cygdrive/c/gap-4.9.2/pkg/carat/carat/functions/Base'
../Makefile_CARAT:106: recipe for target 'Base' failed
make[1]: *** [Base] Error 2
make[1]: Leaving directory '/cygdrive/c/gap-4.9.2/pkg/carat/carat'
Makefile:49: recipe for target 'programs' failed
make: *** [programs] Error 2

WARNING: Failed to build carat

[ChrisJefferson]

To be concrete, I'm currently applying the following fix to carat, before building it (this isn't distributed in GAP, I am experimenting to see which packages which can be implemented in GAP).

This:

a) Renames the itoa function to CARAT_itoa, because cygwin's libc has a function called itoa.
b) Just removes Con.exe and Con.c (after building), because they upset Windows
c) Rename Con.html to ConCarat.html.

This clearly isn't acceptable for release, as I am removign Con.exe while not mentioning I'm doing this in the documentation. I could instead move Con.exe to ConCarat.exe, or just mention in the documentation this function is missing.

What I want to do, is do whatever will take the least amount of work, because obviously Windows support shouldn't be a major requirement. For packages like Carat, which are GPL v3 and has long-standing code which isn't likely to change, my preference would be to just put these fixes into the Cygwin build script, where package authors won't have to worry about them.

(
    cd carat*
    find . -type f -name "*.c" -print0 | xargs -0 sed -i '' -e 's/itoa/carat_ITOA/g'
    find . -type f -name "*.h" -print0 | xargs -0 sed -i '' -e 's/itoa/carat_ITOA/g'
    make
    # The name 'Con' upsets windows.
    rm carat/bin/*/Con.exe carat/src/con.c
    # Rename Con.html to ConCarat.html
    find . -type f -name "*.html" -print0 | xargs -0 sed -i '' -e 's/Con.html/ConCarat.html/g'
    mv carat/tex/progs/Con.html carat/tex/progs/ConCarat.html
)

[olexandr-konovalov]

While on this matter, would be good to untangle this: 44.6 Matrix Groups in Characteristic 0 says "Most of the functions described in this and the following section have implementations which use functions from the GAP package Carat. If Carat is not installed or not compiled, no suitable methods are available." - these should better be moved to the Carat package.

[gaehler]

The CARAT program Con is a low level auxiliary program, and not really relevant for us here (it has no GAP interface). One could rename it to Conj, though.

I am surprised that CARAT compiles on Windows with minor modifications. Still, this is only the first part of the goal of producing prepackaged binaries. Carat uses a database of groups and lattices, which must be located exactly where it was located at build time. In other words, the package Carat must be installed at exactly the same path where it was built. Unfortunately, this is not easy to change.

Regarding the declarations in Chapter 44.6: they were put there in the hope that, some day, there would be other implementations not requiring external programs. How likely this is, is a matter of debate.

[olexandr-konovalov]

@gaehler I am building GAP 4.9.2 for Windows in C:\gap-4.9.2 directory - one could hope that if GAP will be installed in this default path, then things may work... Although my advise to Windows users requiring Carat would be to try to use Linux VM, or Docker, or Windows 10 UNIX subsystem etc. instead...

[olexandr-konovalov]

Just had another insight into this. I can delete easily GAP installation made using exe installer. Perhaps because it simply does not contain offending files already - they were ignored when the installer has been made? So users of the exe installer may not experience this problem at all. Good news.

[olexandr-konovalov]

Good news - there is now a repository at https://github.com/lbfm-rwth/carat/, and @DominikBernhardt is its maintainer. If @ChrisJefferson or @gaehler would like to submit a PR to fix this, that would be very helpful!

[gaehler]

I will prepare a PR with Windows compatibility fixes.

[olexandr-konovalov]

Thanks @gaehler for lbfm-rwth/carat#14 ! @ChrisJefferson please help to get that PR reviewed.

[fingolfin]

The issue was resolved in carat (now: CaratInterface) 2.3, and thus will be resolved in GAP 4.11.