fix: update to swipl v9.1.18

[jeswr]

fix: update to swipl v9.1.18

[jeswr]

@JanWielemaker looks like the ctests are failing again. Any idea what is causing this (see https://github.com/SWI-Prolog/npm-swipl-wasm/actions/runs/6726523064/job/18282932244)

[JanWielemaker]

Hmm. yes. That reproduces. Rather curious as nothing relevant has changes AFAIK.

[JanWielemaker]

Fixed, as it seems you discovered. What I do not really understand is why this shows up now. These bugs were all along the LibBF based big integer and rational support on 32 bit platforms. For me, ctest passes.

[jeswr]

Looks like the change you made fixes it @JanWielemaker (see #405).

Would you be able to make another patch release of SWIPL with these changes so we can release it here? This is because the build script we have for swipl-wasm builds off a given tag in swipl-devel (see

npm-swipl-wasm/docker/Dockerfile

Line 32 in b24de16

RUN git clone --depth 1 https://github.com/SWI-Prolog/swipl-devel --branch V$SWIPL_VERSION

).

[JanWielemaker]

I'm afraid the about two weekly release schema is as frequent as it gets. Otherwise we get too much overhead and confusion as there is almost daily some little thing that bothers some user on some platform. Can't you simply use the hash as version?

[JanWielemaker]

P.s. Does a hash work? If not, and the only thing you need is a tag, I am happy to add a tag, say V9.1.18-wasm to the current GIT head.

[jeswr]

I can make commit hash work. Will try and organise that later today.

It will just make the CD a bit slower.

As an aside, have you looked into using CD more on the swipl-devel repo to make the release process less burdensome over there?

[jeswr]

🎉 This PR is included in version 3.5.6 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release
• v3.5.6

Your semantic-release bot 📦🚀

[JanWielemaker]

As an aside, have you looked into using CD more on the swipl-devel repo to make the release process less burdensome over there?

The release process is pretty much automated. Source, docs, Windows binaries and Linux PPAs are all doing by calling one script. MacOS binaries are separate as Linux doesn't run the MacOS tools 😢 Then there are the website, SWISH, WASM version on the website, Linux snap, Macports, the official docker images and the announcement summary. 99% of that is scripted, so it isn't too bad. Most annoying situation happens if somewhere down the chain a port issue is found. With so many targets and configurations that is hard to completely avoid 😢 Ideally CI avoids that, but it takes a lot of resources to go through all checks for every patch.

If you think this can be significantly improved, please say so.

[jeswr]

If you think this can be significantly improved, please say so.

I've had a read through the release readme. It seems like most of it could be turned into a GitHub action that is triggered by just cutting a release in the GitHub UI - or pushing a new tag (i.e. running https://github.com/SWI-Prolog/swipl-devel/blob/master/scripts/newversion). Noting that GH actions support mac, windows and Linux environments; and that you can also use Dockerfiles in CI if needed.

Which means that all that would be left for you to do is:

1. The announcement summary which could probably also be generated from a CHANGELOG and written to the website by a bot if you really wanted.
2. Make any changes if any of the builds fail during this CD process; which as you say is the most annoying situation.

The main question is whether the time investment to do this is worth the time saved on manual releases / the opportunity to release more frequently.

Ideally CI avoids that, but it takes a lot of resources to go through all checks for every patch.

Github action tests can be run in parallel; so it should be quite feasable to build and run all of the different configurations in https://github.com/SWI-Prolog/swipl-devel/blob/master/scripts/make-distribution in CI without slowing down the time it takes CI to run.

[JanWielemaker]

Thanks. Good to know. Note that the ChangeLog on the website is done automatically. The same script generates the announcement except that I add a summary with some highlights and sometimes some warnings or uncouragements to update.

Failing builds is typically not when creating the binary releases for MacOS and Windows. Anyway, that takes just a few minutes on my hardware. Problems tend to come from submitting the PPA to be build on older and newer versions of Ubuntu than my dev machine, update the Prolog version that runs the website that also runs on another Ubuntu version and failures in e.g. Macports, MSYS2, the npm versions, etc.

Github action tests can be run in parallel

That is not the main issue. The issue is that the current CI build on GitHub takes about 5 min. Adding a platform adds another 5min, etc. There are a lot of platforms with different versions of the dependencies, using different compilers and different setups for SWI-Prolog (default, single threaded. without LibGMP, minimal setup, ...) We would quickly run out of the free CPU usage for GH. And even if that was not an issue it is probably not worth the energy consumption ...

[JanWielemaker]

P.s. if it is possible to add a CI that builds and tests the WASM version on each update, that might be worthwhile. The build time is fairly limited and the version does just about anything different than the default Linux build (single threaded, Clang based, 32-bits, LibBF bignums, statically linked extensions). Please make a PR if you know how to do that.