Data::Dumper: cannot handle ref type 10

[p5pRT]

Migrated from rt.perl.org#121254 (status was 'open')

Searchable as RT121254$

[p5pRT]

From agalama@mailfish.de

$ perl -MData​::Dumper -E 'say Dumper(\pos())' cannot handle ref type 10 at /usr/lib64/perl5/vendor_perl/Data/Dumper.pm line 222. $VAR1 = ;

$ perl -MData​::Dumper -E 'say $Data​::Dumper​::VERSION' 2.145

$ perl --version

This is perl 5\, version 18\, subversion 2 (v5.18.2) built for x86_64-linux-thread-multi (with 19 registered patches\, see perl -V for more detail)

Copyright 1987-2013\, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the GNU General Public License\, which may be found in the Perl 5 source kit.

Complete documentation for Perl\, including FAQ lists\, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet\, point your browser at http​://www.perl.org/\, the Perl Home Page.

[p5pRT]

From @garu

I'm probably way out of my league here\, but it looks like Data​::Dumper can't handle LVALUE references. This is what I get using Data​::Printer​:

perl -MDDP -E 'my $x = \pos(); p $x' undef (LVALUE)

perl -MDDP -E '$_ = q(foo); if(m/o/g) { $x = \pos(); p $x }' 2 (LVALUE)

Even when pos() is set\, $VAR1 still behaves weirdly​:

perl -MData​::Dumper -E '$_ = q(foo); if(m/o/g) { $x = \pos(); warn Dumper($x) }' cannot handle ref type 10 at /Users/garu/perl5/perlbrew/perls/perl-5.19.8/lib/5.19.8/darwin-thread-multi-2level/Data/Dumper.pm line 222. $VAR1 = ;

The pure Perl version fails similarly\, but with a less cryptic error message​:

perl -MData​::Dumper -E '$Data​::Dumper​::Useperl=1; say Dumper(\pos())' Can't handle 'LVALUE' type at -e line 1.

If the fix is just treating it as a regular SCALAR ref\, I can try and play with it. Otherwise there might be some decision-making to be done\, because I have no idea how an LVALUE is supposed to be re-evalled into Perl code.

Cheers\,

garu

On Sat\, Feb 15\, 2014 at 1​:56 PM\, Anand Galama \perlbug\-followup@​perl\.org wrote​:

# New Ticket Created by Anand Galama # Please include the string​: [perl #121254] # in the subject line of all future correspondence about this issue. # \<URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=121254 >

$ perl -MData​::Dumper -E 'say Dumper(\pos())' cannot handle ref type 10 at /usr/lib64/perl5/vendor_perl/Data/Dumper.pm line 222. $VAR1 = ;

$ perl -MData​::Dumper -E 'say $Data​::Dumper​::VERSION' 2.145

$ perl --version

This is perl 5\, version 18\, subversion 2 (v5.18.2) built for x86_64-linux-thread-multi (with 19 registered patches\, see perl -V for more detail)

Copyright 1987-2013\, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the GNU General Public License\, which may be found in the Perl 5 source kit.

Complete documentation for Perl\, including FAQ lists\, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet\, point your browser at http​://www.perl.org/\, the Perl Home Page.

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @demerphq

On 15 February 2014 19​:18\, breno \garu@&#8203;cpan\.org wrote​:

I'm probably way out of my league here\, but it looks like Data​::Dumper can't handle LVALUE references. This is what I get using Data​::Printer​:

perl -MDDP -E 'my $x = \pos(); p $x' undef (LVALUE)

perl -MDDP -E '$_ = q(foo); if(m/o/g) { $x = \pos(); p $x }' 2 (LVALUE)

Even when pos() is set\, $VAR1 still behaves weirdly​:

perl -MData​::Dumper -E '$_ = q(foo); if(m/o/g) { $x = \pos(); warn Dumper($x) }' cannot handle ref type 10 at /Users/garu/perl5/perlbrew/perls/perl-5.19.8/lib/5.19.8/darwin-thread-multi-2level/Data/Dumper.pm line 222. $VAR1 = ;

