I apologize in advance for the stupid newbie question that follows.
I have the two systems below. When I change a file in cl-farm, it recompiles it, but when I demand loading of cl-farm-test again, ASDF does not recompile it, even though its dependency has changed. Why? Is this expected.
This all is based on the latest ASDF from git, invoked from Slime (but I do not think this makes a difference)
Juanjo
(defsystem :cl-farm :serial t :components ((:file "package") (:file "machines")))
(defsystem :cl-farm-test :depends-on (:rt :cl-farm) :serial t :components ((:file "tests/package") (:file "tests/files") (:file "tests/run")))
On Wed, Oct 12, 2011 at 12:06, Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com wrote:
I apologize in advance for the stupid newbie question that follows. I have the two systems below. When I change a file in cl-farm, it recompiles it, but when I demand loading of cl-farm-test again, ASDF does not recompile it, even though its dependency has changed. Why? Is this expected. This all is based on the latest ASDF from git, invoked from Slime (but I do not think this makes a difference)
This is bug 479522. https://bugs.launchpad.net/asdf/+bug/479522
Somehow, this behaviour exists for backwards compatibility, and nobody took wants to take the responsibility for saying "we need to break compatibility and just do it".
Also, it isn't clear that the "obvious fix" would work if you (asdf:load-system :cl-farm) then try to (asdf:load-system :cl-farm-test) afterwards. Something new and magic need to happen about operation-done-p and mark-operation-done, so that the depending-on system detects that the depended-on system has been recompiled in a previous run.
If you take responsibility for writing a patch that does the Right Thing, I'll merge it.
But at some point, I say: this boggles my mind, I'd rather use XCVB, that doesn't have these issues.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The American businessmen, as a class, have demonstrated the greatest productive genius and the most spectacular achievements ever recorded in the economic history of mankind. What reward did they receive from our culture and its intellectuals? The position of a hated, persecuted minority. The position of a scapegoat for the evils of the bureaucrats. — Ayn Rand
On 10/12/11 Oct 12 -11:34 AM, Faré wrote:
On Wed, Oct 12, 2011 at 12:06, Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com wrote:
I apologize in advance for the stupid newbie question that follows. I have the two systems below. When I change a file in cl-farm, it recompiles it, but when I demand loading of cl-farm-test again, ASDF does not recompile it, even though its dependency has changed. Why? Is this expected. This all is based on the latest ASDF from git, invoked from Slime (but I do not think this makes a difference)
This is bug 479522. https://bugs.launchpad.net/asdf/+bug/479522
Somehow, this behaviour exists for backwards compatibility, and nobody took wants to take the responsibility for saying "we need to break compatibility and just do it".
Also, it isn't clear that the "obvious fix" would work if you (asdf:load-system :cl-farm) then try to (asdf:load-system :cl-farm-test) afterwards. Something new and magic need to happen about operation-done-p and mark-operation-done, so that the depending-on system detects that the depended-on system has been recompiled in a previous run.
If you take responsibility for writing a patch that does the Right Thing, I'll merge it.
Yes, Faré is zeroing in on the key challenge. In order to correctly do dependency tracking across system boundaries, you would have to make ASDF preserve its state across lisp runs. To see why this is necessary, consider the case where you recompile cl-farm, close your lisp, start a new job, and then load-cl-farm-test.
Now, I suppose we could compare the most recent compile date on cl-farm with the least recent compile date on cl-farm-test to get a partial solution.
Getting this right is complicated a bit by the odd semantics of the COMPILE-OP and LOAD-OP when applied to a SYSTEM object. I will not bore the regular reader of this mailing list by explaining this yet again.
One of the reasons why I think we should change this at ASDF3 is that I think we could radically simplify this by changing the objects that go in an ASDF plan to give the plan a hierarchical structure (i.e., make it so that PERFORMing a compilation on a system INCLUDES all of the sub-component compilations).
best, r
On Wed, Oct 12, 2011 at 09:06, Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com wrote:
I apologize in advance for the stupid newbie question that follows. I have the two systems below. When I change a file in cl-farm, it recompiles it, but when I demand loading of cl-farm-test again, ASDF does not recompile it, even though its dependency has changed. Why? Is this expected.
It is normal behavior for ASDF: Recompilation will only ever be triggered for components in the same module. (I'm not saying it's a good thing!)
There are a few architectural reasons for this (I have only a vague recollection about them, but they're there )-:). I believe there's not much that can be done about it, save rewriting your systems (asdf-dependency-grovel was made in part for this reason - to merge systems/modules into one), or rewriting asdf.
On 10/12/11 Oct 12 -11:34 AM, Andreas Fuchs wrote:
On Wed, Oct 12, 2011 at 09:06, Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com wrote:
I apologize in advance for the stupid newbie question that follows. I have the two systems below. When I change a file in cl-farm, it recompiles it, but when I demand loading of cl-farm-test again, ASDF does not recompile it, even though its dependency has changed. Why? Is this expected.
It is normal behavior for ASDF: Recompilation will only ever be triggered for components in the same module. (I'm not saying it's a good thing!)
That's actually not correct. ASDF fixed part of this problem. Cross-module changes DO trigger recompilation in ASDF 2. But cross SYSTEM changes do not.
There are a few architectural reasons for this (I have only a vague recollection about them, but they're there )-:). I believe there's not much that can be done about it, save rewriting your systems (asdf-dependency-grovel was made in part for this reason - to merge systems/modules into one), or rewriting asdf.
You don't need to do this rewriting any more.
best, r
On Wed, Oct 12, 2011 at 10:12, Robert Goldman rpgoldman@sift.info wrote:
On 10/12/11 Oct 12 -11:34 AM, Andreas Fuchs wrote:
On Wed, Oct 12, 2011 at 09:06, Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com wrote:
I apologize in advance for the stupid newbie question that follows. I have the two systems below. When I change a file in cl-farm, it recompiles it, but when I demand loading of cl-farm-test again, ASDF does not recompile it, even though its dependency has changed. Why? Is this expected.
It is normal behavior for ASDF: Recompilation will only ever be triggered for components in the same module. (I'm not saying it's a good thing!)
That's actually not correct. ASDF fixed part of this problem. Cross-module changes DO trigger recompilation in ASDF 2. But cross SYSTEM changes do not.
Huh, ok, then I was operating on outdated information. Last I looked, it was modules. In that case - nice work!
Thanks for the correction,
On 10/12/11 Oct 12 -12:41 PM, Andreas Fuchs wrote:
On Wed, Oct 12, 2011 at 10:12, Robert Goldman rpgoldman@sift.info wrote:
On 10/12/11 Oct 12 -11:34 AM, Andreas Fuchs wrote:
On Wed, Oct 12, 2011 at 09:06, Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com wrote:
I apologize in advance for the stupid newbie question that follows. I have the two systems below. When I change a file in cl-farm, it recompiles it, but when I demand loading of cl-farm-test again, ASDF does not recompile it, even though its dependency has changed. Why? Is this expected.
It is normal behavior for ASDF: Recompilation will only ever be triggered for components in the same module. (I'm not saying it's a good thing!)
That's actually not correct. ASDF fixed part of this problem. Cross-module changes DO trigger recompilation in ASDF 2. But cross SYSTEM changes do not.
Huh, ok, then I was operating on outdated information. Last I looked, it was modules. In that case - nice work!
Thanks for the correction,
At the expense of self-advertising, see the paper that Faré and I wrote about the new state of ASDF:
http://rpgoldman.real-time.com/papers/ilc2010-asdf.pdf
Cheers, r
On 10/12/11 Oct 12 -11:06 AM, Juan Jose Garcia-Ripoll wrote:
I apologize in advance for the stupid newbie question that follows.
I have the two systems below. When I change a file in cl-farm, it recompiles it, but when I demand loading of cl-farm-test again, ASDF does not recompile it, even though its dependency has changed. Why? Is this expected.
This all is based on the latest ASDF from git, invoked from Slime (but I do not think this makes a difference)
Juanjo
(defsystem :cl-farm :serial t :components ((:file "package") (:file "machines")))
(defsystem :cl-farm-test :depends-on (:rt :cl-farm) :serial t :components ((:file "tests/package") (:file "tests/files") (:file "tests/run")))
Unfortunately, this is the "correct" behavior for ASDF2. Change tracking in dependencies is not tracked across system boundaries.
I agree that this should be fixed, but I propose that fixing it is a gross enough change that when we do it, we should call the result "ASDF 3."
Note also that some people (I am not one of them) have said that this is a feature: that it should be the programmer's responsibility to track changes in a library's API. For the record, I think (as, I believe, you do) that it's more appropriate that the computer do this mental drudgery, instead of the programmer.
Best, Robert
-
Andreas Fuchs -
Faré -
Juan Jose Garcia-Ripoll -
Robert Goldman