[Openmcl-devel] Weird ASDF problem

Ron Garret ron at flownet.com
Sat Sep 11 11:42:20 PDT 2010


On Sep 11, 2010, at 7:04 AM, Robert P. Goldman wrote:

> We (ok, really Fare) had a bunch of troubles with merge-pathnames because it supplied default hosts and devices at times. Any chance that's related to this problem?

Yes.

> The latest asdf abandoned merge-pathnames altogether, in favor of its own replacement.

The problem is that it gets called behind the scenes by TRUENAME.  Here's the sequence of events.

At some point, the variable *output-translations* gets initialized with the result of a call to (wrapping-output-translations).  That in turn calls (truename #p"ccl:"), which barfs if *default-pathname-defaults* is set to an absolute path.  This is also the reason that the problem manifests itself only at the console and not in the IDE.  The IDE bakes ASDF in at build time, when (in my case) *defatult-pathname-defaults* is not set, and so *output-translations* gets initialized properly and saved along with the rest of the application.  You can reproduce the problem in the IDE by calling (asdf::clear-output-translations).

It is far from clear to me how best to fix this.  On my reading of the standard, merge-pathnames is actually behaving correctly, and not even altogether unreasonably.  The real problem (I think) is that there's no way to distinguish a namestring that specifies a logical host but not a directory from a namestring that specifies the root directory of a logical host.

I would suggest replacing (truename #p"ccl:") in wrapping-output-translations with (let ((*default-pathname-defaults* nil)) (truename "ccl:")).  It's not quite the Right Thing, but CL pathnames are such a horrible quagmire that even just figuring out what the Right Thing is is probably not worth the pain.

rg




More information about the Openmcl-devel mailing list