Re: Perl 64-bit versions

Replies are listed 'Best First'.
Re^2: Perl 64-bit versions by BrowserUk (Patriarch) on Mar 13, 2012 at 14:29 UTC
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: Read more... (21 kB) I have another 101 packages that I had to manually install after futzing them to adapt them to Windows/64-bit/windows 64-bit: Read more... (6 kB) 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?	[reply] [d/l] [select]
Re^3: Perl 64-bit versions by Eliya (Vicar) on Mar 13, 2012 at 14:45 UTC
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.	[reply]
Re^4: Perl 64-bit versions by BrowserUk (Patriarch) on Mar 13, 2012 at 15:10 UTC
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. The way you describe your upgrade procedures, it makes it sound like you would still have 5.005 kicking around for running those scripts that never needed a newer version? So, at what point to you move a script to the latest, greatest version of Perl? When it needs something that is unavailable from the version you had when you wrote it? When a bug you encountered when using it was announced fixed in the newer version? I've had several versions (AS binaries and self-builds) of 5.14.x on my machine since the first RC, but except for performing make tests for the self-builds and specific tests for individual items, they just sit there doing nothing because I haven't had sufficient reason to use them. What's the point in going through the pain of upgrading when there's going to be another one along any minute. Availability is not sufficient reason. I now have a particular reason (need) to upgrade. I have choices. I wish to narrow those choices based on the accumulated experience of others. 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?	[reply]
Re^5: Perl 64-bit versions by Eliya (Vicar) on Mar 13, 2012 at 15:46 UTC
Re^6: Perl 64-bit versions by BrowserUk (Patriarch) on Mar 13, 2012 at 16:16 UTC
Some notes below your chosen depth have not been shown here
Re^2: Perl 64-bit versions by VinsWorldcom (Prior) on Mar 13, 2012 at 14:13 UTC
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	[reply]
Re^3: Perl 64-bit versions by Eliya (Vicar) on Mar 13, 2012 at 14:26 UTC
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.	[reply]