Anyone interested in the future of the development tools and GUI is invited to checkout these versions. Primary topics I am primarily interested in are:
Does it install?
UI functionality of the “app”. Please also check the popup in the terminal. I pruned the menus a lot. Probably too much. Which options should be added?
Stability.
General impression
Note that the functionality is now pretty much the same on all platforms.
If you prefer building from source:
Take the branch sdl from swipl-devel.git
Configure using -DEPILOG=ON
Dependencies are SDL3, SDL3_image, cairo, pango and libedit. That is in addition to the old dependencies. The X11, jpeg and xpm dependencies are no longer needed.
On Debian based systems, these are libcairo2-dev, libpango1.0-dev and libedit-dev while SDL3 and SDL3_image must be build from source on most distros. If you have a very recent one you might have them.
$ swipl
Welcome to SWI-Prolog (threaded, 64 bits, version 9.3.25-44-gc2ffbe14f-DIRTY)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
Please run ?- license. for legal details.
For online help and background, visit https://www.swi-prolog.org
For built-in help, use ?- help(Topic). or ?- apropos(Word).
1 ?- [library(editline)].
true.
With this all the old terminal functionality is back (history, tab completion, extended characters) without the -Dno-readline command line option. In fact, if you include the option, it complains when processing init.pl
ERROR: set_prolog_flag/2: Type error: `bool' expected, found `readline' (an atom)
At least for me, you don’t need this. It is loaded automatically.
MacOS 10.14.6 is long out of service … The MACOSX_DEPLOYMENT_TARGET is set to 10.15, though I doubt such old versions will work. The stack seems mostly bogus
Nice that the commandline version improved a bit. The app is about the GUI version though.
The trouble is that SDL3 is just out and it seems a bad idea to start a new project on SDL2. The functionality is not widely different, but SDL3 revised the entire C API for consistency in naming and types and adopting modern C standards and practices. Something I have been thinking about for SWI-Prolog as well. As we see, such a move has severe consequences on other projects
On the other hand, there is a library that lets most SDL2 code run on SDL3, but AFAIK not the other way around …
Agree. (Historical artifact in my local init.pl was causing the problem.)
I might be wrong but I recall the reason for moving the target up to 10.15 was to accommodate an upgrade in Qt, which is a bit ironic given that Qt is being removed. In any case, at that point, I moved to the commandline version and, after a short learning curve, decided that the GUI version wasn’t really providing me with much additional value.
Note that the commandline version has always worked so, at least for that, I don’t share your skepticism that “old versions” of MacOS won’t work, unless there’s something in the new libraries that is incompatible. I won’t get into the reasons I don’t chase Apple’s OS upgrades, but I don’t expect you to support my perhaps idiosyncratic configuration.
Understood. I’m primarily interested in ensuring that the commandline version continues to work as before. I haven’t done a lot of testing but one obvious feature that no longer works is profile/1 since it opens an X-Window (via Quartz). (For now, 9.2.9 seems to be my best option since it also has an optimized version for Intel Macs.)
True. I left the deployment target as is though. Possibly it can be set to older versions. Building the (fat) dependencies is a lot of work though that requires a lot of manual tweaks and a lot of patience. I’d rather update your Mac for you
Running the commandline version as swipl --no-pce ... as fix that.
The new GUI versions should also provide some useful stuff, such as clickable errors and warnings If you have Macports or Homebrew still working, building from source should be feasible.
I’d upgrade myself if I didn’t run the risk of breaking some existing app. That’s why I’ve taken an “If it ain’t broke…” approach. SWIP isn’t sufficiently broke (yet).
This actually also fixes the ERROR hell when you try to profile anything, so that’s a good suggestion. The only issue is that the text only version of show_profile/1 is a (very) pale imitation of what the the X-Window version provides (call chains, full port counts, sampling stats, “browsing” capability to name a few).
Maybe, if I get really desperate (v9.2.9 is just fine for now), but I’ve never built an app bundle before. (To be honest, I’d probably try this before upgrading the OS if I had any assurance that the new libraries were MacOS 10.14 compatible.)
Yes, it listens to SDL_GetSystemTheme(). You should be able to add -Dtheme=light and possibly you can use
:- set_prolog_flag(theme, light).
in init.pl (unsure about the timing).
I’m doing some work on improving the dark theme. It seems to many people use it these days that it is worthwhile to make it good. A list of issues would be great. The work in progress is mostly at the xpce level to make the theme adjustment more fine grained where needed. The actual theme declarations are in library(theme/dark). Note that you can clone the dark theme to your personal library and adjust it. Please share the improvements. My eyes do not like dark theme …
I pushed several patches to make the profiler behave at least mostly fine under the dark theme. Didn’t update the installers, so you have to build from source. I know you can do that Take the sdl branch for both Prolog and xpce. Using -DEPILOG=ON when configuring. Then src/swipl-win is the same as what the flatpak runs.
Good question. I compiled the libraries for Intel on MacOS 14 (15 does not run on Intel Macs). The deployment target is set to 10.15 and all compiled fine. I verified that it runs on an Intel MacOS 14 system as well.
The other obvious question is ok, you do not want to upgrade from 10.14, so you install a new version in a new partition. Why not install the most recent version that can run on your hardware?
Another useful datapoint: SDL version runs on Intel MacOS 14 and Apple MacOS15 (and, I would guess, MacOS 14 as well). That would seem to point to the OS version as the issue (although I suppose the build tools can’t be completely eliminated as a possible cause). If I was more comfortable with building the bundled app from source directly on my config, that would be an interesting experiment to try.
It’s a bit curious, to me anyway, that on my older 10.14 system, the OS could detect incompatibility with the Qt bundle and not even allow you to launch, whereas the SDL version was deemed compatible (in some sense) but crashed after launching. But as noted previously the commandline version seems to work well.
Well in the middle of this discussion I remembered I had an older install of 10.15, which I probably did around the time of the Qt upgrade. I did so to assess how many of my existing apps were broken by the upgrade as well as to test the upgraded version of SWIP at that time.
I believe the latest MacOS version that will run on my hardware is MacOS 12 so a few years old at this point. And I guess I’ve pretty much committed to using the commandline version of SWIP for the foreseeable future, so upgrading further isn’t any further benefit to me that I can see, other than providing another data point for this discussion.
There probably aren’t very many MacOS users who have this issue so I don’t expect any resolution (or additional effort), but it still would be nice to know the minimum MacOS requirement.
Possibly the Info.plist file claimed the requirement of 10.15? That file was populated by the Qt install scripts. The current version is hand crafted and might be lacking of of this stuff. If we would know which version is required, we could consider adding this info. As we do not know, there is not much point …
You could try that …, though MacOS 12 is also EOL
You best option would be to compile from source. But, you need C11 and I’m not sure the old version of Xcode supports that …
I’d install Linux on the hardware. Then you get a recent version and it will probably be a lot faster
