Re: DateTime::Stringify ...

2004-02-22 Thread Matt Sisk
David Wheeler wrote:

So perhaps the eval will do the trick, esp. since one is generally 
generating a stack trace just before die'ing, so the run-time use of 
these constructs is not so questionable.


I tried it both ways with no effect, in various scopes. I came to the 
conclusion, without delving into the innards, that the pragma is not 
universal, but specific to each scope in which it's used (which makes 
sense when you think about scope in perl ... e.g. 'use bytes' does not 
extend to packages you use). So in this case the no overload would 
only be of use in your particular package or class that uses it 
initially -- dipping into that sans permission, outside of subclassing, 
would be yet another ugly kludge.

I could of course be missing much here -- it was only a cursory 
investigation where I twiddled some knobs in a test script/package.

Matt




Re: [OT] Re: DateTime::Stringify ... Data::Dumper'ing DT objects

2004-02-22 Thread Dave Rolsky
On Sun, 22 Feb 2004, Rick Measham wrote:

 Back on Topic, below is the module I use for dumping ... if people
 are interested I don't mind releasing it. Basically I summarise some
 of the long parts of the dump as strings. If you pass it anything but
 a DateTime object the module just passes it onto Data::Dumper.

This is poking about it in object internals way too much to be released on
CPAN, I think.

Like I said, I think the real solution is for there to be a module which
is designed to dump data structures for debugging that would respect some
sort of hooks.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/


Re: [OT] Re: DateTime::Stringify ... Data::Dumper'ing DT objects

2004-02-22 Thread Andrew Pimlott
On Sat, Feb 21, 2004 at 03:42:40PM -0600, Dave Rolsky wrote:
 I think the problem is that Data::Dumper has historically had two
 orthogonal uses.  One was serializing data structures for persistence, ala
 Storable, and the other was for debugging.
 
 Nowadays, I'm guessing most people use Storable for the first, and so it's
 probably used more for debugging.  But just dumping the structure as is
 may not be ideal for debugging.

This dichotomy is unfortunate.  It's quite nice to have a readable
serialized format, when space is not important.  However, you must use
Data::Dumper _very_ carefully to get reliable serialization, and when I
suggested that it be made easier, people said Data::Dumper is for
pretty-printing, use Storable.  Meanwhile, Data::Dumper is much more
verbose than a pretty-printer needs to be.  So it's sort of stuck in
no-man's land.

 So I suspect what we really need is something like Data::DebugDumper or
 something like that, which is _only_ used for debugging.  Is there already
 something on CPAN that might be suitable for this?

Dumpvalue is what the debugger uses (actually, I think it's a copy of it
:-/), so that's the natural choice.  It is much more concise and
readable than Data::Dumper, IMO.

Andrew


Re: [OT] Re: DateTime::Stringify ... Data::Dumper'ing DT objects

2004-02-22 Thread Tim Bunce
On Sun, Feb 22, 2004 at 02:34:58PM -0500, Andrew Pimlott wrote:
 On Sat, Feb 21, 2004 at 03:42:40PM -0600, Dave Rolsky wrote:
  I think the problem is that Data::Dumper has historically had two
  orthogonal uses.  One was serializing data structures for persistence, ala
  Storable, and the other was for debugging.
  
  Nowadays, I'm guessing most people use Storable for the first, and so it's
  probably used more for debugging.  But just dumping the structure as is
  may not be ideal for debugging.
 
 This dichotomy is unfortunate.  It's quite nice to have a readable
 serialized format, when space is not important.  However, you must use
 Data::Dumper _very_ carefully to get reliable serialization, and when I
 suggested that it be made easier, people said Data::Dumper is for
 pretty-printing, use Storable.  Meanwhile, Data::Dumper is much more
 verbose than a pretty-printer needs to be.  So it's sort of stuck in
 no-man's land.

I'd support a patch to Data::Dumper that added (something like) a

   $Data::Dumper::Stringify = ...

Where 0 (the default) means dig into objects the way it does now.
And 1 means if $obj-can('') then dump the object as a string.
That seems simple, fast and effective.

An extra layer of the icing on the cake could be:

   $Data::Dumper::Stringify = {
DEFAULT = 1, # or 0
$class_name = 0, # or 1
};

