[mkcl-devel] quiclisp

[Jean-Claude Beaudoin]

On Thu, Jun 30, 2011 at 1:04 PM, Robert Burghart <jestersks at gmail.com>wrote:

> On Windows XP SP3 I tried to load quicklisp.lisp using mkcl an it errors
> out near the bottom of the file at:
> (setf *default-pathname-defaults* (truename *default-pathname-defaults*))
>

First, you are breaking fresh ground here since quicklisp has not been
ported to MKCL yet and such a port remains to be done (soon I hope but there
are still other more pressing needs).


> Apparently *default-pathname-defaults* defaults to "".  Is that
> intentional?  From the hyperspec it says that it's implementation dependent
> but that many will store the path where the repl was started in.
>

Indeed the initial value of *default-pathname-defaults* is #P"" (not "") and
in this MKCL follows the behavior of CCL (and also Lispworks I think). Also
note that MKCL is a multi-threaded Common Lisp and in such a context
directly sharing a global variable like *default-pathname-defaults* would be
problematic at best, therefore *default-pathname-defaults* has been made a
thread-locally rebound special variable by default.

The problem you see comes not from the #P"" value but from the behavior of
function "truename". In MKCL (truename #P"") raises a file-error since #P""
is not the valid filespec of any physical file in the filesystem but in SBCL
or in CCL (truename #P"") returns the pathname of the current working
directory as given by the underlying OS process. This behavior of SBCL, CCL
and some others is clearly an extension of the specification. This extension
seems very difficult to justify in a multi-threaded context where the
process current working directory is a resource globally shared among the
different threads of the process.
This makes, in a multi-threaded SBCL, impossible to predict the value of:

(equal (truename #P"") (truename #P""))

It may return T most of the time but not always since the current working
directory may have been changed by some other thread between the two
"truename" calls.

Portability concerns are also at play here since the concept of a current
working directory is very OS specific. For example, Windows does not have a
single current working directory but rather a set of current working
directories, with one current working directory per drive.

BTW, in MKCL if you want access to the current working directory you should
call (si:getcwd) and be prepared to handle the result as an OS specific
value.


> _______________________________________________
> mkcl-devel mailing list
> mkcl-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/mkcl-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/mkcl-devel/attachments/20110630/b50d3ef6/attachment.html>