Re^2: Dumping variables but DRY and simple

> 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

Comment on Re^2: Dumping variables but DRY and simple

Replies are listed 'Best First'.
Re^3: Dumping variables but DRY and simple by BrowserUk (Patriarch) on Mar 27, 2010 at 21:00 UTC
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 } }->()->() +"` [download] 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` [download] over `20100327204831.321 file.pl(87): $buf = '...';` [download] 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. "I'd rather go naked than blow up my ass"	[reply] [d/l] [select]
Re^4: Dumping variables but DRY and simple by Anonymous Monk on Mar 28, 2010 at 01:17 UTC
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} } }->()->()->()'`	[reply] [d/l] [select]
Re^5: Dumping variables but DRY and simple by BrowserUk (Patriarch) on Mar 28, 2010 at 01:23 UTC
Not off the top of my head. And I've no doubts that the bug I did demonstrate will be fixed shortly. But it served my purpose. 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"	[reply]