in reply to Re: Finding file level lexical variables
in thread Finding file level lexical variables

I think that should be peek_my(0):

#! perl
use strict;
use warnings;
use feature   qw( state );
use PadWalker qw( peek_my );

our $fred = 'Flintstone';
my  $foo  =  17;
my  $quux =  bar();

printf "Sum is %d\n", $foo + $$quux;

sub bar
{
    state   $c   =  5;
    my      $baz = 42;
    return \$baz;
}

my $h_ref = peek_my(0);

print "$_\n" for keys %$h_ref;

[download]

Output:

 2:00 >perl 1643_SoPW.pl
Sum is 59
$quux
$foo

 2:00 >

[download]

Hope that helps,

Athanasius <°(((>< contra mundum Iustus alius egestas vitae, eros Piratica,

Replies are listed 'Best First'.
Re^3: Finding file level lexical variables
by LanX (Saint) on May 25, 2016 at 16:08 UTC
    well I meant peek_my(1) to be called from a sub to avoid cluttering the top scope with introspection code. :)

    Cheers Rolf
    (addicted to the Perl Programming Language and ☆☆☆☆ :)
    Je suis Charlie!

[reply]
[d/l]
      PadWalker has some serious problems when it comes to file-level lexical variables. Consider the following Perl script and Perl module: 
      use strict;
use Devel::Size qw(total_size);
use Data::Dumper;
use TestModule;

my $h = TestModule::get_mem();
foreach my $name (keys(%$h)) {
    my $ref = $h->{$name};
    my $mem = total_size($ref);
    print("$name - $mem bytes\n");
    print(Dumper($ref));
    print("\n");
    }

      [download]
      package TestModule;

use strict;
use PadWalker qw(peek_my);

my $str = 'abcxyzabcxyzabcxyzabcxyz';
my $h = { x => 'abcabcabcabcabc', y => 'xyzxyzxyzxyzxyz'};
my $l = ['abcdefghi', 'stuvwxyz'];

sub get_mem {

my $str1 = 'abcxyzabcxyzabcxyzabcxyz';
my $h1 = { x => 'abcabcabcabcabc', y => 'xyzxyzxyzxyzxyz'};
my $l1 = ['abcdefghi', 'stuvwxyz'];

return peek_my(0);
}

1;

      [download]
      It produces the following output (I'm doing this on Windows using ActivePerl, PadWalker version 2.2). I'm particularly intrigued by the fact that it reports the variable $str of having size 88 bytes (which is correct), while Data::Dumper says that it's a reference to undef! 
      $str1 - 52 bytes
$VAR1 = \'abcxyzabcxyzabcxyzabcxyz';

$h - 16 bytes
$VAR1 = \undef;

$h1 - 230 bytes
$VAR1 = \{
            'y' => 'xyzxyzxyzxyzxyz',
            'x' => 'abcabcabcabcabc'
          };

$l1 - 132 bytes
$VAR1 = \[
            'abcdefghi',
            'stuvwxyz'
          ];

$str - 52 bytes
$VAR1 = \undef;

$l - 16 bytes
$VAR1 = \undef;

      [download]
[reply]
[d/l]
[select]
        What exactly is your point? Not sure what you expect. ...

        You are using peek_my(0) , the file scope variables are from the outer scope but never used, so they are not really integrated in the pad and should be already destroyed at the time of your printing. (By ref counting, but digging in memory might still show the old content)

        PadWalker is reading internals in unofficial ways and can't be more intelligent as their structures. Always be prudent about side effects.

        Anyway, the case of the OP is easily solved with peek_my(1)

        update

        If I were you I'd do the introspection and analysis in the sub before any destruction can have happened! Do not return references.

        Cheers Rolf
        (addicted to the Perl Programming Language and ☆☆☆☆ :)
        Je suis Charlie!

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom