I used to use it, then it broke months ago on my local setup so I just disabled it.

AFAICT, it is disabled by default, and it is not documented in the ASDF manual.> So is this code even live, except for in the test scripts?

It was pretty painful to get this to work because it relies on unexported (and hence unstable) SBCL internals.> My *guess* is that this was originally done as a way to dispense with WITH-COMPILATION-UNIT and hence potentially parallelize the compilations.> If no one is even using it, I am tempted to move it to be a contrib and drop it from the tests and maintenance as part of core ASDF. Maybe it would be better as a part of a POIU extension to ASDF, and relieve me of dealing with these SBCL compiler internals?> Cheers, r

-- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.

On Wed, May 30, 2018 at 6:01 PM Robert Goldman <rpgoldman@sift.info> wrote:

AFAICT, it is disabled by default, and it is not documented in the ASDF manual.

So is this code even live, except for in the test scripts?

It was pretty painful to get this to work because it relies on unexported (and hence unstable) SBCL internals.

My guess is that this was originally done as a way to dispense with WITH-COMPILATION-UNIT and hence potentially parallelize the compilations.

If no one is even using it, I am tempted to move it to be a contrib and drop it from the tests and maintenance as part of core ASDF. Maybe it would be better as a part of a POIU extension to ASDF, and relieve me of dealing with these SBCL compiler internals?

Sorry I only see this message now. I haven't used deferred warnings in quite some time (since QRes was cancelled), but I can comment on the design. The goal was to make undefined-function warnings usable in an incremental (not just parallel) context. Suppose a file A uses a function F, that is (supposed to be) defined in file B. Further, there is no dependency from A to B and indeed there may be a dependency from B to A, due to e.g. macros in A being used in B. If B fails to define F, then SBCL will issue a warning at the end of the "compilation unit", which since ASDF 1 has always been "the entire ASDF build". Now, if we're in an incremental build, and A was previously compiled, then A.fasl is loaded, SBCL doesn't even register that a function was used before it was defined, and no warning is issued at all. In the case of a parallel build with no dependency between A and B, then, depending on the compilation unit situation, either there would always be a spurious warning or never a warning at all compiling A, and never a warning afterwards. This made those warnings less than useful at ITA. Some hacker at ITA got the idea of saving the context for these warnings (maybe James Knight? he usually had all the clever ideas). It was first implemented for SBCL by Douglas Katzman, and I made it part of XCVB, POIU, and later ASDF 3. This was really nice to have at ITA. However, when I proposed making it the default in ASDF 3, the proposal was immediately met with a huge backlash from the community, so the feature remained disabled, and may have bitrotten. One thing (that I've done) is sending patches to hundreds of projects to fix their builds that depended on unsupported or deprecated ASDF behavior that was refactored away, when the system authors will welcome the patches. Another thing that I learned not to try (after the XCVB debacle) is try to maintain software patches against the wishes of the authors. I apologize for never documenting it. My bad. With the poor reception, I wasn't motivated. Moreover, for QRes we had this configuration layer whereby the third-party libraries we depended on were usually compiled with many more warnings disabled than when building our code, where we disabled some warnings but enabled others. The code is part of the quux code dump on qitab, but would be pain to document. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Anyone who goes to a psychiatrist ought to have his head examined. — Samuel Goldwyn