in reply to Update: homespun GUI Wrapper for the Perl Debugger with an auto-refreshing editor (BBEdit on Mac OS X) (was: Perl Debugger: Is there a variable with the current source line number being traced?)

is $DB::line what you are looking for?

It should essentially always be set to (caller)[2].

Did you already have a look at perldebguts?

perl5db.pl is also heavily PODed.

This thread might also be of interest Make debugger break on source lines matching a pattern.

HTH! :)

Cheers Rolf

( addicted to the Perl Programming Language)

  • Comment on Re: Perl Debugger: Is there a variable with the current source line number being traced?
  • Select or Download Code

Replies are listed 'Best First'.
Re^2: homespun GUI Wrapper for the Perl Debugger with an auto-refreshing editor (BBEdit on Mac OS X)
by Shoveler (Acolyte) on Feb 26, 2014 at 11:46 UTC
    yes, $DB::line was the one I was looking for originally. Thanks.

    The perl5db.pl documentation was most helpful to me, but actually the in-place comments more than the POD, at least for what I wanted right now. perldebguts is also interesting.

    I've also begun to use the explicit debugger invocation from the source in a few interesting places.

    My current state is this (to give everyone some feedback):

    I'm working on a Mac and I have employed BBEdit as debugging output viewer.

    I have made just some minor modifications to perl5db.pl to the following effects:

    • whenever the debugger detects a switch between sources (notably including evals as well!), it writes out the current source to the file ~/t/Perl/thesource.pl

    • The debugger pushes a cursor position update on every tracing step to the BBEdit window named thesource.pl via AppleScript (called osascript on the command-line gateway):

    system("osascript", "-e", "tell application \"BBEdit\" tell the text of the window \"thesource.pl\" select insertion point before line $line end tell end tell");

    • I have augmented the debugger command "|" with an optional parameter which is appended to the pager option string before execution. I'm using it like this:

    o pager=cat>~/t/Perl/ {|(vars.pl)y {{|(stack.txt)T {{|(package_vars.pl)X

    |(vars.pl)y actually executes the y command and pipes it to the effective "pager" cat>~/t/Perl/vars.pl, writing it to that file on every prompt.

    So the pre-prompt auto commands keep updating the following files in ~/t/Perl/:

    vars.pl: dump of local variables
    stack.txt: stack backtrace
    package_vars.pl: package variables (I keep this off much of the time because in my project the amount can be huge)

    In the GUI editor BBEdit I keep these three files and thesource.pl open besides my working sources and data files. BBEdit automatically detects any files being updated and reloads them transparently while preserving their scrolled positions. And perl5db.pl also keeps updating the cursor in thesource.pl.

    This is so fast that it is an actually usable replacement for a regular GUI debugger.

    And when I occasionally want to display additional information, I can just push it to additional windows as needed like this:

    |(more.pl)x %mhash

    For me it's quite nice that syntax colouring and all the GUI niceties of my regular source editor are just seamlessly available and I have large, independent windows for debugger output. That the debugger still needs to be operated on the command line in a Terminal window is not an issue in this context since BBEdit in the background keeps updating its windows while I keep going.

    And this is what it looks like while debugging Perl code:

    <img src="http://i.imgur.com/zSWB3wO.png" title="Hosted by imgur.com" />

    I'm aware that this is kind of freaky (which is half the fun of it!), but it works quite well and is much more practical than the command-line-only debugger on its own. I'm aware that there are some other GUI wrappers around, but they come with their own quirks again, so I actually prefer it this way for the moment.

    The same principle could certainly be applied to other environments than OS X and BBEdit as well, so maybe it helps anyone else along as well.

    If anyone is interested, I can of course provide the (pretty raw) modifications I've made to perl5db.pl.

    I've just needed to get ahead with the actual debugging in some relatively complex code, so right now functionality goes before beauty for me.

    One known TODO would be to run the tracing cursor in the actual source files and switching between those as needed instead of using the saved thesource.pl for everything (except for evals where that's the only way), but I may get around to that some time later.

      tl;dr .... :-|

      Unfortunately I don't have the time to go into details ATM, but I think many modifications to perl5db.pl where unnecessary.

      For instance you could have used persistent aliases instead of manipulating commands. The debugger has also an IDE interface to direct outputs to pipes.

      If you can't get ptkdb running on your Mac because of TK version problems (which is really weird and merits a thread of its own) try giving emacs a try, which has more or less the reference implementation of debugger integration.

      With Aquamacs you'll even get standard Mac behaviour.

      Try M-x perldb.

      For more tricks of how to patch the debugger please see the slides I linked in the thread I linked to before.

      HTH :)

      Cheers Rolf

      ( addicted to the Perl Programming Language)

        I haven't even done "many" changes to perl5db.pl to begin with! ;-)

        It's been less than 20 lines in total (including the AppleScript ones shown above), and in only 3 places.

        And how would aliases help me? Aliases can't seem to add actual functionality – they only alias existing functionality for shorthand invocation as far as I can tell. But I actually need additional functionality.

        Do you happen to know where to look for the IDE interface? I hadn't noticed it so far. But in that case I would have had to create a separate intermediate process; Sounds like a lot of additional complexity...

        Of course I agree that that might be cleaner, if it can actually achieve what I need.

        Emacs wouldn't be an advantage for me – it would introduce a whole additional editor environment with different usage, different presentation and a substantial learning curve. The BBEdit solution actually works surprisingly well already.

        Interesting information and hints from you and above, in any case. While I might eventually end up changing things from where I'm now, I'm quite stoked about the level of usability I've managed to wring out of this provisional solution already with a minimum of customization.

        Many thanks to everybody anyway! :-)