[asdf-devel] clisp, logical pathnames, and ASDF

[Faré]

>> BEWARE!
>> ENSURE-PATHNAME uses PARSE-UNIX-NAMESTRING, not PARSE-NAMESTRING.
>> In this case, you want PARSE-NAMESTRING (possibly through PATHNAME).
>>
>> (describe (uiop/pathname:ensure-pathname "home:lisp;asdf;"))
>>
>> #P"home:lisp;asdf;" is a pathname, with the following components:
>> NAME = "home:lisp;asdf;"
>> VERSION = :NEWEST
>
> Thanks.  But isn't this a bug:
>
>  (uiop/pathname:ensure-pathname "home:lisp;asdf;" :namestring :lisp)
> #P"home:lisp;asdf;"
> [10]> (describe *)
>
> #P"home:lisp;asdf;" is a pathname, with the following components:
> NAME = "home:lisp;asdf;"
>
That looks like a bug indeed, but after I
(setf (logical-pathname-translations "home") '(("**;*.*"
#p"/home/tunes/**/*.*")))

it's working for me:
(describe (uiop/pathname:ensure-pathname "home:lisp;asdf;" :namestring :lisp))

#P"HOME:LISP;ASDF;" is a portable pathname, with the following components:
HOST = "HOME"
DIRECTORY = (:ABSOLUTE "LISP" "ASDF")

It seems to me that either probe-asd or sysdef-central-registry-search
before it calls probe-asd should indeed call ensure-pathname somehow
and fails to, and that that's the problem.

> Here I have explicitly told UIOP & clisp that the namestring is a LISP
> namestring, so it should see this as a valid logical-pathname, not
> garble the logical pathname into a PATHNAME's name field.
>
That sounds like a bug indeed; however, it doesn't happen on my recent
checkout of CLISP (on Linux x64, but I suppose this part of the clisp
code is portable.)

> This seems to have to do with an oddity (I suspect it's conforming,
> strictly speaking, but it's awkward at best, and impossible at worst) in
> clisp's interpretation of PARSE-NAMESTRING for logical pathnames.
>
If parse-namestring was called, it's probably not conforming to not
parse the : as a host separator. If parse-namestring was not called,
it's a bug in ASDF and/or UIOP, and trace will hopefully tell you as
much.

> I have absolutely no idea how to preserve usefulness of logical
> pathnames on clisp, since it looks like I would have to do a lot of
> horrible mess to try ripping colon-postfixed substrings off everything
> that might be a logical pathname, before feeding it to PARSE-NAMESTRING.
>
> I suppose if ENSURE-PATHNAME is a bottleneck, I could try that there,
> wrapping some error-handling around a check...
>
Sometimes, you have to concede defeat and move on. Certainly if some
old (or new) version of CLISP doesn't parse logical-pathnames
properly, that's a bug that should be reported and then we'd move on.

IIRC, there was also a bug whereby #p"foo:" was parsed improperly for
logical pathnames on Allegro (should be absolute, was relative); in
this case, I had a workaround (see uiop:pathname-root and other
horrors), so I just issued the bug report and moved on.

In general, logical pathnames were HELL to support, for little or no
benefit. (With maybe a handful users in the whole world.) I recommend
eschewing them completely. After breaking their support a few times,
there are now regression tests, though, that you might want to extend
to include some basic parsing.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Obama's economic policies will be so remembered that he'll be the president
picked for the face on the hundred trillion dollar bill.