Re: What is the history behind the DB module?

2012-09-14 Thread Rocky Bernstein
On Fri, Sep 14, 2012 at 3:47 AM, Shlomi Fish wrote:

 Hi Rocky,

 On Thu, 13 Sep 2012 19:40:53 -0400
 Rocky Bernstein wrote: 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

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

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.


 Shlomi Fish

 Shlomi Fish
 What Makes Software Apps High Quality -

 Quark: “Too much of a good thing is a bad thing. But only for your
 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 - .

Re: breakpoint bug in the debugger

2011-12-21 Thread Rocky Bernstein
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

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

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 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
 a line where a 'use' statement exists, the breakpoint will show as set and
 the debugger won't complain:
 $ perl -d
 Loading DB routines from version 1.32
 Editor support available.
 Enter h or `h h' for help, or `man perldebug' for more help.
 7: print hello!\n;
 DB1 b 9
 DB2 v
 4: use strict;
 5: use warnings;
 7== print hello!\n;
 9:b use Data::Dumper;
 11: print goodbye!\n;
 13: exit 0;
 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
 a mention.
 I couldn't figure out how to actually file a bug at http://rt.perl.organd didn't have the
 usual 'View/Report Bugs' that most modules have. I'm happy to file a bug
 someone could point me in the right direction.

 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.