Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Perl Version Change - Detecting Problems in Advance

by Roger_B (Scribe)
on Sep 21, 2005 at 17:02 UTC ( #493871=perlquestion: print w/ replies, xml ) Need Help??
Roger_B has asked for the wisdom of the Perl Monks concerning the following question:

Monks,

I am upgrading Perl from version 5.005_03 to version 5.8.x, and I want to verify that there are no issues in our existing scripts caused by changes to Perl's syntax.

I know that the incompatibilities are few, and everything will probably 'just work'. I know I can use 'perl -c' to verify that the files compile.

This leaves the possibility of a few cases where the Perl script will compile, but it will do something different! I would like to do what I can to capture such issues in advance, in case there are any holes in our test scripts.

I was hoping that this might be a problem that has been addressed before (it seemed a logical requirement to me), however I have had no success in Perl FAQs and in Google.

The only lead I have found so far is from ChatterBox, where the PPI module was suggested. This could certainly be used, but I wonder if anyone has done something like this already, either with or without this module?

The '-w' flag and the 'use strict;' pragma are not used in some Perl scripts. While I would like to see these added throughout, this is not likely to happen. My feeling is that this increases the chances of issues existing, while decreasing the chances of catching them.

Thanks,

Roger

Update 21 Sep 2005

Thanks all for your responses to date. Keep them coming! Here are some observations:

test coverage: Agreed, we do need good test coverage. Improving our coverage is an ongoing goal here, although not specifically my responsibility. The Perl code is distributed throughout the application, so providing better coverage specifically for Perl as a separate task isn't really practical. As the scripts interact in various ways with other code in C, Java and shell scripts, I don't think we'll manage to get around this with Perl automated tests.

As far as I am aware, 100% coverage of all possible permutations is impossible and we need to consider cost; the cost of going from 95% to 99% might be too high to justify for example.

I see these two methods as complementary. A search for incompatible code searches 100% of the code with less than 100% efficiency; a good test suite covers less than 100% of the code with near to 100% efficiency. Thus while the overlap ought to be substantial, each covers areas the other may miss.

strict & warnings pragmas: Personally, I never write a Perl program of more than one line without these pragmas. I am familiar with them and completely sold on their use (Of course in 5.005_03 I have to use '-w' as the warnings module doesn't exist, but that will change when we upgrade). Unfortunately, that attitude is not universal here. While I will suggest they are added as part of the upgrade, the budget for this is not guaranteed, so I want to cover the case that scripts exist without.

Note that, while actually adding the pragmas is simple, there will be a significant cost associated with finding and applying appropriate fixes for the errors and warnings they produce. I am thinking particularly of variable scope and possibly barewords. Does anyone have any thoughts on the effort this might require? If I can confidently provide a low estimate, the chances of having it approved increase!

perl -c: agreed, this won't pick up anything our tests wouldn't, but they would be picked up earlier, reducing costs. I think it's worthwhile on that basis.

perldeltas: I have looked briefly at these; that's what prompted me to write this message! Thanks for the pointer.

Perl Medic: Excellent pointer. Thanks, I'll look into that.

threads and unicode: Agreed, these are two of the problem areas. I am quite confident these will not be used. I have grepped case-independently for 'thread', 'locale' and 'utf' and found no occurrences. Are there any other simple searches I should consider to confirm this?

Thanks again for all your input.

Comment on Perl Version Change - Detecting Problems in Advance
Re: Perl Version Change - Detecting Problems in Advance
by Corion (Pope) on Sep 21, 2005 at 17:12 UTC

    I would install the new Perl as a separate Perl (say, in a different directory tree), and run the scripts with both Perls and compare the output. Of course you will need to have two database instances if your scripts use a database for that, and you will also need to duplicate all other resources that get consumed by your scripts.

Re: Perl Version Change - Detecting Problems in Advance
by polypompholyx (Chaplain) on Sep 21, 2005 at 17:26 UTC
    If there are holes in your test scripts, then they are not testing everything you deem important! If you can't trust your test suite to test your scripts and modules, then what can you trust? A hit-and-miss perl -c approach will be unlikely to pick up any more bugs than your tests. If you don't think your tests are good enough, I'd get intimate with the relevant incompatible changes in the perldeltas (a quick search on your scripts for threads and unicode might not go amiss); then install your modules and scripts on a dev box, and run them into the ground with automated tests. Whenever you find a bug, add it to the test suite, and that's one less thing you need to do manually next time. Best of luck with it.
Re: Perl Version Change - Detecting Problems in Advance
by samtregar (Abbot) on Sep 21, 2005 at 17:56 UTC
    Pick up a copy of Perl Medic. It has a lot of good advice about migrating old code to new Perl versions.

    -sam

      Thanks for the pointer. I've taken a look at the chapter on versions. This is full of useful information, but doesn't really address my query; it is listing new features and suggesting ways they might be used, rather than pointing out possible pitfalls. It doesn't mention the CHECK keyword introduced in Perl 5.6 for example.

      Nevertheless this looks like an invaluable source for Perl information and one I'm sure I'll refer to in the future.

      Thanks again,

      Roger

Re: Perl Version Change - Detecting Problems in Advance
by aufflick (Deacon) on Sep 21, 2005 at 23:38 UTC
    -w and use strict; can increase your problems, but they will also definately increase your chance of finding hidden problems. I would definately do what it takes to make use strict; happy. -w (or use warnings;) is a harder beast to keep happy and fairly often complains about things that are somewhat reasonable. use strict; and use warnings; can always be overridden for a chunk of wierd code that you have otherwise proven is functioning correctly eg:
    use warnings; my $foo = 1; { no warnings; my $foo = 2; #normally get a scope warning }
    use strict; is even better because you can override various subsets of it's checks (eg. no strict 'refs';) - see perldocs for strict and warnings
Re: Perl Version Change - Detecting Problems in Advance
by geektron (Curate) on Sep 22, 2005 at 07:45 UTC
    one thing i just thought of ...

    if you want to "quickly and painlessly" add  use strict; and  use warnings; you could just use some inline perl ...

    replace the  #! line with <code> $1 plus the 2 pragmas ...

Re: Perl Version Change - Detecting Problems in Advance
by cbrandtbuffalo (Deacon) on Sep 22, 2005 at 12:47 UTC
    We recently did an upgrade, and this is what bit us:

    • Hashes really are random now. They should have been before, but we had some CGI scripts that were using hashes to generate drop-downs. The drop-downs would always come out in the same order before because for very small hashes, the order wasn't really random. They will be different each time now.
    • CGI.pm changes a lot. I think we jumped something like 40 versions when we upgraded. Read the change log and look for gotchas. Tab index feature added to CGI.pm might be one gotcha.
    • DBI changed some default connect options along the way somewhere. I think the one that burned us was ChopBlanks.

    The last thing is just to note that you'll need to re-compile all your supporting C code too for the newest versions of modules. So if you use XML modules, you'll probably need to get the newest version of expat and recompile, etc.

    Our upgrade went very smooth, with the exception of the issues above. If you need to install a lot of modules too, you might try out Order your autobundle by dependency

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://493871]
Approved by Corion
Front-paged by ChemBoy
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (5)
As of 2014-10-25 23:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (149 votes), past polls