<br><br><div class="gmail_quote">On Thu, Jun 30, 2011 at 1:04 PM, Robert Burghart <span dir="ltr"><<a href="mailto:jestersks@gmail.com">jestersks@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Windows XP SP3 I tried to load quicklisp.lisp using mkcl an it errors out near the bottom of the file at:<br>(setf *default-pathname-defaults* (truename *default-pathname-defaults*))<br></blockquote><div><br>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).<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>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.<br>
</blockquote><div><br>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. <br>
<br>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.<br>
This makes, in a multi-threaded SBCL, impossible to predict the value of:<br><br>(equal (truename #P"") (truename #P""))<br><br>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.<br>
<br>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.<br>
 <br>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.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br>_______________________________________________<br>
mkcl-devel mailing list<br>
<a href="mailto:mkcl-devel@common-lisp.net">mkcl-devel@common-lisp.net</a><br>
<a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/mkcl-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/mkcl-devel</a><br>
<br></blockquote></div><br>