From ...
From: Erik Naggum <erik@naggum.no>
Subject: Re: Logical pathname hosts.
Date: 1998/12/24
Message-ID: <3123471323156503@naggum.no>#1/1
X-Deja-AN: 425436237
References: <75k4tr$uom$1@nnrp1.dejanews.com> <3123192188393170@naggum.no> <75l1qu$lum$1@nnrp1.dejanews.com> <4nhfupr3c7.fsf@rtp.ericsson.se> <3123281615303079@naggum.no> <4nbtkwqndm.fsf@rtp.ericsson.se> <3123422807290302@naggum.no> <4n3e66r8ik.fsf@rtp.ericsson.se>
mail-copies-to: never
Organization: Naggum Software; +47 8800 8879; http://www.naggum.no
Newsgroups: comp.lang.lisp

* Raymond Toy <toy@rtp.ericsson.se>
| Which test case are we talking about here?

  sigh.  you need to look up the meaning of relative and absolute logical
  pathnames in the specification.  you clearly do not understand this, yet
  you assume you do.  that is _bad_ karma.

  "host:name.type" is an absolute logical pathname namestring.  an absolute
  logical pathname's directory component is (:ABSOLUTE).  "host:;name.type"
  is a relative logical pathname namestring.  a logical pathname's
  directory component is either NIL or (:RELATIVE).  THIS IS OPPOSITE OF
  PHYSICAL PATHNAME NAMESTRINGS under Unix, where "foo.bar" should have a
  directory component of NIL or (:RELATIVE) when parsed, and "/foo.bar"
  should have a directory component of (:ABSOLUTE) when parsed.

  the specification of logical pathname namestring syntax is very clear.  I
  cannot fathom how you could begin to patch and hack on CMUCL without even
  reading it.

| Are you saying the logical pathname "demo:foo.lisp" gets mapped to a
| physical pathname relative to the current directory?

  "demo:foo.lisp" is an _absolute_ logical pathname.  pay attention!

| I suppose that would be true if (logical-pathname-translations "demo")
| was '((";**;*.*.*" "./")), but isn't that what the translation says to do?

  huh?  the whole point of logical pathnames is to remove the dependencies
  on locations in the file systems.  using the current working directory as
  the target of a logical pathname translation is just really stupid.

  I installed cmucl_2.4.5 on my Debian system, and this trial run shows the
  pathological¹ case, somewhat abbreviated to reduce CMUCL's overly chatty
  error-reporting:

CMU Common Lisp 18a+ release x86-linux 2.4.5 29 June 1998 cvs, running on sourcery

* (setf (logical-pathname-translations "DEMO")
'(("**;*.*" "/tmp/") (";**;*.*" "/tmp/foo/")))

(("**;*.*" "/tmp/") (";**;*.*" "/tmp/foo/"))
* (translate-logical-pathname #p"demo:x")

File-error in function TRANSLATE-LOGICAL-PATHNAME:
   No translation for #.(logical-pathname "DEMO:X")
* (translate-logical-pathname #p"demo:;x")

#p"tmp/foo/x"
* (translate-logical-pathname #p"demo:foo;x")

#p"/tmp/x"

  please note how insanely useless the translation of #p"demo:;x" is.

| Anyway, I've sent a patch which makes CMUCL behave in the same way as
| ACL for the original question.

  this is not comforting.  this is why I want to argue with people who may
  know better than me and who have real, economic concerns about making
  changes to their code before something is admitted into an implementation.

  you have not heeded my warnings that what I have shown you is not ACL 5.0
  behavior, it's the behavior of _my_patched_ ACL 5.0, because I think I
  got it right after spending a _lot_ of time on this shit, and there are
  a few minor issues in ACL 5.0 that don't rhyme with what I think, and I
  went ahead and made it make sense according to my understanding of the
  standard.  it is _not_ a resolved set of issues at Franz Inc, and they
  are understandably reluctant to make changes that will affect customer
  applications.  I really wish more "free" software was as cautious.  (this
  appears to contradict my desire to see fully conforming implementations,
  but getting there involves changes, and changes involve investments.)

  _I_ think you have just rebugged CMUCL's logical pathname handling.

#:Erik
-------
¹ "ersatz", anyone?  (honk if you get the reference! :)
-- 
  Nie wieder KrF!  Nie wieder KrF!  Nie wieder KrF!  Nie wieder KrF!