in reply to Re^4: Perl 64-bit versions
in thread Perl 64-bit versions

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

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...

Replies are listed 'Best First'.
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"

    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?

      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.

      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

      Enjoy, Have FUN! H.Merijn
        That has always worked in 64bitint perls!

        What is this (in your ouput?):

        === /usr/bin/perl 5.014002 i586-linux-thread-multi Negative offset to vec in lvalue context at -e line 1.

        And this (on mine):

        C:\test>test -S=1 -L=12 5.014002 # +# perl version 1431374382 # +# offsets to vec 1070103942 224876390 1364159134 875710158 4060380287 # +# < 2**32 > 2**31 Negative offset to vec in lvalue context at C:/Perl64-14/site/lib/Bloo +m/Filter.pm line 206.

        Line 206 of Bloom::Filter:

        # flip the appropriate bits on print(), vec($self->{filter}, $_, 1) = 1 foreach @{$self->_get +_cells($key)}; ## print() added

        perl -V:

        C:\test>perl -V Summary of my perl5 (revision 5 version 14 subversion 2) configuration +: Platform: osname=MSWin32, osvers=5.2, archname=MSWin32-x64-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=und +ef use64bitint=define, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -GF -W3 -MD -Zi -DNDEBUG -Ox -GL -fp:pr +ecise -DWIN32 -D_CONSOLE -DNO_STRICT -DWIN64 - optimize='-MD -Zi -DNDEBUG -Ox -GL -fp:precise', cppflags='-DWIN32' ccversion='15.0.21022', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='__int64', ivsize=8, nvtype='double', nvsize=8, Off_t='__in +t64', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -lt +cg -libpath:"C:\perl64-14\lib\CORE" -machine libpth=\lib libs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib +comdlg32.lib advapi32.lib shell32.lib ole32.li perllibs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.l +ib comdlg32.lib advapi32.lib shell32.lib ole3 libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl514.lib gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt: +ref,icf -ltcg -libpath:"C:\perl64-14\lib\CORE Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PL_OP_SLAB +_ALLOC USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF USE_SITECUSTOMIZE Locally applied patches: ActivePerl Build 1402 [295342] Built under MSWin32 Compiled at Oct 7 2011 15:19:36 @INC: C:/Perl64-14/site/lib C:/Perl64-14/lib .

        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?

      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.