Front page | perl.perl5.porters |
Postings from August 2013
Re: [perl #119493] perl5.18.0-broken -- breaks most existingprograms w/warnings
Thread Previous
|
Thread Next
From:
Ricardo Signes
Date:
August 28, 2013 01:37
Subject:
Re: [perl #119493] perl5.18.0-broken -- breaks most existingprograms w/warnings
Message ID:
20130828013705.GB6647@cancer.codesimply.com
* Linda Walsh <perlbug-followup@perl.org> [2013-08-27T20:26:41]
> I was trying to install perl 5.18.0 (I found a version for suse ---
> but it breaks nearly all existing scripts).
>
> 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 "broken,"
because as near as we could tell, fatal warnings are fairly rare. Of course,
we can only test:
* published code on the CPAN
* private code that is tested against blead and reported on by concerned
programmers
Nonetheless, I think it was the general feeling among "the list" that the
breakage was pretty minor. Warnings for "my $_" were added in Dec 2012 and
warnings for ~~ were added (admittedly lamentably late) in Apr 2013.
Although there have been plenty of complaints that these warnings are
"annoying," yours is the first complaint that anything has been broken.
Nonetheless, the real issue seems to be:
> Telling someone that these things were deprecated might be one thing.
> But causing any program that uses these legal constructs to now fail
> w/o anything in the release notes about them being deprecated -- I can't
> 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.
The thing is, warnings are how we communciate these things. In general,
experience shows that users generally *do not* read the release notes. That's
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.
(The addition of these "experimental" warnings and the means to disable them is
the first item listed in perl5180delta.)
> 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 release
of the devel cycle. Right now, I'm running 5.19.3. It has been great for
shaking out bugs. I also test my work code against blead, which helps find
that such-and-such bugfix will negatively impact work. Then I can prepare for
the coming breakage months in advance.
The perspective I suggest you consider is that of a world in which we did *not*
issue such warnings.
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 systems,
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 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".
If no warnings were issued, and you missed the entry in perldelta somewhere
that such-and-such feature was experimental, then when 5.x came, changing
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!
In the past, there has been an unpleasant feeling of pressure to keep bad
behavior that "was never guaranteed" but only offered experimentally, as
clearly noted in "perl598delta" 87% down the file. We want to make it very
clear that using experimental features is an opt-in, and it was something that
was carefully considered. In the future, expect *more* such warnings, not
*less*. Of course, they'll be for new features, so your old code won't be
affected. This transition period is a bit unpleasant, but it's necessary to
establish the new procedure.
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.
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 guess.
--
rjbs
Thread Previous
|
Thread Next