Discussion:
Is anyone actually using the deferred warnings code?
Robert Goldman
2018-05-30 22:01:11 UTC
Permalink
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
2018-05-30 22:28:27 UTC
Permalink
I used to use it, then it broke months ago on my local setup so I just
disabled it.
Post by Robert Goldman
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.
Robert Goldman
2018-05-30 22:50:57 UTC
Permalink
Post by Stelian Ionescu
I used to use it, then it broke months ago on my local setup so I just
disabled it.
Two questions:

1. I'm curious about why you used it. Anything you could share would be
helpful.

2. Was the breakage due to the change in the compiler internals? If so,
the merge request I just sent off should fix it (and I hope to have a
new release with it integrated soon).

Best,
r
Post by Stelian Ionescu
Post by Robert Goldman
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.
Faré
2018-08-06 01:13:24 UTC
Permalink
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

Loading...