in reply to Re^5: In need of a Dumper that has no pretentions to being anything else.
in thread In need of a Dumper that has no pretentions to being anything else.

I don't get it. When Purity=0 DD, doesn't claim to reevaluate correctly and it's frequently more readable. When Purity=1, it seems to work perfectly for me.

Here's something that takes your examples above, DDDumps them with Purity=1 and reevals the string and then shows the Streamer version of the original and of the evaled. 

use Data::Dumper;
use Data::Dump::Streamer;
$Data::Dumper::Purity=1;

my ($x,$y);
$x=\$y;
$y=\$x;
test([$x, $y]);

my $ary=[];
$ary->[0]=\$ary->[1];
$ary->[1]=\$ary->[0];

test($ary);

sub test
{
  my $VAR1;
  my $s = shift;
  my $d = Dumper($s);
  my $s2 = eval "$d;\$VAR1";
  die $@ if $@;
  print "original---------------\n";
  print Dump($s);
  print "DDed---------------\n";
  print Dump($s2);
  print "\n"
}
__END__
original---------------
$ARRAY1 = [
            \do { my $v = 'V: $ARRAY1->[1]' },
            \do { my $v = 'V: $ARRAY1->[0]' }
          ];
${$ARRAY1->[0]} = $ARRAY1->[1];
${$ARRAY1->[1]} = $ARRAY1->[0];
DDed---------------
$ARRAY1 = [
            \do { my $v = 'V: $ARRAY1->[1]' },
            \do { my $v = 'V: $ARRAY1->[0]' }
          ];
${$ARRAY1->[0]} = $ARRAY1->[1];
${$ARRAY1->[1]} = $ARRAY1->[0];

original---------------
$ARRAY1 = [
            'R: $ARRAY1->[1]',
            'R: $ARRAY1->[0]'
          ];
$ARRAY1->[0] = \$ARRAY1->[1];
$ARRAY1->[1] = \$ARRAY1->[0];
DDed---------------
$ARRAY1 = [
            \do { my $v = 'V: $ARRAY1->[1]' },
            \do { my $v = 'V: $ARRAY1->[0]' }
          ];
${$ARRAY1->[0]} = $ARRAY1->[1];
${$ARRAY1->[1]} = $ARRAY1->[0];

[download]

The first one comes out identical. The second one is not textually identical but if ${$x} = $y means the same thing as $x = \$y then I can't see what DD did wrong. Do they mean the same thing?

Replies are listed 'Best First'.
Re^7: In need of a Dumper that has no pretentions to being anything else.
by demerphq (Chancellor) on Feb 23, 2005 at 23:27 UTC

    The second one is not textually identical but if ${$x} = $y means the same thing as $x = \$y then I can't see what DD did wrong. Do they mean the same thing?

    No. $x=\$y; makes $x's value be a reference to $y. $$x=$y makes the var referenced by $x to become a copy of the value in $y.

    Think of what happens when you do $obj->[0]=1; With the first example [$x,$y] if we do so we see that ${$obj->[1]} does not change, with the second example we see it does. In the first example we are dealing with 6 items, an SV containing a ref to an array which contains two SVs which themselves contain refs to two more SV's which are self referential. In the second case we are only dealing with four items, an SV containing a ref to an array which two SV's which are self referential. Because of the way DD works these two cases appear to it to be identical.

    Basically the problem is that it can't output a ref to a scalar that is itself part of a composite item being dumped later properly. It doesnt find out until way too late, and once it does, it doesnt do anything about it. If you start considering aliases then it gets things really wrong.

    DDS avoids these problems by traversing the data structure twice using the refcounts to determine what it needs to keep an eye on (to avoid the problem you proposed to fix in DD) and uses that information later to ensure such things as this get handled properly. It also does the first pass in a breadth first fashion and then uses that info to control the later depth first output, which means that DDS dumps of self referential data tend not to look as crazy (ie a list of nodes of a tree structure doesnt result in the full tree being dumped from the first node, but rather evenly across the roots selected). The notation there is useful too: 'R: $ARRAY1->[1]', means "this scalar slot contains a reference to $ARRAY1->[1] but that the latter isnt defined yet". Likewise the 'V: $ARRAY1->[1]' means that "this scalar is a copy of the value of $ARRAY1->[1] but the latter isnt defined yet".

    Incidentally one thing i regret is making the default to be Purity(1), i should have made it Purity(0) as well. :-(

    Read more... (1528 Bytes)

    Cheers

    ---
    demerphq

[reply]
[d/l]
[select]
      Aha!
[reply]
      DDS avoids these problems by traversing the data structure twice using the refcounts to determine what it needs to keep an eye on...

      If I am building a data structure that intentionally contains self references and I follow the advice for avoiding memory leaks by using Scalar::Util::weaken(), will that have a bad affect upon your heuristic?

      Examine what is said, not who speaks.
      Silence betokens consent.
      Love the truth but pardon error.
[reply]
[d/l]

        Yes weakrefs() are one thing that causes DDS a lot of problems, they completely screw DDS and there really is nothing I can do about it.

        As for the advice that weakrefs are the correct way to do self referential structures, I disagree. There really is no reason to require weakrefs and in fact IMO when you design self referential structures without using weakrefs you get certain benefits that are available when you do not use weakrefs.

        The central idea is that you use a stub object that isnt part of the self referential structure as the root or container of the structure. Since the root is not part of the reference cycle its refcount will decrement properly when it falls out of use, which will then trigger the DESTROY{} method which will then traverse the structure and eliminate the reference cycles. This is a useful design anyway as you can now use the root for various bookeeping efforts like how many nodes their are, different entry points into traversing the structure, even state information for things like iterators. All of these latter things are impossible or very difficult to accomplish with a "no container class using weakrefs" type data structure.

        ---
        demerphq

[reply]

In Section Seekers of Perl Wisdom