Re: WARNING: System definition file ...

[Faré]

On Thu, Oct 12, 2017 at 7:17 AM, Stas Boukarev  wrote:
> Yes, SBCL has a deprecation process that goes through several stages which
> span several years. QUIT signals a style-warning, not warning, and is
> unlikely to ever signal a warning and will never go away.
>
.asd files are load'ed and not compile-file'd so the difference
between warning and style-warning there is inconsequential.

And yes, the deprecation process for ASDF also takes many years, and
the warning won't turn into an error for at least two years to come
and maybe more. Some of the deprecated functions will probably forever
remain style-warning's. Other functions may be escalated to warnings
or errors.

> If you're willing to fix all the affected systems just go through quicklisp,
> it'll have plenty. But maybe that should be done before introducing new
> warnings.
>
I've done that kind of stuff in the past and will keep doing it. The
warning is how you get things fixed. Just like with SBCL deprecation.

—♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org
[I]f we wish to count lines of code, we should not regard them as "lines
produced" but as "lines spent": the current conventional wisdom is so foolish
as to book that count on the wrong side of the ledger. — E. W. Dijkstra

Re: WARNING: System definition file ...

[Stas Boukarev]

Yes, SBCL has a deprecation process that goes through several stages which
span several years. QUIT signals a style-warning, not warning, and is
unlikely to ever signal a warning and will never go away.

If you're willing to fix all the affected systems just go through
quicklisp, it'll have plenty. But maybe that should be done before
introducing new warnings.

On Thu, Oct 12, 2017 at 2:05 PM Faré  wrote:

> On Thu, Oct 12, 2017 at 6:00 AM, Stas Boukarev  wrote:
> > I get 12 warnings with "System definition file  contains definition for
> > system . Please only define and secondary systems with a name starting
> with
> > in that file." while loading a single project.
> >
> These are valid warnings, and those systems must be fixed. Can you
> give me a list of the affected systems, so I may send patches
> upstream?
>
> Background: Secondary systems (systems loaded in a .asd file beside
> the "primary" system that the .asd file is named after) that do not
> follow the / convention can't be found by name by ASDF before the .asd
> file is loaded; they can clash with other systems and then cause
> "interesting" behavior. They were an abuse that kind of worked but not
> really from the bad old ASDF 1 days. ASDF 3 fully supports secondary
> systems, but requires them to start with a prefix of foo/ where foo is
> the primary system name (that the .asd file is named after). The old
> behavior is still supported at this time, but we started issuing
> warnings this year, together with other deprecation warnings.
>
> > How do I disable these warnings? If we are to update ASDF in SBCL I want
> to
> > make the asdf.lisp version bundled with SBCL to have them disabled by
> > default.
> >
> The best way to disable to warnings is to fix the 12 affected libraries.
>
> If you modify ASDF to remove that message, please change all
> occurrences of "3.3.0" to "3.3.0.0.1" in the sources, too, to indicate
> one local change.
>
> > And if some future version of ASDF stops loading any of the 12 libraries,
> > then I just won't update SBCL to that ASDF version.
> >
> ASDF won't stop supporting that feature for at least the next 2 years.
> Those 12 libraries will have that much time to be fixed. If the last
> maintainers have quit, the libraries will have to be taken over by
> e.g. sharplispers some time before then.
>
> Experience shows that 2 years is about the time it takes for some
> change to "fully" propagate through the Common Lisp community (e.g.
> for a new version of ASDF to be used by all implementations). It is
> not an unreasonable target for backward compatibility of ASDF. I see
> no good reason to keep 15 or 26 year old bugs around indefinitely.
>
> SBCL does introduce new warnings at times, that sometimes affect tens
> of existing systems (e.g. the quit / exit renaming). I see no
> principled reason for SBCL to shy away from legitimate warnings from
> ASDF. How long did SBCL maintain backward compatibility with the old
> calling convention?
>
> PS: I wrote a function
> ql-test:find-misnamed-secondary-asdf-systems-in-quicklisp in my system
> ql-test https://gitlab.common-lisp.net/frideau/ql-test and it finds
> 330 suspect defsystem entries in quicklisp. Some are templates that
> can be ignored (and probably filtered out of this function), but most
> are legitimate issues that must be fixed in the next two years.
>
> —♯ƒ • François-René ÐVB Rideau •Reflection•
> http://fare.tunes.org
> If debugging is the process of removing bugs,
> then programming must be the process of putting them in.
> — Dijkstra
>

