http://www.perlmonks.org?node_id=1010235

Here's a first draft, incomplete implementation a possible response to my notion (YMMV) that Perl's CLI debugger is intimidating to novices (well, it was to me... for several years).

IOW, here's a simple-minded, do-nothing, little script that invites the user to explore some debugger commands in circumstances in which s/he need not fear will be tantamount to rm rf (or del *.* /s, if 'doze in the learner's OS flavor).

My hope is that the minimal set of operations in the script give a hint of (or maybe "are extensive enough for a start?") the range of debugger options/commands which the user would be well advised to learn.

The specific RFC follows the code:

#!/usr/bin/perl use 5.014; # modify to match your "perl -v" unless (@ARGV) { say "debugger practice; on restart, 1st arg must be a number\n"; exit; } say "Explore debugger commands w expr W expr b Ln|Event B Ln|Event (et +c incl l v s n)\n"; my ($var1, $var2, $var3); my @arr = qw (a b c d e f g); sub testable { # useless uninformative comment my $subvar1 = shift; say "\t In sub testable, \$var1: $var1"; my $subvar2 = shift; say "\t AS PASSED TO SUB, \$var2: $var2"; $subvar2 *= 5; say "\t In sub testable, \$subvar2: $subvar2"; my $subvar_rand_int = int(rand($subvar2)); say "\t In sub, \$subvar_rand_int is: $subvar_rand_int."; return $subvar_rand_int; # to $result } chomp($var1 = shift); $var2 = int(3*$var1); say "Pre_sub, \$var1: $var1 and \$var2: $var2"; push my @pass_to_sub,$var1; push @pass_to_sub,$var2; my $result = testable(@pass_to_sub); say "Back from sub with \$result: $result"; # another comment for exploration of the deugger for $_(@arr) { $_ .= "_foo"; say "$_ " x $result; say "\n"; }

So, the question: are this notion and this approach worth pursuing, further, with additional scripts focusing on packages, OO, modules, etc... If so, where should that focus begin?

Or should one, IYO, focus instead on getting noobs to use some of the available (often for $$$) GUI debuggers/other debuggers?

Replies are listed 'Best First'.
Re: RFC: debugger_trainer
by roboticus (Chancellor) on Dec 24, 2012 at 22:40 UTC

    ww:

    That's a great idea. I would've loved something like that when I started. I like the idea of having print statements suggesting debugging operations to try, too. It would be interesting to guide a user through some basic debugging operations. It would also be nifty if it was extensible, so when someone has a debug trick they like, they could add a small script showing how to perform the trick.

    ...roboticus

    When your only tool is a hammer, all problems look like your thumb.

      "it was extensible...."

      Extensible, as in a suite of scripts -- each focusing on a few areas? I'm not sure that's what you had in mind, but if so, sounds like a very good idea.

      FOSS lives!

        ww:

        Yep. I was thinking that there might be a set of functions that many/most debug trainer scripts might want. Hopefully it would then be possible to do include it, set up a data structure or two and a few print statements or something. I was thinking it would be nice if you'd run a script, and it would start out telling you what it was going to show you, do a little setup and then present the debug prompt. (Perhaps using the @DB::typeahead buffer to get the program running before the user had to guess what to do.)

        Of course, I may be over-thinking it, too. It might just be as simple as a few print statements containing instructions and a CPAN bundle and/or namespace to put 'em.

        I don't use the debugger much, and when I do, it's just for a few simple things. I don't know everything it's capable of. I used to use Microsoft's CodeView, and learned a lot about it. It was surprisingly capable. It will be interesting to see what techniques might get published.

        ...roboticus

        When your only tool is a hammer, all problems look like your thumb.

Re: RFC: debugger_trainer
by Anonymous Monk on Dec 25, 2012 at 05:24 UTC

    If so, where should that focus begin?

    I would focus on solving an actual problem (actual debugging), not teaching perl5db -- learning perl5db commands should be a side-effect of solving a problem using perl5db

    I understand this may be more ambitious undertaking :)

    Why? Because I've learned some debugger commands, but I still do my debugging with print ( Data::Dump::dd actually ), maybe you can teach me something?

    Its like every $language-oop tutorial, teaches the how not the why, what each button does, not when to use it -- good examples can do both

    speaking of perl5db :) have you seen ebug/ebug_wx?

    Are debuggers good? Well, you can't debug everything with them :) ( Preventing BEGIN blocks from being run in the debugger? )

Re: RFC: debugger_trainer
by davies (Prior) on Dec 25, 2012 at 12:14 UTC

    ++ for the idea. I'm sorry to say that I don't think that this is the way to implement it, but as you seem to be saying that this is a work in progress, it may well be that you plan to expand it to something I would find helpful.

    I've never tried using the debugger. Like the anonymonk above, what I write is so simple that I can sort out my bugs with print statements. But I've heard nice things said about the debugger, so I'd like to get started. This is the first difficulty I have - I can see nothing telling me how to invoke the debugger, something I don't know how to do.

    You then give a number of debugger commands to explore. I can see nothing indicating what they are supposed to do and so cannot imagine how to explore them. Feigning ignorance, I cannot see any need to debug natural logarithms, not that I ever use them. As far as strings are concerned (and I'm not feigning ignorance here - that's clearly what "expr" means if you read perldoc -f split), I don't see what debugging would be needed. Again without feigning ignorance, I'm totally at a loss as to what "events" might be. This may be because my viewpoint is coloured by Excel VBA, where event handling is a powerful feature. I strongly believe that all three terms need expansion.

    I'm not clear what your code is supposed to do. Running it, it seems to work, so it's not clear to me what the bug(s) is/are that I'm supposed to find. I would find it very useful to have code (possibly a series of small bits of code) with a bug that I could identify (if only from reading the accompanying text), information on how to invoke the debugger and something telling me how to choose the command that is most likely to help me find the problem.

    If, as I said in my first paragraph, this is work in progress and you are looking for advice on whether to continue, then I for one would love you to. If this is supposed to be an accompaniment to the official docs, it would help to specify which ones and at what point(s) to refer to them or this.

    Re-reading what I have written, it seems to be very critical. I hope it's constructive criticism, as I would love to see a debugger tutorial. If I've failed, all I can do is apologise and hope that I haven't put you off.

    Regards,

    John Davies

      Re John's comment immediately preceding, "it's not clear to me what the bug(s) is/are ...."

      Sorry, that's rooted in my inadequate explanation. There are some infelicities, but not, TTBOMK, any bugs to find.

      Rather, as a candidate for first script in a series, this one is aimed solely at familiarizing the user with the use of w(atch), l(ist) and company.

      But you're absolutely correct that any such effort should include some simple scripts with obvious bugs and some more with more subtle problems... albeit, all in the class that is discoverable with straightforward use of the distribution's debugger. (I say "straightforward" because I'm quite sure some of our most skilled colleagues make the debugger jump thru hoops and do discovery-acrobatics well beyond the little I've learned.)

Re: RFC: debugger_trainer
by lwicks (Friar) on Dec 28, 2012 at 11:03 UTC
    I really like the idea if a script that guides you through using the perl debugger. Like some of the other monks I tend to fall back on print statements and Data::Dumper; which I know is daft but I am really lacking in skills in the debugger. I like the idea of a script that basically tells me to try various things and explains why. So when you try and run it direct it tells me to run it with -d. Then there are perhaps comments/prints that tell me what to do. That describe perhaps a problem and a command that helps me identify the problem etc. Happy to act as a guinea pig on this. :-)

    Kia Kaha, Kia Toa, Kia Manawanui!
    Be Strong, Be Brave, Be perservering!