in reply to Storable- long integer size

Using Storable to transfer data between Perl installations is not really advisable in my opinion. You need to make sure that the Perl and Storable versions are identical and also that the flags used to compile Perl are identical. You also need to make sure to use nstore* instead of store everywhere (even though that shouldn't matter when moving between the same CPU platform). Maybe your OSX Perl is compiled with 64bit long and the Windows Perl is not? Or maybe it's the other way around?

You can find out where the differences between your Perl versions lie by comparing the output of perl -V in both environments.

If you mostly need a one-time migration, consider using Data::Dumper to transfer the data from the old environment to the new environment. If the file size is too large, Sereal also might be byte-order independent.

Personally, I would look at using SQLite or SQL as a transfer mechanism, or JSON. JSON doesn't like to export blessed structures though.

Having an export and import feature is also a good approach for having good backups, in the case that the original environment was lost and cannot be restored as easily as a similar but crucially different environment.

Replies are listed 'Best First'.
Re^2: Storable- long integer size
by syphilis (Archbishop) on Oct 21, 2015 at 11:46 UTC
    Maybe your OSX Perl is compiled with 64bit long and the Windows Perl is not?

    I think that quite likely explains it.
    On Windows, the "long" is always 32bit. Therefore, on a 64bit integer build of Windows perl, the IV type will always be something other than "long".

    However, I don't know enough about Storable to know whether that should trip things up.
    I was thinking that, so long as the IV sizes were the same on both perls (and endianness was not an issue), then maybe it shouldn't matter if the respective $Config{ivtype} values don't match ?
    (Clarification welcome.)

    Cheers,
    Rob
[reply]
      linux-x64 $ perl -V:'.*size|byte.*' | sort
byteorder='12345678';
charsize='1';
d_chsize='undef';
d_malloc_good_size='undef';
d_malloc_size='undef';
doublesize='8';
fpossize='16';
gidsize='4';
i16size='2';
i32size='4';
i64size='8';
i8size='1';
intsize='4';
ivsize='8';
longdblsize='16';
longlongsize='8';
longsize='8';
lseeksize='8';
nvsize='16';
ptrsize='8';
shortsize='2';
sig_size='69';
sizesize='8';
st_ino_size='8';
u16size='2';
u32size='4';
u64size='8';
u8size='1';
uidsize='4';
uvsize='8';
$

      [download]
      hp-ux ia64 $ perl -V:'.*size|byte.*' | sort
byteorder='87654321';
charsize='1';
d_chsize='undef';
d_malloc_good_size='undef';
d_malloc_size='undef';
doublesize='8';
fpossize='8';
gidsize='4';
i16size='2';
i32size='4';
i64size='8';
i8size='1';
intsize='4';
ivsize='8';
longdblsize='16';
longlongsize='8';
longsize='8';
lseeksize='8';
nvsize='16';
ptrsize='8';
shortsize='2';
sig_size='49';
sizesize='8';
u16size='2';
u32size='4';
u64size='8';
u8size='1';
uidsize='4';
uvsize='8';
$

      [download]

      The quotation will be different on Windows. An IV has not only length shown by ivsize, but also an order, as shown by byteorder. Both have to match for Storable to work. I also would promote the use of Sereal instead, as that was written with portability in mind.

      You can also keep using Storable if what you store are strings from pack where you define the format yourself. A long would then be packed using "l>", and unpacked with the same signature: the ">" defines the endianness


      Enjoy, Have FUN! H.Merijn
[reply]
[d/l]
[select]
        An IV has not only length shown by ivsize, but also an order, as shown by byteorder. Both have to match for Storable to work

        Yes, I knew that ivsize and byteorder would have to match for Storable to work, but I was unsure whether ivtype also had to match.

        I take it that ivtype does *not* have to match.
        Thanks !!

        Cheers,
        Rob
[reply]

In Section Seekers of Perl Wisdom