(Yet another Lisp novice ... returning to it after twenty years, and
struggling with defsystems.)
I am having some problems getting MK-DEFSYSTEM to work right in
LispWorks Personal Edition 4.3.6 on Windows XP, and I think I tracked it
down to odd behavior in make-pathname. I would appreciate verification,
since most of Common Lisp is new to me.
(make-pathname :name "utilities" :type "system")
=> #P"c:utilities.system"
The resulting "c:" prefix doesn't seem right. From the HyperSpec, I
can't see that make-pathname is allowed to supply defaults for any part
of the pathname on its own initiative.
This behavior causes MAKE:COMPUTE-SYSTEM-PATH to fail.
Assuming I've understood the problem correctly, can I work around it by
redefining COMMON-LISP:MAKE-PATHNAME, e.g. w/ a function like this:
(defun my-make-pathname (&rest args)
(apply #'cl:make-pathname args :defaults ""))
This function seems to have the right behavior -- how would I safely use
this definition to replace Xanalys' definition of MAKE-PATHNAME, so that
libraries like MK-DEFSYSTEM will work correctly?
I realize this question might be better sent to Xanalys, but I beg your
indulgence -- obviously I'm using their unsupported evaluation version
right now, and I'm not quite ready to invest in a licensed copy yet.
Also, I'm not yet certain that I understand Lisp well enough to point a
finger at their implementation.
Thanks in advance!
From: Joe Marshall
Subject: Re: make-pathname in LW PE on Win32
Date:
Message-ID: <k775129h.fsf@ccs.neu.edu>
Dan Muller <·········@sneakemail.com> writes:
> (Yet another Lisp novice ... returning to it after twenty years, and
> struggling with defsystems.)
>
> I am having some problems getting MK-DEFSYSTEM to work right in
> LispWorks Personal Edition 4.3.6 on Windows XP, and I think I tracked it
> down to odd behavior in make-pathname. I would appreciate verification,
> since most of Common Lisp is new to me.
>
> (make-pathname :name "utilities" :type "system")
> => #P"c:utilities.system"
>
> The resulting "c:" prefix doesn't seem right. From the HyperSpec, I
> can't see that make-pathname is allowed to supply defaults for any part
> of the pathname on its own initiative.
The default defaults come from *default-pathname-defaults*
> This behavior causes MAKE:COMPUTE-SYSTEM-PATH to fail.
>
> Assuming I've understood the problem correctly, can I work around it by
> redefining COMMON-LISP:MAKE-PATHNAME, e.g. w/ a function like this:
>
> (defun my-make-pathname (&rest args)
> (apply #'cl:make-pathname args :defaults ""))
>
> This function seems to have the right behavior -- how would I safely use
> this definition to replace Xanalys' definition of MAKE-PATHNAME, so that
> libraries like MK-DEFSYSTEM will work correctly?
I *think* you might be better off binding *default-pathname-defaults*
to something without a device. I ran into this problem myself, but
I forgot what I did to solve it. It wasn't replacing the definition
of MAKE-PATHNAME though.
In article <············@ccs.neu.edu>, ···@ccs.neu.edu says...
> Dan Muller <·········@sneakemail.com> writes:
> >
> > (make-pathname :name "utilities" :type "system")
> > => #P"c:utilities.system"
>
> The default defaults come from *default-pathname-defaults*
Aha. Thank you. I found the documentation of this symbol in the
HyperSpec, and the example is exactly analogous to what I saw. And when
I read MAKE-PATHNAME more carefully, I see that that the default value
for defaults in fact takes just the host component from here. I had set
*DEFAULT-PATHNAME-DEFAULTS* to something starting with C:, and
apparently that's being treated as a host name. Guess I'll have to ask
on Xanalys' mailing list to find out to how to properly convert Windows
paths to pathnames.
`
In article <··························@news1.toast.net>, itd98ds02
@sneakemail.com says...
> In article <············@ccs.neu.edu>, ···@ccs.neu.edu says...
> > Dan Muller <·········@sneakemail.com> writes:
> > >
> > > (make-pathname :name "utilities" :type "system")
> > > => #P"c:utilities.system"
> >
> > The default defaults come from *default-pathname-defaults*
>
> Aha. Thank you. I found the documentation of this symbol in the
> HyperSpec, and the example is exactly analogous to what I saw. And when
> I read MAKE-PATHNAME more carefully, I see that that the default value
> for defaults in fact takes just the host component from here. I had set
> *DEFAULT-PATHNAME-DEFAULTS* to something starting with C:, and
> apparently that's being treated as a host name. Guess I'll have to ask
> on Xanalys' mailing list to find out to how to properly convert Windows
> paths to pathnames.
I haven't asked any questions on the LispWorks mailing list yet, but I
just spent a few hours learning more about logical pathnames and
experimenting with both LispWorks and Corman Lisp on Windows. Turns out
that Corman does a nice job with local namestrings, but doesn't know
about UNCs. LispWorks handles UNCs nicely, but doesn't handle local
drive letters as one would expect.
Quiz: How would you expect the following namestrings to be parsed by
parse-namestring on a modern Windows system? Assume that no logical
pathname translations have been specified by the user. Perhaps the
implementation predefines some, but there's no standard way to find that
out, AFAIK.
(show-n-to-s "c:/projects/lisp/")
(show-n-to-s "c:\\projects\\lisp\\")
(show-n-to-s "c:/projects/lisp")
(show-n-to-s "c:lisp/")
(show-n-to-s "c:/projects/lisp/utilities/matrix.cl")
(show-n-to-s "//localhost/data/") ;pegasus = localhost
(show-n-to-s "//pegasus/data/") ;pegasus = localhost
(show-n-to-s "//scorpion/danm/yop.txt")
(show-n-to-s "\\\\scorpion\\danm\\yop.txt")
See the full test source code and links to results for Corman and
Lispworks here: <http://www.spookydistance.com/cgi-bin/public-wiki.pl?
Pathnames_Test>
(It's a Usemod wiki, so if you can figure out how, feel free to post
additional results from other implementations.)
From: james anderson
Subject: Re: Logical pathnames on Windows (WAS: make-pathname in LW PE on Win32)
Date:
Message-ID: <3F8F2F06.1FB5C1D2@setf.de>
my guess would be that on lw the first five cases put the "C:" in the host,
while others put it in the device. then looking at the next three, i'd wonder
whether one wanted them to be treated as file urls, with the host component
handled accordingly. i've never look to see if the implementation agree with
the expectation. finally, as the last one is no logical form i've seen perhaps
it would signal an error, but then, i'm not well versed in windows pathname forms.
Dan Muller wrote:
>
> ...
>
> Quiz: How would you expect the following namestrings to be parsed by
> parse-namestring on a modern Windows system?
i would expect enough variation that the guesses above are proposed more for
entertainment value than for reference. if on needs portability, use make
pathname with a know logical host and specify the components.
> Assume that no logical
> pathname translations have been specified by the user.
that's like putting a bag over ones head and stepping out into traffic.
why would one want to do that?
> Perhaps the
> implementation predefines some, but there's no standard way to find that
> out, AFAIK.
>
> (show-n-to-s "c:/projects/lisp/")
> (show-n-to-s "c:\\projects\\lisp\\")
> (show-n-to-s "c:/projects/lisp")
> (show-n-to-s "c:lisp/")
> (show-n-to-s "c:/projects/lisp/utilities/matrix.cl")
> (show-n-to-s "//localhost/data/") ;pegasus = localhost
> (show-n-to-s "//pegasus/data/") ;pegasus = localhost
> (show-n-to-s "//scorpion/danm/yop.txt")
> (show-n-to-s "\\\\scorpion\\danm\\yop.txt")
>
...
In article <·················@setf.de>, ··············@setf.de says...
>
> my guess would be that on lw the first five cases put the "C:" in the host,
> while others put it in the device. then looking at the next three, i'd wonder
> whether one wanted them to be treated as file urls, with the host component
> handled accordingly. i've never look to see if the implementation agree with
> the expectation. finally, as the last one is no logical form i've seen perhaps
> it would signal an error, but then, i'm not well versed in windows pathname forms.
The last one just uses backslashes, the "natural" representation on
Windows, instead of forward-slashes. It only looks funny because the
backslashes have to be doubled up to actually get them in the string.
And by the way, *none* of these are *logical* forms, these are physical
namestrings, as they might be supplied by a user or returned from a
Win32 API call. Exactly what I'm interested in here is the translation
of physical namestrings to logical pathnames. If I've misread the
HyperSpec and parse-namestring is the wrong function for this, please
let me know.
>
> Dan Muller wrote:
> >
> > ...
> >
> > Quiz: How would you expect the following namestrings to be parsed by
> > parse-namestring on a modern Windows system?
>
> i would expect enough variation that the guesses above are proposed more for
> entertainment value than for reference. if on needs portability, use make
> pathname with a know logical host and specify the components.
Given some of the funny stuff that goes on, I don't think you can
necessarily work your way out of all problems using logical pathname
translations. For instance, with LispWorks you can set up something
perfectly reasonable, and MK-DEFSYSTEM will reasonably build a
namestring from it, then try to parse the namestring again. Because LW
sees drive letters as logical pathnames, this fails. Perhaps if I set up
a translation for each valid drive letter ... yech.
>
> > Assume that no logical
> > pathname translations have been specified by the user.
>
> that's like putting a bag over ones head and stepping out into traffic.
> why would one want to do that?
Why do you say that? I'm interested here in how the implementations
handle the parsing of standard, native namestrings, not in how the
translation mechanism works. It's reasonable to expect (and even
necessary, if you're processing string coming from outside your program)
that they give a sane result for the platform they're implemented on.
Just to be sure we're on the same page: I was talking about translations
specified via (setf (logical-pathname-translations host-name) '((wild-
from wild-to))).
From: james anderson
Subject: Re: Logical pathnames on Windows (WAS: make-pathname in LW PE on Win32)
Date:
Message-ID: <3F8F4CEE.B241E38C@setf.de>
Dan Muller wrote:
>
> In article <·················@setf.de>, ··············@setf.de says...
> >
> > my guess would be that on lw the first five cases put the "C:" in the host,
> > while other [pc lisps] put it in the device. then looking at the next three, i'd wonder
> > whether one wanted them to be treated as file urls, with the host component
> > handled accordingly. i've never look[ed] to see if the implementation agree with
> > the expectation. finally, as the last one is no logical form i've seen perhaps
> > it would signal an error, but then, i'm not well versed in windows pathname forms.
>
> The last one just uses backslashes, the "natural" representation on
> Windows, instead of forward-slashes. It only looks funny because the
> backslashes have to be doubled up to actually get them in the string.
yes, which is why i distinguished what might "reasonbly" interpreted as a file url.
>
> And by the way, *none* of these are *logical* forms, these are physical
> namestrings, as they might be supplied by a user or returned from a
> Win32 API call. Exactly what I'm interested in here is the translation
> of physical namestrings to logical pathnames. If I've misread the
> HyperSpec and parse-namestring is the wrong function for this, please
> let me know.
parse namestring has a "standard" definition iff it is parsing a pathname with
a known logical host. even then there are different opinions as to what this
definition entails. despite which the variations are nominal enough to permit
portable code.
if there is no logical host in the pathname namestring, i would predict
nothing which i have not esablished by testing in the respective implementation.
>
> >
> > Dan Muller wrote:
> > >
> > > ...
> > >
> > > Quiz: How would you expect the following namestrings to be parsed by
> > > parse-namestring on a modern Windows system?
> >
> > i would expect enough variation that the guesses above are proposed more for
> > entertainment value than for reference. if on needs portability, use make
> > pathname with a know logical host and specify the components.
>
> Given some of the funny stuff that goes on, I don't think you can
> necessarily work your way out of all problems using logical pathname
> translations. For instance, with LispWorks you can set up something
> perfectly reasonable, and MK-DEFSYSTEM will reasonably build a
> namestring from it, then try to parse the namestring again.
"reasonably"? asked rhetorically, as one cannot expect to roundtrip physical
and logical pathnames. i do not know mk-defsystem internals, but i understand
that it purports to be portable, and portability and parsing physical
namestrings do not go together. should it be intending portable results from
parsing physical namestrings it is a potential mk-defsystem bug. should it not
be getting portable results from parsing a logical namestring it is an
implementation bug.
note that logical pathnames cannot and were not intended to capture everything
which any conceivable implementation might need to represent physical
pathnames. information is lost in one direction and fabricated in the other.
if one tries to go in a circle one is playing telephone.
> Because LW
> sees drive letters as logical pathnames, this fails.
a view of the world with which, as i recall, it stands alone. thus my guesses above.
> Perhaps if I set up
> a translation for each valid drive letter ... yech.
>
> >
> > > Assume that no logical
> > > pathname translations have been specified by the user.
> >
> > that's like putting a bag over ones head and stepping out into traffic.
> > why would one want to do that?
>
> Why do you say that? I'm interested here in how the implementations
> handle the parsing of standard, native namestrings, not in how the
> translation mechanism works.
i say that because the phrase "standard, native namestrings" is a
contradiction in terms. there is no such thing.
> It's reasonable to expect (and even
> necessary, if you're processing string coming from outside your program)
> that they give a sane result for the platform they're implemented on.
there may be reason to wish for, but i am not aware of a reason to expect this result.
>
> Just to be sure we're on the same page: I was talking about translations
> specified via (setf (logical-pathname-translations host-name) '((wild-
> from wild-to))).
were i concerned with user/os origins for namestrings, i would consider the following
- it makes no sense to specify logical pathname translations in terms of local
pathname syntax, as the point of them is portability and local pathnames are
not portable. i have been much more successful where i require either
-- there to be enough of a local context defined in terms of logical pathnames
outside of the immediate system, that all translation targets can be specified
in terms of those logical hosts, or
-- that a value such as *load-pathname* be relevant enough that one can rely
on its values for the things like device and host as defaults and manipulate
only values like directory, name, and type and only relative to those defaults.
- use enough-namestring to extract those components which can be treated in a
standard way across implementations - directory, name, type. in theory one
should be able to extract them relative to a physical pathname and get
consistent results. if with respect to directory one operates on the list for
only and never attempts to use the string form, the chances of success are better.
- in general, i would expect more predictable results from a user interface
which constructed the pathnames from components, rather than from strings in
the local physical syntax. in that case, it could construct logical pathnames directly.
- the situation with pathname designators from os operations is different, in
that some implementations endeavour to return logical pathnames were they can
recognize the relevance of a known host, while others do not. for those
implementations which do not, i would try to know the context of any return
value and force the logical pathname abstraction in a wrapper function.
...
Thanks, this was a pretty informative reply...
In article <·················@setf.de>, ··············@setf.de says...
>
>
> Dan Muller wrote:
> >
> > In article <·················@setf.de>, ··············@setf.de says...
> > >
> parse namestring has a "standard" definition iff it is parsing a pathname with
> a known logical host. even then there are different opinions as to what this
> definition entails. despite which the variations are nominal enough to permit
> portable code.
I'm not so sure of that last point, at least not with the choice that
LW appears to make wrt treating the drive letter as a host name. The
host name has various special effects in the standard, such as having to
match a caller-supplied logical host, or being erroneous treated as a
logical host and causing unwanted translations to be attempted.
> if there is no logical host in the pathname namestring, i would predict
> nothing which i have not esablished by testing in the respective implementation.
Given the wording in the standard, I can see that. It's unfortunate that
implementations seem to vary this much on a single platform. That's why
I'm curious what other Win32 implementations do, since I've only seen
two so far.
> "reasonably"? asked rhetorically, as one cannot expect to roundtrip physical
> and logical pathnames. i do not know mk-defsystem internals, but i understand
> that it purports to be portable, and portability and parsing physical
> namestrings do not go together. should it be intending portable results from
> parsing physical namestrings it is a potential mk-defsystem bug. should it not
> be getting portable results from parsing a logical namestring it is an
> implementation bug.
I looked more carefully, and mk-defsystem does in fact create physical
namestrings from pathnames, then tries to turn them into pathnames
again. (compute-system-path forms the native namestring, and passes it
to append-directories, which tries to go back to logical pathnames.)
>
> note that logical pathnames cannot and were not intended to capture everything
> which any conceivable implementation might need to represent physical
> pathnames. information is lost in one direction and fabricated in the other.
> if one tries to go in a circle one is playing telephone.
Well, yes, anything's possible when a standard says "implementation-
dependent". But on platforms where there's no need for data loss, which
covers most of them (no doubt by design, since pathnames are pretty
information-rich compared to the simplest common file system models), it
certainly seems gratuitously surprising that a round-robin trip wouldn't
work.
>
> > Because LW
> > sees drive letters as logical pathnames, this fails.
>
> a view of the world with which, as i recall, it stands alone. thus my guesses above.
>
> > Perhaps if I set up
> > a translation for each valid drive letter ... yech.
> >
> > >
> > > > Assume that no logical
> > > > pathname translations have been specified by the user.
> > >
> > > that's like putting a bag over ones head and stepping out into traffic.
> > > why would one want to do that?
> >
> > Why do you say that? I'm interested here in how the implementations
> > handle the parsing of standard, native namestrings, not in how the
> > translation mechanism works.
>
> i say that because the phrase "standard, native namestrings" is a
> contradiction in terms. there is no such thing.
Ah, sorry, poor choice of word. "Standard" in this context meant
relative to the platform. Certainly, on Windows, there is a
specification of what UNCs and local pathnames look like and mean. But I
do get your point, that mapping the platform's meaning to the meaning of
the components in standard CL is unspecified. In fact, as my
understanding of this increases, my expectations of a good mapping have
changed. Originally, I assumed the host name in a UNC should map to a
host name component, but now I see that would likely be unwise. A UNC
would be better treated as containing no host or device components.
> > It's reasonable to expect (and even
> > necessary, if you're processing string coming from outside your program)
> > that they give a sane result for the platform they're implemented on.
>
> there may be reason to wish for, but i am not aware of a reason to expect this result.
> >
> > Just to be sure we're on the same page: I was talking about translations
> > specified via (setf (logical-pathname-translations host-name) '((wild-
> > from wild-to))).
>
> were i concerned with user/os origins for namestrings, i would consider the following
>
> - it makes no sense to specify logical pathname translations in terms of local
> pathname syntax, as the point of them is portability and local pathnames are
> not portable. i have been much more successful where i require either
> -- there to be enough of a local context defined in terms of logical pathnames
> outside of the immediate system, that all translation targets can be specified
> in terms of those logical hosts, or
> -- that a value such as *load-pathname* be relevant enough that one can rely
> on its values for the things like device and host as defaults and manipulate
> only values like directory, name, and type and only relative to those defaults.
>
> - use enough-namestring to extract those components which can be treated in a
> standard way across implementations - directory, name, type. in theory one
> should be able to extract them relative to a physical pathname and get
> consistent results. if with respect to directory one operates on the list for
> only and never attempts to use the string form, the chances of success are better.
>
> - in general, i would expect more predictable results from a user interface
> which constructed the pathnames from components, rather than from strings in
> the local physical syntax. in that case, it could construct logical pathnames directly.
>
> - the situation with pathname designators from os operations is different, in
> that some implementations endeavour to return logical pathnames were they can
> recognize the relevance of a known host, while others do not. for those
> implementations which do not, i would try to know the context of any return
> value and force the logical pathname abstraction in a wrapper function.
>
Thank you for this enlightening summary!
It seems like one might be best off not relying at all on the
implementation-specific parsing and creation of local namestrings, but
instead supplying one's own, which should not be too difficult in most
cases. This would give precise control over the mapping of native
concepts to logical components. At that point, though, it doesn't seem
like the logical hostname translation facilities of the standard are all
that useful any more; or perhaps I'm just not seeing how best to use
them yet.
Thanks, James.
From: james anderson
Subject: Re: Logical pathnames on Windows (WAS: make-pathname in LW PE on Win32)
Date:
Message-ID: <3F8FA38E.508BFBF9@setf.de>
Dan Muller wrote:
>
> Thanks, this was a pretty informative reply...
>
> In article <·················@setf.de>, ··············@setf.de says...
> >
> >
> > Dan Muller wrote:
> > >
> > > In article <·················@setf.de>, ··············@setf.de says...
> > > >
> > parse namestring has a "standard" definition iff it is parsing a pathname with
> > a known logical host. even then there are different opinions as to what this
> > definition entails. despite which the variations are nominal enough to permit
> > portable code.
>
> I'm not so sure of that last point, at least not with the choice that
> LW appears to make wrt treating the drive letter as a host name.
yes. that is an issue. it is a know issue (i pointed out in my first reply).
to my knowledge it it true of theur pc version only. it is also the only #+/-
which i can recall in the pathname related code in cl-xml, which is portable code.
> The
> host name has various special effects in the standard, such as having to
> match a caller-supplied logical host, or being erroneous treated as a
> logical host and causing unwanted translations to be attempted.
yes.
>
> > if there is no logical host in the pathname namestring, i would predict
> > nothing which i have not esablished by testing in the respective implementation.
>
> Given the wording in the standard, I can see that. It's unfortunate that
> implementations seem to vary this much on a single platform. That's why
> I'm curious what other Win32 implementations do, since I've only seen
> two so far.
where the consideration is portability, i would expect no more common
interpretation between two pc physical pathname implementations than between a
pc and a mac-os9 implementation.
>
> > "reasonably"? asked rhetorically, as one cannot expect to roundtrip physical
> > and logical pathnames. i do not know mk-defsystem internals, but i understand
> > that it purports to be portable, and portability and parsing physical
> > namestrings do not go together. should it be intending portable results from
> > parsing physical namestrings it is a potential mk-defsystem bug. should it not
> > be getting portable results from parsing a logical namestring it is an
> > implementation bug.
>
> I looked more carefully, and mk-defsystem does in fact create physical
> namestrings from pathnames,
that is a mistake if it endeavours to be portable.
> then tries to turn them into pathnames
> again. (compute-system-path forms the native namestring, and passes it
> to append-directories, which tries to go back to logical pathnames.)
> >
> > note that logical pathnames cannot and were not intended to capture everything
> > which any conceivable implementation might need to represent physical
> > pathnames. information is lost in one direction and fabricated in the other.
> > if one tries to go in a circle one is playing telephone.
>
> Well, yes, anything's possible when a standard says "implementation-
> dependent". But on platforms where there's no need for data loss, which
> covers most of them (no doubt by design, since pathnames are pretty
> information-rich compared to the simplest common file system models), it
> certainly seems gratuitously surprising that a round-robin trip wouldn't
> work.
see above wrt pc/mac
>
> >...
> >
> > > Perhaps if I set up
> > > a translation for each valid drive letter ... yech.
> > >
> > > >
> > > > > Assume that no logical
> > > > > pathname translations have been specified by the user.
> > > >
> > > > that's like putting a bag over ones head and stepping out into traffic.
> > > > why would one want to do that?
> > >
> > > Why do you say that? I'm interested here in how the implementations
> > > handle the parsing of standard, native namestrings, not in how the
> > > translation mechanism works.
> >
> > i say that because the phrase "standard, native namestrings" is a
> > contradiction in terms. there is no such thing.
>
> Ah, sorry, poor choice of word. "Standard" in this context meant
> relative to the platform.
again, as you note above. there is no such thing.
> Certainly, on Windows, there is a
> specification of what UNCs and local pathnames look like and mean.
to windows.
> But I
> do get your point, that mapping the platform's meaning to the meaning of
> the components in standard CL is unspecified.
yes.
> In fact, as my
> understanding of this increases, my expectations of a good mapping have
> changed. Originally, I assumed the host name in a UNC should map to a
> host name component, but now I see that would likely be unwise. A UNC
> would be better treated as containing no host or device components.
>
> > > It's reasonable to expect (and even
> > > necessary, if you're processing string coming from outside your program)
> > > that they give a sane result for the platform they're implemented on.
> >
> > there may be reason to wish for, but i am not aware of a reason to expect this result.
> > >
> > > Just to be sure we're on the same page: I was talking about translations
> > > specified via (setf (logical-pathname-translations host-name) '((wild-
> > > from wild-to))).
> >
> > were i concerned with user/os origins for namestrings, i would consider the following
> >
> > ...
> >
> Thank you for this enlightening summary!
>
> It seems like one might be best off not relying at all on the
> implementation-specific parsing and creation of local namestrings,
yes,
> but
> instead supplying one's own, which should not be too difficult in most
> cases.
in my experience that has not proved necesary.
> This would give precise control over the mapping of native
> concepts to logical components. At that point, though, it doesn't seem
> like the logical hostname translation facilities of the standard are all
> that useful any more; or perhaps I'm just not seeing how best to use
> them yet.
without knowing the exact use case, that is hard to say, but given the
immediately preceeding paragraph i would not contract the closing sentence.
...
From: james anderson
Subject: Re: Logical pathnames on Windows (WAS: make-pathname in LW PE on Win32)
Date:
Message-ID: <3F8FAA97.43390282@setf.de>
james anderson wrote:
>
> Dan Muller wrote:
> >
> > Thanks, this was a pretty informative reply...
> >
> > In article <·················@setf.de>, ··············@setf.de says...
> > >
> > >
> > > Dan Muller wrote:
> > > >
> > > > In article <·················@setf.de>, ··············@setf.de says...
> > > > >
> > > parse namestring has a "standard" definition iff it is parsing a pathname with
> > > a known logical host. even then there are different opinions as to what this
> > > definition entails. despite which the variations are nominal enough to permit
> > > portable code.
> >
> > I'm not so sure of that last point, at least not with the choice that
> > LW appears to make wrt treating the drive letter as a host name.
>
> yes. that is an issue. it is a know issue (i pointed out in my first reply).
> to my knowledge it it true of theur pc version only. it is also the only #+/-
> which i can recall in the pathname related code in cl-xml, which is portable code.
>
just to make the point clear:
- if one examines the file xml:code;base;utils.lisp in the cl-xml release, one
will find a portable implementation for file urls which does manage
application-domain specific file designators by mapping between them and
logical pathnames. the only #-/+ in it is that for the lisp-works host/device.
which implies to me that the logical pathnames are themselves a sufficiently
portable representation.
- if one examines any given http server's http url to/from file designator
mapping one would by definition find an implementation of something similar.
in the case of cl-http i know it to be portable across lisp implementations.
that is, it is certainly possible to achieve the portability without inventing
a new designator form - file urls would likely suffice, and in at least one
case, logiccal pathnames are sufficient to accomplish all translation.
[as a fine point, cl-xml maps the logical host to the file-url authority,
which is non-standard in file-url terms.]
...
In article <·················@setf.de>, ··············@setf.de says...
>
>
> james anderson wrote:
> >
> > Dan Muller wrote:
> > >
> > > Thanks, this was a pretty informative reply...
> > >
> > > In article <·················@setf.de>, ··············@setf.de says...
> > > >
> > > >
> > > > Dan Muller wrote:
> > > > >
> > > > > In article <·················@setf.de>, ··············@setf.de says...
> > > > > >
> > > > parse namestring has a "standard" definition iff it is parsing a pathname with
> > > > a known logical host. even then there are different opinions as to what this
> > > > definition entails. despite which the variations are nominal enough to permit
> > > > portable code.
> > >
> > > I'm not so sure of that last point, at least not with the choice that
> > > LW appears to make wrt treating the drive letter as a host name.
> >
> > yes. that is an issue. it is a know issue (i pointed out in my first reply).
> > to my knowledge it it true of theur pc version only. it is also the only #+/-
> > which i can recall in the pathname related code in cl-xml, which is portable code.
> >
>
> just to make the point clear:
> - if one examines the file xml:code;base;utils.lisp in the cl-xml release, one
> will find a portable implementation for file urls which does manage
> application-domain specific file designators by mapping between them and
> logical pathnames. the only #-/+ in it is that for the lisp-works host/device.
> which implies to me that the logical pathnames are themselves a sufficiently
> portable representation.
> - if one examines any given http server's http url to/from file designator
> mapping one would by definition find an implementation of something similar.
> in the case of cl-http i know it to be portable across lisp implementations.
>
> that is, it is certainly possible to achieve the portability without inventing
> a new designator form - file urls would likely suffice, and in at least one
> case, logiccal pathnames are sufficient to accomplish all translation.
>
> [as a fine point, cl-xml maps the logical host to the file-url authority,
> which is non-standard in file-url terms.]
> ...
>
The logical system, although not perfect, does seem fairly well thought
out, and it seems that I am mostly bumping up against LW's odd choice of
implementation at this point, and perhaps a bug in mk-defsystem.
To correct one of my earlier thoughts: Taking complete control of the
mapping is not really feasible without replacing some CL functions,
because some standard functions need to convert to physical namestrings
internally to do their work, e.g. DIRECTORY. As an example of the
problem, in LW I tried explicitly constructing a pathname with what I
considered a reasonable mapping:
(namestring (make-pathname :host nil
:device "c"
:directory '(:absolute "projects" "lisp")
:name :wild
:type :wild
:version nil))
But this results in an unusable namestring: ":c:\\projects\\lisp\\*.*"
The extra leading colon is unintelligible to windows. So one has little
choice but to acquiesce to the implementation's mapping:
(namestring (make-pathname :host "c"
:device nil
:directory '(:absolute "projects" "lisp")
:name :wild
:type :wild
:version nil))
=> "c:\\projects\\lisp\\*.*"
Looking at the example in cl-xml, I see it is exactly accomodating this
quirk in its mapping.
Thanks again for the thoughtful replies. I think I now have enough of an
understanding to work around these quirks. If I decide to continue using
mk-defsystem, it seems I may have to provide a (rather extensive) patch
for it.
From: Joe Marshall
Subject: Re: Logical pathnames on Windows
Date:
Message-ID: <ptgvzywa.fsf@ccs.neu.edu>
Dan Muller <·········@sneakemail.com> writes:
> To correct one of my earlier thoughts: Taking complete control of the
> mapping is not really feasible without replacing some CL functions,
> because some standard functions need to convert to physical namestrings
> internally to do their work, e.g. DIRECTORY.
Unfortunately true. I needed to do this for my project.
In article <············@ccs.neu.edu>, ···@ccs.neu.edu says...
> Dan Muller <·········@sneakemail.com> writes:
>
> > To correct one of my earlier thoughts: Taking complete control of the
> > mapping is not really feasible without replacing some CL functions,
> > because some standard functions need to convert to physical namestrings
> > internally to do their work, e.g. DIRECTORY.
>
> Unfortunately true. I needed to do this for my project.
>
>
Urp. I just discovered that Corman Lisp doesn't implement translate-
logical-pathname or translate-pathname. So I guess if I want my
environment and code to be portable among the common Win32
implementations, I'll have to stay away from translations entirely.
Sigh.
You know, this all started when I tried to follow the instructions in
Henrik Motakef's "Fight the System" (<http://www.henrik-
motakef.de/defsystem.html>). And guess what I've been doing ever since?
:-P
From: james anderson
Subject: Re: Logical pathnames on Windows (WAS: make-pathname in LW PE on Win32)
Date:
Message-ID: <3F9027ED.D5557778@setf.de>
Dan Muller wrote:
>
> ...
>
> Thanks again for the thoughtful replies. I think I now have enough of an
> understanding to work around these quirks. If I decide to continue using
> mk-defsystem, it seems I may have to provide a (rather extensive) patch
> for it.
that's good. if you discover other quirks, i would appreciate hearing about them.
...
From: Björn Lindberg
Subject: Re: Logical pathnames on Windows (WAS: make-pathname in LW PE on Win32)
Date:
Message-ID: <hcs1xtcoz24.fsf@tjatte.nada.kth.se>
Dan Muller <·········@sneakemail.com> writes:
> It seems like one might be best off not relying at all on the
> implementation-specific parsing and creation of local namestrings, but
> instead supplying one's own, which should not be too difficult in most
> cases. This would give precise control over the mapping of native
> concepts to logical components. At that point, though, it doesn't seem
> like the logical hostname translation facilities of the standard are all
> that useful any more; or perhaps I'm just not seeing how best to use
> them yet.
At the risk of being wrong, it seems to me that you are confusing
"pathnames" with "logical pathnames". The latter is a subset of the
former. Pathnames are rich enough to accomodate file references on any
(reasonable) file system, while _logical_ pathnames are kind of a
least common denominator for file systems. A portable program could
for instance use logical pathnames to name its own configuration file,
and the same logical pathnames should work portably on all platforms,
but for file references from external sources I think pathnames are
needed or you will lose information in the conversion.
(I have not fully grasped all the subtleties of pathnames myself yet,
so someone correct me if I'm wrong above.)
Bj�rn
In article <···············@tjatte.nada.kth.se>, Bj�rn says...
> Dan Muller <·········@sneakemail.com> writes:
>
> > It seems like one might be best off not relying at all on the
> > implementation-specific parsing and creation of local namestrings, but
> > instead supplying one's own, which should not be too difficult in most
> > cases. This would give precise control over the mapping of native
> > concepts to logical components. At that point, though, it doesn't seem
> > like the logical hostname translation facilities of the standard are all
> > that useful any more; or perhaps I'm just not seeing how best to use
> > them yet.
>
> At the risk of being wrong, it seems to me that you are confusing
> "pathnames" with "logical pathnames". The latter is a subset of the
> former. Pathnames are rich enough to accomodate file references on any
> (reasonable) file system, while _logical_ pathnames are kind of a
> least common denominator for file systems. A portable program could
> for instance use logical pathnames to name its own configuration file,
> and the same logical pathnames should work portably on all platforms,
> but for file references from external sources I think pathnames are
> needed or you will lose information in the conversion.
>
> (I have not fully grasped all the subtleties of pathnames myself yet,
> so someone correct me if I'm wrong above.)
I think "subset" is too simply put. The logical pathname system in the
standard is more than adequate to represent Windows file namestrings,
and in fact can represent wildcarding patterns that aren't understood by
any native Win32 tools. The problem is more with details of the mapping
between logical and physical, and how the logical host name component
interacts with certain feaures of the standard functionality.
Interestingly, I looked at my old 1984 edition of Steele's "Common
Lisp", and the logical pathname translation stuff (which one of the
complexities that LW's mapping runs afoul of) is not mentioned. I assume
that this was added in the later edition, or in the ANSI standard. I
wonder if it was really such a good idea; similar functionality could
have been provided as an explicit layer of translation without
intertwining it in the standard functions' interpretation of pathnames
and namestrings.
On Thu, 16 Oct 2003 13:39:20 -0400, Dan Muller <·········@sneakemail.com> wrote:
> I realize this question might be better sent to Xanalys, but I beg
> your indulgence -- obviously I'm using their unsupported evaluation
> version right now, and I'm not quite ready to invest in a licensed
> copy yet. Also, I'm not yet certain that I understand Lisp well
> enough to point a finger at their implementation.
You can send questions to the LispWorks mailing list. Most questions
are answered very fast (and often my members of the Xanalys
staff). Also, it doesn't hurt to ask them directly or file a bug
report. That you're using an evaluation version doesn't necessarily
imply that they won't answer.
Have fun with Lisp,
Edi.
Dan Muller <·········@sneakemail.com> writes:
> (make-pathname :name "utilities" :type "system")
> => #P"c:utilities.system"
Others have answered your question, but I wanted to note in passing
that MK-DEFSYSTEM (if we're talking about the 3.x version) was mostly
written prior to the widespread adoption of ANSI pathnames, and
sometimes is happier if just given a namestring.
DEFSYSTEM 4 probably fixes this. Personally I use ASDF instead, but I
would do; I wrote it.
> This function seems to have the right behavior -- how would I safely use
> this definition to replace Xanalys' definition of MAKE-PATHNAME, so that
> libraries like MK-DEFSYSTEM will work correctly?
As a general rule, redefining anything in the CL package is a Bad
Idea. You don't know what else might be using it.
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
In article <··············@noetbook.telent.net>, ···@telent.net says...
> Dan Muller <·········@sneakemail.com> writes:
>
> > (make-pathname :name "utilities" :type "system")
> > => #P"c:utilities.system"
>
> Others have answered your question, but I wanted to note in passing
> that MK-DEFSYSTEM (if we're talking about the 3.x version) was mostly
> written prior to the widespread adoption of ANSI pathnames, and
> sometimes is happier if just given a namestring.
>
> DEFSYSTEM 4 probably fixes this. Personally I use ASDF instead, but I
> would do; I wrote it.
Thanks for the tip; I'll take a look at it. Can't say that I'm enamored
of defsystem after studying it for a few days, and I gather that it's a
sore point with many experienced Lisp programmers, too.
> > This function seems to have the right behavior -- how would I safely use
> > this definition to replace Xanalys' definition of MAKE-PATHNAME, so that
> > libraries like MK-DEFSYSTEM will work correctly?
>
> As a general rule, redefining anything in the CL package is a Bad
> Idea. You don't know what else might be using it.
Yeah, I've been programming long enough to know that redefining standard
library routines is not usually a good thing. :-) But in this case I was
wondering if the vendor's implementation was actually kaputt for some
cases. (And in fact I think it may be -- see my further postings on the
subject of namestring -> pathname parsing.)
Dan Muller writes:
> Thanks for the tip; I'll take a look at it. Can't say that I'm enamored
> of defsystem after studying it for a few days, and I gather that it's a
You might try Dan Barlow's `asdf', and check the article by Kent
Pitman mentioned in the README.
Paolo
--
Paolo Amoroso <·······@mclink.it>
In article <··············@plato.moon.paoloamoroso.it>,
·······@mclink.it says...
> Dan Muller writes:
>
> > Thanks for the tip; I'll take a look at it. Can't say that I'm enamored
> > of defsystem after studying it for a few days, and I gather that it's a
>
> You might try Dan Barlow's `asdf', and check the article by Kent
> Pitman mentioned in the README.
>
>
> Paolo
Thanks for the suggestion. I found a copy of the article online at
<http://www.nhplace.com/kent/Papers/Large-Systems.html>.