Hello,
currently Declt advertises component dependencies by using COMPONENT-LOAD-DEPENDENCIES. This function however only returns a list of symbols naming the components.
What would be the best way to retrieve a list of component objects instead ?
Thanks!
On Wed, Jun 26, 2013 at 7:31 AM, Didier Verna didier@lrde.epita.fr wrote:
Hello,
currently Declt advertises component dependencies by using COMPONENT-LOAD-DEPENDENCIES. This function however only returns a list of symbols naming the components.
What would be the best way to retrieve a list of component objects instead ?
Thanks!
Cher Didier,
what are you *really* trying to do?
Usually, one wants to get a list of components within a system. Then, one typically uses required-components, e.g. like this (YMMV): (asdf:required-components (asdf:find-system :fare-utils) :component-type '(not asdf:system) :keep-operation 'asdf:load-op :keep-component 'asdf:source-file)
If you *really* want to walk the dependencies by yourself, use asdf/plan:visit-dependencies. There are also functions map-direct-dependencies, reduce-direct-dependencies, direct-dependencies that you may want to use instead. More often than not, it's a bad idea, though. Most of the time, if you need to go under the hood, it is better to manually use traverse-action traverse-actions traverse-sub-actions with your choice of plan, e.g. a sequential-plan or filtered-sequential-plan.
These are all ASDF 3 idioms. For these kinds of hacks, ASDF 2 is just not supported.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Faré's Second Law of Dissent: I am Right, whence it follows that all who disagree with me are either (1) evil, (2) stupid or (3) crazy. (The alternatives are not mutually exclusive.) This universal law is valid for all values of "me", including "you".
Faré fahree@gmail.com wrote:
what are you *really* trying to do?
Really, trying to get the same thing that component-load-dependencies gives me, but as component objects instead of names.
Usually, one wants to get a list of components within a system. Then, one typically uses required-components, e.g. like this (YMMV): (asdf:required-components (asdf:find-system :fare-utils) :component-type '(not asdf:system) :keep-operation 'asdf:load-op :keep-component 'asdf:source-file)
That's the opposite of what I want. It seems that component-load-dependencies gets me all the (direct) things a component depends on (for loading). That may be implicit in an ASDF system description if :serial t is used, or explicit with a :depend-on declaration. This is exactly what I want, but as objects, not names.
If you *really* want to walk the dependencies by yourself, use asdf/plan:visit-dependencies. There are also functions map-direct-dependencies, reduce-direct-dependencies, direct-dependencies that you may want to use instead. More often than not, it's a bad idea, though. Most of the time, if you need to go under the hood, it is better to manually use traverse-action traverse-actions traverse-sub-actions with your choice of plan, e.g. a sequential-plan or filtered-sequential-plan.
All of this is way beyond me.
I wrote:
All of this is way beyond me.
But by looking at the code, it seems that the dependency names I'm looking for are in the SIDEWAY-DEPENDENCIES slot of the components. From there, it seems that I can use RESOLVE-DEPENDENCY-NAME to finally get a component object.
Does this sound reasonable?
On Wed, Jun 26, 2013 at 12:05 PM, Didier Verna didier@lrde.epita.fr wrote:
But by looking at the code, it seems that the dependency names I'm looking for are in the SIDEWAY-DEPENDENCIES slot of the components. From there, it seems that I can use RESOLVE-DEPENDENCY-NAME to finally get a component object.
Does this sound reasonable?
My bet is that this isn't what you really want in the end, but since you provide no justification for what you are trying to do, anything can be "reasonable" or not. Have fun playing with ASDF.
Once again, if you want to walk dependencies, map-dependencies and visit-dependencies are your friend.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown. — Carl Sagan
Faré fahree@gmail.com wrote:
since you provide no justification for what you are trying to do, anything can be "reasonable" or not.
I'm not sure what I need to justify, since my original question was actually quite precise.
My bet is that this isn't what you really want in the end,
Usually, one wants to get a list of components within a system. Then, one typically uses required-components, e.g. like this (YMMV):
That's the opposite of what I want.
Thank you very much, but even assuming I don't know what I want and you know what I want better than I know what I want, I'm still sure that I don't want the opposite of what I want.
Have fun playing with ASDF.
Not really, no.
On Thu, Jun 27, 2013 at 3:08 AM, Didier Verna didier@lrde.epita.fr wrote:
Faré fahree@gmail.com wrote:
since you provide no justification for what you are trying to do, anything can be "reasonable" or not.
I'm not sure what I need to justify, since my original question was actually quite precise.
Your original question was quite bogus and shows superficial understanding of the ASDF dependency model. There is no such thing as "component dependencies". The notion doesn't exist in ASDF, never did, and never will. And so, despite any inappropriate naming established by history. Components do NOT have dependencies. Actions do. The dependency graph is a graph of actions, not of components. Components have parents and children, that's all.
If you want to know the direct dependencies of an action, use component-depends-on, or map-direct-dependencies or visit-dependencies.
If you want to know the indirect dependencies of an action, use make-plan, visit-action, visit-actions, visit-sub-actions, etc.
If you want to extract the set of components an action depends on, in dependency order, while dropping the associated operation, use required-components.
Anything else is semantically meaningless or incomplete and not directly called by the ASDF planning engine.
sideway-dependencies are only a fraction of the user-specified information from which the graph is extracted. But if for some reason you want to put it on a pedestal, then yes, you can resolve it using resolve-dependency-spec, the same way that map-direct-dependencies does.
Thank you very much, but even assuming I don't know what I want and you know what I want better than I know what I want, I'm still sure that I don't want the opposite of what I want.
Whatever you're trying to achieve, I hope you're successful at it.
Have fun playing with ASDF.
Not really, no.
Then don't do it.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If Government is the solution to any alleged "failure" of free society, what is the solution to blatant failures of Government?
-
Didier Verna -
Faré