Debugger angst

Discussion in 'Perl Misc' started by Clint Olsen, Jul 30, 2004.

  1. Clint Olsen

    Clint Olsen Guest

    One of the things I can't stand about Perl is the debugger. It really
    lacks compared to C debuggers, and I can't for the life of me figure out
    why this has to be. Do most Perl programmers just use print to debug their
    code?

    When I get the runtime error 'Can't use string ("BLAH") as an ARRAY
    ref...', the first thing you would expect is that the debugger stop
    excution immediately so you can inspect what access caused the problem.
    For example, in a multi-level data structure access, how can I tell which
    particular access resulted in a violation?

    $$hr{abc}[123][456] = $foo; # ????

    Instead Perl bails out completely, so while the call stack is nice, that's
    all you get!

    Secondly, what's with the lack of ability to go up/down frames in the
    stack? You can use 'T' to view the call stack, but in traditional
    debuggers, you can view variables etc. at each stack frame to actually find
    out /how/ you got into a particular predicament. So, I end up having to
    put on my psychic hat to figure how how I /might/ have gotten there and
    hope I can set a sensible breakpoint.

    Thanks,

    -Clint
     
    Clint Olsen, Jul 30, 2004
    #1
    1. Advertising

  2. Clint Olsen

    Dan Wilga Guest

    In article <slrncgjqop.18d4.clint@belle.0lsen.net>,
    Clint Olsen <clint@belle.0lsen.net> wrote:

    > One of the things I can't stand about Perl is the debugger. It really
    > lacks compared to C debuggers, and I can't for the life of me figure out
    > why this has to be. Do most Perl programmers just use print to debug their
    > code?


    I agree that perl's debugger is a bit lacking, though not really very
    much compared to gdb (ack, ptooey!).

    There are a few graphical perl debuggers and IDEs that probably address
    some of what you want:

    http://sourceforge.net/projects/ddd/
    http://sourceforge.net/projects/ptkdb/
    http://sourceforge.net/projects/open-perl-ide/

    However, if you're looking for commandline-only debugging, then I think
    the answer you're going to get from most folks who read this newsgroup
    is: perl's debugger is written in perl, and it's open source. So feel
    free to develop a better one. ;-)

    --
    Dan Wilga
    ** Remove the -MUNGE in my address to reply **
     
    Dan Wilga, Jul 30, 2004
    #2
    1. Advertising

  3. Clint Olsen

    Peter Scott Guest

    In article <slrncgjqop.18d4.clint@belle.0lsen.net>,
    Clint Olsen <clint@belle.0lsen.net> writes:
    >One of the things I can't stand about Perl is the debugger. It really
    >lacks compared to C debuggers, and I can't for the life of me figure out
    >why this has to be. Do most Perl programmers just use print to debug their
    >code?


    Some of us use the debugger quite a bit. Some of us have even
    written books featuring it :)

    >When I get the runtime error 'Can't use string ("BLAH") as an ARRAY
    >ref...', the first thing you would expect is that the debugger stop
    >excution immediately so you can inspect what access caused the problem.
    >For example, in a multi-level data structure access, how can I tell which
    >particular access resulted in a violation?
    >
    >$$hr{abc}[123][456] = $foo; # ????


    Run it under the debugger again and set a breakpoint for that line.
    You wouldn't want the overhead of the debugger on every execution,
    would you?

    >Secondly, what's with the lack of ability to go up/down frames in the
    >stack? You can use 'T' to view the call stack, but in traditional
    >debuggers, you can view variables etc. at each stack frame to actually find
    >out /how/ you got into a particular predicament. So, I end up having to
    >put on my psychic hat to figure how how I /might/ have gotten there and
    >hope I can set a sensible breakpoint.


    Which is why I developed the 'y' command which allows you to inspect
    lexicals at higher stack frames. perldoc perldebug.

    --
    Peter Scott
    http://www.perldebugged.com/
    *** NEW *** http://www.perlmedic.com/
     
    Peter Scott, Jul 30, 2004
    #3
  4. Clint Olsen

    Clint Olsen Guest

    On 2004-07-30, Peter Scott <> wrote:
    >>$$hr{abc}[123][456] = $foo; # ????

    >
    > Run it under the debugger again and set a breakpoint for that line.
    > You wouldn't want the overhead of the debugger on every execution,
    > would you?


    Of course not. But if I'm running the code in the debugger, I've already
    accepted the overhead. Trap the problem, and allow the user to inspect the
    data that's there. Don't unroll and bail out on me...

    The line I showed above only failed under certain conditions. This happens
    in Perl all the time. So, just setting a breakpoint does nothing. I could
    succeed hundreds of times on this line. Coming up with the condition can
    be really irritating in a situation like this:

    $foo = $$hr{abc}[123]{def}[456]; # one level is undef, which one?

    So, in a multidimensional hash/array access, just telling me an array or
    hash was 'undef' doesn't tell me a whole lot. Since Perl has runtime type
    checking, it would seem that it should be able to tell me /which/ thingy
    was malformed.

    > Which is why I developed the 'y' command which allows you to inspect
    > lexicals at higher stack frames. perldoc perldebug.


    Ok, I'll install PadWalker and see if I can make this thing work for me.

    Thanks,

    -Clint
     
    Clint Olsen, Jul 30, 2004
    #4
  5. Clint Olsen

    Clint Olsen Guest

    On 2004-07-30, Dan Wilga <> wrote:
    >
    > I agree that perl's debugger is a bit lacking, though not really very
    > much compared to gdb (ack, ptooey!).


    I would sure like to know where you think gdb is lacking in capability. I
    think the end-all of capabilties in gdb is [hardware] watchpoints. Either
    I don't understand how watches workin Perl or they are abysmal. Every time
    an object goes out of scope I get a notice that the value of a particular
    object has changed. This is especially common in scripts not using
    file-scoped lexicals. I've tried dereferencing an object so I could
    actually look at the actual object in question, but it doesn't seem to
    help.

    > http://sourceforge.net/projects/ddd/
    > http://sourceforge.net/projects/ptkdb/
    > http://sourceforge.net/projects/open-perl-ide/


    Thanks for the links. I'll check them out. Although my preference would
    be for a graphical debugger that actually did not wrap around Perl's
    command-line debugger. The user interface is pretty terse.

    Thanks,

    -Clint
     
    Clint Olsen, Jul 30, 2004
    #5
  6. Clint Olsen

    Clint Olsen Guest

    On 2004-07-30, Peter Scott <> wrote:
    >
    > Which is why I developed the 'y' command which allows you to inspect
    > lexicals at higher stack frames. perldoc perldebug.


    Ok, I managed to get this installed, and here are my thoughts on this:

    1) Since 'T' doesn't print out the numbers of the stack frames, I end up
    using 'wc -l' to calculate my 'uplevel'. This is really annoying.

    2) This command (and apparently 'X' and 'Y') don't take qualified type
    names or references to such, just the literal text name. Why? So, if I
    wanted to inspect a multi-level data structure (array, hash, or
    whatever), I either get all or none of it. In our case, that was about
    1/4 mi. of text :)

    3) 'y' and friends don't have a depth limit so you don't get the reams of
    data mentioned in #2.

    On another completely independent gripe:

    Why doesn't the perl debugger take File:line input as debug points? Every
    time I have to type "f Package.pm" and "b lineno", it's very aggravating.

    Don't get my wrong, 'y' is a big improvement over what I had before -
    zip/nada for peeking at the stack. I just wanted to point out some usage
    model issues that could use some refinement.

    It would be interesting if you could interject on the effort involved on
    any of these points. I'd even consider trying to add them with my fumble
    fingers if it was feasible. I either need to do that or get the heck out
    of using Perl. :)

    -Clint
     
    Clint Olsen, Aug 5, 2004
    #6
  7. Clint Olsen

    Peter Scott Guest

    In article <slrnch3222.neh.clint@belle.0lsen.net>,
    Clint Olsen <> writes:
    >On 2004-07-30, Peter Scott <> wrote:
    >>
    >> Which is why I developed the 'y' command which allows you to inspect
    >> lexicals at higher stack frames. perldoc perldebug.

    >
    >Ok, I managed to get this installed, and here are my thoughts on this:
    >
    >1) Since 'T' doesn't print out the numbers of the stack frames, I end up
    > using 'wc -l' to calculate my 'uplevel'. This is really annoying.


    Agreed.

    >2) This command (and apparently 'X' and 'Y') don't take qualified type
    > names or references to such, just the literal text name. Why? So, if I
    > wanted to inspect a multi-level data structure (array, hash, or
    > whatever), I either get all or none of it. In our case, that was about
    > 1/4 mi. of text :)


    'y' was intended as an analog to 'V' and 'X', which were already defined as
    ways of scanning a package for particular variables. For inspecting an
    arbitrary expression, 'x' is your friend. Unfortunately, 'x' can't jump
    scoping levels.

    >3) 'y' and friends don't have a depth limit so you don't get the reams of
    > data mentioned in #2.
    >
    >On another completely independent gripe:
    >
    >Why doesn't the perl debugger take File:line input as debug points? Every
    >time I have to type "f Package.pm" and "b lineno", it's very aggravating.


    Agreed, but you can usually set a breakpoint for the subroutine in Package.pm,
    or in some other way wait until you get to that file before setting the
    breakpoint. I have wanted the feature you suggest, but not very strongly.
    As to 'why', see below.

    >Don't get my wrong, 'y' is a big improvement over what I had before -
    >zip/nada for peeking at the stack. I just wanted to point out some usage
    >model issues that could use some refinement.
    >
    >It would be interesting if you could interject on the effort involved on
    >any of these points. I'd even consider trying to add them with my fumble
    >fingers if it was feasible. I either need to do that or get the heck out
    >of using Perl. :)


    The reason the features you request aren't in the debugger is best explained
    by the fact that it is a tortuous mess of incomprehensible code with a creaky
    legacy user interface. Only a few brave souls in recent years have had the
    inclination and the courage to attempt to modify it. I was responsible only
    for minuscule modifications. Most people these days are waiting for Mark
    Jason Dominus' rewrite, schedule unknown to me.

    If you wanted to attempt any of those changes, the one that might be doable
    without encountering insanity in the process is qualifying line number
    breakpoints with filenames. No guarantee, though.

    --
    Peter Scott
    http://www.perldebugged.com/
    *** NEW *** http://www.perlmedic.com/
     
    Peter Scott, Aug 5, 2004
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Derek Goto

    Debugger question

    Derek Goto, Aug 25, 2003, in forum: Perl
    Replies:
    1
    Views:
    996
    Eric J. Roode
    Aug 25, 2003
  2. Paul Faulstich
    Replies:
    0
    Views:
    500
    Paul Faulstich
    Jan 27, 2004
  3. Sara
    Replies:
    0
    Views:
    695
  4. Robert Oschler
    Replies:
    1
    Views:
    246
    Mcginkel
    Sep 5, 2005
  5. aflat362
    Replies:
    7
    Views:
    236
    naixn
    Dec 7, 2006
Loading...

Share This Page