perl.debugger
  Home FAQ Contact Sign in
perl.debugger only
 
Advanced search
September 2008
motuwethfrsasuw
1234567 36
891011121314 37
15161718192021 38
22232425262728 39
2930      40
2008
 Jan   Feb   Mar   Apr 
 May   Jun   Jul   Aug 
 Sep   Oct   Nov   Dec 
2008 2007    
total
perl.debugger Profileā€¦
RELATED GROUPS

POPULAR GROUPS

more...

 Up
  accelerated stepping         


Author: heiko
Date: Aug 27, 2008 12:33

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 ...
Show full article (1.56Kb)
12 Comments
  Remote debugger         


Author: Gabor Szabo
Date: Aug 1, 2008 00:05

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

--
Gabor Szabo http://szabgab.com/blog.html
Perl Training in Israel http://www.pti.co.il/
Test Automation Tips http://szabgab.com/test_automation_tips.html
1 Comment
  Re: Unreliable breakpoint path specification         


Author: Jan Ploski
Date: Jun 6, 2007 10:59

On Wed, Jun 06, 2007 at 10:03:45AM +0200, Richard Foley wrote:
> On Tuesday 05 June 2007 19:25, Jan Ploski wrote:
>>
>> Thank you for your suggestions.
>>
> Did "b subname" not work?

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.
>> 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.
>>
> Are there any potential side-effects for other users?

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.
Show full article (1.90Kb)
1 Comment
  Re: Unreliable breakpoint path specification         


Author: Jan Ploski
Date: Jun 5, 2007 10:25

On Tue, Jun 05, 2007 at 09:17:02AM +0200, Richard Foley wrote:
> On Monday 04 June 2007 16:45, Jay Rifkin 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.
Show full article (1.37Kb)
1 Comment
  Re: Unreliable breakpoint path specification         


Author: Richard Foley
Date: Jun 5, 2007 00:17

On Monday 04 June 2007 16:45, Jay Rifkin wrote:
> Hi Jan -
> If you have write access to the "require"d file, you can try setting a
> breakpoint in it, via setting:
> $DB::single = 1
>
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
> I am now considering throwing away perl5db.pl or rewriting significant
> portions of it.
>
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:
Show full article (0.86Kb)
no comments
  Unreliable breakpoint path specification         


Author: Jan Ploski
Date: Jun 2, 2007 09:46

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.
Show full article (1.85Kb)
1 Comment
  Re: Debugger Doesn't Show Program Lines         


Author: Richard Foley
Date: May 4, 2007 08:31

On Friday 04 May 2007 17:10, Nelson R Pardee wrote:
> I don't even know how to file a bug report, and right now this problem
> is "ages" ago in terms of projects:-)
>
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.
no comments
  RE: Debugger Doesn't Show Program Lines         


Author: Nelson R Pardee
Date: May 4, 2007 07:17

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.
> -----Original Message-----
> From: Richard Foley [mailto:[email protected]rfi.net]
> Sent: Friday, May 04, 2007 08:25
> To: [email protected]perl.org
> Cc: Nelson R Pardee
> Subject: re: Debugger Doesn't Show...
Show full article (1.19Kb)
2 Comments
  re: Debugger Doesn't Show Program Lines         


Author: Richard Foley
Date: May 4, 2007 05:24

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.
> In-ReplyTo: [email protected]gamera.syr.edu
>
> We're upgrading from an old 5.005_03 to v5.6.1. Now when I use -d on
> via the first line of the program, it starts in debug mode but...
Show full article (1.08Kb)
no comments
  RE: perl newbie trying to start debugger         


Author: Nelson R Pardee
Date: Apr 24, 2007 10:37

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.
no comments
1 2