On Wed, Dec 27, 2017 at 10:33 AM, Robert Goldman rpgoldman@sift.info wrote:
On 4 Dec 2017, at 21:56, Faré wrote:
Fixing the same potential issue with the (more stable but still evolvable) code in the core of ASDF will require applying the same solution to action.lisp all files that define new operations.
Will you please clarify this sentence? It looks like some editing error cost us some key words. Did you originally write "to action.lisp" and then decide it had to change to "to all files that define new operations"?
Oops, I meant to action.lisp AND all files that define new operations. Fixing action.lisp is trivial: change all the operation slots to methods. But *first* you need to change all clients to do the same, probably over a year (doing it in the other order doesn't work).
Alternatively, demand that suitable update-instance-for-redefined-class methods be written; but it's just as much work, and much more fragile. It's also slightly more backward compatible, especially if are aggressive bumping *oldest-forward-compatible-asdf-version*, but the fragility means that if someone makes an API call with an operation created before upgrade then things might go wrong (the operate :around method will catch that in the common case; but your uncommon case will be "interesting" to debug).
https://bugs.launchpad.net/asdf/+bug/1739514 Basically, ASDF fails spuriously rebuilds misnamed secondary systems and/or things that depend on them, instead of just issuing a warning as intended.
Another editing query here. Looks like it might be either "ASDF fails to rebuild" or "ASDF spuriously rebuilds misnamed..."
Yes, it's "ASDF spuriously rebuilds misnamed...".
Note that if it were a simple circular dependency, it would have just broken the build and be very visible and I'd have caught it last year.
Without having looked at the code or tried to debug it yet, my working hypothesis is that having "foo" in "foo.asd" depend on "bar" also defined in "foo.asd" causes dependency from (define-op "foo") to (define-op . "bar"), which is always in need of build because there is no "bar.asd" and the associated timestamp is therefore NIL. If that is correct, the backward-compatible solution would be to make sure that "bar" remembers that it was defined in "foo.asd", so that it gets the timestamp from "foo.asd", and the next time around, if there is no up-to-date "bar.asd", ASDF falls back on looking at the previously loaded "foo.asd" or a more up-to-date version of it.
Note that if "bar" is defined in both "foo.asd" and "bar.asd" you'll still have a mighty bug. Therefore people should still fix their code to properly name secondary system, ASDF should still issue a warning when they are misnamed, and this warning should still be upgraded to a cerror then an error when all of Quicklisp is fixed (>300 systems).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Rocky's Lemma of Innovation Prevention Unless the results are known in advance, funding agencies will reject the proposal.