Finding depended-upon systems
This seems like it might be a good FAQ, and we had some correspondence about a related query earlier. (sort (mapcar #'asdf:component-name (mapcar #'cdr (remove-if-not #'(lambda (x) (and (typep (cdr x) 'asdf/system:system) (typep (car x) 'asdf:load-op))) (asdf::traverse (make-instance 'asdf::load-op) (asdf:find-system "hunchentoot") :force :all)))) #'string-lessp) This requires knowing a bit about the internals of ASDF and relies on an obsoleted function (TRAVERSE). Maybe we should wrap this up and provide it as part of an ASDF query API? Cheers, r P.S. Sorry about the horrible word-wrapping...
On Tue, Nov 17, 2015 at 3:37 PM, Robert Goldman <rpgoldman@sift.net> wrote:
This seems like it might be a good FAQ, and we had some correspondence about a related query earlier.
(sort (mapcar #'asdf:component-name (mapcar #'cdr (remove-if-not #'(lambda (x) (and (typep (cdr x) 'asdf/system:system) (typep (car x) 'asdf:load-op))) (asdf::traverse (make-instance 'asdf::load-op) (asdf:find-system "hunchentoot") :force :all)))) #'string-lessp)
This requires knowing a bit about the internals of ASDF and relies on an obsoleted function (TRAVERSE).
Maybe we should wrap this up and provide it as part of an ASDF query API?
I believe that this should work: ((lambda (x) (sort (mapcar (lambda (a) (asdf:coerce-name (cdr a)) x 'string<) (asdf::required-components :hunchentoot :keep-component 'asdf:system :other-systems t)) Actually, it won't work if you have direct dependencies from non-system components to systems, but that's strongly frowned upon and should probably be prevented by some future ASDF. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I'd rather write programs that write programs than write programs — Dick Sites
Also, note that this fails to find defsystem-depends-on systems, and, what is worse, that ASDF will fail to reload them then reload the .asd files that depend on it when these systems change. See https://bugs.launchpad.net/asdf/+bug/1500578 —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Faith, n: That quality which enables us to believe what we know to be untrue. On Tue, Nov 17, 2015 at 4:10 PM, Faré <fahree@gmail.com> wrote:
On Tue, Nov 17, 2015 at 3:37 PM, Robert Goldman <rpgoldman@sift.net> wrote:
This seems like it might be a good FAQ, and we had some correspondence about a related query earlier.
(sort (mapcar #'asdf:component-name (mapcar #'cdr (remove-if-not #'(lambda (x) (and (typep (cdr x) 'asdf/system:system) (typep (car x) 'asdf:load-op))) (asdf::traverse (make-instance 'asdf::load-op) (asdf:find-system "hunchentoot") :force :all)))) #'string-lessp)
This requires knowing a bit about the internals of ASDF and relies on an obsoleted function (TRAVERSE).
Maybe we should wrap this up and provide it as part of an ASDF query API?
I believe that this should work: ((lambda (x) (sort (mapcar (lambda (a) (asdf:coerce-name (cdr a)) x 'string<) (asdf::required-components :hunchentoot :keep-component 'asdf:system :other-systems t))
Actually, it won't work if you have direct dependencies from non-system components to systems, but that's strongly frowned upon and should probably be prevented by some future ASDF.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I'd rather write programs that write programs than write programs — Dick Sites
On 11/17/15 Nov 17 -3:10 PM, Faré wrote:
On Tue, Nov 17, 2015 at 3:37 PM, Robert Goldman <rpgoldman@sift.net> wrote:
This seems like it might be a good FAQ, and we had some correspondence about a related query earlier.
(sort (mapcar #'asdf:component-name (mapcar #'cdr (remove-if-not #'(lambda (x) (and (typep (cdr x) 'asdf/system:system) (typep (car x) 'asdf:load-op))) (asdf::traverse (make-instance 'asdf::load-op) (asdf:find-system "hunchentoot") :force :all)))) #'string-lessp)
This requires knowing a bit about the internals of ASDF and relies on an obsoleted function (TRAVERSE).
Maybe we should wrap this up and provide it as part of an ASDF query API?
I believe that this should work: ((lambda (x) (sort (mapcar (lambda (a) (asdf:coerce-name (cdr a)) x 'string<) (asdf::required-components :hunchentoot :keep-component 'asdf:system :other-systems t))
Actually, it won't work if you have direct dependencies from non-system components to systems, but that's strongly frowned upon and should probably be prevented by some future ASDF.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I'd rather write programs that write programs than write programs — Dick Sites
There was some discussion about this in connection with finding what needed to be recompiled. Is the latter even a query that ASDF can answer? In old ASDF we computed the plan first, and only after that did we decide whether the operations needed performing.
Robert Goldman <rpgoldman@sift.net> wrote:
There was some discussion about this in connection with finding what needed to be recompiled. Is the latter even a query that ASDF can answer? In old ASDF we computed the plan first, and only after that did we decide whether the operations needed performing.
I was the one who asked about that and this is what I ended up with: (defun out-of-date-components (system &key (other-systems t)) "Returns a list of the components of SYSTEM (or its dependent systems, if OTHER-SYSTEMS is true (which is the default)) which are out-of-date." (let ((op (make-instance 'asdf/lisp-action:compile-op)) res) (dolist (c (asdf:required-components system :force nil :force-not nil :keep-component 'asdf:cl-source-file :keep-operation 'asdf:compile-op :other-systems other-systems)) (when (eq (asdf/action:compute-action-stamp nil op c) t) ;; Operation timestamp is in the future. This indicates that the operation ;; needs to be performed. (push c res))) res)) I would have been nice if I hadn't had to write this myself.
"Robert" == Robert Goldman <rpgoldman@sift.net> writes:
Robert> This seems like it might be a good FAQ, and we had some correspondence Robert> about a related query earlier. [snip] Robert> Maybe we should wrap this up and provide it as part of an ASDF query API? These kinds of introspection seem useful, and it would be nice if there was an API for that. Once in a long while I've wanted to get a list of all of the source files, or the fasl files, a dependency graph (tree?). Mostly just to see what the system thinks it has and what I think it should have. -- Ray
Once in a long while I've wanted to get a list of all of the source files, or the fasl files, a dependency graph (tree?). Mostly just to see what the system thinks it has and what I think it should have.
There is a contrib/ directory in asdf repository, but its downside is that having the asdf/ repository in your source-registry means you're getting more than you might want. Maybe there could be a separate repository asdf-extras or asdf-inspect or something that would hold these functions that don't belong in asdf itself but are useful to users who want to do things with asdf... —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Law is always law of the strongest. The only question is what feedback mechanism selects this strongest and controls his behavior.
"Fare" == Far <Far> writes:
>> Once in a long while I've wanted to get a list of all of the source >> files, or the fasl files, a dependency graph (tree?). Mostly just to >> see what the system thinks it has and what I think it should have. >> Fare> There is a contrib/ directory in asdf repository, but its downside is Fare> that having the asdf/ repository in your source-registry means you're Fare> getting more than you might want. Oh, I never noticed that before. The files therein are (currently) tiny compared to asdf.lisp. These might be useful to include with asdf in cmucl.... But it would be nice if at least a subset of them were officially supported as part of asdf in some way. -- Ray
On 11/18/15 Nov 18 -10:47 AM, Raymond Toy wrote:
"Fare" == Far <Far> writes:
>> Once in a long while I've wanted to get a list of all of the source >> files, or the fasl files, a dependency graph (tree?). Mostly just to >> see what the system thinks it has and what I think it should have. >> Fare> There is a contrib/ directory in asdf repository, but its downside is Fare> that having the asdf/ repository in your source-registry means you're Fare> getting more than you might want.
Oh, I never noticed that before. The files therein are (currently) tiny compared to asdf.lisp. These might be useful to include with asdf in cmucl.... But it would be nice if at least a subset of them were officially supported as part of asdf in some way.
I'm with Ray on this one. Code that you need to debug your use of ASDF needs to come with ASDF, always, not be an optional add-on. ASDF has grown in features, portability, and performance, but also opacity. There are a lot more complex and difficult-to-inspect data structures in it now to support things like caching, and they work well, but if you get your configuration wrong, it can be very difficult to debug. So one of my priorities going forward is to support better inspection of ASDF's state. cheers, r
"Robert" == Robert Goldman <rpgoldman@sift.net> writes:
Robert> On 11/18/15 Nov 18 -10:47 AM, Raymond Toy wrote: >>>>>>> "Fare" == Far <Far> writes: >> >> >> Once in a long while I've wanted to get a list of all of the source >> >> files, or the fasl files, a dependency graph (tree?). Mostly just to >> >> see what the system thinks it has and what I think it should have. >> >> Fare> There is a contrib/ directory in asdf repository, but its downside is Fare> that having the asdf/ repository in your source-registry means you're Fare> getting more than you might want. >> >> Oh, I never noticed that before. The files therein are (currently) >> tiny compared to asdf.lisp. These might be useful to include with >> asdf in cmucl.... But it would be nice if at least a subset of them >> were officially supported as part of asdf in some way. Robert> I'm with Ray on this one. Code that you need to debug your use of ASDF Robert> needs to come with ASDF, always, not be an optional add-on. Robert> ASDF has grown in features, portability, and performance, but also Robert> opacity. There are a lot more complex and difficult-to-inspect data Robert> structures in it now to support things like caching, and they work well, Robert> but if you get your configuration wrong, it can be very difficult to debug. Robert> So one of my priorities going forward is to support better inspection of Robert> ASDF's state. That is awesome! -- Ray
participants (5)
-
Ahmon Dancy -
Faré -
Mark H. David -
Raymond Toy -
Robert Goldman