On Wed, 23 Feb 2011 16:33:49 +0100, Brian Raven <bra...@nyx.com> wrote:
>>> I remembered this morning that there is a bug tracker for ActivePerl, >>> started to write up an error report and in doing so ended up >>> formulating a possible for for ActiveState: >>> http://bugs.activestate.com/show_bug.cgi?id=89447 >> >> It's the standard behavior of Perl. > > While autovivication is part of Perl's normal behaviour, I'm not sure > that it is cause of this problem. The fact that un-commenting the line > before the grep in the OP's code makes the problem go away tends to > confirm this. > > I suspect that it is related to the Activestate overriding of Config > ('use diagnostics' will give a stack trace) but I can't see how it > causes that error, i.e. "%Config::Config is read-only". > > Note that inhibiting the activestate override > ($ENV{ACTIVEPERL_CONFIG_DISABLE} = 1) also seems to make the problem go > away. > > Maybe somebody from Activestate has a clue. Try reading the whole bug i linked. It has a detailed description of what happens and when and where the offending error is triggered and how it can be prevented. Summary: Grep makes $_ point at $Config{foo}, on first load ActivePerl::Config tries to load File::Basename, which triggers Exporter.pm, which goes "local $_". At THAT point an attempt to autovivify is made causing the whole thing to crash down. Solution: Make sure $_ isn't pointing at %Config when Exporter.pm happens. This can be done as simple as this: map { require ActiveState::Path } 1; (Though i'm sure more elegant solutions exist.) -- With regards, Christian Walde _______________________________________________ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
