On 19 May 2011, at 20:58, Robert Goldman wrote:
On 5/19/11 May 19 -1:24 PM, Pascal Costanza wrote:
On 18 May 2011, at 15:28, Robert Goldman wrote:
On 5/18/11 May 18 -12:26 AM, Chun Tian (binghe) wrote:
I found a workaround for myself:
(in-package :asdf)
(defun user-homedir () #P"Macintosh HD:Users:binghe:")
with above code loaded as a ASDF patch, I can load other packages well.
As I read this, it's simply a bug in MCL --- they just aren't implementing user-homedir-pathname properly.
Isn't that right?
No, it's not right. The meaning of user-homedir-pathname is (intentionally) underspecified in ANSI CL.
I was not very careful here. The meaning of U-H-D is *not* underspecified when the host is provided as an (optional) argument. If we were providing our host as an argument to the function, then I believe the MCL behavior would be clearly buggy, since the spec says:
"The definition of home directory is implementation-dependent, but defined in Common Lisp to mean the directory where the user keeps personal files such as initialization files and mail."
There is no such directory in pre Mac OS X.
I don't think that the MCL behavior of supplying the installation directory of the lisp implementation is defensible in light of the above language.
OK, in this case I was not careful. Here is what the documentation says: When Macintosh Common Lisp is run, two logical hosts are set up automatically: * The host "ccl" is set to the directory holding the MCL application. * The host "home" is set to the directory holding the document that was launched with Macintosh Common Lisp. user-homedir-pathname returns #P"home:" which points to wherever you started MCL from (for example, by double-clicking on some .lisp file).
It would be good if ASDF wouldn't rely on such underspecified features, or if it would have a way to deal with the lack of such features in a more meaningful way because, for example, this may not be the last time in history that the notion of a user directory isn't supported or, as another example, that pathnames look different from the usual Unix flavors that you see these days.
Point taken, but I think this is unfair to ASDF. This seems more like a case where (as with many things involving interaction with filenames and directories) the ANSI standard doesn't give us any /specified/ features that fill a very real need. So we necessarily rely on underspecified features. What are the /specified/ features that will fill this need?
Indeed, one of the things that ASDF does is provide a POSIX-ish portable file system sub-system precisely because the specified facilities (pathnames, logical pathnames) didn't do the job.
Because ASDF 2.x caused me some trouble in RMCL, I actually put some effort into learning logical pathnames - and they seem to work extremely well, as far as I can tell (but it requires specifying :ignore-inherited-configuration in my source registry configuration, which seems somewhat unclean to me - but I don't really know...) Pascal -- Pascal Costanza