Front page | perl.perl5.porters |
Postings from August 2013
[perl #119493] perl5.18.0-broken -- breaks most existing programs w/warnings
From: Linda Walsh via RT
August 28, 2013 21:31
[perl #119493] perl5.18.0-broken -- breaks most existing programs w/warnings
Message ID: rt-3.6.HEADemail@example.com
On Tue Aug 27 18:37:46 2013, firstname.lastname@example.org wrote:
> > First big problem -- it generates warnings by default on what
> > was previously legal code. (my $_, given, when, etc).
> > It's considered normal to treat warnings as errors and my code
> > does just that... it rolls over and dies.
> First off, I'd like to take issue with the statement made several
> times in your
> report that 5.18.0 "breaks most programs with warnings."
> Evidence suggests that relatively little code "with warnings" was
> because as near as we could tell, fatal warnings are fairly rare. Of
In nearly any treatise on good perl programming, it is said to use
warnings and strict and to address all messages that come out of that.
It is recommended in many places to treat warnings as errors. Given
that such is common advice, and would I dare to say common sense, how
could one release something that would flag a warning in a large (maybe
not the majority) number of programs.
> we can only test:
> * published code on the CPAN
This is not representative of the code body, at large. Going
through the listed recommendations of getting code on CPAN would turn up
that use of any of the constructs you flag warnings for "should" be
minimal to non-existent. I specifically remember that I rewrote code
for CPAN to NOT use 'given/while', as they were features that were not
compatible with 5.6 and to try to minimize the use of such in order to
maximize the utility of the code on CPAN.
You can't use CPAN as a "indicator" of what code is like outside of
CPAN as the same constraints don't apply.
You can only use a sampling of a smaller population to determine
a larger, overall population's behavior in something IF and only IF,
the smaller population is selected at random out of the larger
population (AI/statistical reasoning). The CPAN population is far from
being close to a true random sampling given the recommendations one is
given as one goes to submit a module for CPAN inclusion.
> * private code that is tested against blead and reported on by
> concerned programmers
A statistically irrelevant sample, more likely to be composed of
those who are p5p-porters ("perl-insiders") than not.
> Nonetheless, I think it was the general feeling among "the list" that
> breakage was pretty minor. Warnings for "my $_" were added in Dec
> 2012 and
> warnings for ~~ were added (admittedly lamentably late) in Apr 2013.
The opinion of what public list? The opinions of private lists do
not apply to the general perl-use public if the list isn't open to such.
It is not, and cannot be used to justify actions that are to be carried
out and dumped on the perl-programming public.
You (and this is specifically aimed at you Ricardo), by your
previous actions and how you choose to exclude people (no matter
"how right", you or those supporting your actions, feel they
were/are justified), have created a *self-approving* environment of
yes-men. Those who might have objected have already been labeled as
"unambiguously [sic] unacceptable communicators" and excised from
the list. If you exclude the 'outliers' from consideration in your
decisions, you are automatically, NOT going to get a relevant
sampling that represents the larger perl-using public's usage.
> Although there have been plenty of complaints that these warnings are
> "annoying," yours is the first complaint that anything has been
It is said among more conservative developers, that anyone who
ignores warnings in their program is a fool. I take that seriously
and work to have any program fail on warnings due to the emphasis
that historically they represent a much higher statistical chance
that something is wrong than in programs that have no warnings.
> Nonetheless, the real issue seems to be:
> > Telling someone that these things were deprecated might be one
> > But causing any program that uses these legal constructs to now fail
> > w/o anything in the release notes about them being deprecated -- I
> > see how this is at all responsible.
> First, these things have not been marked deprecated, but experimental.
> Whatever, though: it's not the point, is it? The point is that
> instead of
> "telling someone," we've added warnings.
Instead of giving the advance warning that deprecation would have
required, by going the warning route you've violated the _principle_,
if not the letter, of releasing things that cause breakage on a wide
scale without an advance notification cycle.
> The thing is, warnings are how we communciate these things. In
> experience shows that users generally *do not* read the release notes.
> understandable. Even with all the time spent trying to make the
> release notes
> put the most important stuff up front and in concise wording, the
> notes don't
> seem to get read.
That doesn't mean you stop releasing them. I do read the
delta's, though usually after installing the new version -- as
I don't expect things to already be broken, and really have no easy
way to determine what in the delta is relevant to my code.
> (The addition of these "experimental" warnings and the means to
> disable them is
> the first item listed in perl5180delta.)
That is a point at issue.
There are no instructions on how to disable them on a site-wide
basis. The only method given is one that works by modifying the
source code of each module -- a laborious and usually unacceptable
change to be done done on the spur of a moment, but one that needs
some planning to exhaustively change all source modules to comply
I would have issue with the idea of flagging warnings for anything
that people might commonly be using -- like given/when (which was
perl's answer for the lack of a case statement) and was useful
outside of the affects of "~~" which I, only occasionally, find of use.
I see no benefit in releasing code that uses experimental
constructs nor putting such constructs to use in vital roles and
would "doubly", doubt you'd see something on CPAN using such due to
compatibility concerns. As this comes off to me, any feature
released after 5.6 is experimental.
> > Um... did anyone bother to test 5.18 with cpan before
> > it went out the door .. or anything code that "use's warnings";
> > [...]
> > So how was it expected that this would be useful for anyone?
> > I.e. shipping a perl that disables most programs on arrival?
> Yup! I run all my code, CPAN code and all, every day, with the latest
> of the devel cycle. Right now, I'm running 5.19.3. It has been great
> shaking out bugs. I also test my work code against blead, which helps
> that such-and-such bugfix will negatively impact work. Then I can
> prepare for
> the coming breakage months in advance.
If perl was portable enough to be generated in diverse
environments, more might take advantage of that. But portability
issues exist and have created distro's who will not support
anything other than a sterile build of perl under their own
build system which makes it hard for end-perl users to do the same.
> The perspective I suggest you consider is that of a world in which we
> did *not*
> issue such warnings.
But give a cycle advanced notice?
> The warnings are easy to work around. You either say, "Gosh, this
> feature is
> experimental? I didn't know. I better stop relying on it in critical
> since it is subject to massive change in the next version" or you say,
> "I don't
> have time to re�ngineer, I will disable this warning" as shown in the
> perldelta. I suggested the former, for critical code, but the latter
> is quite
> easy, and I used it to fix some of the very few parts of the CPAN
> broken by the
> introduction of these warnings.
If it was doable on a site-wide basis for those who have multiple
perl modules that would need to have it disabled in each module,
that would have been acceptable but it doesn't appear that it is.
> If you replace the affected code to eliminate experimental warnings,
> then when
> the behavior of ~~ or lexical topic changes radically in the next
> major version
> of Perl 5, *you will be safe*. Alternately, you can know just which
> hunks of
> code to review based on (a) the emission of warnings or (b) grepping
> for "no
> warnings .experimental".
It depends on how the feature is being used and how long it has
been in production perls without being tagged experimental.
I don't recall when/given being tagged as experimental in 5.10
or 5.12 or 5.14...etc... When something experiemental continues
into the next version where it is no longer listed as experimental,
> If no warnings were issued, and you missed the entry in perldelta
> that such-and-such feature was experimental, then when 5.x came,
> things, your code would *actually* break. That is: its runtime
> behavior would
> change! Much worse than having a compile-time error telling you
> "you're using
> something subject to change without acknowledging it," you'd just get
> a program
> that did something else! Yikes!
Not if there was a cycle advance notice.
> In the past, there has been an unpleasant feeling of pressure to keep
> behavior that "was never guaranteed" but only offered experimentally,
> clearly noted in "perl598delta" 87% down the file.
Bzzzt. 5.9.8 isn't a public stable release. If it was not
documented as experiemental in 5.10.0 and 5.12.0...etc, then it
the assumption is that by the time it had reached the public
release where it is no longer called experimental, it isnt'.
> See also all the work done to figure out the status of experiments,
> via the
> commits to pod/perlexperiment.pod since 5.16.0 and the tickets related
> to it.
> I think it's been worth doing, and that it will definitely pay
> dividends in the
> maintainability of both perl and Perl programs in the future.
Here's where you broke it. If someone puts "use 5.18.x" in their
code, then they get the new warnings. Otherwise, you use the new
feature "expermental::warnings"; By turning on this new feature by
default, code that treats warnings as failures (as they've been told
to not ignore warnings) will fail.
> I'm not sure what, if any, further response to this ticket is
> required. Please
> let me know or I will close this ticket in a few days.
> > Then I try to update my cpan modules, but seems CPAN got
> > broken as well...
> This seeems unrelated. I will be interested to hear back what the
> solution to
> this problem is. I'm guessing you need to tweak your CPAN config or
> environment to drop mention of ReadLine::Gnu, but that's a complete
I didn't know it had even been deprecated, let alone killed.
via perlbug: queue: perl5 status: open