#677 logical pathnames and letter case gone wrong

[François-René Rideau]

While running ASDF 3.1.5.14's test suite, a logical pathname test fails, because of an interaction between logical pathnames and the case of alphabetical characters in the pathname name.

You may reproduce with:
make t l=clisp t=test-logical-pathname.script

I have no time to investigate right now, but if and when a CLISP maintainer is interested in fixing the issue, I will be happy to dig further.

[Sam Steingold]

please supply a reproducible test case.
thanks

[François-René Rideau]

I carefully wrote a response, and sourceforge looks like it ate it. Sigh.

1- logical pathnames are not parsed correctly. If you (setf (logical-pathname-translations "ASDF") ...) clisp won't parse #p"ASDF:foo" correctly. translate-pathname works on strings but not on (already incorrectly parsed) pathnames.

2- even when synthesizing logical pathnames using make-pathname-logical, things go weird. The test case above in test-logical-pathname has compile-file go all confused between case-preservation and downcasing of logical pathnames. I'll try harder to isolate the issue if you want.

3- Another issue I don't quite remember the details of was causing segfaults with clisp. Filed separately as #678.

[François-René Rideau]

Regarding point 1-, I of course meant translate-logical-pathname, not translate-pathname (that seems to work fine AFAICT).

[François-René Rideau]

Wow, in my scripts #p"ASDF:test;" is parsed correctly, but not at the SLIME command-line. WTF?

[François-René Rideau]

Regarding #2, here are

(COMPILE-FILE '#P"ASDF:TEST;LOGICAL-FILE.LISP.NEWEST" ':OUTPUT-FILE
 '#P"/home/fare/cl/asdf/build/fasls/clisp-2.49+-unix-x64/test/LOGICAL-FILE-tmp6VZ4HMJW.fas"
 ':EXTERNAL-FORMAT '#<ENCODING CHARSET:UTF-8 :UNIX>)
;; Compiling file ASDF:TEST;LOGICAL-FILE.LISP.NEWEST ...
;; Wrote file ASDF:TEST;LOGICAL-FILE-tmp6VZ4HMJW.fas.NEWEST

2. Trace: COMPILE-FILE ==> #P"/home/fare/cl/asdf/build/fasls/clisp-2.49+-unix-x64/test/logical-file-tmp6vz4hmjw.fas", NIL, NIL
2. Trace: 
(RENAME-FILE-OVERWRITING-TARGET
 '#P"/home/fare/cl/asdf/build/fasls/clisp-2.49+-unix-x64/test/LOGICAL-FILE-tmp6VZ4HMJW.lib"
 '#P"ASDF:TEST;LOGICAL-FILE.lib.NEWEST")
TEST ABORTED: 
OPEN: File #P"/home/fare/cl/asdf/build/fasls/clisp-2.49+-unix-x64/test/LOGICAL-FILE-tmp6VZ4HMJW.lib" does not exist

So, apparently, the fact the source pathname is logical somehow leaks into the output-file and leads to downcasing it, even though the explicitly provided :output-file is physical. Indeed it looks like the pathname name and type of :output-files are merged into the source file, but the pathname directory is dropped. This is unlike what happens when the source is a physical pathname, and the pathname directory is kept.

I can see a workaround: don't trust clisp to fully heed the :output-file argument, and instead look at the output-truename result from compile-file, and also deduce the .lib path from that. I'll push that workaround to ASDF 3.1.7.8. It's still a clisp bug.

[François-René Rideau]

Regarding 1- I found out why my script could parse logical pathnames but not my SLIME REPL: I was not using the -ansi flag of clisp when invoking SLIME, but a shell alias was adding it at the shell REPL.

[Sam Steingold]

regarding 1 - see it might be related to *PARSE-NAMESTRING-ANSI*.

[Sam Steingold]

regarding 2 - I did not examing the report in details, but I think the issue might be that input and output are actually merged and thus may result in a logical pathname.
as usual, the most useful bug report should contain a reproducible test case
thanks

[François-René Rideau]

Regarding 2, the merging seems to go wrong:

• The directory seems to be wholly taken from the logical pathname source rather than from the absolute or relative pathname output-file. Thisi is very unlike the merging that happens when the source is a physical pathname.
• The host is taken from the logical pathname. This is probably bad, yet at the same time, if you're using anything like merge-pathnames, this is the sad result of physical pathnames having a NIL host and that leading to the logical host "winning".
• This very anti-useful behavior of merge-pathnames is why I wrote uiop:merge-pathnames.

[Sam Steingold]

again, where is the test case?

1. what is the definition of the logical host "ASDF"?
2. please supply the call to compile-file-pathname
   thanks

[François-René Rideau]

1. The definition of the host doesn't seem to matter. See example.
2. Duh. Attached.
3. Maybe the solution is to always translate-logical-pathname on CLISP before calling compile-file; it doesn't look like you save the original (logical) pathname in debugging information, anyway, do you?

[François-René Rideau]

For the record, this is the call that returns fishy results:

(COMPILE-FILE-PATHNAME #P"BUG:TEST;FILE.LISP" :OUTPUT-FILE "/tmp/Bug677/file-TEMP01.fas") #P"BUG:TEST;file-TEMP01.fas.NEWEST"

#P"BUG:TEST;file-TEMP01.fas.NEWEST" is a portable pathname, with the following components:
HOST = "BUG"
DIRECTORY = (:ABSOLUTE "TEST")
NAME = "file-TEMP01"
TYPE = "fas"
VERSION = :NEWEST

[François-René Rideau]

Final note: it is probably a bad thing to call logical pathnames "portable pathnames". In my experience, logical pathnames are the least portable feature of Common Lisp.

[Sam Steingold]

"portable pathnames" refers to object portability across platforms, not functionality portability across implementations

[François-René Rideau]

Thanks a lot for the fix! I looked at it, it works, but it's slightly subtle and might deserve being documented.