Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Perl 64-bit versions

by BrowserUk (Pope)
on Mar 13, 2012 at 13:16 UTC ( #959325=perlquestion: print w/ replies, xml ) Need Help??
BrowserUk has asked for the wisdom of the Perl Monks concerning the following question:

Finally, it is time to upgrade my 64-bit installation. But to what? How "good" are the versions available?

The flurry of new major versions that followed 5.10.1 left me cold. So I decided to wait it out until some sanity returned.

There's no doubt that many would suggest "get the latest" version, but memories of 5.8.0, 5.8.2 5.8.5 make me reluctant.

Anyone have any "Don't use" 5.12.x or 5.14.x (with emphasis on 64-bit Win) they'd care to share?


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Comment on Perl 64-bit versions
Re: Perl 64-bit versions
by Anonymous Monk on Mar 13, 2012 at 13:42 UTC
    I've been running Perls on x86_64/Linux since the 5.10 era without any problems pertaining to bitness.

    Upgrade to the most recent stable, which as of now is 5.14.2.

    Your prebuilt options for Windows are ActiveState Perl, Strawberry Perl, DWIM Perl. Citrus Perl appears to be stuck on 5.12.

      Upgrade to the most recent stable, which as of now is 5.14.2.

      Why? I'm not being facetious. Is it as good as 5.14.1? Better? Only slightly worse? What made you upgrade from 5.14.1 to 5.14.2?


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?

        Since all the minor versions are supposed to contain only bug fixes (and no new features), in theory 5.14.2 should be better than 5.14.1, which in turn should be better than 5.14.0

        In practice I didn't run into any problems with either 5.14.1 or 5.14.2, which I've both used for several months (though on linux, and without threads).

Re: Perl 64-bit versions
by VinsWorldcom (Priest) on Mar 13, 2012 at 13:44 UTC

    I'm not a heavy Perl user - certainly not as much as you are judging by the quantity and quality of your posting on this site - but I am an exclusive Windows Perl user. I started with Activestate but have since migrated to Strawberry back around 5.10 and while still on Windows XP.

    I'm now on Windows 7 64-bit with Strawberry 5.12.3 64-bit and have had no issues with my aforementioned light Perl usage. Module installation - including XS compiling - has worked for 99% of all attempts. There are a few instances where a 'cpan' install won't work as there is some required patching for the Windows version to install (perl Makefile.PL; dmake; dmake install) - the one that comes to mind is Net::Pcap and the patches (rt://53292) supplied by Corion that work a treat.

    VinsWorldcom@C:\Users\VinsWorldcom> ver Microsoft Windows [Version 6.1.7601] VinsWorldcom@C:\Users\VinsWorldcom> where perl C:\strawberry\perl\bin\perl.exe VinsWorldcom@C:\Users\VinsWorldcom> perl -v This is perl 5, version 12, subversion 3 (v5.12.3) built for MSWin32-x +64-multi-thread

    I see Strawberry has a 5.14 out, but I haven't tried it yet - apparently waiting for the very feedback you're asking for in this thread!

Re: Perl 64-bit versions
by Eliya (Vicar) on Mar 13, 2012 at 13:56 UTC
    ...but memories of 5.8.0, 5.8.2 5.8.5 make me reluctant.

    For someone as experienced as you are, it shouldn't involve too much effort to just install a recent version next to your currently used one.  This way, in case you should really find a show-stopper bug in the new release, you can always easily return to the older version (and a "power user" like you finding/reporting any such bug would help us all).

    Not a lot to be lost with that approach, except maybe a couple of minutes installation time...

    Any version has bugs, and it's hard to tell a priori whether the current minor version will be the last for some time to come.

      Good insight, having never tried that on Linux, I can't comment, but on Windows (based on experience) it isn't perfect.

      The killer is the file associations (assoc) which tie the .pl extension to a specific executable. So no matter what your system PATH environment variable is, you may not be executing with the Perl version you think you are unless you're calling your scripts with 'perl.exe <scriptname>' specifically.

      I've seen other options talked about on this site (Perlbrew for one, IIRC) but I don't know about the Windows support.

      I do have Strawberry 5.14.x (can't remember) installed on a Windows VM on my current Windows box, but it takes so bloody long to launch that I rarely ever use it unless I'm looking to release something into the wild (CPAN) and want to validate on different versions (in which case I also have an Ubuntu VM with Perl 5.10.x for limited *nix testing). So there is another multiple-version approach, albeit not the most efficient

        The killer is the file associations (assoc) which tie the .pl extension to a specific executable.

        Yes, but what about associating .pl with the new version (i.e. make it the default), and re-associating things back in case you should encounter problems.

        I'm only an occasional Windows user, but this seems rather straightforward to me — at least I can't remember to have ever had any problems with multiple Perl versions on Windows.  And precompiled Windows Perl installations have "always" been relocatable to an arbitrary top-level directory (at least the ActiveState versions), while that feature has not been available on Unix before Perl 5.10.

      If there is a problem with me asking for the experiences of others, please explain it to me?

      Not a lot to be lost with that approach, except maybe a couple of minutes installation time...

      If only...

      I have 272 PPM packages installed in my 5.10.1 installation, many of which are not available for 5.14.x:

      I have another 101 packages that I had to manually install after futzing them to adapt them to Windows/64-bit/windows 64-bit:

      Upgrading is a lot of work! And backing out is more.

      I use Perl a lot, but I don't meet the requirements for involving myself in the internals, beyond what is necessary for me to make forward progress on my own projects.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?

        If there is a problem with me asking for the experiences of others, please explain it to me?

        Of course, there is no problem asking... — I was only commenting on the particular phrase I quoted (i.e. the reluctance).

        As for upgrading all modules at once, I usually upgrade XS modules on a "as needed" basis (and sucessively switch my scritps/applications to the new version as my pool of upgraded modules grows). And with the pure-Perl ones, it's mostly a matter of copying them over, anyway.

        But maybe Windows' missing support for shebang execution (i.e. having the Perl version tied to the script, by default) does make such a migration plan more difficult than it would need to be. YMMV.

Re: Perl 64-bit versions
by Tux (Monsignor) on Mar 13, 2012 at 16:11 UTC

    Sorry I do not emphasize on Windows, but I'd like to share my thoughts too.

    First off, anything 5.10.1 and up is fine with me. I really want defined-or in my code, but as I was able to patch perl-5.8.x, I had that since 5.8.1. All below 5.8.4 is crap when you want Unicode support.

    The way 5.14.x and up deals with charnames and Unicode was a reason for me to upgrade to 5.14.1 and I ran into no serious problems perl-wise. The problems I ran into were module related: e.g. the newest version of DBD::Oracle only works with Oracle-10 and up. My box had oracle 9. Then one has to dive to BackPAN to find the last module that works with a new perl and an old environment. That is what is taking long long long time and is no fun, certainly if the maintainer of the module switched somewhere between the working version on your previous perl and the not-working version on the new perl.

    I never enable old perl trees in my new environment. I build perl to ignore old trees, so I can remove them when all tests passed. Not only to keep the disks clean (I have to copy most of it to customers too, and having a sanatized tree makes that a lot easier to do), but also this forces me to test every module I use on the new perl.

    That said, with so many modules to install, you should have a look into cpanprefs and make a "Bundle" of what you have now and install the Bundle into the new perl. If you make the right preferences to cpanprefs, a single cpan command can run for up to 50 hours unattended! (been there, done that).


    Enjoy, Have FUN! H.Merijn
      That said, with so many modules to install, you should have a look into cpanprefs and make a "Bundle"

      In general, I found that anything cpan* could install automatically, is available as a ppm from AS. And

      \oldperl\ppm profile save \ppmprofile.5.10.1 path = \newperl\bin;... \newperl\pp profile restore \ppmprofile.5.10.1

      Dealt with most of the 272 ppms in a matter of a few minutes. It took it longer to download the packing list than it did to download and install all the packages that were available.

      The problem child(s) are those that won't install automatically. The ones that need manual tweaks to adapt for *nix-isms or 64-bitisms. I keep the source trees (with my modifications) kicking around and can copy them over, but it still requires going through and building them manually -- including doing the dependencies in the right order. It is just a painful process and one I'd rather keep to a minimum.

      Keeping up with 5.8.x upgrades was pretty easy. With binary compatibility being maintained, I could just throw the latest version in over the top of the previous and mostly everything just still worked. But with the last half dozen versions having broken binary compatibility 3 times "keeping up" seems to be a game for those that like to spend their time building Perl rather than using it.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?

        The problems that I have seen with 64bitness have diminished to almost neglectable. The most problems I have seen in the incompatibility area are with longdoubles.


        Enjoy, Have FUN! H.Merijn
Re: Perl 64-bit versions
by ikegami (Pope) on Mar 13, 2012 at 21:38 UTC

    5.14.3 has been postponed for lack of requests to backport fixes. In other words, nothing critical is known to be missing from 5.14.2.

    I don't know any 5.12.x or 5.14.x that has problems not in earlier 5.12.x or 5.14.x. They truly have been maintenance releases as they should be.

      Looks like I'll be holding out for 5.16.1 when (hopefully) they'll have fixed the problem with vec.

      It'd be nice if this silliness went away also, but as it seems to be deliberate -- no matter how ill-advised -- I won't hold my breath.

      c:\test>perl -wE"$x = 0xffffffffffffffff" Hexadecimal number > 0xffffffff non-portable at -e line 1.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?

        I agree. That belongs in a linter (e.g. perlcritic).

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (11)
As of 2014-12-26 13:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (171 votes), past polls