demerphq wrote: > On 12/5/06, Ken Williams <[EMAIL PROTECTED]> wrote: >> On Dec 4, 2006, at 12:35 PM, Julian Mehnle wrote: >> >>> Is it likely that this occurs with CPANTS in the first place? >>> Unfortuna- >>> tely, CPANTS doesn't tell the Data::Dumper version it is using... :-( >> I looked at the three failure reports you referenced, and seeing as 2 >> of them come from the same person, perhaps we could ask imacat what >> version is installed? I just used 'svn annotate' to go *way* back in >> the sources for M::B and I confirmed that we've been using "Terse" >> dumping since this feature was introduced. >> >> Another idea I just had by looking at the Data::Dumper docs was that >> maybe some funny refs are in the structure it's trying to write? It >> says "$VARn names will be avoided where possible", and maybe in this >> case it doesn't think it's possible. So we'd probably also need to >> see the build_params file to diagnose that. > > Im shocked that anyone is using Terse in production code. It is > completely unsafe and intended ONLY for debugging purposes. In fact id > say that using Data::Dumper without Purity(1) as a serialization > mechanism in production code is simply insane. > > All you need is a single ref in two positions in a data structure to > make an unevalable dump without Purity(1). With Terse it will just be > worse.
If that's the case, perhaps the docs for Terse could use stronger language. Right now it's a little obtuse. · $Data::Dumper::Terse or $OBJ−>Terse([NEWVAL]) When set, Data::Dumper will emit single, non‐self‐referential values as atoms/terms rather than statements. This means that the $VARn names will be avoided where possible, but be advised that such output may not always be parseable by "eval". Something like B<don't use this to serialize data in production!> -- There will be snacks.
