Re^4: Is there a way to reduce Data::Dumper's output size? (Sereal)

Replies are listed 'Best First'.
Re^5: Is there a way to reduce Data::Dumper's output size? (Sereal) by BrowserUk (Patriarch) on Feb 11, 2015 at 17:38 UTC
there's no reason to pick Storable over Sereal. One reason: Sereal doesn't build on windows. 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". I'm with torvalds on this In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked	[reply]
Re^6: Is there a way to reduce Data::Dumper's output size? (Sereal on winz too) by Discipulus (Canon) on Feb 12, 2015 at 08:40 UTC
Uh? maybe my Strawberry made my OS no more windows? `c>perl -e "use Sereal::Encoder qw (sereal_encode_with_object); my $enc +oder = Sereal::Encoder->new(); prin t sereal_encode_with_object($encoder, \@INC),qq(\n\n), qx(perl -v);" =žrl♥ (+♦&"C:/path/strawberry/perl/site/lib&$C:/path/straw +berry/perl/vendor/lib}C:/path/strawberry/perl/liba. This is perl 5, version 14, subversion 2 (v5.14.2) built for MSWin32-x +86-multi-thread Copyright 1987-2011, Larry Wall [..]` [download] Read more... (308 Bytes) L* There are no rules, there are no thumbs.. Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.	[reply] [d/l]
Re^7: Is there a way to reduce Data::Dumper's output size? (Sereal on winz too) by Anonymous Monk on Feb 12, 2015 at 08:47 UTC
cough http://code.activestate.com/ppm/Sereal/	[reply]
Re^8: Is there a way to reduce Data::Dumper's output size? (Sereal on winz too) by CoVAX (Beadle) on Feb 13, 2015 at 00:20 UTC
Re^9: Is there a way to reduce Data::Dumper's output size? (Sereal on winz too) by Anonymous Monk on Feb 13, 2015 at 04:44 UTC
Some notes below your chosen depth have not been shown here
Re^6: Is there a way to reduce Data::Dumper's output size? (Sereal) by BrowserUk (Patriarch) on Feb 13, 2015 at 09:32 UTC
See Re^10: (Do you trust a C programmer who ignores warnings; any more than you trust a Perl programmer who does?) for the mess that is Sereal. You're gonna trust that code with your data? 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". I'm with torvalds on this In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked	[reply]
Re^5: Is there a way to reduce Data::Dumper's output size? (Sereal) by Anonymous Monk on Nov 01, 2015 at 10:02 UTC
If the starting point is DD then that is certainly true. Strictly speaking there are /still/ certain use cases where Storable is a better choice. For instance in the cases where exact struct level equivalence is required. But that level of accuracy goes out the window as soon as almost /any/ serialization package is used, and in %99.99999 of use cases this level of equivalancy is unnecessary. (Consider subtle things like dualvars and whether you care if they round trip "properly", most use cases would not care.) On the other hand, there are a number of good reasons to choose Sereal: it produces smaller output faster, and it is not vulnerable to the "Storable upgrade trap", which can be serious blocker preventing upgrading perl in "continuous availability" environments. Storable always outputs the latest version of the protocol, and the encoder and decoder are inseperable from each other, so you cannot run mixed versions of perl in an environment that shares data using Storable. If you do, when a new perl writes it will write something unreadable by all the older perls/Storables. So while the new Storables will be able to read data written by the old perls, the new perls wont be able to write something that the old perls can read. (Maybe this has been fixed since the last time I paid close attention to Storable, but I doubt it.) Avoiding this trap was one of the primary motivations for writing Sereal. We looked at improving Storable, but there was no spec for it, so it would have been a lot of work to make it do what we needed. So we designed Sereal to deal with all the issues we had with Storable. By migrating all our Storable data to Sereal we escaped the upgrade trap and at the same gained speed and size efficiencies across the board.	[reply]