SWI-Prolog 9.1.20 is ready for download. Highlights:
Discussions about Janus, the Python interface are practically
finished. The latest modifications have been incorporated.
The documentation is extended with a compatibility note for
all predicates and Python functions that are covered by the
discussions.
A lot of changes to CMake configuration management to facilitate
Conda. This notably streamlines building on Windows using
VS2022 and better facilitaties to support the POSIX-like
application layout on Windows next to the conventional
stand-alone directory in C:\Program Files\swipl. The
current Conda recipe is at GitHub - SWI-Prolog/swi-prolog-feedstock. The plan
is to get that merged into the official Conda forge port at GitHub - conda-forge/swi-prolog-feedstock: A conda-smithy repository for swi-prolog..
Generalize the benchmark suite. See other posts. Hopefully
this can be extended to more systems and wider coverage.
Several sandbox updates to facilitate clpBNR by @ridgeworks
A small enhancement to calling foreign predicates. This is
a change in the VM that invalidates old states and .QLF files.
If you do an incremental update, please remove the *.plf
files under the build directory before building. With incremental
build I refer to git pull && git submodule update followed by ninja in the build directory. If you build in a fresh
build directory all works fine.
Enjoy ā Jan
P.s. Problems with Ubuntu PPA services appear to be resolved and PPAs
are available for 9.1.20.
SWI-Prolog Changelog since version 9.1.19
DOC: Improve swipl --help (list āappā mode)
SANDBOX: Declare flag write_attributes as safe. This may call
portray, but local definitions are verified and global definitions
cannot be changed.
CLEANUP: Move installation locations to cmake/Locations Moving it
into a separate file keeps the main file short and it needs to be
before Ports because we need to act on them. Possibly though, we
need part of the locations before and part after the Ports? As is,
that does not seem to be the case. Alternatively we could move part
of this into the Port files?
PORT: Allow for not having a compiled-in āhomeā directory Conda has
no sensible fixed installation location.
FIXED: check_installation not to bail out if a feature test raises
an exception.
CLEANUP: Moved default definition for file_search_path/2 foreign
to library(shlib). This simplifies maintenance. The change also adds swi(lib/Arch) for all platforms, although the default SWI-Prolog
for Windows installs the libraries in swi(bin). Possibly we can
change that too?
INSTALL: Allow installing in public directory without symlink For some
installations we want the executables in another directory than the
āhomeā. Normally these were POSIX systems and we would symlink from
the executable to the real location in the self-contained binary.
But, also some Windows installations such as MSYS2 and Conda (and
probably
Cygwin) want this. Therefore we added SWIPL_INSTALL_AS_LINK which, if
OFF, compiles the relative path to the anticipated home into the binary
such that we can install the .exe in a separate directory (for Windows
along with the DLLs needed to run them).
CLEANUP: format_types/2 Remove not-working attempt to make it
bi-directional. It now properly raises an instantiation error,
causing sandbox analyis to work without breaking anything.
FIXED: Conditional compilation and :- include/1. Avoid errors on
:- if(...).
:- include(...).
:- elif(...).
...
ENHANCED: Shorten and simplify calling deterministic foreign functions
This patch unifies I_FOPEN with the subsequent calling function and
somewhat simpifies the design.
SANDBOX: added several arithmetic predicates as safe: -
current_arithmetic_function/1 - bounded_number/3 - float_class/2 -
float_parts/4
Package bench
ENHANCED: Better compensation for computing dummy overhead.
Contributed by Jose Morales
PORT: Make benchmarks run on Scryer Prolog 0.9.3
FIXED: queens_clpfd.pl benchmark merely posted the constraints.
Now actually solves them and does not generate all solutions as these
are too many.
ADDED: Ciao lang
PORT: Improve portability for boyer.pl
PORT: Generalize, support XSB, GNU-Prolog and Trealla Prolog.
PORT: Support clpfd benchmark for SICStus.
PORT: fast_mu.pl: avoid length/2.
PORT: browse.pl benchmark to avoid length/2
PORT: sieve.pl: avoid forall/2, ignore/1 and between/3.
ENHANCED: Portability, Prolog driver, many details Now uses a single
(SWI-)Prolog program for the overall management, running the Prolog
system(s), joining the data and generating the chart.
We now have a system in place to support pretty much every Prolog
system, with or without modules. SWI, Yap and SICStus can do the
job with the original sources. For e.g., Scryer we transform the
sources and test beforehand which files Scryer can handle.
COMPAT: Avoid name/2 in favor of atom_codes/2 and number_codes/2.
PORT: Support CSV for all platforms
PORT: Revive YAP and SICStus compatibility.
Package clib
ADDED: ensure_directory/1
Package cpp
MODIFIED: SWI-cpp2.h includes inlined methods by default
Package http
ADDED: reply_html_partial/1 Reply HTML element without DOCTYPE
and <html>.
ADDED: Allow no-chunking behavior for pengines. If chunk=false
we avoids the usage of findnsols (and the effects on global variables
associated with its backtracking). Initially, this was motivated by
the fact that I wanted the pengine top-level (which is recursive
in nature) to respect the chr store, but I also think itās a more
principled thing to do.
Package pldoc
ADDED: @since tag Allows annotating the version when a predicate
was added.
Package swipl-win
INSTALL: Sync with central cmake changes
Package swipy
ADDED: Allow returning Python dicts as {K:V,ā¦} terms. Improves
portability.
MODIFIED: Return dicts we cannot represent using portable style.
COMPAT: Python functions that as for truth values now use truth_vals truth_vals is the original keyword name from XSB. truth was
considered too ambiguous.
As decided in Janus PIP (Prolog Improvement Proposal) meeting on Nov 22.
Indeed. The Python package is agreed to be called janus_<system>, for us janus_swi
Indeed. At the ICLP conference in London the idea of PIP (Prolog Improvement Proposal) was launched. The idea is that multiple (as in more than one) teams discuss something related to Prolog and write this up as a public PIP publication. Janus was discussed between the XSB team that started Janus, me and people from Ciao that launched the PIP idea. The technical discussion is practically finished and we are now discussing what the PIP publication must look like.
The idea behind PIPs is that, due to a small number of participants that have at least some common understanding about a topic, we can make real progress. The result does not need to be exhaustive and formal like with ISO and does not need to be accepted by a large group. That way, we have proven that we cannot make progress Still, the problem is considered from multiple perspectives and the result is typically better than what any of the individual teams could have achieved.
Surely this worked for Janus were we started with the idea that a low-level bi-directional interface that exploits the dynamic data types of both languages is what we want to build. We started with quite different viewpoints about the API though. All has landed nicely. Surely, one can see some compromises in the final result. The result is also better than what either of us started with
I am now quite convinced this works nicely for topics that are either not yet settled or for which there are no serious backward compatibility issues. The whole process needs to be streamlined a bit, including establishing a team, (not) sharing progress and making the result public.
That was the missing info. I did not know that PIP also meant Prolog Improvement Proposal and when seeing talk of Python and the acronym PIP instintivly thought of pip Ā· PyPI
I was also wanted to clarify this before a search engine starts the Python world deciding upon this post and then we get unneeded questions.
Tested on my old Intel Mac running Ventura 13.2.1. Runs fine (but slow compared to the M1 )
It is not Qt, or any of the non-macOS dependencies as the binaries thereof have not been updated. The release is compiled using MACOSX_DEPLOYMENT_TARGET=10.14. The only thing relevant I can think of that is updated is the xCode. MacOS 10 is end-of-life since Sep 2022. Possibly the command-line version still works? It is inside the app at Contents/MacOS/swipl (from my head).
Iām afraid there is not much that can be done about that. What I can think of is
Compile from source. To keep it simple using Homebrew or Macports dependencies.
Upgrade MacOS. If your hardware is too old, there is still Linux for Max hardware ā¦
$ SWI-Prolog9.1.20-bndl/MacOS/swipl
Welcome to SWI-Prolog (threaded, 64 bits, version 9.1.20)
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).
?-
Sounds like it might be a MacOS version dependency in the bundle, but whatās the difference between 9.1.19, which runs fine, and 9.1.20 which crashes immediately? (Changes to CMake sound a little ominous.)
Basically nothing changed except for the C/C++ compiler that was updated to the latest xCode version. None of the libraries involved in the GUI was updated. Something similar happened to GMP when used with the app quite some MacOS and Prolog versions back
Something has obviously changed and the command line version seems to be OK, although Iām not sure what that means. Iāll spend some time looking at the bundle contents in more detail.
You could try to copy swipl-win from a working old version to the new version. Eventually this looks like a dead end though. SWI-Prolog tries to support an as wide as possible range of versions in dependencies, build tools and OSes. While supporting the latest versions has priority, OS versions that have passed end-of-life have no priority. If it works, fine, if not, bad luck. Sorry about that.
Replacing the 9.1.20 version of the SWI-Prolog executable with the 9.1.19 version did indeed fix the problem AFAICT. I conclude there is nothing wrong with any of the other libraries or the configuration either internal to the bundle or in the OS. Unless something has changed in the SWI-Prolog executableās source, the root cause, as suspected, seems to be the new version of Appleās build tools. I have to wonder what the change might be to cause such a drastic difference in behaviour (a Segmentation fault) .
As far as future considerations are concerned, my experience with Appleās OS releases is āif it aināt broke donāt fix itā. MacOS 10.14 is a perfectly serviceable OS from my perspective as I have no need to support new hardware, but a vested interest in keeping the various applications I do have functioning. If anything, this little episode would seem to validate that approach. From time to time I upgrade to suit my needs, but itās never a painless experience. As someone who has to support the latest products, hardware and software, youāll have a different, equally valid, perspective.
As the announcements tells us ā¦ I know, it is easy to miss. In general though, incremental builds work 99% of the time. If they fail, check the announcement or simply delete and recreate the build directory. Note there is no reason to remove the sources because the build process does not touch anything outside this directory.
Thanks Jan. Sorry for this. I must say that I do not succeed to use Ninja with my MX Linux (Debian stable) and I do not know why. If you are a Linux user, your help will be welcome, again. But of course, I can make a fresh build directory .
In this case, simply deleting the *.qlf files will do, whether you use make or ninja. I wonder why ninja does not work? I use it on all Linux and MacOS builds. Surely works on Debian as well. The user experience is much better: it is faster and reuses the same terminal line for reporting progress, only leaving warnings and errors.
I use cmake on Debian (on a ChromeBook) - no problems.
For a complete rebuild, I do ārm -rf buildā and then run the following commands twice (cmake thinks that the first build leaves some files needing to be built a 2nd time), followed by ninja install:
Hmm. Most of that seems unneeded. Documentation and protobufs options are default. Running things twice is, AFAIK, not needed from a clean build. Surely this is not done for all the release builds. As is, the known problems are
The version stamp is not properly updated by simply running ninja after changes. Works fine if you frst run cmake .
Changes that affect the qlf format require deleting all .qlf files before the build.
Ensuring the library index files are up-to-date is not elegant. As is, we force updating them at the end of the build. That causes warnings with some build backends (but works on all).
Package dependencies are not well described, which may lead to problems when trying to use non-standard selections of packages.
Setting LANG for running the tests should not be necessary (used to be).
What goes wrong?
As is, the build is supposed to work using the following backends: ninja, Unix make, VS project files and Microsoft nmake.
What went wrong in my setup with ninja install was that it did not work like make install . With make install it seems to me that a symbolic link was created in /usr/local/bin .
By contrast, with ninja install, I get this:
root@mx:/usr/local/swipl-devel/build# ninja install
[47/48] Install the project...
-- Install configuration: "PGO"
-- Set runtime path of "/root/lib/swipl/bin/x86_64-linux/swipl" to "/root/lib/swipl/lib/x86_64-linux"
-- Set runtime path of "/root/lib/swipl/lib/x86_64-linux/libswipl.so.9.1.20" to "/root/lib/swipl/lib/x86_64-linux"
-- Set runtime path of "/root/lib/swipl/bin/x86_64-linux/swipl-ld" to "/root/lib/swipl/lib/x86_64-linux"
-- Set runtime path of "/root/lib/swipl/lib/x86_64-linux/libjpl.so" to "/root/lib/swipl/lib/x86_64-linux:/usr/lib/jvm/default-java/include:/usr/lib/jvm/default-java/include/linux:/usr/lib/jvm/default-java/lib/server"
-- Set runtime path of "/root/lib/swipl/bin/x86_64-linux/swipl-win" to "/root/lib/swipl/lib/x86_64-linux"
and as you can see, nothing is done for /usr/local/bin
Still, the problem is considered from multiple perspectives and the result is typically better than what any of the individual teams could have achieved.
But of course, I can make a fresh build directory .