I just finished a workshop with 17 professional software engineers coming from other languages to Prolog.
This was a big thing for them, and I think they took getting Prolog installed reasonably seriously.
Yet over 50% of them arrived with Prolog installs with no working graphics.
Install glitches I saw:
* The mac install rarely works, because xquartz isn’t there
* Windows install to a username with a unicode character is broken
* check_installation is a great tool, but fails to help beginners distinguish between things like JPL that are broken and only important if you’re going to use Java, and things like xpce, that leave you pretty broken.
* There are too many ways documented to do it, they conflict with each other, and overall we communicate how to install poorly.
Work may be bringing me to Amsterdam soon. Is it possible we could have a public day where we ask random engineers to come in and let us watch them install SWI-Prolog?
Then clean this area up.
So far the issue seems to be check_installation/0 which relies on tmp_file_stream/3 which was not unicode aware. 8.1.14 probably fixes this, though I didn’t test on Windows. The bug also applied to Unix when setting the tmp dir to something non-ascii though. That is fixed.
The issue Jan B is referring to is that SWI-Prolog uses a hybrid internal encoding that uses char* using ISO latin 1 for strings/atoms with all characters in the Unicode range 0…255 and wchar_t* for other strings, expecting this to use UCS-4 (UTF-32)
encoding. Unfortunately on Windows, the wide character encoding is UTF-16, from which we use the UCS-2 subset. Fortunately most Unicode characters are in the range 0…2^16, but those that are not cannot be represented.
There are several ways out, but most are quite a bit of work and/or require a lot of re-encoding and thus slowdown. I guess this waits for someone willing to do the work or someone paying someone else to do the work.
Well, overall, it’s just worrysome that we had that many folks with issues.
From the web-prolog discussion, I like Paulo’s list of things that are important in adoption, and ‘smooth install’ is on them. Since we can’t easily control many of the others, we should fix the ones we can.
I surely agree that smooth install is a bit asset. Easily control is another thing though. Yes, we can make sure the system installs for people with non-ascii characters in their home location (this should be fixed with 8.1.14; can someone check?) On Windows, things are relatively straightforward as the binary compatibility is good and we have no external dependencies. On MacOS things get a lot harder. There are four ways to install: using Homebrew, Macports, just from source and the Mac App binary. Each comes with advantages and disadvantages. Homebrew doesn’t like to accept the package with many default dependencies, so people end up with a very basic system unless they add some flags. The native binary still has some issues dealing with the fact it is a POSIX application in a Mac jacket that doesn’t really fit. All have the problem they need XQuartz for the development tools. The only way around I see is to write a binding to cacao for xpce. That is doable, but probably requires a month for an experienced C programmer. Finally, there is Linux. There we have the PPAs for Ubuntu. On other platforms you either have a rather old version from the distro (if) or you have to compile from source. Typically not really hard, but it can go wrong. The end result is best though