The pure Perl version fails similarly\, but with a less cryptic error message​:

perl -MData​::Dumper -E '$Data​::Dumper​::Useperl=1; say Dumper(\pos())' Can't handle 'LVALUE' type at -e line 1.

If the fix is just treating it as a regular SCALAR ref\, I can try and play with it. Otherwise there might be some decision-making to be done\, because I have no idea how an LVALUE is supposed to be re-evalled into Perl code.

I think that it is going to be somewhere between difficult and impossible to handle LVALUE's properly in Perl land. Doing so would require looking at the PV slot of an SV. We probably need to prioritise utility functions in Internals to allow Perl code to do this. However in XS land IMO it is probably relatively straight forward to serialize LVALUEs properly.

Consider the following from blead​:

$ ./perl -Ilib -MDevel​::Peek -e'my $str="foobar"; Dump $x=[\$str\, \substr($str\,0\,1)\, \pos($str)]; ${$x->[1]}="b"; print $str; Dump($x)' SV = IV(0x1415418) at 0x1415428   REFCNT = 1   FLAGS = (ROK)   RV = 0x140b378   SV = PVAV(0x13f7dd0) at 0x140b378   REFCNT = 2   FLAGS = ()   ARRAY = 0x14052c0   FILL = 2   MAX = 2   ARYLEN = 0x0   FLAGS = (REAL)   Elt No. 0   SV = IV(0x140b410) at 0x140b420   REFCNT = 1   FLAGS = (ROK)   RV = 0x14153f8   SV = PV(0x13f6d90) at 0x14153f8   REFCNT = 5   FLAGS = (PADMY\,POK\,IsCOW\,pPOK)   PV = 0x14188f0 "foobar"\0   CUR = 6   LEN = 16   COW_REFCNT = 1   Elt No. 1   SV = IV(0x140b428) at 0x140b438   REFCNT = 1   FLAGS = (ROK)   RV = 0x13f6370   SV = PVLV(0x1446570) at 0x13f6370   REFCNT = 3   FLAGS = (GMG\,SMG)   IV = 0   NV = 0   PV = 0   MAGIC = 0x14339e0   MG_VIRTUAL = &PL_vtbl_substr   MG_TYPE = PERL_MAGIC_substr(x)   TYPE = x   TARGOFF = 0   TARGLEN = 1   TARG = 0x14153f8   FLAGS = 0   SV = PV(0x13f6d90) at 0x14153f8   REFCNT = 5   FLAGS = (PADMY\,POK\,IsCOW\,pPOK)   PV = 0x14188f0 "foobar"\0   CUR = 6   LEN = 16   COW_REFCNT = 1   Elt No. 2   SV = IV(0x140b4a0) at 0x140b4b0   REFCNT = 1   FLAGS = (ROK)   RV = 0x140b360   SV = PVLV(0x14465c0) at 0x140b360   REFCNT = 3   FLAGS = (GMG\,SMG)   IV = 0   NV = 0   PV = 0   MAGIC = 0x141d3a0   MG_VIRTUAL = &PL_vtbl_pos   MG_TYPE = PERL_MAGIC_pos(.)   TYPE = .   TARGOFF = 0   TARGLEN = 0   TARG = 0x14153f8   FLAGS = 0   SV = PV(0x13f6d90) at 0x14153f8   REFCNT = 5   FLAGS = (PADMY\,POK\,IsCOW\,pPOK)   PV = 0x14188f0 "foobar"\0   CUR = 6   LEN = 16   COW_REFCNT = 1 SV = IV(0x1415418) at 0x1415428   REFCNT = 1   FLAGS = (ROK)   RV = 0x140b378   SV = PVAV(0x13f7dd0) at 0x140b378   REFCNT = 1   FLAGS = ()   ARRAY = 0x14052c0   FILL = 2   MAX = 2   ARYLEN = 0x0   FLAGS = (REAL)   Elt No. 0   SV = IV(0x140b410) at 0x140b420   REFCNT = 1   FLAGS = (ROK)   RV = 0x14153f8   SV = PV(0x13f6d90) at 0x14153f8   REFCNT = 4   FLAGS = (PADMY\,POK\,pPOK)   PV = 0x1404fa0 "boobar"\0   CUR = 6   LEN = 24   Elt No. 1   SV = IV(0x140b428) at 0x140b438   REFCNT = 1   FLAGS = (ROK)   RV = 0x13f6370   SV = PVLV(0x1446570) at 0x13f6370   REFCNT = 1   FLAGS = (GMG\,SMG\,POK\,IsCOW\,pPOK)   IV = 0   NV = 0   PV = 0x1433930 "b"\0   CUR = 1   LEN = 16   COW_REFCNT = 1   MAGIC = 0x14339e0   MG_VIRTUAL = &PL_vtbl_substr   MG_TYPE = PERL_MAGIC_substr(x)   TYPE = x   TARGOFF = 0   TARGLEN = 1   TARG = 0x14153f8   FLAGS = 0   SV = PV(0x13f6d90) at 0x14153f8   REFCNT = 4   FLAGS = (PADMY\,POK\,pPOK)   PV = 0x1404fa0 "boobar"\0   CUR = 6   LEN = 24   Elt No. 2   SV = IV(0x140b4a0) at 0x140b4b0   REFCNT = 1   FLAGS = (ROK)   RV = 0x140b360   SV = PVLV(0x14465c0) at 0x140b360   REFCNT = 1   FLAGS = (GMG\,SMG)   IV = 0   NV = 0   PV = 0   MAGIC = 0x141d3a0   MG_VIRTUAL = &PL_vtbl_pos   MG_TYPE = PERL_MAGIC_pos(.)   TYPE = .   TARGOFF = 0   TARGLEN = 0   TARG = 0x14153f8   FLAGS = 0   SV = PV(0x13f6d90) at 0x14153f8   REFCNT = 4   FLAGS = (PADMY\,POK\,pPOK)   PV = 0x1404fa0 "boobar"\0   CUR = 6   LEN = 24

