Re: Error message 'Global symbol "$VAR1" requires explicit package name' with newer M::B
Julian Mehnle
I wrote:
> I am getting reports of a strage error message when trying to build a
> M::B 0.26 based distro (Mail::SPF, currently 2.000_003) on certain
> systems that have a _higher_ version of M::B:
>
> http://cpantesters.perl.org/show/Mail-SPF.html
>
> For example, on a system with M::B 0.280500, it says:
>
> | Global symbol "$VAR1" requires explicit package name at (eval 24)
> | line 1075, <GEN6> line 1.
> | ...propagated at
> | /usr/local/standard-perl/lib/perl5/site_perl/5.8.8/Module/Build/Base.pm
> | line 1002, <GEN6> line 1.
>
> The 'Global symbol "$VAR1" requires explicit package name' message is
> the recurring pattern.
>
> As the maintainer of the libmodule-build-perl Debian package seems to
> be sleeping, Debian still has only 0.26, so I haven't been able to
> reproduce the issue myself.
>
> A user of my package found out that the problem could be avoided by
> changing _build/build_params to say '$main::VAR1' instead of '$VAR1'.
> Again, I couldn't reproduce it myself.
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.
Demerphq
>
> 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.
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/"
Michael G Schwern
> On 12/5/06, Ken Williams <k...@mathforum.org> 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.
Michael G Schwern
>> 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!>
>
> such output may not always be parseable by "eval">
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.
Michael G Schwern
> Would something like the following patch be good in your opinion?
Yeah, I like the idea of having the best practice encoded as a function.
Ken Williams
On Sep 25, 2007, at 4:55 PM, demerphq 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.
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
Ken Williams
On Sep 25, 2007, at 4:55 PM, demerphq wrote:
> 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 }';
I've committed this change in the M::B code.
-Ken