Re: [Sbcl-devel] Re: Dan's last two messages

[Daniel B. <da...@te...>]

William Harold Newman <wil...@ai...> writes:

> Daniel Barlow wrote:
> 
> > My experience has been that it's generally better not to develop on a
> > branch if it's avoidable - use the HEAD for developing and the

[ if anyone else was wondering where this message came from, I
accidentally sent it direct to WHN instead of following up to the list.
There wasn't much of interest in it that he didn't quote, so don't
feel like you've missed anything ]

>                                                               unless
>       I'm even more confused than before, you didn't remove the test,
>       I did.

Haha!  OK ...

> Hmm, I did wonder whether the special treatment of "" was needed. (I
> was pretty sure it had been needed some time in the evolutionary past,
> but a quick check didn't spot any places where it was obviously needed
> now.) Now I know. And I fully agree that the correct way to deal with
> it is to fix the caller, so I'll take a shot at that before trying
> to rebuild the system with itself.

Some thoughts:

(1) CLHS "19.2.3 Merging Pathnames" says

  Except as explicitly specified otherwise, for functions that
  manipulate or inquire about files in the file system, the pathname
  argument to such a function is merged with
  *default-pathname-defaults* before accessing the file system (as if
  by merge-pathnames).

ENSURE-DIRECTORIES-EXIST doesn't do this, yet it accesses the file
system, so arguably it should

(2) this doesn't actually help much as *default-pathname-defaults* is
#P"".  My proposal is that it should be set to the value of
(SB-EXT::DEFAULT-DIRECTORY) at startup and advertised as the standard
way of "changing directory" - given that SB-EXT::DEFAULT-DIRECTORY
isn't exported anyway, we need some such thing.

This would be the first step along a route towards "pay no attention
to the process's current directory - just do the merging ourselves and
use absolute pathnames everywhere".  As we have to support
*default-pathname-defaults* anyway, I can't help feeling that things
would be easier to understand without _two_ concepts of "current
directory" to deal with.

(It was pointed out that _some_ access to the unix cwd needs to be
retained, for foreign code, and for servers that want to chdir("/").)

(3) found in the course of implementing (1), I realised that we
currently have different behaviours for the :defaults argument to 
make-pathname than for merge-pathnames. 

* *default-pathname-defaults*
#P"/home/dan/src/sourceforge/sbcl/"

* (make-pathname :directory '(:relative "bar") :name "foo" :defaults *default-pathname-defaults*)
#P"bar/foo"

- but -

* (merge-pathnames (make-pathname :directory '(:relative "bar") :name "foo") *default-pathname-defaults*)
#P"/home/dan/src/sourceforge/sbcl/bar/foo"

The first case may be conforming, but imho it sucks anyway.  If you
have usenet access, see my recent post to c.l.l with subject "pathname
defaulting" (Message-ID: <87s...@no...>)


-dan

-- 

  http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources