I believe my first ASDF patch had a minor buglet that could cause over-compilation.
Here's the deal: when new TRAVERSE detects that the components of a module need to have an operation performed on them, it binds a dynamic variable and calls itself on the components of the module. The dynamic variable forces the components to be done even when they satisfy operation-done-p. This has an effect equivalent to propagating the module's dependencies onto the children.
However, this also means that the dynamic variable is in place when we call TRAVERSE recursively on the dependencies recorded on the children, then those dependencies are forced to happen as well.
In /theory/ this could cause over-compilation, over-loading, etc. However, I cannot come up with a test case where this will /actually/ occur. Why is that? It's because components of modules cannot "reach out" of the containing module to depend on anything in their surroundings. E.g. if I have a module FOO, then components of FOO can record dependencies only onto other components of FOO. This is a consequence of how name resolution works in ASDF.
So I have what I think is a fix for performing unnecessary operations in ASDF, but I cannot figure out a way to craft a test case where unnecessary operations could actually occur.
I feel like I should put the patch in anyway, in case we change the rules on name-lookup in ASDF, but this feels wrong.
Any suggestions? Have I missed something? Is there any way, for example, a component of FOO could depend on an outside system? I don't believe that this is possible, but I could be wrong.
thanks, r
On 10 February 2010 00:28, Robert Goldman rpgoldman@sift.info wrote:
I believe my first ASDF patch had a minor buglet that could cause over-compilation.
Here's the deal: when new TRAVERSE detects that the components of a module need to have an operation performed on them, it binds a dynamic variable and calls itself on the components of the module. The dynamic variable forces the components to be done even when they satisfy operation-done-p. This has an effect equivalent to propagating the module's dependencies onto the children.
However, this also means that the dynamic variable is in place when we call TRAVERSE recursively on the dependencies recorded on the children, then those dependencies are forced to happen as well.
In /theory/ this could cause over-compilation, over-loading, etc. However, I cannot come up with a test case where this will /actually/ occur. Why is that? It's because components of modules cannot "reach out" of the containing module to depend on anything in their surroundings. E.g. if I have a module FOO, then components of FOO can record dependencies only onto other components of FOO. This is a consequence of how name resolution works in ASDF.
So I have what I think is a fix for performing unnecessary operations in ASDF, but I cannot figure out a way to craft a test case where unnecessary operations could actually occur.
I feel like I should put the patch in anyway, in case we change the rules on name-lookup in ASDF, but this feels wrong.
Any suggestions? Have I missed something? Is there any way, for example, a component of FOO could depend on an outside system? I don't believe that this is possible, but I could be wrong.
Can't you work around the name resolution by using a defmethod? Say, have a component type :foo-file that depends on system :foo? (Note that this case is rather artificial; in practice, you'd have your .asd do a load-op of foo).
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Does artillery violate the natural rights of the target? I would say: the entire *purpose* of artillery is to violate the natural rights of the target.
-
Faré -
Robert Goldman