[asdf-devel] ASDF2: Please, no unwrapped calls to "truename".

Jean-Claude Beaudoin jean.claude.beaudoin at gmail.com
Mon Apr 5 11:38:40 UTC 2010


My very first attempt at using ASDF version 1.661 on my system
ended-up in the debugger on a file-error signaled by
function truename.

The offending call came from function asdf::component-parent-pathname
that contains a call to truename unwrapped in any condition
handler although truename is required to signal errors. This seems
to be the only such instance in asdf.lisp, all the other truename
calls being wrapped inside a ignore-errors.

I fixed the situation by modifying asdf::component-parent-pathname
this way:

(defun component-parent-pathname (component)
   (aif (component-parent component)
        (component-pathname it)
        (or (ignore-errors (truename *default-pathname-defaults*))
	   *default-pathname-defaults*)))

BTW, I would like to mention that in my CL system
*default-pathname-defaults* is not a replacement for
the process current working directory (which can be properly
queried only through a call to getcwd). Thinking otherwise seems
to me to be pretty clearly an unportable assumption unsupported
by the ANSI CL standard. That ASDF seems to make that assumption
troubles me seriously.

In fact I cannot figure out how I would explain to a naive
beginning lisper on MS-Windows that *default-pathname-defaults*
is an equivalent of the current directory when there is a
potential of up to 26 simultaneous current directories on
his OS (one per drive letter).

On the top of that the current working director(y|ies) is/are
a process-level attribute and *default-pathname-defaults*
being a special variable is most likely to have a thread-local
binding at one point or an other, in some CL systems this
could even be part of the initial thread bindings. How one
reconciles these many independently evolving thread bindings
with the single process-level attribute sure beat me!

Cheers,

Jean-Claude Beaudoin








More information about the asdf-devel mailing list