On 2010-02-12, at 17:17 , Robert Goldman wrote:
On 2/12/10 Feb 12 -4:48 AM, james anderson wrote:
good morning;
On 2010-02-12, at 06:11 , Faré wrote:
[...]
The problem with doing the INTER-system dependencies is that I don't believe that ASDF currently has the infrastructure to do The Right Thing. In order to do the right thing, each system would have to store with itself information about the state of the dependencies when it was built.
A timestamp is all you should be needing. What else do you need, really?
Pace Daniel H, I don't believe that timestamps on files is sufficient to do this. We have developed an API based on operation-done-p, and I don't believe that operation-done-p is sufficient for this. Timestamps on files is sufficient for make, but I'm not confident it's sufficient for ASDF. At any rate, I believe that we need to go through a process of making proposals about a protocol that will do the right thing, and then move on.
Maybe the current timestamps in ASDF are somewhat lacking, but that doesn't mean timestamps can't solve the issue. I think that one timestamp per pair (op component) should do the trick, stored as an alist (op timestamp) in a slot of the component.
is that not what the `operation-time` cache[1] is already there to do? (traverse x operation-done-p) reads as if module-level "done-p" is hard-coded[2] with logic, which is different than that for components in general, and which does not act on this cache. perhaps some protocol additions would work here.
One problem is that this cache does not survive across lisp sessions, so we can't appeal to it to establish correctness when our lisp first starts up (unless we add code to populate the cache with inferred compilation times).
one might conclude, that the (cache x done-p) semantics should be defined such that they yield the same results for respective external states across system instantiations.
A second problem is that there are two meanings to performing an operation on a system, and these two meanings need to be teased apart. (I don't believe this distinction is helpful.)
[? this parenthetical sentence and the preceding clause can be read such that they contradict each other.]
One meaning is the intuitive one: to operate on a module is to operate on all of its components. The second is the less intuitive tree walking one: there is a tree node that corresponds to operating on the module proper, and we do the operation by calling PERFORM on the operation and module objects.
once one has arrived to the point, where each "component" can concern internal, intrinsic performance, that of constituents, and that of requirements, one is able to consider for which component classes which combinations of (internal x constituent x requirement) performance have which effects on completion status. yes, that is an essential step.
With respect to your point about module level done-p being hard- coded, I agree --- I discussed this in terms of the distinction between operation-done-p and traverse, in my earlier response to Faré. Note that the unhelpful dual definition of performing an operation on a module almost forces this distinction.
yes, your #3 in that earlier message, suggests that you may also have reached the point, above.