Summary: I'm considering a "whitelist" approach for allowing old software to be compiled without checking deferred warnings while they remain enabled by default for all new software. But implementation is prolematic.
Over a week after I contacted every maintainer of a Quicklisp system with a known issue with ASDF3, half replied only (26 out of 51), most of them (19) by fixing the new found bug in their code, a few of them (3) by declaring their package unmaintained (lisp-on-lines cambl-test xmls-tools), a few of them (4) working on it.
There may be more problematic systems not found by Anton's cl-test-grid yet, because they depend on a system that breaks the build earlier.
Therefore, it seems unreasonable to expect all these systems to be updated in a timely manner (or maybe ever at all).
Since the entire idea of ASDF2, as told in rpgoldman's and my 2010 paper "Evolving ASDF: More Cooperation, Less Coordination" is that upgrading should require less rather than more coordination between hackers, it is time that I declare this simultaneous change towards checking deferred warnings as a failure.
The question then being, what next? Is there any way that ASDF can ever enforce new code restriction to help developers without breaking things for users of existing software?
My proposal is that ASDF should have a new configuration mechanism that lets users override some settings in other systems without modifying the .asd file, and have default values for this mechanism that disable the checking of warnings on old enough copies of a system. ASDF would come with builtin such configuration (ignorable as usual with :ignore-inherited-configuration) to handle all the known systems that fail.
The detection of what system is "old enough" is itself a challenge. Unhappily, git doesn't preserve timestamps by default (there are scripts floating around to touch each file with the date of its latest modifying commit, but that's not the default behaviour), and neither does darcs. We therefore can't assume the filesystem timestamp of the .asd file was preserved from the original source archive. We could then use the asdf :version as the basis for such overrides, but that would force the authors of any such system to adopt the ASDF versioning system when they previously weren't.
What do you think?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Designing a computer programming system that doesn't address transactional persistence means that you're proud of having no data worth keeping.
On Sat, 2013-03-02 at 13:40 -0500, Faré wrote:
Summary: I'm considering a "whitelist" approach for allowing old software to be compiled without checking deferred warnings while they remain enabled by default for all new software. But implementation is prolematic.
Over a week after I contacted every maintainer of a Quicklisp system with a known issue with ASDF3, half replied only (26 out of 51), most of them (19) by fixing the new found bug in their code, a few of them (3) by declaring their package unmaintained (lisp-on-lines cambl-test xmls-tools), a few of them (4) working on it.
There may be more problematic systems not found by Anton's cl-test-grid yet, because they depend on a system that breaks the build earlier.
Therefore, it seems unreasonable to expect all these systems to be updated in a timely manner (or maybe ever at all).
Since the entire idea of ASDF2, as told in rpgoldman's and my 2010 paper "Evolving ASDF: More Cooperation, Less Coordination" is that upgrading should require less rather than more coordination between hackers, it is time that I declare this simultaneous change towards checking deferred warnings as a failure.
The question then being, what next? Is there any way that ASDF can ever enforce new code restriction to help developers without breaking things for users of existing software?
My proposal is that ASDF should have a new configuration mechanism that lets users override some settings in other systems without modifying the .asd file, and have default values for this mechanism that disable the checking of warnings on old enough copies of a system. ASDF would come with builtin such configuration (ignorable as usual with :ignore-inherited-configuration) to handle all the known systems that fail.
The detection of what system is "old enough" is itself a challenge. Unhappily, git doesn't preserve timestamps by default (there are scripts floating around to touch each file with the date of its latest modifying commit, but that's not the default behaviour), and neither does darcs. We therefore can't assume the filesystem timestamp of the .asd file was preserved from the original source archive. We could then use the asdf :version as the basis for such overrides, but that would force the authors of any such system to adopt the ASDF versioning system when they previously weren't.
What do you think?
It's a very good idea. The configuration mechanism is the last big hurdle preventing a virtual environment for Common Lisp. I think you should disable deferred warnings by default and keep filing bugs, postponing their re-enabling for 6-12 months.
On Sat, Mar 2, 2013 at 1:50 PM, Stelian Ionescu sionescu@cddr.org wrote:
It's a very good idea. The configuration mechanism is the last big hurdle preventing a virtual environment for Common Lisp. I think you should disable deferred warnings by default and keep filing bugs, postponing their re-enabling for 6-12 months.
Better late than never, I have disabled deferred warnings check by default in 2.31.6.
I will think of a better upgrade plan before I try to push that change again.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "I'm not a procrastinator, I'm temporally challenged"
I think it's right to disable the deferred warnings check by default, but at the same time I would recommend everyone to enable it in his lisp initialization file.
Yesterday I started to use ASDF 2.31.1 where deferred warnings are checked. And found 3 bugs in the code I am working on (like referencing a special variable removed long ago, just having an accidentally typed letter 'd' in the middle of a function code, and a typo in variable name).
Bugs hasn't affected me yet because I normally do not use the system in a way where the bugs will be enabled. I am glad that compiler notices the bugs and that ASDF now can inform me about them.
I am not ready to propose upgrade plan. Do to so I need to learn better what warnings may detected by this new feature, and in general learn and think more about warning handling.
02.03.2013, 23:07, "Faré" fahree@gmail.com:
On Sat, Mar 2, 2013 at 1:50 PM, Stelian Ionescu sionescu@cddr.org wrote:
It's a very good idea. The configuration mechanism is the last big hurdle preventing a virtual environment for Common Lisp. I think you should disable deferred warnings by default and keep filing bugs, postponing their re-enabling for 6-12 months.
Better late than never, I have disabled deferred warnings check by default in 2.31.6.
I will think of a better upgrade plan before I try to push that change again.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "I'm not a procrastinator, I'm temporally challenged"
asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
BTW, one more complication. We have only compared how deferred-warnings mode affects quicklisp libraries on SBCL.
But as different compilers may signal different warnings, it is possible that other libraries will be affected on other compilers. (Although I think SBCL is the most strict in this sense? Or not?)
it is time that I declare this simultaneous change towards checking deferred warnings as a failure.
i haven't experimented much with this infrastructure, so take it with a piece of salt... but maybe there's a middle ground, where the new warnings get printed but the load/compile is not forced to fail? or that's the case already?
On Sun, Mar 3, 2013 at 2:17 AM, Attila Lendvai attila.lendvai@gmail.com wrote:
it is time that I declare this simultaneous change towards checking deferred warnings as a failure.
i haven't experimented much with this infrastructure, so take it with a piece of salt... but maybe there's a middle ground, where the new warnings get printed but the load/compile is not forced to fail? or that's the case already?
Well, the checking obeys *compile-file-warnings-behaviour* and *compile-file-failure-behaviour*, so it will only cause the build to fail when there is a full warning, on SBCL and MKCL.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In a five year period we can get one superb programming language. Only we can't control when the five year period will begin. — Alan Perlis
-
Anton Vodonosov -
Attila Lendvai -
Faré -
Stelian Ionescu