About two years ago, I made a post-processing filter for Data::Dumper which would make the output more legible. Not as radical as going breadth-first instead of depth-first, but it helped format the output much more readably for human consumption.

As with you, I found the C-and-Perl issue to be daunting. If not in skills required, then in hassle to overcome. So I just decided to not bother. I would have to rework the main loop of Dumper to facilitate the filtering, and I just couldn't be arsed to jump through that hoop.

It's also part of the main distribution, now, so any changes have to be checked just that much more deeply. It's basically frozen in time and won't get much better than it is. Which is a shame.

Your module sounds great though.

/J

Id just like to address a couple of minor points here. There was some chattering yesterday in the CB that Data::Dump::Streamer fails to dump

my @a = ('a0'..'a9'); 
unshift @a, \$a[2]; 
print Dump \@a;
[download]

corectly, in a similar way to modules like YAML, Data::Dumper, Data::Dump fail this test. I assure you that this is NOT the case:

$ARRAY1 = [
            'R: $ARRAY1->[3]',
            'a0',
            'a1',
            'a2',
            'a3',
            'a4',
            'a5',
            'a6',
            'a7',
            'a8',
            'a9'
          ];
$ARRAY1->[0] = \$ARRAY1->[3];
[download]

which is perfectly correct. A thorough examination of this problem can be found in the dogpound.t test file contained in the distribution.

The other thing is that there seem to be difficulties installing the module on some architectures and version of perl. Ive tested as well as I can on Win32 and some versions of linux, but obviously cant test everywhere. Please email me the results of TEST_VERBOSE=1 if you have a failed build.

UPDATE: grinder kindly obliged me with a test output from a failed build, (thanks dude!) and it looks like its a bug in perl. If the only failure is test 14 of dump.t (all the reports so far are for this test) and you get the following as part of the verbose test output then your perl is buggy in that (1) x 4 returns four identical objects and not four seperate objects. (Or is it the other way round and the perls that _dont_ do this are buggy?, either way there are two distinct behaviours out there and Streamer notices the difference. :-)

Rle(1) Alias Got: 
$ARRAY1 = [ 
            1, 
            'A: $ARRAY1->[0]', 
            'A: $ARRAY1->[0]', 
            1, 
            0, 
            'A: $ARRAY1->[3]', 
            1, 
            'A: $ARRAY1->[6]', 
            'A: $ARRAY1->[6]' 
          ]; 
make_ro($ARRAY1->[0]); 
alias_av(@$ARRAY1, 1, $ARRAY1->[0]); 
alias_av(@$ARRAY1, 2, $ARRAY1->[0]); 
make_ro($ARRAY1->[4]); 
alias_av(@$ARRAY1, 5, $ARRAY1->[3]); 
make_ro($ARRAY1->[6]); 
alias_av(@$ARRAY1, 7, $ARRAY1->[6]); 
alias_av(@$ARRAY1, 8, $ARRAY1->[6]); 
EXPECT
[download]

Thanks and cheers.

One limitation I've noticed in Data::Dumper is that it doesn't handle closures. e.g.,

my $foo;
{
  my $bar = 'bar';
  $foo = sub { return ($bar .= join $bar, @_) }
}
use Data::Dumper; print Dumper(\$foo);
[download]

That doesn't work. At all. (Okay, it prints *something*, but it's not anything *useful*.) Does your module handle this better? Or am I just being unreasonable in expecting to be able to dump something like that?

Both my version and the current Data::Dumper() allow coderefs to be dumped. My module does it by default, Data::Dumper does it only on request.



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

Both my version and the current Data::Dumper() allow coderefs to be dumped. My module does it by default, Data::Dumper does it only on request.

I didn't ask about coderefs in general. I asked about closures specifically.

---

;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print