Problem with adding input files...
Faré
fahree at gmail.com
Fri Jun 30 18:54:03 UTC 2017
> 1. When I invoke LOAD-OP the second time, why is ACTION-UP-TO-DATE-P
> never called? What short-circuits this?
>
ACTION-UP-TO-DATE-P only applies to your DEFSYSTEM-DEPENDS-ON
dependencies. If you have none, it won't be called. What will be
called in your case is the regular COMPUTE-ACTION-STATUS ->
COMPUTE-ACTION-STAMP. What ACTION-UP-TO-DATE-P does, compared to
TRAVERSE-ACTION, is query whether the dependency is up-to-date
*without* marking it needed if it is out-of-date (because it might not
actually be needed anymore after the system that had the
defsystem-depends-on is invalidated).
> 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).
>
Good! That's what matters. Does that timestamp indeed include that of
your read-file-line input files?
> 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.
>
Yes! That's totally the intended process.
> 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.
>
The DEFINE-OP should still have a previous COMPONENT-OPERATION-TIME,
and checking that it matches the computed stamp is the last step of
COMPUTE-ACTION-STAMP (or else the previous performance is
invalidated).
Actually, this suggests a performance bug whereby ASDF does over
recomputation: if you perform a (not needed-in-image) action, then it
gets out-of-date, but some *other process* performs and makes it up to
date, then we do not need to look at the COMPONENT-OPERATION-TIME!
> 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.
>
Don't butcher anything: this function was years in the making.
We (1) infer a timestamp from inputs and dependencies, and
(2) compare this timestamp to what was previously performed,
to see if it must be done again. But indeed this second check
is only meaningful for needed-in-image actions.
> It seems inelegant, and also I'm not very confident in how I apportioned
> functions to the different ASDF component files/packages. I don't
> richly understand the dependency structure laid out in asdf.asd, so
> there was a little trial and error involved in code placement.
>
Did you add a new file?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Statism is the secular version of salvation through faith: it doesn't
matter what bureaucrats do, only that they do it with good intentions.
More information about the asdf-devel
mailing list