in reply to Dumping variables but DRY and simple

UPDATE: hmm maybe Conway's Smart::Comments should be mentioned, but it uses code filters...

...but only on comments, and only when you're debugging. Once you've finished, comment it out and it's all gone.

It's far less invasive than PadWalker.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"I'd rather go naked than blow up my ass"
  • Comment on Re: Dumping variables but DRY and simple

Replies are listed 'Best First'.
Re^2: Dumping variables but DRY and simple
by LanX (Saint) on Mar 27, 2010 at 19:01 UTC
    > It's far less invasive than PadWalker.

    In my example "hack" I'm using PadWalker to determine the variable name for use in debugging or error msg context.

    I can check if it's installed and otherwise savely fall back to something like "$VAR1" or the "$filename-$linenumber" if not.

    And I doubt that PadWalker can cause instabilities just by parsing the optree!

    In any way I wouldn't suggest using code filters for error msgs in productive code...

    Cheers Rolf

      And I doubt that PadWalker can cause instabilities just by parsing the optree!

      No? Try

      perl -MPadWalker=peek_my -e"my $x = 42; sub { my $closed_over = $x; sub { peek_my 0 } }->()->() +"
      In any way I wouldn't suggest using code filters for error msgs in productive code...

      Neither did I.

      But then neither would I recommend the tracing of variables in production code.

      The need for that is: a) a clear sign of inadequate testing; b) poor design.

      Excepting Acts of God and Cosmic Rays, given the same values, code produces the same results. The only source of variability is IO.

      And if this is a permanent feature of your logging or error handling, then the trivial extra investment to log:

      20100327204831.321 file.pl(87): Received '...' from socket:0xdeadbeef

      over

      20100327204831.321 file.pl(87): $buf = '...';

      The point is that noone, neither programmer nor user, is going to be able to draw any conclusions from "$buf = '...', without consulting the source. And with the file and line number, the variable that contains the value is obvious. Making it unnecessary information in the log.

      For development time debugging, watching the values of variables change without reference to the source can give the programmer clues to his mistakes--out by one being the classic. And Smart::Comments is ideal for this.

      But once you move into production, there is always a better identification for a value--more meaningful to both user and maintenance programmer alike--than the internal variable identifier.

      You won't agree. And I won't argue the point further.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
        can you demonstrate a segmentation fault using peek_my 1?

        no problems with this:

        perl -MPadWalker=peek_my -e'my $x = 42; sub { my $c = $x; sub { sub {peek_my 1} } }->()->()->()'