to control stringification style of individual classes.
(But that icing doesn't work well in the face of subclasses.)


An alternative/complementary approach would be to allow a callback
to be called for each newly encountered class during a Dump.
The return value would then control how Data::Dumper behaves
for instances of that class.

The callback can use $obj-isa($base_class) to control stringification
so that subclasses are also covered.


Tim.

p.s. CC'd to Ilya Martynov [EMAIL PROTECTED], the current maintainer


[OT] Re: DateTime::Stringify ... Data::Dumper'ing DT objects

2004-02-22 Thread Rick Measham
At 3:42 pm -0600 2004-02-21, Dave Rolsky wrote:
I think the problem is that Data::Dumper has historically had two
orthogonal uses.  One was serializing data structures for persistence, ala
Storable, and the other was for debugging.
Nowadays, I'm guessing most people use Storable for the first, and so it's
probably used more for debugging.  But just dumping the structure as is
may not be ideal for debugging.
So I suspect what we really need is something like Data::DebugDumper or
something like that, which is _only_ used for debugging.  Is there already
something on CPAN that might be suitable for this?
But this is way OT for this list.


Back on Topic, below is the module I use for dumping ... if people 
are interested I don't mind releasing it. Basically I summarise some 
of the long parts of the dump as strings. If you pass it anything but 
a DateTime object the module just passes it onto Data::Dumper.



package DateTime::Util::Dumper;

# Dumper for DateTime objects

use strict;
use Data::Dumper qw//;
sub Dump {
my $dt = shift;
return Data::Dumper::Dumper($dt) unless
(ref($dt)=~/DateTime/ and $dt-isa('DateTime'));
my $dtdata = $dt-clone;
$dtdata-{tz} = $dtdata-{tz}-name;
	$dtdata-{locale} = $dtdata-{locale}-id;

return Data::Dumper::Dumper($dtdata);
}
sub Dump_Locale {
my $dt = shift;
return Data::Dumper::Dumper($dt) unless
(ref($dt)=~/DateTime/ and $dt-isa('DateTime'));
	my $locale = $dt-clone-{locale};

return Data::Dumper::Dumper($locale);
}
sub Dump_TZ {
my $dt = shift;
return Data::Dumper::Dumper($dt) unless
(ref($dt)=~/DateTime/ and $dt-isa('DateTime'));
	my $dtdata = $dt-clone-{tz};

	$dtdata-{spans} = scalar( @{$dtdata-{spans}} ) . ' spans in 
original object';
	$dtdata-{rules} = scalar( @{$dtdata-{rules}} ) . ' rules in 
original object';
	$dtdata-{last_observance}-{local_start_datetime} = 
_render_observance($dtdata-{last_observance}-{local_start_datetime});
	$dtdata-{last_observance}-{utc_start_datetime} = 
_render_observance($dtdata-{last_observance}-{utc_start_datetime});

return Data::Dumper::Dumper($dtdata);
}
sub Dump_TZ_rules {
my $dt = shift;
return Data::Dumper::Dumper($dt) unless
(ref($dt)=~/DateTime/ and $dt-isa('DateTime'));
return Data::Dumper::Dumper( $dt-{tz}-{rules} );
}
sub Dump_TZ_spans {
my $dt = shift;
return Data::Dumper::Dumper($dt) unless
(ref($dt)=~/DateTime/ and $dt-isa('DateTime'));
	my $spans = $dt-clone-{tz}-{spans};

foreach my $span (@$spans) {
$span = _render_span($span);
}
return Data::Dumper::Dumper( $spans );
}


sub _render_observance {
my $obs = shift;
if ( $obs-{tz}-is_utc || $obs-{tz}-is_floating )
{
$obs-{local_rd_days} = $obs-{utc_rd_days};
$obs-{local_rd_secs} = $obs-{utc_rd_secs};
}
else
{
$obs-{local_rd_days} = $obs-{utc_rd_days};
$obs-{local_rd_secs} = $obs-{utc_rd_secs} + $obs-offset;
# intentionally ignore leap seconds here
$obs-_normalize_tai_seconds( $obs-{local_rd_days}, 
$obs-{local_rd_secs} );
}

$obs-_calc_local_components;
   
return $obs-datetime;
}

sub _render_span {
	my $span = shift;
	my ($utc_start, $utc_end, $local_start, $local_end, $offset, 
$is_dst, $shortname) = @$span;

return {
utc_start   = _render_rd($utc_start),
utc_end = _render_rd($utc_end),
local_start = _render_rd($local_start),
local_end   = _render_rd($local_end),
is_dst  = $is_dst,
shortname   = $shortname,
}
}
sub _render_rd {
my $rd = shift;
my $days = int($rd / (24*60*60));
my $secs = $rd - ($days * 24*60*60);
my $obj = bless( {
local_rd_days = $days,
local_rd_secs = $secs,
utc_rd_days = $days,
utc_rd_secs = $secs,
tz = DateTime::TimeZone-new(name='floating'),
}, 'DateTime');
return _render_observance($obj);
}
__END__

--

There are 10 kinds of people:
  those that understand binary, and those that don't.

  The day Microsoft makes something that doesn't suck
is the day they start selling vacuum cleaners

Write a wise proverb and your name will live forever.
   -- Anonymous