I have been grappling with my inability to upgrade clisp, and find myself confused by the following events in my transcript:
[17]> (uiop/pathname:ensure-pathname "home:lisp;asdf;") #P"home:lisp;asdf;" [18]> (probe-file (merge-pathnames (uiop/pathname:ensure-pathname "home:lisp;asdf;") "asdf.asd")) NIL [19]> (translate-logical-pathname "home:lisp;asdf;asdf.asd") #P"/Users/rpg/lisp/asdf/asdf.asd" [20]> (probe-file (translate-logical-pathname "home:lisp;asdf;asdf.asd")) #P"/Users/rpg/lisp/asdf/asdf.asd" [21]> (probe-file (merge-pathnames (translate-logical-pathname "home:lisp;asdf;") "asdf.asd")) #P"/Users/rpg/lisp/asdf/asdf.asd"
Am I for some reasonnot to expect that the standard pathname functions (e.g., merge-pathnames) will work with logical pathnames?
The online clisp manual page discussing LOGICAL PATHNAMES says only:
"No notes."
http://www.clisp.org/impnotes/log-path.html
But as I understand the CLHS on MERGE-PATHNAMES, with reference to the definition of "pathname designator", the above behavior seems to be non-conforming.
I am not at all experienced with clisp, and find myself on strange and shaky ground here.
thanks, r
On Sun, Feb 2, 2014 at 7:38 PM, Robert P. Goldman rpgoldman@sift.info wrote:
I have been grappling with my inability to upgrade clisp, and find myself confused by the following events in my transcript:
[17]> (uiop/pathname:ensure-pathname "home:lisp;asdf;") #P"home:lisp;asdf;"
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
(Also, most of the time that you use MERGE-PATHNAMES, you should probably instead be using UIOP:MERGE-PATHNAMES* or UIOP:SUBPATHNAME.)
I am not at all experienced with clisp, and find myself on strange and shaky ground here.
CLHS pathnames are strange and shaky. UIOP tries to paper over the issues, making them notably less shaky and the price of being a bit stranger.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org First they ignore you. Then they laugh at you. Then they fight you. Then you win. — Gandhi
Faré fahree@gmail.com writes:
On Sun, Feb 2, 2014 at 7:38 PM, Robert P. Goldman rpgoldman@sift.info wrote:
I have been grappling with my inability to upgrade clisp, and find myself confused by the following events in my transcript:
[17]> (uiop/pathname:ensure-pathname "home:lisp;asdf;") #P"home:lisp;asdf;"
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
(Also, most of the time that you use MERGE-PATHNAMES, you should probably instead be using UIOP:MERGE-PATHNAMES* or UIOP:SUBPATHNAME.)
I am not at all experienced with clisp, and find myself on strange and shaky ground here.
CLHS pathnames are strange and shaky. UIOP tries to paper over the issues, making them notably less shaky and the price of being a bit stranger.
there's also a difference between clisp -ansi and clisp without -ansi.
You can also test by setting or resetting custom:*ansi* (a symbol macro, use ext:letf if you want to change it temporarily).
I always use clisp with -ansi,
On Mon, Feb 3, 2014 at 1:40 PM, Pascal J. Bourguignon pjb@informatimago.com wrote:
Faré fahree@gmail.com writes:
On Sun, Feb 2, 2014 at 7:38 PM, Robert P. Goldman rpgoldman@sift.info wrote:
I have been grappling with my inability to upgrade clisp, and find myself confused by the following events in my transcript:
[17]> (uiop/pathname:ensure-pathname "home:lisp;asdf;") #P"home:lisp;asdf;"
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
(Also, most of the time that you use MERGE-PATHNAMES, you should probably instead be using UIOP:MERGE-PATHNAMES* or UIOP:SUBPATHNAME.)
I am not at all experienced with clisp, and find myself on strange and shaky ground here.
CLHS pathnames are strange and shaky. UIOP tries to paper over the issues, making them notably less shaky and the price of being a bit stranger.
there's also a difference between clisp -ansi and clisp without -ansi.
You can also test by setting or resetting custom:*ansi* (a symbol macro, use ext:letf if you want to change it temporarily).
I always use clisp with -ansi,
Indeed, I find that my Ubuntu-provided CLISP binary has custom:*ansi* nil by default, whereas my self-compiled one has it being T by default, and that both fail to parse the logical namestring in -traditional mode and succeed in -ansi mode.
I also note that test/run-tests.sh does explicitly specify -ansi as a flag when running tests.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You don't have to like everything about me, but if you don't love me the way I am, it's not me you love, only some fantasy of yours.
Faré wrote:
On Sun, Feb 2, 2014 at 7:38 PM, Robert P. Goldman rpgoldman@sift.info wrote:
I have been grappling with my inability to upgrade clisp, and find myself confused by the following events in my transcript:
[17]> (uiop/pathname:ensure-pathname "home:lisp;asdf;") #P"home:lisp;asdf;"
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;"
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.
Here's the magic:
[12]> (describe (parse-namestring "lisp;asdf;" "home"))
#S(LOGICAL-PATHNAME :HOST "HOME" :DEVICE :UNSPECIFIC :DIRECTORY (:ABSOLUTE "LISP" "ASDF") :NAME NIL :TYPE NIL :VERSION NIL) is a portable pathname, with the following components: HOST = "HOME" DIRECTORY = (:ABSOLUTE "LISP" "ASDF")
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.
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...
cheers, r
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.
Faré wrote:
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.
If I pass the :lisp value to the NAMESTRING, ENSURE-PATHNAME *does* call PARSE-NAMESTRING.
Yes, looking at the spec for PARSE-NAMESTRING, this is a bug:
"If host is nil and thing is a syntactically valid logical pathname namestring containing an explicit host, then it is parsed as a logical pathname namestring."
So this is a clisp fail, 2.49 on Mac OS X (from Mac Ports).
If it works for you, perhaps this has already been fixed. I don't have time to build and run clisp from the repo.
If I pass the :lisp value to the NAMESTRING, ENSURE-PATHNAME *does* call PARSE-NAMESTRING.
Yes, looking at the spec for PARSE-NAMESTRING, this is a bug:
"If host is nil and thing is a syntactically valid logical pathname namestring containing an explicit host, then it is parsed as a logical pathname namestring."
So this is a clisp fail, 2.49 on Mac OS X (from Mac Ports).
If it works for you, perhaps this has already been fixed. I don't have time to build and run clisp from the repo.
I confirm that the bug is present in the CLISP package provided by Ubuntu 12.04.4 LTS, and not present in the CLISP binary I compiled from the most recent hg. So it must be a relatively recent bug fix.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Failure is not an option. It comes bundled with your Microsoft product. — Ferenc Mantfeld