Re: breakpoint bug in the debugger
At the risk of beating an already dead horse, since setting a breakpoint on a use statement is likely to continue to cause confusions like this, I've added a hack in Devel::Trepan to see if the line that a breakpoint has been set at starts with the regexp /^\s*use\s+/. If so, a warning is issued given. The breakpoint is still set - it is just a warning. There are many ways that this heuristic can fail. For example setting a breakpoint on a line with: use English; $x = 3; may skip the use and still stop on the assignment statement. On Mon, Dec 19, 2011 at 12:20 AM, Rocky Bernstein ro...@cpan.org wrote: A while back on Tue, 31 May 2011 18:20:51 -0700 Conor wrote: Not exactly a high priority bug, but I found that if you set a breakpoint on a line where a 'use' statement exists, the breakpoint will show as set and the debugger won't complain: $ perl -d breakpoint-bug.pl Loading DB routines from perl5db.pl version 1.32 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. main::(breakpoint-bug.pl:7): 7: print hello!\n; DB1 b 9 DB2 v 4: use strict; 5: use warnings; 6 7== print hello!\n; 8 9:b use Data::Dumper; 10 11: print goodbye!\n; 12 13: exit 0; DB2 But, if you 'c' from line 7, you skip over the breakpoint on 9 as if it wasn't there. It isn't a huge problem (and I really should keep all of my 'use' statements at the beginning of the script), but I figured it was worth a mention. I couldn't figure out how to actually file a bug at http://rt.perl.organd http://search.cpan.org/~jesse/perl-5.14.0/lib/perl5db.pl didn't have the usual 'View/Report Bugs' that most modules have. I'm happy to file a bug if someone could point me in the right direction. -Conor I just looked at this. I don't think there is a bug here. The code has a use statement. A breakpoint is set on that which the reporter doesn't feel is respected. However, recall that use happens at compile time and this occurs before the first stop you see in the debugger. To verify this when I issued: $Data::Dumper::VERSION from Devel::Trepan stopped at line 7, I got a version string, e.g. '2.124'. (in perl5db use p $Data::Dumper::VERSION Change the use to a require which then changes the semantics, and you'll things will work as you seem to expect it to would above. So in sum, I don't think there is a bug. Just perhaps confusion about how execution works -- which I admit is confusing.
Re: What is the history behind the DB module?
On Fri, Sep 14, 2012 at 3:47 AM, Shlomi Fish shlo...@shlomifish.org wrote: Hi Rocky, On Thu, 13 Sep 2012 19:40:53 -0400 Rocky Bernstein rocky.bernst...@gmail.com wrote: http://perldoc.perl.org/DB.html mentions a programmatic interface to the Perl debugging API. As far as I can tell it hasn't really changed at all since Perl 5.8 and not much between that and 5.6 except bug fixes. Why was this not more widely adopted? I guess not too many people need to write custom debuggers. I am weary of arguments of the form because if X isn't used much something that X attempts to address is not needed by too many people. First, from what I've seen there have been a number of custom debuggers including a large number of customization of perl5db: for remote execution or handling syntax highlighting. I just became aware of a recent YAPC paper on trying to automatically figure out when an input line in perl5db is not finished so as to offer another read rather than eval the line. And consider dtrace which is popular. From what I understand, that is used for custom tracing which to me amounts to the same thing as debugging. dtrace doesn't sport a REPL although one could probably add that into the callback. Now back to the DB module. Although it may appear to advertise itself as for writing REPL debuggers, it doesn't have to be used that way. So perhaps the DB API module was not advertising itself in not the most encompassing way. One of the ideas that I think is right about the DB module is the fact that programs can register for a callback. Supposedly DB handles all of the lower-level boilerplate DB module stuff. One might imagine registering a callback when various events occur to be something that should be put in the Perl core, but since all of this code can be written in Perl (as evidence by the DB module), why then put it in the Perl core? And finally coming back to the original question, I was hoping that someone who was working on perl5db at the time could elaborate on what specifically happened here, rather than speculatively what might have happened. Furthermore, it seems that many Perl developers avoid using the debugger in favour of print statements and other stuff like that. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ What Makes Software Apps High Quality - http://shlom.in/sw-quality Quark: “Too much of a good thing is a bad thing. But only for your customers”. Rule of acquisition No. 172. — Star Trek, “We, the Living Dead” by Shlomi Fish Please reply to list if it's a mailing list post - http://shlom.in/reply .