You will need to decode the MAGIC attached to the LVALUE and also peek "through" the LVALUE to see the PV it is attached to. Some of this is probably currently not possible in Pure Perl\, which IMO should be seen as a bug in how LVALUES are implemented\, and probably a 5.20 blocker.

Yves

[p5pRT]

From @demerphq

On 17 February 2014 12​:54\, demerphq \demerphq@&#8203;gmail\.com wrote​:

On 15 February 2014 19​:18\, breno \garu@&#8203;cpan\.org wrote​:

I'm probably way out of my league here\, but it looks like Data​::Dumper can't handle LVALUE references. This is what I get using Data​::Printer​:

perl -MDDP -E 'my $x = \pos(); p $x' undef (LVALUE)

perl -MDDP -E '$_ = q(foo); if(m/o/g) { $x = \pos(); p $x }' 2 (LVALUE)

Even when pos() is set\, $VAR1 still behaves weirdly​:

perl -MData​::Dumper -E '$_ = q(foo); if(m/o/g) { $x = \pos(); warn Dumper($x) }' cannot handle ref type 10 at /Users/garu/perl5/perlbrew/perls/perl-5.19.8/lib/5.19.8/darwin-thread-multi-2level/Data/Dumper.pm line 222. $VAR1 = ;

The pure Perl version fails similarly\, but with a less cryptic error message​:

perl -MData​::Dumper -E '$Data​::Dumper​::Useperl=1; say Dumper(\pos())' Can't handle 'LVALUE' type at -e line 1.

If the fix is just treating it as a regular SCALAR ref\, I can try and play with it. Otherwise there might be some decision-making to be done\, because I have no idea how an LVALUE is supposed to be re-evalled into Perl code.

I think that it is going to be somewhere between difficult and impossible to handle LVALUE's properly in Perl land. Doing so would require looking at the PV slot of an SV.

Sorry\, this was mistaken and I should have removed it before sending. All one needs to be able to do is determine the address of the referenced SV in the LVALUE.

We probably need to prioritise utility functions in Internals to allow Perl code to do this. However in XS land IMO it is probably relatively straight forward to serialize LVALUEs properly.

