Fix test failures introduced by the change of flags on op_sort

[p5sagit/p5-mst-13.2.git] / ext / Storable / Storable.pm

diff --git a/ext/Storable/Storable.pm b/ext/Storable/Storable.pm
index 51e4f9c..712f597 100644 (file)
--- a/ext/Storable/Storable.pm
+++ b/ext/Storable/Storable.pm
@@ -21,14 +21,17 @@ package Storable; @ISA = qw(Exporter DynaLoader);
 use AutoLoader;
 use vars qw($canonical $forgive_me $VERSION);
 
-$VERSION = '2.15';
+$VERSION = '2.15_01';
 *AUTOLOAD = \&AutoLoader::AUTOLOAD;            # Grrr...
 
 #
 # Use of Log::Agent is optional
 #
 
-eval "use Log::Agent";
+{
+    local $SIG{__DIE__};
+    eval "use Log::Agent";
+}
 
 require Carp;
 
@@ -521,7 +524,7 @@ settings.
 
 Since Storable version 2.05, CODE references may be serialized with
 the help of L<B::Deparse>. To enable this feature, set
-C<$Storable::Deparse> to a true value. To enable deserializazion,
+C<$Storable::Deparse> to a true value. To enable deserialization,
 C<$Storable::Eval> should be set to a true value. Be aware that
 deserialization is done through C<eval>, which is dangerous if the
 Storable file contains malicious data. You can set C<$Storable::Eval>
@@ -698,14 +701,14 @@ Returned value: none.
 =item C<STORABLE_attach> I<class>, I<cloning>, I<serialized>
 
 While C<STORABLE_freeze> and C<STORABLE_thaw> are useful for classes where
-each instance is independant, this mechanism has difficulty (or is
+each instance is independent, this mechanism has difficulty (or is
 incompatible) with objects that exist as common process-level or
 system-level resources, such as singleton objects, database pools, caches
 or memoized objects.
 
 The alternative C<STORABLE_attach> method provides a solution for these
-shared objects. Instead of C<STORABLE_freeze> --E<GT> C<STORABLE_thaw>,
-you implement C<STORABLE_freeze> --E<GT> C<STORABLE_attach> instead.
+shared objects. Instead of C<STORABLE_freeze> --E<gt> C<STORABLE_thaw>,
+you implement C<STORABLE_freeze> --E<gt> C<STORABLE_attach> instead.
 
 Arguments: I<class> is the class we are attaching to, I<cloning> is a flag
 indicating whether we're in a dclone() or a regular de-serialization via
@@ -928,7 +931,7 @@ data back to 8 bit and C<croak()> if the conversion fails.
 Prior to Storable 2.01, no distinction was made between signed and
 unsigned integers on storing.  By default Storable prefers to store a
 scalars string representation (if it has one) so this would only cause
-problems when storing large unsigned integers that had never been coverted
+problems when storing large unsigned integers that had never been converted
 to string or floating point.  In other words values that had been generated
 by integer operations such as logic ops and then not used in any string or
 arithmetic context before storing.