Re^3: Dumping variables but DRY and simple

Replies are listed 'Best First'.
Re^4: Dumping variables but DRY and simple by LanX (Saint) on Mar 27, 2010 at 15:58 UTC
> To get to the real name, you would have to fiddle with the compiler. Sorry IMHO that's wrong, I can get the realname for `my` and `our` declarations with the help of PadWalker ~~which is core~~! And even without strictures I can still search through the symbol tabel of the caller's package. (which might produce multiple results) Cheers Rolf	[reply] [d/l] [select]
Re^5: Dumping variables but DRY and simple by ikegami (Patriarch) on Mar 27, 2010 at 16:06 UTC
PadWalker inspects the opcode tree, which what I think `rovf` meant.	[reply] [d/l]
Re^5: Dumping variables but DRY and simple by rovf (Priest) on Mar 27, 2010 at 16:09 UTC
Sorry IMHO that's wrong, I can get the realname for my and our declarations with the help of PadWalker which is core! I think PadWalker does interfere with the compiler (otherwise I don't see how it could get the names of the lexicals). Since when is it in Core? I can't see it in Perl 5.10.0 (in the ActiveState distribution). -- Ronald Fischer <ynnor@mm.st>	[reply] [d/l]
Re^6: Dumping variables but DRY and simple by ikegami (Patriarch) on Mar 27, 2010 at 17:00 UTC
I haven't looked at the code recently, but I don't think so. The name of a lexical IS available. `>perl -MO=Concise,-exec -e"my $x; print $x" 1 <0> enter 2 <;> nextstate(main 1 -e:1) v:{ 3 <0> padsv[$x:1,2] vM/LVINTRO <---- 4 <;> nextstate(main 2 -e:1) v:{ 5 <0> pushmark s 6 <0> padsv[$x:1,2] l <---- 7 <@> print vK 8 <@> leave[1 ref] vKP/REFC -e syntax OK` [download] And yes, PadWalker is not distributed with Perl.	[reply] [d/l]
Re^6: Dumping variables but DRY and simple by LanX (Saint) on Mar 27, 2010 at 16:19 UTC
> Since when is it in Core? very strange I never saw an installation without PadWalker but it's indeed not listed. UPDATE: `corelist -a PadWalker<P> PadWalker was not in CORE (or so I think)` [download] urgh ... well ... hard to understand ... anyway I always need to install it when debugging and it's all about debugging. Cheers Rolf	[reply] [d/l]
Re^7: Dumping variables but DRY and simple by Anonymous Monk on Mar 27, 2010 at 16:33 UTC
Re^8: Dumping variables but DRY and simple by LanX (Saint) on Mar 27, 2010 at 18:53 UTC
Some notes below your chosen depth have not been shown here
Re^4: Dumping variables but DRY and simple by LanX (Saint) on Mar 27, 2010 at 16:32 UTC
For completeness, there is still the possibility to fiddle with the sourcecode. caller returns linenumber and filename of the caller. Anyway I'm not sure if there are sideeffects when trying to access the file... Cheers Rolf	[reply]
Re^5: Dumping variables but DRY and simple by rovf (Priest) on Mar 27, 2010 at 16:40 UTC
Anyway I'm not sure if there are sideeffects when trying to access the file... This would really be a hack. For instance, the file might already have been changed after the program has been started (a quite common situation during development). But yes, it is a clever idea. -- Ronald Fischer <ynnor@mm.st>	[reply] [d/l]
Re^6: Dumping variables but DRY and simple by LanX (Saint) on Mar 27, 2010 at 16:48 UTC
There are more options: `Furthermore, when called from within the DB package, caller returns more detailed information: it sets the list variable @DB::args to be the arguments with which the subroutine was invoked.` Whatever this practically means... anyway I need the dumping for debugging and as rubasov said any keystroke saved is a bless while debugging. OR I could pass only the variable _names_ and use PadWalker and Stash to get the references/values in caller's context. But as stated in the OP I don't wanna reinvent the wheel... Cheers Rolf	[reply]
Re^5: Dumping variables but DRY and simple by ikegami (Patriarch) on Mar 27, 2010 at 16:55 UTC
That's even worse. That requires the ability to parse Perl, and it assumes the code came from a file and that there is only one function call in the statement at that line.	[reply]