Hi all,

I just encountered this myself:

| io:~/source/mail-spf-perl/trunk> perl Build.PL
| Creating custom builder _build/lib/MyModuleBuilder.pm in _build/lib
| Checking whether your kit is complete...
| Looks good
|
| Checking prerequisites...
| Looks good
|
| Creating new 'Build' script for 'Mail-SPF' version 'v2.005_001'
| io:~/source/mail-spf-perl/trunk> ./Build manifest
| Global symbol "$VAR1" requires explicit package name at (eval 22)
| line 20, <GEN6> line 1.
|         ...propagated at /usr/share/perl5/Module/Build/Base.pm
|         line 1015, <GEN6> line 1.

I am running Module::Build 0.2808 now, so I am now in a position to
reproduce the problem and provide whatever information is needed to debug
it.  I am attaching my _build/build_params.

I have been running M::B 0.28 for quite a while, and today is the first
time this happened to me.  As indicated above, changing _build/
build_params to say '$main::VAR1' instead of '$VAR1' works around it
temporarily.  Not really a solution, though, obviously.

My versions:
  Perl 5.8.8
  Module::Build 0.2808
  version 0.7203
  Data::Dumper 2.121_08

Julian.

build_params.gz 2K Download

signature.asc < 1K Download

On 12/5/06, Ken Williams <k...@mathforum.org> wrote:

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.

Note only the last dump is actually valid.

d:\sync-clone>perl -MData::Dumper -le"my $x=[]; my $y=[$x,$x]; print
Dumper($y); print Data::Dumper->new([$y])->Terse(1)->Dump; print
Data::Dumper->new([$y])->P
urity(1)->Dump();
$VAR1 = [
          [],
          $VAR1->[0]
        ];

[
          [],
          $VAR1->[0]
        ]

$VAR1 = [
          [],
          []
        ];
$VAR1->[1] = $VAR1->[0];

So it looks like two issues, first, using Dumper in production code
without Purity(1), and second, somehow the data structure being dumped
contains a duplicated reference.

This is the reason why in DDS the default is Purity(1), even tho in
debugging it makes the dump harder to read. You have to specifically
request an unsafe mode for output. With Dumper it gives an unsafe
output by default and you have to request the safe mode explicitly.

The proper way to get DD to do what I think you want to do is as follows:

my $serialized="do{ my "
                      . Data::Dumper->new([$var],['dumped_var'])
                                           ->Purity(1)
                                           ->Dump()
                      . '$dumped_var }';

and then later on you do:

my $deserialized=eval $serialized or die "Error '$@' in serialized
code:\n$serialized";

By putting the code in a do{} block, adding the my, explicitly
designating the variable name it will use and explicitly asking the
do{} to return the correct value you get the same effect as Terse()
but it is actually robust.

Of course you can waste a lot of time working out why the ref occurs
in the original data structure multiple times, but well, why bother?
Just serialize it properly.

Cheers,
Yves

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

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.

Yeah, but you wrote a Dumper. :)

Terse shows up in a bunch of examples, perhaps it should be removed from them?

--
I have a date with some giant cartoon robots and booze.

Yeah, I like the idea of having the best practice encoded as a function.

--
There will be snacks.

On Sep 25, 2007, at 4:55 PM, demerphq wrote:

There's no way you're that easily shocked.  If so, I'm shocked. =)

Thanks for your strongly-worded help, we'll get a DumpVar-like fix in  
M::B soon.

  -Ken

On Sep 25, 2007, at 4:55 PM, demerphq wrote:

I've committed this change in the M::B code.

  -Ken