Closed jcbeaudoin closed 12 years ago
What's with the #-mkcl bit?
It prevents a visit to the debugger that would happen otherwise and seems not to affect the rest of the code.
Why does (truename *default-pathname-defaults*)
land in the debugger?
Like in clisp and ccl (and probably others), the value of *default-pathname-defaults*
in MKCL is #P""
.
But unlike clisp and ccl, in MKCL a call of (truename #P"")
does not return the current working directory of the process but rather signals a file-error since no appropriate file could be located in the file system for such filespec.
(I am paraphrasing from the bottom of the Hyperspec page for truename
.)
To have access to the "current working directory" of the process, an eminently platform specific concept,
one can call (mkcl:getcwd)
instead, and be ready for a result with some platform specificity.
*default-pathname-defaults*
not being initialized to a valid pathname (for which truename
returns something useful) is very, very, very inconvenient.
The "working directory" may indeed be a platform-specific concept, but *default-pathname-defaults*
is not.
If you don't intend to change MKCL's behavior, please at least create a patch which introduces a new generic function rather than #+/#- conditionalization.
I don't understand what kind of generic function you're pointing to here. Do you mean something defined
through defgeneric
and defmethod
and that discriminates on a class (which one?)?
I would be happy to write something along the lines of what you want but I fail to see what you have in mind. Can you give an hint as to the function needed behavior and signature?
BTW, I find very intriguing that this #-mkcl seems to have no observable impact on the rest of the quicklisp code.
As to the initial value of *default-pathname-defaults*
being #P""
, on this matter MKCL is in the
same group as clisp, ccl, cmucl and lispworks.
Ok, I surrender! From now on truename
will behave like in clisp, ccl, cmucl, lispworks and allegro
when it comes to (truename #P"")
. Thus you can remove the #-mkcl from the patch.
Thanks for your flexibility on this issue. I think it's the right way to go -- even though it is not precisely specified, there's value in acting much like others do in unspecified territory.
This new behavior will not be available before MKCL 1.1.0 RC3, that I hope to push out the door in a few days...
In case this is what was holding back progress on this "pull request", I can now confirm that MKCL 1.1.0 RC3 has been released for public use a few hours ago.
Hello again Zach,
Here is the bootstrap part that matches the main client pull request of a few minutes ago.
Cheers,
Jean-Claude Beaudoin