There are several places where ASDF relies on *DEFAULT-PATHNAME-DEFAULTS* to provide a default path. The value of this variable is "An implementation-dependent pathname, typically in the working directory that was current when Common Lisp was started up." [ http://www.lispworks.com/documentation/HyperSpec/Body/v_defaul.htm ] I think it would be better to define a variable, like asdf:*pathname-defaults*, asdf:*registry-pathname-defaults, etc., that is explicitly set using feature expressions. The biggest argument for not making this change is that some systems may rely on the value of *DEFAULT-PATHNAME-DEFAULTS*. I don't think it would be too difficult to correct those systems, but admit that it might not be worth the effort.
My motivation for making this change was prompted by the function default-source-registry. It creates a :directory entry in the source registry that is constructed from the TRUENAME of the value returned by *DEFAULT-PATHNAME-DEFAULTS*. The first point is that the value *DEFAULT-PATHNAME-DEFAULTS* is implementation dependent. For the cases I tested using CCL 1.6 and LispWorks 6.0.1 on Windows 7, the value is the empty path #P"". The second point is that the pathname returned by TRUENAME when it is given the empty path is implementation dependent. In the case of CCL, (TRUENAME #P"") returns the working directory that was current when Common Lisp was executed. In the case of LispWorks, (TRUENAME #P"") returns #P"C:/Windows/system32/". This may be the working directory that was current when LispWorks was started, but it is clearly not a desirable place for ASDF systems. In either case, the result is a :directory entry in the source registry that is not well defined. I think it is better to have the default pathname well defined.
Thank you,
~ Tom ---------------------------------------------------------------- Thomas M. Hermann Odonata Research LLC http://www.odonata-research.com/ http://www.linkedin.com/in/thomasmhermann
I think that this change may be annoying to Unix[1] *users* who start up their lisp from the shell, and who have expectations about how their lisp implementation is going to set the *default-pathname-defaults* from the current working directory.
This change would not break any systems, but it would break some users' conventional usage patterns. I don't see that any benefit is provided that would compensate for that. And I don't see that there is a problem: this only kicks in when people have failed to provide a usable path to their systems. For some people, with some usage patterns and some choice of implementation, the current behavior will provide a desirable outcome. For others, they are no worse off (so ASDF looks someplace stupid where there will be no .asd files, consuming some minimal amount of cycles in an error case).
Furthermore, vendors/implementors for whom *default-pathname-defaults* will not be usefully set, may feel free to define appropriate behaviors.
So I'm not convinced that ASDF is broke, and request that we not fix it.
Best, r
[1] by this I mean the broadest sense of the word, to cover Linux, the BSD family, and Mac OS X.
On Thu, Dec 23, 2010 at 4:15 PM, Robert Goldman rpgoldman@sift.info wrote:
I think that this change may be annoying to Unix[1] *users* who start up their lisp from the shell, and who have expectations about how their lisp implementation is going to set the *default-pathname-defaults* from the current working directory.
This change would not break any systems, but it would break some users' conventional usage patterns. I don't see that any benefit is provided that would compensate for that. And I don't see that there is a problem: this only kicks in when people have failed to provide a usable path to their systems. For some people, with some usage patterns and some choice of implementation, the current behavior will provide a desirable outcome. For others, they are no worse off (so ASDF looks someplace stupid where there will be no .asd files, consuming some minimal amount of cycles in an error case).
Furthermore, vendors/implementors for whom *default-pathname-defaults* will not be usefully set, may feel free to define appropriate behaviors.
So I'm not convinced that ASDF is broke, and request that we not fix it.
Best, r
[1] by this I mean the broadest sense of the word, to cover Linux, the BSD family, and Mac OS X.
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Robert,
I'm not arguing that ASDF is broken, rather that the default behavior is not explicitly defined. The benefit I envision is defined behavior versus implementation dependent behavior. I acknowledge that the benefit may not justify the change. If the concern is for users that rely on *DEFAULT-PATHNAME-DEFAULTS*, though, I think the internals can be modified to result in defined behavior while still respecting the value of *DEFAULT-PATHNAME-DEFAULTS* when it is defined. I think the change can be made in a way that is transparent to the users.
I don't really think of this as a bug and probably should have brought it up here before entering it in launchpad. I'm really just interested in bringing it up to discuss and getting feedback. I have a local git branch of ASDF that I work from and will develop my ideas there. I installed VirtualBox and will work on testing it on Linux as well.
Thanks,
~ Tom ---------------------------------------------------------------- Thomas M. Hermann Odonata Research LLC http://www.odonata-research.com/ http://www.linkedin.com/in/thomasmhermann
On 12/23/10 Dec 23 -4:36 PM, Thomas M. Hermann wrote: ....
Robert,
I'm not arguing that ASDF is broken, rather that the default behavior is not explicitly defined. The benefit I envision is defined behavior versus implementation dependent behavior.
Right. I'm not sure where to draw the line. I am by and large very happy that my /programs/ are not implementation-dependent. However, for example, I find that there are a number of things about the /environment/ my usual implementation provides me, and I would be reluctant to give those up.
Since this is a matter of environment, I'm inclined to think we don't need to smooth over implementation differences here. Others' opinions may differ.
Also, I don't know whether people who use more than one implementation are really the majority of ASDF users. I wouldn't be surprised if we were a majority of ASDF maintainers, but our preferences (which might lie in having, e.g., portable configurations) might well be unrepresentative.
Best, r
Robert Goldman rpgoldman@sift.info writes:
I think that this change may be annoying to Unix[1] *users* who start up their lisp from the shell, and who have expectations about how their lisp implementation is going to set the *default-pathname-defaults* from the current working directory.
In my understanding, Thomas is not proposing to change *default-pathname-defaults* but to define another variable, specific to ASDF.
In my mind, *default-pathname-defaults* is a user variable: the user may change it as he wants for whatever purpose he wants. For example, I have cd/pwd/pushd/popd functions that maintain the synchronicity between *default-pathname-defaults* and the current working directory on POSIX systems.
It would be bad if the user changing *default-pathname-defaults* for whatever purpose unrelated to asdf would impact the behavior of asdf.
An example, was a bug in clisp, where (require "module") could not find the its module anymore when *default-pathname-defaults* was changed.
I don't see how not using *default-pathname-defaults*, after perhaps an initialization, you can have: (defvar asdf:*pathname-defaults* (truename *default-pathname-defaults*)) would break unix users expectations. When I want to load an asd file from some directory, be it the current directory, I push it onto asdf:*central-registry*, I don't mess with *default-pathname-defaults*.
On 12/23/10 Dec 23 -11:34 PM, Pascal J. Bourguignon wrote:
Robert Goldman rpgoldman@sift.info writes:
I think that this change may be annoying to Unix[1] *users* who start up their lisp from the shell, and who have expectations about how their lisp implementation is going to set the *default-pathname-defaults* from the current working directory.
In my understanding, Thomas is not proposing to change *default-pathname-defaults* but to define another variable, specific to ASDF.
In my mind, *default-pathname-defaults* is a user variable: the user may change it as he wants for whatever purpose he wants. For example, I have cd/pwd/pushd/popd functions that maintain the synchronicity between *default-pathname-defaults* and the current working directory on POSIX systems.
It would be bad if the user changing *default-pathname-defaults* for whatever purpose unrelated to asdf would impact the behavior of asdf.
An example, was a bug in clisp, where (require "module") could not find the its module anymore when *default-pathname-defaults* was changed.
I don't see how not using *default-pathname-defaults*, after perhaps an initialization, you can have: (defvar asdf:*pathname-defaults* (truename *default-pathname-defaults*)) would break unix users expectations. When I want to load an asd file from some directory, be it the current directory, I push it onto asdf:*central-registry*, I don't mess with *default-pathname-defaults*.
I don't have any arguments with what you say, Pascal, but I don't see it as the job of ASDF to keep the user from doing things which might (like counting on something about *default-pathname-defaults*), especially not at the cost of dictating to that user (if the user's lisp implementation lets him/her LOAD-SYSTEM a system that happens to be in the same working direction as the CWD of the lisp job, who am I to mess with this?).
This seems exceedingly low priority with respect to other use of scarce ASDF development hours. And even if it's trivial to implement, it needs testing and potentially messes people up. Adding code always has the potential to introduce bugs.
For this reason, any change to ASDF has a potentially high cost, especially since ASDF is close to the root of any lisp programmer's dependency tree. Unless a change is a clear /benefit/, I believe it should be rejected. I see no benefit here. We don't need ASDF:*pathname-defaults* --- you can already configure asdf's system search in at least two ways.
Best, r
-
Pascal J. Bourguignon -
Robert Goldman -
Thomas M. Hermann