Consider the following from blead​:

$ ./perl -Ilib -MDevel​::Peek -e'my $str="foobar"; Dump $x=[\$str\, \substr($str\,0\,1)\, \pos($str)]; ${$x->[1]}="b"; print $str; Dump($x)' SV = IV(0x1415418) at 0x1415428 REFCNT = 1 FLAGS = (ROK) RV = 0x140b378 SV = PVAV(0x13f7dd0) at 0x140b378 REFCNT = 2 FLAGS = () ARRAY = 0x14052c0 FILL = 2 MAX = 2 ARYLEN = 0x0 FLAGS = (REAL) Elt No. 0 SV = IV(0x140b410) at 0x140b420 REFCNT = 1 FLAGS = (ROK) RV = 0x14153f8 SV = PV(0x13f6d90) at 0x14153f8 REFCNT = 5 FLAGS = (PADMY\,POK\,IsCOW\,pPOK) PV = 0x14188f0 "foobar"\0 CUR = 6 LEN = 16 COW_REFCNT = 1 Elt No. 1 SV = IV(0x140b428) at 0x140b438 REFCNT = 1 FLAGS = (ROK) RV = 0x13f6370 SV = PVLV(0x1446570) at 0x13f6370 REFCNT = 3 FLAGS = (GMG\,SMG) IV = 0 NV = 0 PV = 0 MAGIC = 0x14339e0 MG_VIRTUAL = &PL_vtbl_substr MG_TYPE = PERL_MAGIC_substr(x) TYPE = x TARGOFF = 0 TARGLEN = 1 TARG = 0x14153f8 FLAGS = 0 SV = PV(0x13f6d90) at 0x14153f8 REFCNT = 5 FLAGS = (PADMY\,POK\,IsCOW\,pPOK) PV = 0x14188f0 "foobar"\0 CUR = 6 LEN = 16 COW_REFCNT = 1 Elt No. 2 SV = IV(0x140b4a0) at 0x140b4b0 REFCNT = 1 FLAGS = (ROK) RV = 0x140b360 SV = PVLV(0x14465c0) at 0x140b360 REFCNT = 3 FLAGS = (GMG\,SMG) IV = 0 NV = 0 PV = 0 MAGIC = 0x141d3a0 MG_VIRTUAL = &PL_vtbl_pos MG_TYPE = PERL_MAGIC_pos(.) TYPE = . TARGOFF = 0 TARGLEN = 0 TARG = 0x14153f8 FLAGS = 0 SV = PV(0x13f6d90) at 0x14153f8 REFCNT = 5 FLAGS = (PADMY\,POK\,IsCOW\,pPOK) PV = 0x14188f0 "foobar"\0 CUR = 6 LEN = 16 COW_REFCNT = 1 SV = IV(0x1415418) at 0x1415428 REFCNT = 1 FLAGS = (ROK) RV = 0x140b378 SV = PVAV(0x13f7dd0) at 0x140b378 REFCNT = 1 FLAGS = () ARRAY = 0x14052c0 FILL = 2 MAX = 2 ARYLEN = 0x0 FLAGS = (REAL) Elt No. 0 SV = IV(0x140b410) at 0x140b420 REFCNT = 1 FLAGS = (ROK) RV = 0x14153f8 SV = PV(0x13f6d90) at 0x14153f8 REFCNT = 4 FLAGS = (PADMY\,POK\,pPOK) PV = 0x1404fa0 "boobar"\0 CUR = 6 LEN = 24 Elt No. 1 SV = IV(0x140b428) at 0x140b438 REFCNT = 1 FLAGS = (ROK) RV = 0x13f6370 SV = PVLV(0x1446570) at 0x13f6370 REFCNT = 1 FLAGS = (GMG\,SMG\,POK\,IsCOW\,pPOK) IV = 0 NV = 0 PV = 0x1433930 "b"\0 CUR = 1 LEN = 16 COW_REFCNT = 1 MAGIC = 0x14339e0 MG_VIRTUAL = &PL_vtbl_substr MG_TYPE = PERL_MAGIC_substr(x) TYPE = x TARGOFF = 0 TARGLEN = 1 TARG = 0x14153f8 FLAGS = 0 SV = PV(0x13f6d90) at 0x14153f8 REFCNT = 4 FLAGS = (PADMY\,POK\,pPOK) PV = 0x1404fa0 "boobar"\0 CUR = 6 LEN = 24 Elt No. 2 SV = IV(0x140b4a0) at 0x140b4b0 REFCNT = 1 FLAGS = (ROK) RV = 0x140b360 SV = PVLV(0x14465c0) at 0x140b360 REFCNT = 1 FLAGS = (GMG\,SMG) IV = 0 NV = 0 PV = 0 MAGIC = 0x141d3a0 MG_VIRTUAL = &PL_vtbl_pos MG_TYPE = PERL_MAGIC_pos(.) TYPE = . TARGOFF = 0 TARGLEN = 0 TARG = 0x14153f8 FLAGS = 0 SV = PV(0x13f6d90) at 0x14153f8 REFCNT = 4 FLAGS = (PADMY\,POK\,pPOK) PV = 0x1404fa0 "boobar"\0 CUR = 6 LEN = 24

