tfeb / tfeb-lisp-hax Goto Github PK

Building with SBCL 2.2.7.28-02bc916fd / ASDF 3.3.5 for quicklisp dist creation.

Trying to build commit id 65e7379

org.tfeb.hax.metatronic fails to build with the following error:

Unhandled UNBOUND-VARIABLE in thread #<SB-THREAD:THREAD "main thread" RUNNING {10016D0003}>: The variable ORG.TFEB.TOOLS.REQUIRE-MODULE::*MODULE-PATH-DESCRIPTIONS* is unbound.

org.tfeb.hax.simple-loops fails to build with the following error:

Unhandled UNBOUND-VARIABLE in thread #<SB-THREAD:THREAD "main thread" RUNNING {10016D0003}>: The variable ORG.TFEB.TOOLS.REQUIRE-MODULE::*MODULE-PATH-DESCRIPTIONS* is unbound.

org.tfeb.hax.slog fails to build with the following error:

Unhandled UNBOUND-VARIABLE in thread #<SB-THREAD:THREAD "main thread" RUNNING {10016D0003}>: The variable ORG.TFEB.TOOLS.REQUIRE-MODULE::*MODULE-PATH-DESCRIPTIONS* is unbound.

org.tfeb.hax.spam fails to build with the following error:

Unhandled UNBOUND-VARIABLE in thread #<SB-THREAD:THREAD "main thread" RUNNING {10016D0003}>: The variable ORG.TFEB.TOOLS.REQUIRE-MODULE::*MODULE-PATH-DESCRIPTIONS* is unbound.

org.tfeb.hax.utilities fails to build with the following error:

Unhandled UNBOUND-VARIABLE in thread #<SB-THREAD:THREAD "main thread" RUNNING {10016D0003}>: The variable ORG.TFEB.TOOLS.REQUIRE-MODULE::*MODULE-PATH-DESCRIPTIONS* is unbound.

org.tfeb.hax fails to build with the following error:

Unhandled UNBOUND-VARIABLE in thread #<SB-THREAD:THREAD "main thread" RUNNING {10016D0003}>: The variable ORG.TFEB.TOOLS.REQUIRE-MODULE::*MODULE-PATH-DESCRIPTIONS* is unbound.

org.tfeb.hax/test fails to build with the following error:

Unhandled UNBOUND-VARIABLE in thread #<SB-THREAD:THREAD "main thread" RUNNING {10016D0003}>: The variable ORG.TFEB.TOOLS.REQUIRE-MODULE::*MODULE-PATH-DESCRIPTIONS* is unbound.

Full log here

Building with SBCL 2.2.0.166-863804f68 / ASDF 3.3.5 for quicklisp dist creation.

Trying to build commit id d7fdde9

org.tfeb.hax/test fails to build with the following error:

Unhandled SB-INT:SIMPLE-FILE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {1001B98003}>: Failed to find the TRUENAME of /home/quicklisp/quicklisp-controller/dist/build-cache/tfeb-lisp-hax/3a6caaf23dc4c98b4985540fc1be70c369bcd587/tfeb-lisp-hax-20220129-git/test/test-collecting.lisp: No such file or directory

Full log here

Building with SBCL 2.2.7.28-02bc916fd / ASDF 3.3.5 for quicklisp dist creation.

Trying to build commit id aed0708

org.tfeb.hax/test fails to build with the following error:

Unhandled SB-INT:SIMPLE-FILE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {10016C8003}>: Failed to find the TRUENAME of /home/quicklisp/quicklisp-controller/dist/build-cache/tfeb-lisp-hax/c338cd6f0fc3aedfcca35cbd77656413f2485b88/tfeb-lisp-hax-20220926-git/test/test-simple-loops.lisp: No such file or directory

Full log here

In the documentation for slog, it is stated explicitly that the process's working directory is used for log files, and that the portable fallback (make-pathname :name nil :type nil :version nil :defaults *default-pathname-defaults*) is almost certainly wrong.

However, this means that the method slog uses to resolve relative pathnames is different from the method used by all functions defined in the CL standard, which are defined to merge all pathnames with *default-pathname-defaults* before filesystem access (additionally, setting certain components of *default-pathname-defaults* to nil before performing merging is not in the specification, should generally be unnecessary, and further deviates from the standard procedure).

In the standard, it is stated that *default-pathname-defaults* is "typically in the working directory that was current when Common Lisp was started up", so in general the behaviour of slog would not change for most programs if the merging was done with respect to *default-pathname-defaults*, unless they change their working directory with chdir without also updating *default-pathname-defaults* (which is somewhat of an unusual thing to do, in my opinion, and also makes the standard functions behave in a surprising way and so is generally avoided), and may be surprising if, for instance, a user binds *default-pathname-defaults* lexically and expects files which were being placed in the current directory to be placed elsewhere.

Additionally, the pathname canonicalization function should probably call translate-logical-pathname on the input before merging. This allows using logical pathnames, which could be very useful for logging (e.g. a client could define a logical pathname host called log, set to the platform-appropriate logging location, and then specify its log-file paths as log:foo.log log:bar;baz.log etc.), and also lines up better with the behaviour of open and other standard filesystem functions, which also perform logical pathname translations.

I am willing to create a pull request implementing these behaviours, if desired; I submitted an issue first to gauge opinion on this.

EDIT: actually, it is possible to use logical pathnames in the current state; the issue is that, without translating them, a logical pathname will have a different stream than its equivalent, translated, physical pathname, as follows:

CL-USER> (setf (logical-pathname-translations "log") '(("**;*.*.*" "/var/log/**/")))
(("**;*.*.*" "/var/log/**/"))
CL-USER> (org.tfeb.hax.slog:slog-to "log:foo;bar.log" "test1")
#<ORG.TFEB.HAX.SLOG:SIMPLE-LOG-ENTRY "test1" {10081F14A3}>
CL-USER> (org.tfeb.hax.slog:slog-to "/var/log/foo/bar.log" "test2~%")
#<ORG.TFEB.HAX.SLOG:SIMPLE-LOG-ENTRY "test2~%" {100820A1D3}>
CL-USER> (org.tfeb.hax.slog:flush-open-log-file-streams)
(#P"/var/log/foo/bar.log" #P"LOG:FOO;BAR.LOG")

Note that in this example "/var/log/foo/bar.log" and "log:foo;bar.log" point to the same file.