swipl-devel | SWI-Prolog Main development repository

There is something really going wrong.

I have never had the swipl:xsb/nonmt_tests tests failing (whatever they are).

Is the shell variable install_under properly set when you run the above?

For example, I always install under a directory like /usr/local/logic/swipl, so here you would have to say

-DCMAKE_INSTALL_PREFIX=/usr/local/logic/swipl

or

export install_under=/usr/local/logic/

in your case (not sure whether the export is needed, it sets an environment variable).

I went through SWI Environment Control (Prolog flags). Good candidates are 'unknown' and 'report_error'. I was not able to get them to work. Try your luck. Otherwise, your only option is catch.

Basic tree expression parser with counters

Assuming a compound term representation for binary-unary trees (e.g., b(t,u(b(t,t,)))), here is a basic parser. CLP(FD) is generally recommended for reasoning over integers.

Commits in Git are connected one-way; a commit knows what its parents are and that's it. When git log or gitk display a graph, they have to start reading the graph at a certain point, a branch or tag or commit. And then they can only see the ancestors of that tag. By default, both gitk and git log work this way and start with your current commit.

But you used git log --all. This will start at every branch head and tag and display everything reachable. It'll show you every branch and every tag and all their ancestor commits.

gitk, in contrast, will work from the current commit backwards. You'll only see ancestors of the current commit. v7.4.1 is not an ancestor of the current commit, so it doesn't even know about it.

Compare apples to apples: gitk --all with git log --all and gitk with git log.

There is a branch that ends with the tag "V7.4.1" (red circle around commit df973c8). This branch has become stale as no further work has been done on it. Is this right?

This isn't a branch, it's a tag. Both branches and tags are just labels which point at a commit, but tags are not supposed to move. Tags are intended to mark a single commit, in this case the release of v7.4.1, so they will always be "stale". Don't delete them, they're there so you can find important commits.

The same branch was fed from the master branch a bit earlier (blue circle around commit 675a4049 coming after 2f745e6). I don't understand the back-and-forth diagonal lines at that point though. Why do they "overshoot"?

Branches in Git are literally branches. What you're seeing is Git drawing those branches. But it can't always fit it neatly on the screen, so sometimes they cross. It's like looking down on a highway overpass.

675a4049 is where 2f745e6 and something else further down merged.