You will need to decode the MAGIC attached to the LVALUE and also peek "through" the LVALUE to see the PV it is attached to. Some of this is probably currently not possible in Pure Perl\, which IMO should be seen as a bug in how LVALUES are implemented\, and probably a 5.20 blocker.

Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From perl5-porters@perl.org

Yves Orton wrote​:

You will need to decode the MAGIC attached to the LVALUE and also peek "through" the LVALUE to see the PV it is attached to. Some of this is probably currently not possible in Pure Perl\, which IMO should be seen as a bug in how LVALUES are implemented\, and probably a 5.20 blocker.

You can use B. The hard part is in deciding how to dump the LVALUEs once you have that info.

Do you output \pos(do { my $x = 'xxxxx' })?

Or \pos('xxxxx')?

Either way\, that becomes somewhat meaningless since pos() will be reset when dumping and re-evaluating the source.

So do we output do { my $x = \pos('xxxxx'); $$x = 3; $x }?

[p5pRT]

From @demerphq

On 17 February 2014 15​:28\, Father Chrysostomos \sprout@&#8203;cpan\.org wrote​:

Yves Orton wrote​:

You will need to decode the MAGIC attached to the LVALUE and also peek "through" the LVALUE to see the PV it is attached to. Some of this is probably currently not possible in Pure Perl\, which IMO should be seen as a bug in how LVALUES are implemented\, and probably a 5.20 blocker.

You can use B. The hard part is in deciding how to dump the LVALUEs once you have that info.

Do you output \pos(do { my $x = 'xxxxx' })?

Or \pos('xxxxx')?

Either way\, that becomes somewhat meaningless since pos() will be reset when dumping and re-evaluating the source.

So do we output do { my $x = \pos('xxxxx'); $$x = 3; $x }?

I think the point here is referential integrity.

If I have a data structure [ \$str\, \pos($str) ] then I think the reconstructed value should maintain the referential integrity of the original.

Which means that serializing it as you describe is for me a non-starter.

consider this​:

perl -le'my $str= "foo"; $str=~/./gc; my $x=[ \$str\, \pos($str) ]; print ${$x->[1]}; pos($str)=2; print ${$x->[1]};' 1 2

I would expect that that should do the same as if we did this the dumped output​:

$ perl -le'my $str= "foo"; $str=~/./gc; my $x=[ \$str\, \pos($str) ]; print ${$x->[1]}; pos(${$x->[0]})=2; print ${$x->[1]};' 1 2

IOW\, the important part is we serialize it such that the original referential structure is preserved.

Also I think using pos() as the example for this is less than useful.

I would start with using substr() refs. Which IMO should be much less problematic than pos(). If I have​:

my $str= "foo"; $VAR1 = [ \$str\, \substr($str\,1\,1) ];

and I then do

${$VAR1->[1]}= "Q";

then printing out ${$VAR1->[0]} should output​:

"fQo"

If it doesn't then I would consider referential integrity to be broken.

Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From @tsee

