Re^4: Perl 64-bit versions

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?

Comment on Re^4: Perl 64-bit versions

Replies are listed 'Best First'.
Re^5: Perl 64-bit versions by Eliya (Vicar) on Mar 13, 2012 at 15:46 UTC
So, at what point to you move a script to the latest, greatest version of Perl? It depends. Two criteria are certainly the ones you mentioned. And yes, I generally do have quite a number of Perl versions installed on my machines (7 on this box, for example, reaching back to 5.8.4). Other criteria are When I've got myself a new box (hardware), or have had some reason to wipe/upgrade my entire OS, I (re-)evaluate whether getting any "ancient" versions of Perl set up again on the new system would be more trouble than getting all app's respective module dependencies built for a new version of Perl, finally. When I have some idle time, I sometimes simply invest it to upgrade XS modules for no particular reason other than getting them upgraded, and eventually being able to drop ancient versions of Perl. All in all, this migration process is kind of natural and "automatic", in that the longer some Perl release isn't superseded by another bugfix release, the more upgraded modules I happen to have for that release... New projects are generally started with the most recent release — which creates the "need" in the above outlined upgrade-as-needed approach, for the particular modules used in that project...	[reply]
Re^6: Perl 64-bit versions by BrowserUk (Patriarch) on Mar 13, 2012 at 16:16 UTC
Whilst it is possible to have multiple concurrent versions of Perl installed -- I have 5.8.9 32-bit and 5.10.1 64-bit -- and manage them using the windows alternative to shebang lines -- assoc/ftype/.pl/.pl8 -- I've tried it in the past and just find it a pain to work with. The multiple versions rather the extensions. Whichever version I'm using, it always seems that the module I want to use is already installed everywhere but that version. The biggest pain is needing to work out which modules are pure perl and can just be copied over and which have a binary component that need proper installation. Whilst the split between perl/lib and perl/site/lib has always seemed entirely pointless and arbitrary to me; maintaining a split between pure perl pacjages and those with a binary component seems like it would (have been) far more useful. Way to late now of course. As an aside: do you perchance have a 64-bit 5.15.something installed anywhere? If so, could you try: `perl -wE"$v=''; vec( $v, 2**32, 1 )=1"` [download] And see if the 31-bit limitation on vec has been lifted? 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]
Re^7: Perl 64-bit versions by ikegami (Patriarch) on Mar 13, 2012 at 21:27 UTC
The biggest pain is needing to work out which modules are pure perl and can just be copied over and which have a binary component that need proper installation. Those in $arch (e.g. i686-linux-thread-multi) vs those that aren't. Perl can be setup to peek into the libs of previous version, and that's how it determines what's safe and what's not.	[reply]
Re^7: Perl 64-bit versions by Tux (Canon) on Mar 13, 2012 at 16:23 UTC
That has always worked in 64bitint perls! Running perl-all -we $v="";vec($v,2**32,1)=1 : skipping 5.003 .. 5.13.11 : === base/perl5.14.0 5.014000 i686-linux-64int === base/tperl5.14.0 5.014000 i686-linux-thread-multi-64int-ld === base/perl5.14.1 5.014001 i686-linux-64int === base/tperl5.14.1 5.014001 i686-linux-thread-multi-64int-ld === base/perl5.14.2 5.014002 i686-linux-64int === base/tperl5.14.2 5.014002 i686-linux-thread-multi-64int-ld === base/perl5.15.0 5.015000 i686-linux-64int === base/tperl5.15.0 5.015000 i686-linux-thread-multi-64int-ld === base/perl5.15.1 5.015001 i686-linux-64int === base/tperl5.15.1 5.015001 i686-linux-thread-multi-64int-ld === base/perl5.15.2 5.015002 i686-linux-64int === base/tperl5.15.2 5.015002 i686-linux-thread-multi-64int-ld === base/perl5.15.3 5.015003 i686-linux-64int === base/tperl5.15.3 5.015003 i686-linux-thread-multi-64int-ld === base/perl5.15.4 5.015004 i686-linux-64int === base/tperl5.15.4 5.015004 i686-linux-thread-multi-64int-ld === base/perl5.15.5 5.015005 i686-linux-64int === base/tperl5.15.5 5.015005 i686-linux-thread-multi-64int-ld === base/perl5.15.6 5.015006 i686-linux-64int === base/tperl5.15.6 5.015006 i686-linux-thread-multi-64int-ld === base/perl5.15.7 5.015007 i686-linux-64int === base/tperl5.15.7 5.015007 i686-linux-thread-multi-64int-ld === base/perl5.15.8 5.015008 i686-linux-64int === base/tperl5.15.8 5.015008 i686-linux-thread-multi-64int-ld === /usr/bin/perl 5.014002 i586-linux-thread-multi Negative offset to vec in lvalue context at -e line 1. Exit status: 65280 === /pro/bin/perl 5.014001 i686-linux-64int-ld [download] Enjoy, Have FUN! H.Merijn	[reply] [d/l]
Re^8: Perl 64-bit versions by BrowserUk (Patriarch) on Mar 13, 2012 at 16:49 UTC
Re^9: Perl 64-bit versions by Eliya (Vicar) on Mar 13, 2012 at 18:50 UTC
Some notes below your chosen depth have not been shown here
Re^9: Perl 64-bit versions by Tux (Canon) on Mar 13, 2012 at 17:51 UTC
Some notes below your chosen depth have not been shown here
Re^7: Perl 64-bit versions by ikegami (Patriarch) on Mar 13, 2012 at 21:31 UTC
Whilst the split between perl/lib and perl/site/lib has always seemed entirely pointless and arbitrary to me Well, it does allow you to get to a pristine core installation in seconds. Yeah, it's of limited value. But who cares.	[reply]


We don't bite newbies here... much
	PerlMonks