I’m attempting to see if a problem I have has been solved in a later SWI. This is part of a process to restore my project to a stable state. (It was seen to be not working with the newest SWI, and so I went back to 8.1.13, but now there’s other problems which I’ve never had before. It’s a mess.)
So I need to read over the list of bug fixes, improvements across versions, and I cannot find such a document in the install nor the website.
But it is easier to use git on the command line maybe if you want to only look at certain things like “FIXED” and so on.
Git bisect if you need to figure out when exactly something broke for you.
I do not understand. I want a text file. The link shows zip and tar.gz. Bisect I can’t use because I do not have a working version, and don’t know if my software has to change or SWI or both. I have no idea how to use the git command line to get FIXED lists.
If you click on the release tag then on “commits” you get for example here: Comparing V8.3.20...master · SWI-Prolog/swipl-devel · GitHub
Click around github, it has some tools for comparing between tags and commits and so on. Or use git, possibly with one of the gui clients?
That github link proves useful. thank you.
Do you mean this?
Is the malfunction by any chance something to do with modules? I had some code that (ab)used modules and that code broke after I updated to 8.2.1 and then again to 8.3.14.
I still don’t know. I obtained a working version, and am still using that as I fix other bugs. When I get it all in order I will attempt to update and then I’ll know what is at issue.
P.S. Abused modules? That hinting scares me a bit. I know there’s a theory of modules that anything not exported is supposed to be private, but I never used modules in that way.
For me, modules were simply a namespace thing. I force myself to qualify rarely used predicates with a module name, so I can know immediately from looking at the code what sort of module is involved in this function. I don’t want to export that predicate because (a) I don’t plan sharing in that way, and (b) doing so pollutes the global namespace in ways I prefer to avoid.
So is this abusing modules, and will my code start to break?
Modules work as they work. It is quite unlikely that they disappear or change in a way that would break more than corner cases. I typically do not use cross-module calls unless for emulating some primitive kind of “object orientedness”. The main contract from a module I want is to be able to change anything inside without having to worry that anything outside the module breaks. If you use it the way you seem to be using it you can use public/1 declarations to tell the system that calls may come from anywhere. The declaration has no semantic effect. It only affects highlighting and tells the cross-referencer to not consider this as a predicate that is not called.
Nah, I was just trying to hack the module system to do something it was probably not meant to be doing. I think you’ll be fine.