On 02/17/2014 03​:46 PM\, demerphq wrote​:

On 17 February 2014 15​:28\, Father Chrysostomos \sprout@&#8203;cpan\.org wrote​:

Yves Orton wrote​:

You will need to decode the MAGIC attached to the LVALUE and also peek "through" the LVALUE to see the PV it is attached to. Some of this is probably currently not possible in Pure Perl\, which IMO should be seen as a bug in how LVALUES are implemented\, and probably a 5.20 blocker.

You can use B. The hard part is in deciding how to dump the LVALUEs once you have that info.

Do you output \pos(do { my $x = 'xxxxx' })?

Or \pos('xxxxx')?

Either way\, that becomes somewhat meaningless since pos() will be reset when dumping and re-evaluating the source.

So do we output do { my $x = \pos('xxxxx'); $$x = 3; $x }?

I think the point here is referential integrity.

[snip discussion of referential integrity]

Agreed.

But taking a step back\, is this really something that DD should be able to handle? I really don't look at it as a tool do be able to ultimately serialize all Perl data structures perfectly faithfully.

Shouldn't it instead do one of two things​:

a) Die with an intelligible error message.

or

b) Copy-serialize or some other cop-out?

--Steffen

[p5pRT]

From @demerphq

On Monday\, 17 February 2014\, Steffen Mueller \smueller@&#8203;cpan\.org wrote​:

On 02/17/2014 03​:46 PM\, demerphq wrote​:

On 17 February 2014 15​:28\, Father Chrysostomos \sprout@&#8203;cpan\.org wrote​:

Yves Orton wrote​:

You will need to decode the MAGIC attached to the LVALUE and also peek "through" the LVALUE to see the PV it is attached to. Some of this is probably currently not possible in Pure Perl\, which IMO should be seen as a bug in how LVALUES are implemented\, and probably a 5.20 blocker.

You can use B. The hard part is in deciding how to dump the LVALUEs once you have that info.

Do you output \pos(do { my $x = 'xxxxx' })?

Or \pos('xxxxx')?

Either way\, that becomes somewhat meaningless since pos() will be reset when dumping and re-evaluating the source.

So do we output do { my $x = \pos('xxxxx'); $$x = 3; $x }?

I think the point here is referential integrity.

[snip discussion of referential integrity]

Agreed.

But taking a step back\, is this really something that DD should be able to handle? I really don't look at it as a tool do be able to ultimately serialize all Perl data structures perfectly faithfully.

In the sense of round tripping data i agree. But from the sense of dumping different things differently I think it should mostly handle anything. For instance i think that a lvalue substr ref should be obviously different from a lvalue pos() ref.

Shouldn't it instead do one of two things​:

a) Die with an intelligible error message.

As a debugging tool no\, i dont think so\, at least not with standard config and operating parameters. i think in sucha case it would be better we output an annotated structure that gave th edev some insight of what was going on\, even if it was not evalable.

b) Copy-serialize or some other cop-out?

I would be fine if this was configurable\, so that if you wanted to be able to deserialie the packet we would do something like this on an opt-in basis. But i dont think it would be the right behaviour overall.

its a tough call regardless. we are basically leaking internal abstractions.

yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From mail@steffen-mueller.net

On 02/17/2014 08​:47 PM\, demerphq wrote​:

a\) Die with an intelligible error message\.

As a debugging tool no\, i dont think so\, at least not with standard config and operating parameters. i think in sucha case it would be better we output an annotated structure that gave th edev some insight of what was going on\, even if it was not evalable.

Fair. FTR\, I am not at all a fan of the fact that DD output is evalable. I know it's a long-standing guarantee\, but it's just disaster waiting to happen in code from the uninitiated.

b\) Copy\-serialize or some other cop\-out?

I would be fine if this was configurable\, so that if you wanted to be able to deserialie the packet we would do something like this on an opt-in basis. But i dont think it would be the right behaviour overall.

its a tough call regardless. we are basically leaking internal abstractions.

