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.
On Wed, Oct 11, 2017 at 9:14 PM, Stas Boukarev stassats@gmail.com 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&Cybernethics• http://fare.tunes.org Every four seconds a woman has a baby. Our problem is to find this woman and stop her.
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é fahree@gmail.com wrote:
On Wed, Oct 11, 2017 at 9:14 PM, Stas Boukarev stassats@gmail.com 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&Cybernethics• http://fare.tunes.org Every four seconds a woman has a baby. Our problem is to find this woman and stop her.
On Thu, Oct 12, 2017 at 6:00 AM, Stas Boukarev stassats@gmail.com 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&Cybernethics• http://fare.tunes.org If debugging is the process of removing bugs, then programming must be the process of putting them in. — Dijkstra
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é fahree@gmail.com wrote:
On Thu, Oct 12, 2017 at 6:00 AM, Stas Boukarev stassats@gmail.com 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&Cybernethics• http://fare.tunes.org If debugging is the process of removing bugs, then programming must be the process of putting them in. — Dijkstra
On Thu, Oct 12, 2017 at 7:17 AM, Stas Boukarev stassats@gmail.com 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&Cybernethics• 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
-
Faré -
Stas Boukarev