[asdf-devel] Trying again

Robert Goldman rpgoldman at sift.info
Thu Feb 11 16:39:17 UTC 2010


On 2/10/10 Feb 10 -10:38 PM, Faré wrote:
> On 10 February 2010 18:27, Robert Goldman <rpgoldman at sift.info> wrote:
>> OK, I have just pushed an alternative solution to the module dependency
>> bug, this one (I believe) only triggered by INTRA-system dependencies.
>> This one is also on the module-depends branch.
>>
> A test! This requires a test case in the test suite (and not a suit in
> the suitcase).

Correct.  We need a test where there's an inter-system dependency, we
modify an upstream system and we check to see what is done.
> 
>> This was achieved, as I said, at the cost of some hair, but I believe it
>> does the right thing to the extent that I understand the right thing,
>> and thinking about James's email convinced me that I /don't/ understand
>> what is the right thing with respect to inter-system dependencies.
>>
> I think you do understand the right thing, and that James is wrong to
> want ASDF to somehow DWIM.
> If you want to distinguish in code into parts that are depended on and
> parts that are not, then split your code into two systems.
> System foo-interface provides the interface, with packages, macros,
> specials, types, classes, gfs, and anything that matters at
> compile-time.
> System foo-implementation provides the implementation, with everything
> else. Clients depend on foo-interface and get recompiled if the
> interface changes. The overall system depends on interface AND implementation.
> 
> In other words, on top of a system that does the Right Thing(tm), i.e.
> invalidate dependencies recursively, you can do whatever you want,
> though it may take some effort. On top of a broken system, you always
> and forever have something broken.
> 
>> Somewhat disappointingly, this commit agrees with the last one on the
>> tests, which indicates that the tests need to be augmented...
>>
>> Additional reviews very welcome as are test results!
>>
> No time for that right now. Hopefully tomorrow.

I think to be fair to James he's not saying that ASDF should DWIM, he
was asking for a minimum perturbation fix.

What I took from this was that a minimum perturbation fix is to make
ASDF handle the easy case (INTRA-system module dependencies), test and
incorporate that fix and move on to a better fix later.

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.

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.

The advantage of my currently-committed patch is that, I believe, it
confines itself to a single case where The Right Thing is not debatable
--- I don't think *anyone* could make a case for the current ASDF
behavior, nor against the behavior that I've added.

You and I are in agreement that the behavior I've added is necessary but
not sufficient.  I don't think the fact that the current fix fails to
handle INTER-system dependencies should be allowed to keep us from
fixing INTRA-system dependencies.

I don't think James's arguments mitigate against pushing my modification
onto the trunk, either.  Again, the argument is that the current changes
are not sufficient, not that they are wrong.

Unless I hear a serious argument against doing this by the end of the
day tomorrow, I will push the fix for INTRA-system module dependencies
into the trunk and kill the module-depends branch.

THEN we can go ahead and figure out how to fix INTER-system dependencies.

Best,
r





More information about the asdf-devel mailing list