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 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é" &lt;fahree@gmail.com&gt;:

...

On Fri, Jun 2, 2017 at 2:14 AM, Anton Vodonosov &lt;[avodonosov@yandex.ru](mailto:avodonosov@yandex.ru)&gt; 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&amp;Cybernethics• [http://fare.tunes.org%5D(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 '