Hi,

often during single-stepping I am missing a command like 'n' to step
over not only subroutine calls, but also complete map and grep-commands.

Example:

Instead of

main::(perldb_demo.pl:4): my @a = (1..10);
DB<1> n
main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
DB<1>
main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 ...

I thought I'll try to add debugging capabilities to Padre
http://search.cpan.org/dist/Padre
so I picked up Pro Perl Debugging http://books.perl.org/book/228
where there is a sample script that enables to run the standard perl
debugger remotely.

I started to integrate it when I realized it would be much better
if there was module that implemented it - the other side of the socket - that
could be used by other potential IDEs.

A quick search on CPAN did not turn up anything useful so I wonder if
there is such a module already.

If not, anyone with enough tuits to start to write one?

Richard?

(cross posted to http://www.perlmonks.org/?node_id=701611 )

Gabor

On Wed, Jun 06, 2007 at 10:03:45AM +0200, Richard Foley wrote:

Richard,

It did not work for my purpose - simply because I had no sub in which
to set a breakpoint! Recall that I am writing a general-purpose debugger
frontend (EPIC). The user might set a breakpoint on any source line she
likes (including outside of subs) and I have to cope with it.

No, because the patched up version of perl5db.pl is private to EPIC.
I put it into @INC path when launching the debugger from EPIC.

On Tue, Jun 05, 2007 at 09:17:02AM +0200, Richard Foley wrote:

...

Richard and Jay,

Thank you for your suggestions.

In the end, I solved my problem by patching up perl5db.pl to call back
a user-defined routine on *every* loaded file from sub DB::postponed.
The ambiguous $filename is passed down to my subroutine, which converts
it to a canonical path using Cwd::abs_path and, if there are any pending
breakpoints (about which it was earlier told by the Java frontend),
it transfers them into $DB::postponed_file. This internal variable is
normally used by the debugger to keep track of all breakpoints that need
to be silently reinserted when re-running the script with the 'R' command.

Thanks to this solution I do not have to worry about "step over" stopping
at an unexpected point just because a file was "require"d during the step.
I do NOT set $single = 1 in my routine, I just install breakpoints
while the step command (or any continue command) is being processed
as usual. Of course, if one of the installed breakpoints is hit,
the debugger suspends, which is precisely what I want to happen.

On Monday 04 June 2007 16:45, Jay Rifkin wrote:

Good idea.

Without modifying the source code you could try setting a breakpoint on a
subroutine:

b foo::mysubname

You could also use a watch variable, if you have a suitable variable available
in the file you wish to debug, something like this perhaps:

w $foo::myvarname

Before you try rewriting the debugger from scratch, you might like to look at
the output of the help for breakpoints, which you can access from within the
debugger like this:

Hello,

I am the current maintainer of EPIC (http://e-p-i-c.sf.net), searching
in despair for a sensible way of reliably breaking in "require"d source
files (and some "use"d ones, too).

Let me provide a few simple examples first:

require '/some/abs/path/foo.pm';
require 'foo.pm';
require '/some/abs/path/../foo.pm';

All the paths above when passed to Cwd::abs_path() resolve to
/somewhere_else/abs/path/foo.pm (/some happens to bea symlink
to /somewhere_else).

I want to set a breakpoint in /somewhere_else/abs/path/foo.pm.
I don't care how this file is referred to in the sources, I just want
the debugger to break in it!

However, if I pass the above canonical absolute path to "b load",
it won't break, obviously, because Perl uses one of the strange paths
to refer to the file in %%INC. Hence I won't get a chance to set
line breakpoints and EPIC users will rightfully complain about bugs.

On Friday 04 May 2007 17:10, Nelson R Pardee wrote:

Well, for the next one, just run perlbug :-)

--
Richard Foley
Ciao - shorter than aufwiedersehen

http://www.rfi.net/

ps. Please resend any bounced or unanswered emails.

I found that the combination of -w -d didn't work. But if I did "use
warnings" with -d, the problem went away. I don't think that's what's
supposed to happen, but it's a usable workaround. And 5.8.x had the same
problem, I believe.

Perhaps it's a problem with 5.6.1, have you tried a more recent version of
Perl, like 5.8.n?

--
Richard Foley
Ciao - shorter than aufwiedersehen

http://www.rfi.net/

ps. Please resend any bounced or unanswered emails.

Over and over I see people recommending that we use perl -d. However, I
find it more convenient to use the #/.... -d syntax. Idiosyncratic?
Maybe. But it's a 10 year idiosyncracy. So the question: why is perl -d
good/better?

BTW, I found in 5.6... And 5.8... on Solaris that -w and -d do not play
nicely. But once I switched to "use warnings" the problems went away.