Re: WARNING: System definition file ...

[Faré]

On Thu, Oct 12, 2017 at 6:00 AM, Stas Boukarev  wrote:
> I get 12 warnings with "System definition file  contains definition for
> system . Please only define and secondary systems with a name starting with
> in that file." while loading a single project.
>
These are valid warnings, and those systems must be fixed. Can you
give me a list of the affected systems, so I may send patches
upstream?

Background: Secondary systems (systems loaded in a .asd file beside
the "primary" system that the .asd file is named after) that do not
follow the / convention can't be found by name by ASDF before the .asd
file is loaded; they can clash with other systems and then cause
"interesting" behavior. They were an abuse that kind of worked but not
really from the bad old ASDF 1 days. ASDF 3 fully supports secondary
systems, but requires them to start with a prefix of foo/ where foo is
the primary system name (that the .asd file is named after). The old
behavior is still supported at this time, but we started issuing
warnings this year, together with other deprecation warnings.

> How do I disable these warnings? If we are to update ASDF in SBCL I want to
> make the asdf.lisp version bundled with SBCL to have them disabled by
> default.
>
The best way to disable to warnings is to fix the 12 affected libraries.

If you modify ASDF to remove that message, please change all
occurrences of "3.3.0" to "3.3.0.0.1" in the sources, too, to indicate
one local change.

> And if some future version of ASDF stops loading any of the 12 libraries,
> then I just won't update SBCL to that ASDF version.
>
ASDF won't stop supporting that feature for at least the next 2 years.
Those 12 libraries will have that much time to be fixed. If the last
maintainers have quit, the libraries will have to be taken over by
e.g. sharplispers some time before then.

Experience shows that 2 years is about the time it takes for some
change to "fully" propagate through the Common Lisp community (e.g.
for a new version of ASDF to be used by all implementations). It is
not an unreasonable target for backward compatibility of ASDF. I see
no good reason to keep 15 or 26 year old bugs around indefinitely.

SBCL does introduce new warnings at times, that sometimes affect tens
of existing systems (e.g. the quit / exit renaming). I see no
principled reason for SBCL to shy away from legitimate warnings from
ASDF. How long did SBCL maintain backward compatibility with the old
calling convention?

PS: I wrote a function
ql-test:find-misnamed-secondary-asdf-systems-in-quicklisp in my system
ql-test https://gitlab.common-lisp.net/frideau/ql-test and it finds
330 suspect defsystem entries in quicklisp. Some are templates that
can be ignored (and probably filtered out of this function), but most
are legitimate issues that must be fixed in the next two years.

—♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org
If debugging is the process of removing bugs,
then programming must be the process of putting them in.
— Dijkstra

Re: WARNING: System definition file ...

[Stas Boukarev]

I get 12 warnings with "System definition file  contains definition for
system . Please only define and secondary systems with a name starting with
in that file." while loading a single project.

How do I disable these warnings? If we are to update ASDF in SBCL I want to
make the asdf.lisp version bundled with SBCL to have them disabled by
default.

And if some future version of ASDF stops loading any of the 12 libraries,
then I just won't update SBCL to that ASDF version.

On Thu, Oct 12, 2017 at 5:22 AM Faré  wrote:

