[asdf-devel] Pushed version 220.127.116.11 -- first version with checks for OPERATION subclasses -- please test!
Robert P. Goldman
rpgoldman at sift.info
Wed Jan 22 15:46:26 UTC 2014
Attila Lendvai wrote:
>> For the record, I still think this intentional breakage is a bad idea.
>> In the short term, it causes a known inconvenience
> FTR, i pulled asdf when i saw the request for testing, tried to build
> our stuff, saw that iolib failed (a dependency), and then i decided to
> git reset and stay there until others struggle through this, even
> though we also have some operation subclasses.
> there are situations when the least inconvenient and most productive
> way of breaking backwards compatibility is by starting with a clean
Thank you. The PROCESS-OP in iolib will fail with the new test. There
are two possible solutions:
1. If you want the old behavior, where PROCESS-OP on a system should
cause PROCESS-OP to be applied to its children, make PROCESS-OP inherit
(defclass process-op (#-asdf3 asdf:operation #+asdf3
2. If you want the new behavior, where PROCESS-OP to a system does not
cause any dependent operations to occur, then make PROCESS-OP inherit
from asdf:non-propagating-operation. Perhaps a solution will be found
that does not require NON-PROPAGATING-OPERATION, but after prolonged
discussion, I am pessimistic.
>> PS: I used to avoid committing spaces at end of line.
>> I see that you have some.
> emacs has nice tools to show lose whitespace (see the varaible
> whitespace-style and there are some faces, too).
> it even has automatic cleanup, but that can be too intrusive when
> working on other people's code.
Yes, I turned these off in my editor. I ended up with too many
distracting red blocks on my screen, and then too many spurious diffs
when I would commit automatic whitespace cleanup.
I don't have a good solution to this problem. Maybe before we do the
final release, I could do a whitespace cleanup pass over all the source,
and make a single commit.
More information about the asdf-devel