I think it is about time to start considering SWI-Prolog 8.2. Version 8.0.3 is getting close to a year old and rusty. Due to various reasons large and dangerous rewrites have calmed down for now. Originally I wanted tabling to be mature and fast. At the moment it is quite close to mature, certainly more mature than in 8.0, but not yet fast. I think this project should be moved to 8.3.x. Likewise a rewrite of term/goal expansion and source code layout handling. Planned steps before 8.2:
The SSL interface suffers from memory leaks since change in certificate handling.
Complete the autoload/1,2 support in all default packages.
I think this is a great idea, especially to give more exposure to tabling which is much better now.
Many distributions only pick the stable version and I think it is a good idea to update it as often as it is reasonable to do so. Thanks for the great work you have done since 8.0.3!!
Hi Jan,
Just an info before building stable version 8.2
I occasionally use pack(real) and when I tryed to install swipl swipl-8.1.27-1.x64.exe , pack(real) was no more working (windows10).
Running āfor_realā example caused swi to crash.
reverting to swi 8.1.21 (my previous last update) make it work again.
If I remeber well, same problem occured a couple of months ago.
Thank you for the great work.
Best regards
JAcques
Unfortunately foreign languages extension binary compatibility was broken in this development cycle. That was the price to pay for first class rational numbers.
There is little that can be done. Packages that include binaries must include these for the old and new versions of SWI-Prolog. A stable 8.2 could be used to update the binaries and tell anyone wishing to use these packs to upgrade to 8.2.
Yes, please have a look into an error message under Windows which pops up if there are discontiguous predicates. I see it here on 32-Bit, but I think 64-Bit is affected, as well.
Reproduce:
a.
b.
a.
And then Ctrl-C Ctrl-B.
The error message says: Type error, text expected, found ansi(code, ā~pā, [a/0]). (a compound)
(instead of the warning of ādiscontiguousā predicates)
It may be a small thing, but given that Annie is starting a course with a lot of beginners, removal of this misleading error message might substantially reduce dropout
These are bugs and bugs should be addressed before the next stable (within reason of course). Actually this bug was fully platform independent. Fixed. Thanks for reporting.
Can a pengine have a different default locale than the shell that was used to start a web server? This is somehow related to User Awareness of a Prolog System , whereby I have spun the idea further and am now introducing more flags which I had previously elsewhere.
Is there an API to finger pengine properties? I find pengine_property/2. Is it also possible to set them or modify them at runtime? Looks that the current pengine properties rather reflect some essential immutable properties that are already given to the pengine during creation.
If a pengine had a locale property, one could have an āEnglishā pengine and a āGermanā pengine inside the same web server. A lot of prolog flags are somehow candidate to be lifted on the niveau of pengines, unless pengines are explicitly more lightweight.
But somehow actors could be the more lightweight alternative, and pengines would be more on the level of a broker. But in my current design this is decoupled its more about the context that also determines where Prolog text and modules are stored.
No. As is, C support for thread-specific locale handling is not widely available AFAIK. If it was easy I would add it, but I fear it is a (portability) can of worms That waits for someone with resources to make it possible.
Most of the other properties are thread properties. Manipulating them is typically done using Prolog flags which are thread-specific (and inherited from the creating thread). What you are allowed to change depends on the sandbox restrictions.
Dunno if itās been mentioned, but SWI-Prologās (and XSBās and ECLiPSeās) implementation of attributed variables omits pre_unify, which SICStus Prolog has ā¦ this is not an issue for me now, but I remember the lack of pre_unify causing me trouble in the past although Iāve forgotten the details. (How widespread a problem is this? - I donāt know)
Arbitrary precision floats are definitely not on the 8.2 track. I havenāt seen demand for it anyway, so I guess this waits for someone with a need for it that is strong enough to make it possible.
There was an issue looking at thatā¦looks like it took a long while and ended up being a lot more trouble than it was worth (plus, as Jan said, it was part of a fairly contentious issue between some community members >_<).
How about a package/1 directive? It would make explicit inside the Prolog code, what is somehow implicit through the directory structure and search paths. Example we have this declaration:
But its usually used as use_module(library(http/http_server)). I came up with the idea of package/1 directive for my system inspired from Java. I am still exploring its benefits and upcoming release might give some improvements. One would then write:
New Approach:
:- package(http).
:- module(http_server,
I also read the Ciao Prolog has something. At least they are talking about bundling modules here. But I didnāt check whether Ciao Prolog has a package/1 directive. My proposal is not to be confused with SWI-Prolog packs, which is again on another level.
That waits for someone with resources to make it possible.