Robert Goldman rpgoldman@sift.info writes:
Zach Beane wrote:
Faré fahree@gmail.com writes:
A solution that is both backward-compatible and forward compatible is
1- to rename the systems so they follow the foo/bar convention for naming systems in foo.asd, so that ASDF3 can find them. This solves forward compatibility
If anyone considering fixing mcclim is reading this, please don't use a slash-named system. It's incompatible with Quicklisp.
Zach
Can you explain the incompatibility?
It would be hugely useful to be able to map multiple systems to a single file, as your McCLIM example illustrates.
I think it illustrates the problems of putting multiple systems in the same file, not the utility.
But, of course, we want to maximize quicklisp compatibility.
So can you make suggestions about how to be quicklisp-compatible while making it possible to have multiple findable system definitions in a single file?
Hmm, I think it might be workable if, when a system with a given slashed name is not found, the *system-definition-search-functions* chain was called recursively with the truncated name, instead of having each function in *s-d-s-f* have to know how to truncate on its own.
E.g. imagine I had something like this:
(push (lambda (name) (print (list 'trace name)) nil) *system-definition-search-functions*)
Then it would be nice if the ASDF internals led to putput like this:
(find-system "foo/bar")
(TRACE "foo/bar") (TRACE "foo")
=> #<SYSTEM "foo/bar">
Does it work that way now? I don't think it does.
Zach
Zach Beane xach@xach.com writes:
So can you make suggestions about how to be quicklisp-compatible while making it possible to have multiple findable system definitions in a single file?
Hmm, I think it might be workable if, when a system with a given slashed name is not found, the *system-definition-search-functions* chain was called recursively with the truncated name, instead of having each function in *s-d-s-f* have to know how to truncate on its own.
E.g. imagine I had something like this:
(push (lambda (name) (print (list 'trace name)) nil) *system-definition-search-functions*)
Then it would be nice if the ASDF internals led to putput like this:
(find-system "foo/bar")
(TRACE "foo/bar") (TRACE "foo")
=> #<SYSTEM "foo/bar">
Does it work that way now? I don't think it does.
Actually, another option could be to ONLY call the *s-d-s-f* chain on the truncated name. That would preclude those functions from implementing some new funky logic for slashed names, but I don't think that's really much of an issue.
Zach
If quicklisp can't use / in names, it's probably a bug, since such names have always been accepted by ASDF (though not actually used before). Nevertheless, a workaround is for a system do have the dependency on foo both before and after that on the thing that is loaded when loading foo.asd: :depends-on (foo ... foo-extra ... foo) That's ugly, and probably an abuse.
As for stripping the /, currently it's done by the individual functions in *system-definition-search-functions* by calling primary-system-name. I suppose that could be changed, but the backward-compatible way would be to (let ((name ...) #+asdf3 (name (primary-system-name name))) ...)
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Foreign aid might be defined as a transfer from poor people in rich countries to rich people in poor countries. — Douglas Casey
On Mon, Jul 8, 2013 at 11:11 AM, Zach Beane xach@xach.com wrote:
Zach Beane xach@xach.com writes:
So can you make suggestions about how to be quicklisp-compatible while making it possible to have multiple findable system definitions in a single file?
Hmm, I think it might be workable if, when a system with a given slashed name is not found, the *system-definition-search-functions* chain was called recursively with the truncated name, instead of having each function in *s-d-s-f* have to know how to truncate on its own.
E.g. imagine I had something like this:
(push (lambda (name) (print (list 'trace name)) nil) *system-definition-search-functions*)
Then it would be nice if the ASDF internals led to putput like this:
(find-system "foo/bar")
(TRACE "foo/bar") (TRACE "foo")
=> #<SYSTEM "foo/bar">
Does it work that way now? I don't think it does.
Actually, another option could be to ONLY call the *s-d-s-f* chain on the truncated name. That would preclude those functions from implementing some new funky logic for slashed names, but I don't think that's really much of an issue.
Zach
Faré fahree@gmail.com writes:
As for stripping the /, currently it's done by the individual functions in *system-definition-search-functions* by calling primary-system-name.
I think this could be moved into search-for-system-definition by wrapping coerce-name in primary-system-name.
Zach
On Mon, Jul 8, 2013 at 11:42 AM, Zach Beane xach@xach.com wrote:
Faré fahree@gmail.com writes:
As for stripping the /, currently it's done by the individual functions in *system-definition-search-functions* by calling primary-system-name.
I think this could be moved into search-for-system-definition by wrapping coerce-name in primary-system-name.
One issue I see with this is that some s-f-s-d handlers might be sensitive to the full name rather than to the primary system name, and always loading base on the primary name only drops the information about which specific subsystem one is looking for.
The current solution is for each s-d-s-f function to do its own thing. This is most flexible, but requires all clients of s-d-s-f to be updated to support this feature.
One solution proposed by Zach is that if and when we realize that normalizing to primary system name is always the right thing to do, this can be moved up the call chain — but is it the case? Zach seems to think so, but at least I'm not convinced.
Another solution, that Zach proposed in a previous email, was to search for the full name, then the primary name as a fallback. This is somewhat quirky and makes the semantics of system naming more complex, but probably works automatically in the most cases.
Yet another solution might be to always look for the primary name first and load the system definition, then look for the full name if different. This makes the semantics more regular, though a bit more expensive.
I admit picked the current solution was the most straightforward to implement, and most open to future improvements.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org What's funny with equality is how everyone has a different idea of it. —#f
Faré fahree@gmail.com writes:
On Mon, Jul 8, 2013 at 11:42 AM, Zach Beane xach@xach.com wrote:
Faré fahree@gmail.com writes:
As for stripping the /, currently it's done by the individual functions in *system-definition-search-functions* by calling primary-system-name.
I think this could be moved into search-for-system-definition by wrapping coerce-name in primary-system-name.
One issue I see with this is that some s-f-s-d handlers might be sensitive to the full name rather than to the primary system name, and always loading base on the primary name only drops the information about which specific subsystem one is looking for.
It is theoretically possible that some new handler written in the past few months may be adversely affected by searching only for primary system names via *s-d-s-f*.
It is concretely the case that ALL handlers written prior to the introduction of this feature have been broken by it. And some of those handlers, e.g. the one in Quicklisp, have been widely deployed.
Zach
If given system name "mcclim/freetype" we want ASDF to search for mcclim.asd, then the extension hook should be named *sysdef-file-search-functions* instead of *system-definition-search-functions*.
That would allow the the strategy of fallback to the main system name to be encapsulated in the main ASDF. And still have the code organization reflecting what is really going on: ASDF tries to load system "mcclim/freetype" and asks the extensions for find the "mcclim.asd" file.
Of course, deploying this solution today is complicated - all clients must attach to new hook. So probably it is easier to just duplicate the fallback policy in the clients.
P.S. If it is necessary to support people who keep several system definitions in a single .asd file, then it makes sense to apply the same strategy to dash separated system names: search for "mcclim-freetype" may fallback to search in mcclim.asd
On Mon, Jul 8, 2013 at 9:36 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
If given system name "mcclim/freetype" we want ASDF to search for mcclim.asd, then the extension hook should be named *sysdef-file-search-functions* instead of *system-definition-search-functions*.
Gratuitously changing the hook variable name would only force an even more abrupt transition without obviously bringing any benefit. It's not like the old semantics is hopelessly broken and we want to force people away from it with aggravation (as was the case with the conditional semantics of :if-component-fails). It's more like we introduced a much needed new feature, and it is subtly incompatible with some previous ASDF extensions (or singular key extension, namely quicklisp).
That would allow the the strategy of fallback to the main system name to be encapsulated in the main ASDF.
It is a feature of ASDF3 (started in the last year of ASDF2) that ASDF supports systems that are not backed by files, but simply defined in the lisp image. The feature is notably used by ASDF itself, and could be used by any system that needs to be defined for dependency purpose, and may or may not be upgraded to a version from source when available.
And still have the code organization reflecting what is really going on: ASDF tries to load system "mcclim/freetype" and asks the extensions for find the "mcclim.asd" file.
What if it's not in a file? Shouldn't each extension be responsible for itself?
Of course, deploying this solution today is complicated - all clients must attach to new hook. So probably it is easier to just duplicate the fallback policy in the clients.
As far as I can tell, there is one and only one client that matters — quicklisp. And matters it does.
P.S. If it is necessary to support people who keep several system definitions in a single .asd file, then it makes sense to apply the same strategy to dash separated system names: search for "mcclim-freetype" may fallback to search in mcclim.asd
I don't know if it's necessary, but it has been common practice for a long time, except lacking any supported way to name them in such a way that ASDF would find them, unless they had been somehow found already — until ASDF3. Except as people start to use the new ASDF3 feature, something has to be done in ASDF and/or Quicklisp for Quicklisp to support it.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Any sufficiently advanced misquotation is indistinguishable from an original statement. — John McCarthy, misquoted
-
Anton Vodonosov -
Faré -
Zach Beane