On Thu, May 25, 2017 at 6:45 PM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
Finally results:
No new failures on ASDF 3.1.7 and 3.2.1.
Yaaaay!
ASDF 3.3.0 has failures: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-65.html
Thanks. Interesting. A whole lot of failures seem to be related to using now-deprecated functions, that since 3.2.0 where causing ASDF to issue a STYLE-WARNING, but with 3.3.0 are causing it to issue a full WARNING. I'll send patches. Sent new patches: * metatilities - was already fixed, but quicklisp had the old darcs repo https://github.com/quicklisp/quicklisp-projects/issues/1323 * mgl-pax (affects micmac) https://github.com/melisgl/mgl-pax/pull/3 * weblocks https://github.com/skypher/weblocks/pull/53 * wuwei https://github.com/mtravers/wuwei/pull/16 * yaclml https://github.com/sharplispers/yaclml/pull/1 Still unmerged from my work last time(!), looks unmaintained, sent a ping: * bknr-web https://github.com/hanshuebner/bknr-web/pull/4 * check-it https://github.com/DalekBaldwin/check-it/pull/20 * cl-blapack https://github.com/blindglobe/cl-blapack/pull/8 * cxml-rng (patch sent to the author; I could create a github mirror if needed) * jwacs https://github.com/chumsley/jwacs/pull/2 * macrodynamics https://github.com/DalekBaldwin/macrodynamics/pull/1 * madeira-port (affects sb-cga, mathkit, linedit, glkit) https://github.com/nikodemus/madeira-port/pull/6 * org-sampler (affects nst) (patch sent to the author, who doesn't use git) * s-dot (patch sent to the author, who doesn't use git) Works for me: * cl-rrt * eco * inner-conditional * toms717 I refuse to touch this: * lisp-executable Considering these results, I think that the candidate ASDF 3.3.0 would usefully be committed next month. What do you think? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If you don't like yourself, you *can't* like other people. — Robert Heinlein, "Time Enough For Love"
On 5/26/17 May 26 -6:06 PM, Faré wrote:
Considering these results, I think that the candidate ASDF 3.3.0 would usefully be committed next month. What do you think?
I'm still trying to catch up a bit on the latest changes, but I'm inclined to agree, yes. Also, I'd like to check in with Xach about QL status. Best, r
Why? Because the function has been deprecated for many many years. The only reason it hasn't signaled a style-warning before is because ASDF lacked the infrastructure to do so. When? Is a better question. Now that ASDF does have this deprecation infrastructure (since 3.2.0 in last January), is it a good time, less than 6 months later and without massive adoption of 3.2.0, to ramp up from style-warning to full warning? Maybe not. I'm thinking that the full warning may be usefully pushed back a few more months. -#f On Sun, May 28, 2017, 17:54 Anton Vodonosov <avodonosov@yandex.ru> wrote:
27.05.2017, 02:06, "Faré" <fahree@gmail.com>:
ASDF 3.3.0 has failures: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-65.html
Thanks. Interesting.
A whole lot of failures seem to be related to using now-deprecated functions, that since 3.2.0 where causing ASDF to issue a STYLE-WARNING, but with 3.3.0 are causing it to issue a full WARNING. I'll send patches.
Fare, why do you want to fail compilation with WARNING on ASDF:SYSTEM-DEFINITION-PATHNAME usage? (http://cl-test-grid.appspot.com/blob?key=1ipz631lkv)
Best regards, - Anton
On 5/31/17 May 31 -9:28 AM, Faré wrote:
Why? Because the function has been deprecated for many many years. The only reason it hasn't signaled a style-warning before is because ASDF lacked the infrastructure to do so.
When? Is a better question. Now that ASDF does have this deprecation infrastructure (since 3.2.0 in last January), is it a good time, less than 6 months later and without massive adoption of 3.2.0, to ramp up from style-warning to full warning? Maybe not. I'm thinking that the full warning may be usefully pushed back a few more months.
Suggestion: can we make an ASDF-specific subclass of STYLE-WARNING so that programmers have the option of catching it and handling it? Here's why I ask: at our company, we routinely have Jenkins jobs where we fail on even style-warnings (otherwise people got sloppy and left them around, leading to real bugs not being caught). Now we simply have a zero-tolerance policy. If one has to use a library that uses deprecated ASDF functions while it's being fixed, it would be nice to be able to muffle just such warnings, instead of having no option but to pull out the big club and muffle all style warnings. Cheers, r
-#f
On Sun, May 28, 2017, 17:54 Anton Vodonosov <avodonosov@yandex.ru <mailto:avodonosov@yandex.ru>> wrote:
27.05.2017, 02:06, "Faré" <fahree@gmail.com <mailto:fahree@gmail.com>>:
ASDF 3.3.0 has failures: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-65.html
Thanks. Interesting.
A whole lot of failures seem to be related to using now-deprecated functions, that since 3.2.0 where causing ASDF to issue a STYLE-WARNING, but with 3.3.0 are causing it to issue a full WARNING. I'll send patches.
Fare, why do you want to fail compilation with WARNING on ASDF:SYSTEM-DEFINITION-PATHNAME usage? (http://cl-test-grid.appspot.com/blob?key=1ipz631lkv)
Best regards, - Anton
On Wed, May 31, 2017 at 8:49 AM, Robert Goldman <rpgoldman@sift.net> wrote:
Suggestion: can we make an ASDF-specific subclass of STYLE-WARNING so that programmers have the option of catching it and handling it?
uiop:deprecated-function-style-warning Or, preferably, fix the library and send the fix upstream. I have fixed all the libraries in Quicklisp, though many of them haven't merged my fixes yet (see previous email thread for a list). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Resentment is like taking poison and waiting for the other person to die. — Malachy McCourt
On 5/31/17 May 31 -10:41 AM, Faré wrote:
On Wed, May 31, 2017 at 8:49 AM, Robert Goldman <rpgoldman@sift.net> wrote:
Suggestion: can we make an ASDF-specific subclass of STYLE-WARNING so that programmers have the option of catching it and handling it?
uiop:deprecated-function-style-warning
I see now. I was looking in the wrong place, and just saw the use of :style-warning, and didn't understand how the macro was interpreting it.
Or, preferably, fix the library and send the fix upstream. I have fixed all the libraries in Quicklisp, though many of them haven't merged my fixes yet (see previous email thread for a list).
Yes, that's obviously best, but sometimes it's a pain to maintain a mirror of everything (especially for those projects that use svn instead of git). Cheers, r
On Fri, Jun 2, 2017 at 2:14 AM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
I mean is it impossible to keep existing forever (implemented in terms of the new, better API)?
Some functions have a horrible API that is error-prone or misdefined and should NOT be used by anyone when better APIs are available. RUN-SHELL-COMMAND is a case in point — that horrible function must die, it's a security nightmare as well as a usability absurdity. SYSTEM-DEFINITION-PATHNAME was historically doing the wrong thing; we provide an approximation of what it used to do in terms of supported interfaces, but the only way to be sure that the user doesn't mean something crazy in terms of the old meaning is to migrate to the new interfaces. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Good girls are bad girls that never get caught.
On 20 Sep 2017, at 13:41, Anton Vodonosov wrote:
If the motivation is only this, IMHO it's a difficult approach to backward compatibility - you go online and find all usages, create pull requests, try to contact developers to have the fixes merged. If you don't find all usages (somebody's application not published online), then it will break after the change.
If there is no difficulty keeping the old functions in the code base, I would leave them forever (for course deprecated).
Just my opinion.
18.09.2017, 00:52, "Faré" <fahree@gmail.com>:
On Fri, Jun 2, 2017 at 2:14 AM, Anton Vodonosov <[avodonosov@yandex.ru](<mailto:avodonosov@yandex.ru>)> wrote:
I mean is it impossible to keep existing forever (implemented in terms of the new, better API)?
Some functions have a horrible API that is error-prone or misdefined
and should NOT be used by anyone when better APIs are available. RUN-SHELL-COMMAND is a case in point — that horrible function must die, it's a security nightmare as well as a usability absurdity.
SYSTEM-DEFINITION-PATHNAME was historically doing the wrong thing; we provide an approximation of what it used to do in terms of supported interfaces, but the only way to be sure that the user doesn't mean something crazy in terms of the old meaning is to migrate to the new interfaces.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• [http://fare.tunes.org](<http://fare.tunes.org/>) Good girls are bad girls that never get caught.
I'm willing to do this up to a certain level. But beyond a certain point, we can't maintain code that's cluttered with stuff that we no longer understand or that does the wrong thing. If there's something really wrong, at a certain point, I will need to say "I'm the ASDF maintainer, not the Quicklisp maintainer," and be willing to break things. Particularly things that are un-maintained. Best, r '
participants (3)
-
Anton Vodonosov -
Faré -
Robert Goldman