> On Wed, Oct 11, 2017 at 9:14 PM, Stas Boukarev  wrote:
> > 3.3.0 issues a barrage of new warnings about something it has decided is
> > uncouth now.
> >
> On what systems is it issuing warnings? Any free software that we can
> patch?
>
> Without specific warnings coming from specific libraries, it's hard to
> tell what can be fixed, what cannot, what is an actual problem with
> the code you're using, what is possibly a problem about ASDF itself,
> etc.
>
> Odds are, the something had been decided as uncouth long ago, and ASDF
> just lacked the means to warn you about it.
>
> > I really have no wish to stare at these warnings coming from third party
> > libraries, especially since they're never going to be fixed.
> > Is the old behavior posing problems? Is the old behavior going away soon?
> >
> Yes, some old behavior is posing problem and has for years. Sometimes
> the old behavior has already gone away and/or is precariously emulated
> in slightly incompatible ways using the newer better interface.
> Sometimes we really want to get away from a really bad interface that
> has been deprecated for years (e.g. run-shell-command, which is a
> security liability in addition to been challenged with usability).
> Sometimes a recent refactoring made some operation non-sensical (e.g.
> operation-on-warnings) and/or not so useful (e.g. require-system), or
> a really bad interface to the system (system-registered-p).
>
> Depending on the interfaces, the old behavior may go away within two
> year, especially where supporting it is problematic and/or the
> interface is bogus and misleading and not properly doing what it was
> once advertised to be used for. Well, whoever is maintainer then will
> probably do something conservative that preserves compatibility (with
> some kind of warning) wherever it isn't an encouragement to writing
> nonsensical code.
>
> > This is why I don't update ASDF, I don't want to change anything in my
> code
> > because of a new version.
>
> Last I heard, janderson was using his own slightly forked ASDF 1, and
> some russians had forked ASDF 2.
>
> On the other hand, some programs depend on a recent ASDF, such as
> IOlib or CFFI, or scripts that depend on a fixes run-program or on its
> younger sibling launch-program, especially so on SBCL/Windows.
>
> There is no pleasing everyone, but there's going forward. SBCL also
> sometimes deprecates some old interfaces, and issues warnings to those
> who use them.
>
> —♯ƒ • François-René ÐVB Rideau •Reflection•
> http://fare.tunes.org
> Every four seconds a woman has a baby.
> Our problem is to find this woman and stop her.
>

Re: WARNING: System definition file ...

[Faré]

On Wed, Oct 11, 2017 at 9:14 PM, Stas Boukarev  wrote:
> 3.3.0 issues a barrage of new warnings about something it has decided is
> uncouth now.
>
On what systems is it issuing warnings? Any free software that we can patch?

Without specific warnings coming from specific libraries, it's hard to
tell what can be fixed, what cannot, what is an actual problem with
the code you're using, what is possibly a problem about ASDF itself,
etc.

Odds are, the something had been decided as uncouth long ago, and ASDF
just lacked the means to warn you about it.

> I really have no wish to stare at these warnings coming from third party
> libraries, especially since they're never going to be fixed.
> Is the old behavior posing problems? Is the old behavior going away soon?
>
Yes, some old behavior is posing problem and has for years. Sometimes
the old behavior has already gone away and/or is precariously emulated
in slightly incompatible ways using the newer better interface.
Sometimes we really want to get away from a really bad interface that
has been deprecated for years (e.g. run-shell-command, which is a
security liability in addition to been challenged with usability).
Sometimes a recent refactoring made some operation non-sensical (e.g.
operation-on-warnings) and/or not so useful (e.g. require-system), or
a really bad interface to the system (system-registered-p).

Depending on the interfaces, the old behavior may go away within two
year, especially where supporting it is problematic and/or the
interface is bogus and misleading and not properly doing what it was
once advertised to be used for. Well, whoever is maintainer then will
probably do something conservative that preserves compatibility (with
some kind of warning) wherever it isn't an encouragement to writing
nonsensical code.

> This is why I don't update ASDF, I don't want to change anything in my code
> because of a new version.

Last I heard, janderson was using his own slightly forked ASDF 1, and
some russians had forked ASDF 2.

On the other hand, some programs depend on a recent ASDF, such as
IOlib or CFFI, or scripts that depend on a fixes run-program or on its
younger sibling launch-program, especially so on SBCL/Windows.

There is no pleasing everyone, but there's going forward. SBCL also
sometimes deprecates some old interfaces, and issues warnings to those
who use them.

—♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org
Every four seconds a woman has a baby.
Our problem is to find this woman and stop her.

WARNING: System definition file ...

[Stas Boukarev]

3.3.0 issues a barrage of new warnings about something it has decided is
uncouth now.
I really have no wish to stare at these warnings coming from third party
libraries, especially since they're never going to be fixed.
Is the old behavior posing problems? Is the old behavior going away soon?

This is why I don't update ASDF, I don't want to change anything in my code
because of a new version.