This is from a mothballed dictionary project that I decided to un-mothball. Due to horrible install problems I migrated from M1 Mac to Ubuntu 20.04; I installed from the recommended SWI repo.
This (very large now, 808M) file suddenly spews errors. I used this, if I remember well, in the SWI Prolog 5 and 6 era. It was fine then, on the Mac. I do a qcompile of it, which speeds up things immeasurable. While doing this, lots and lots and lots of errors show up (one example only):
Looking at those lines with awk, the conclusion presents itself as Unicode characters not being supported (anymore) as parts of an atom. Can anybody help?
Maybe there are problems with the encoding? Are the files you have in UTF-8? Can you actually just get this one line that has the error you show, put it in a file on its own, and reproduce the error? That would make it easier to troubleshoot.
Because Unicode source is definitely fully supported. If I just copy the snippet as you showed above and paste it into a file, it loads (compiles) without any issues.
I now copied your snippet, pasted it to a file, saved this file, then loaded it and used listing, then copied the output back in here. Can you check the encoding somehow?
EDIT: if I just copy-paste incapaç to a file called bar, I see:
$ cat bar
incapaç
$ hexdump bar
0000000 69 6e 63 61 70 61 c3 a7 0a
0000009
If UTF-8 and Unicode are supported, and this works on your system, there must be something wrong with this Ubuntu (on an Intel NUC-7, twice upgraded 16->18, 18->20). Back to my Mac.
The encoding of the file must match the default locale or the file must contain a (correct) :- encoding(...). directive at the start. It looks like the file has UTF-8 encoding. Typically, modern Linux systems also default to an UTF-8 based locale. Maybe not in this case?
Try running locale in the shell. That should say something like LANG=…UTF-8. Also Prolog should answer on
?- current_prolog_flag(encoding, X).
X = utf8.
If the locale is wrong install the desired locale and set your LANG environment variable right.
Alternatively you can use the recode utility to recode the file to the current locale. In these days you typically want your environment to use UTF-8 all over though.
That points at a wrong locale. The encoding flag is initalized from LC_CTYPE or LANG. If this ends with UTF-8, utf8 is assumed. If it is a known alias for ISO Latin 1,
this is assume and else it is set to text, which causes Prolog to fallback to the C runtime library to translate input to Unicode.
I compiled it on an M1. At least the current development version compiles fine after installing the dependencies using Macports. You can deduce the build process and dependencies from the Portfile. I was impressed by the performance. It is about twice as fast as the GCC compiled version on my old Macbook air. AFAIK you cannot yet use GCC on the M1. Once you can, I’m curious about the results. At least on Intel, GCC produces much faster code for SWI-Prolog than Clang.
I don’t know whether 8.2 compiles on the M1. It will be updated to 8.4 shortly anyway.
I will try that certainly, soon. As I use NetRexx with JPL, that last component is a bit of a bottleneck. Brew does, for some reason not compile and install JPL; Ports fails with a build error on db53. The macOS package installer is X64_64, and works well with Rosetta; only calling from Java into that dylib fails with a ‘wrong architecture’ error, for some reason Rosetta does not seem to support that (I have Zulu Java for ARM64). So I thought Linux would be faster, but I encountered an error there, which you thankfully diagnosed and which is fixed now. When 8.4 comes out, I’ll build that on the M1.