What changed in library(macros)

Help! Pack
1

I’ve been using a few simple macros - starting in 9.2.9. After recently switching to 1.0.2 and changing nothing in my own code, all the sudden I cannot for the life of me get any (#define/#import) macros to work. I’m currently on a different pc, but when I do the #import(module) line, I get an error $guard-something implying I didn’t define any macros.

No matter how many macros I insert in various files and no matter how frequently I try to use_module(library(macros)) in all files, it makes no difference. Even having just a single simple constant (like #define(xx, 12)) doesn’t work. Did I miss some memo?

2

Not much changed AFAIK. We use them in a project in actual production code and all still works fine. Tried this:

defs.pl (86 Bytes)
usedefs.pl (154 Bytes)

swipl usedefs.pl
...
101 ?- test.
The answer is 42
true.

So, please share code to reproduce.

3

Thanks - I’ll try out your files tonight at home, and see if I can potentially post a simplified sample of my own situation. The setup is a bit intricate, as I load one prolog file from foreign code. This file in turn use_module’s the macros library, imports the macros and consults subsequent prolog files hat also import the same macros. All files (even the initial one) complain, so I wonder if I’m missing something in the foreign setup!?

4

Your files worked as expected, and my own still failed, so I chose to try anything. I prefer to name my files .prolog to be clear and avoid the Perl confusion. So, I renamed my file .pl, and suddenly everything worked like back in the 9.2.9 days.

5

Interesting. .prolog files are still recognised. Can you create a reproducing example?

6

I was only allowed to upload .c and .pl files, so the two latter must be renamed to .prolog files first. When I put these three files in the same folder, compile the .c file and run the result I get:

ERROR: /home/user/repro/kickstart.prolog:2:
ERROR: macros:define_macro/2: Procedure macros:define_macro/2 failed after $-guard in caller

… and when I rename back to .pl it works.

diamondbox.c (836 Bytes)

kickstart.pl (96 Bytes)

diamondbox.pl (56 Bytes)

7

Thanks. That reproduced. After about 2 hours I managed to isolate it from the C code and partly from the macro code, but then I got stuck. I think it is time to cry … after explaining what I already discovered, Claude code nailed it in a few minutes …

Fixed with FIXED: absolute_file_name/3 to enumerate all solutions while loading … · SWI-Prolog/swipl-devel@a26ae37 · GitHub. If you compiled from source, you can apply this to your old version or you can switch to the GIT of the development version (or use .pl files :slight_smile: )

The 10.0 series will not get any further patches (unless a serious security issue pops up). The plan is to start a new stable/development cycle not too long from now.

8

Thanks for noting this.

I have added .prolog to the list of file types that can be uploaded by anyone with permission to upload files.

9

… I definitely recognize the ai experience! :slight_smile: Thanks for fixing so quickly - I might just add this one as a temporary patch for freebsd until swipl 11.X comes out.

10

It will be 10.2.0 :slight_smile: That said, the release numbering as major.minor.patch does not really satisfy SWI-Prolog. Surely the “patch” level of the development series is in reality mostly “minor”. The patch level of the stable series is ok though, but a new stable/devel cycle is more a major update is it typically both comes with incompatible changes and extended new functionality.

11

The file extension quirk is interesting given your foreign code is loading the initial file. Wonder if 1.0.2 tightened module path resolution? Could explain why the extension matters now.