Agreed. My stance is that making DD handle *any* Perl data structure and construct is fiendishly hard and a lot of work at best and a fools errand otherwise. Consider the amount of work we (you and I) have put into Sereal to make it as powerful as it is. If people want the ultimate debugging dumper\, I think you Data​::Dump​::Streamer is what they should reach for.

--Steffen

[p5pRT]

From @timbunce

On Tue\, Feb 18\, 2014 at 09​:21​:47AM +0100\, Steffen Mueller wrote​:

Fair. FTR\, I am not at all a fan of the fact that DD output is evalable. I know it's a long-standing guarantee\, but it's just disaster waiting to happen in code from the uninitiated.

Perhaps that guarantee should be officially loosened in the docs.

Tim.

[p5pRT]

From @demerphq

On 18 February 2014 09​:42\, Tim Bunce \Tim\.Bunce@&#8203;pobox\.com wrote​:

On Tue\, Feb 18\, 2014 at 09​:21​:47AM +0100\, Steffen Mueller wrote​:

Fair. FTR\, I am not at all a fan of the fact that DD output is evalable. I know it's a long-standing guarantee\, but it's just disaster waiting to happen in code from the uninitiated.

Perhaps that guarantee should be officially loosened in the docs.

Unless Purity is enabled there is no such guarantee as far as I know. With strictures enabled you will not be able to eval a self referential structure for instance. And even with Purity enabled DD simply does not model perl vars properly for it to ever be able to dump certain data structures properly.

$ perl -MData​::Dumper -e'my ($x\,$y); $x=\$y; $y=\$x; print Dumper($x\,$y);' $VAR1 = \\$VAR1; $VAR2 = ${$VAR1};

Is an example of a seemingly correct dump which is actually under close inspection NOT correct (Try updating $VAR2\, which should change the value of $$VAR1 but it doesn't). I call this test the "scalar cross" btw.

cheers\, Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From @demerphq

On 18 February 2014 10​:40\, demerphq \demerphq@&#8203;gmail\.com wrote​:

On 18 February 2014 09​:42\, Tim Bunce \Tim\.Bunce@&#8203;pobox\.com wrote​:

On Tue\, Feb 18\, 2014 at 09​:21​:47AM +0100\, Steffen Mueller wrote​:

Fair. FTR\, I am not at all a fan of the fact that DD output is evalable. I know it's a long-standing guarantee\, but it's just disaster waiting to happen in code from the uninitiated.

Perhaps that guarantee should be officially loosened in the docs.

Unless Purity is enabled there is no such guarantee as far as I know. With strictures enabled you will not be able to eval a self referential structure for instance.

And if they are disabled you will be able to eval it\, but it wont produce the correct results.

Cheers\, Yves

perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From @demerphq

On 18 February 2014 09​:21\, Steffen Mueller \mail@&#8203;steffen\-mueller\.net wrote​:

On 02/17/2014 08​:47 PM\, demerphq wrote​:

a\) Die with an intelligible error message\.

As a debugging tool no\, i dont think so\, at least not with standard config and operating parameters. i think in sucha case it would be better we output an annotated structure that gave th edev some insight of what was going on\, even if it was not evalable.

Fair. FTR\, I am not at all a fan of the fact that DD output is evalable. I know it's a long-standing guarantee\, but it's just disaster waiting to happen in code from the uninitiated.

See my reply to Tim. I am not convinced it is guaranteed that is evalable.

b\) Copy\-serialize or some other cop\-out?

I would be fine if this was configurable\, so that if you wanted to be able to deserialie the packet we would do something like this on an opt-in basis. But i dont think it would be the right behaviour overall.

its a tough call regardless. we are basically leaking internal abstractions.

Agreed. My stance is that making DD handle *any* Perl data structure and construct is fiendishly hard and a lot of work at best and a fools errand otherwise. Consider the amount of work we (you and I) have put into Sereal to make it as powerful as it is. If people want the ultimate debugging dumper\, I think you Data​::Dump​::Streamer is what they should reach for.

Yeah\, I agree generally. Or Devel​::Peek. But that has not received the love it should have in recent perl releases. People making internal changes have not kept Devel​::Peek properly updated to reflect their changes. We should probably change that.

Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"