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 > slate.
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 from DOWNWARD-OPERATION: (defclass process-op (#-asdf3 asdf:operation #+asdf3 asdf:downward-operation) ...) 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. Best, r
