On 6/30/17 Jun 30 -10:35 AM, Faré wrote:
>> On 6/30/17 Jun 30 -10:11 AM, Faré wrote:
>>> First, can you confirm that the compute-action-stamp called by
>>> mark-operation-done called by the perform :after method on define-op
>>> returns the correct value?
>>
>> Hm. I don't see any such after method. All I see is this:
>>
>> (defmethod perform ((o define-op) (s system))
> ...
>> (if-let ((pathname (first (input-files o s)))))
> ...
> This call to input-files is problematic, as it will cause the wrong
> value to be cached, before you recorded your input-files. Note that
> you might have to invalidate the cached input-files anyway, because it
> may already have been called by compute-action-stamp at that point.
>
> But I meant the general perform :after method and mark-operation-done
> method from action.lisp.
OK, I see this:
(defmethod perform :after ((o operation) (c component))
(mark-operation-done o c))
That's going to compute a time stamp for the operation. I think that's
OK, because that will be done after the first time the DEFINE-OP is
executed. Ideally, when we go to do it the second time, this timestamp
will be compared with the last write time on the input files (in this
case a revision-number.lisp-expr file), and should trigger the DEFINE-OP
to be done again.
But obviously I'm missing something, since this is not happening.
Actually, there are a bunch of things I don't understand, including:
1. When I invoke LOAD-OP the second time, why is ACTION-UP-TO-DATE-P
never called? What short-circuits this?
2. COMPONENT-OPERATION-TIME is called on DEFINE-OP of SYSTEM at what
looks like the right time (as well as being called a bunch of other
times, presumably to check that it's up-to-date with respect to
downstream components).
3. Looks like COMPUTE-ACTION-STATUS calls COMPUTE-ACTION-STAMP. Looks
like that is where we compute whether or not the operation is up-to-date
wrt the input files.
4. This is likely to be the problem: we compare the time stamp of the
input files against the earliest time stamp of the output files. But
there are no output files from the define-op, so we do
UP-TO-DATE-P = (STAMP<= <number> NIL)
and STAMP<= is defined to always be true if the second argument is null.
So there is no point in the algorithm -- or at least no point that I can
see -- where we compare the input-file time stamps against the
component-operation-time.... I could butcher that in, but I'm a little
worried -- the logic in COMPUTE-ACTION-STAMP is quite subtle.
Anyway, that's how I'm proceeding.
>
>> At any
>> rate, I'm having a hard time tracking down exactly where we determine
>> whether or not a define-op needs redoing.
> Ultimately, it boils down to (compute-action-stamp plan operation
> component [nil]) as called by compute-action-status in plan.lisp. And
> *that* will call input-files.
>
>> The caching code makes things
>> much more efficient, but it also effectively camouflages the algorithm....
>>
> Not just "more efficient", but in some cases keeps O(n) what might be
> a much higher polynomial (or exponential?) when a module's input-files
> recursively depend on its contents (e.g. for warning checking). But
> yes, sometimes you need to invalidate the cache, and this looks like
> one of those times to me.
>
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> Too many people are thinking of security instead of opportunity. They seem
> more afraid of life than death.
> — James F. Byrnes
>
