Re: Unreliable breakpoint path specification
On Wednesday 06 June 2007 19:59, Jan Ploski wrote: > > > > What would be the best way to suggest an API extension to perl5db.pl > > > maintainer(s)? > > > > > The best thing is probably to send a patch to P5P and let them take a look > > at it. > > Ok, in that case I'd have to generalize my on load hook first to make > it independent from EPIC. > I'm not familiar with EPIC, but there are a number of cases where the debugger has been quite literally hacked to work with various OS's, terminals, certain libraries and so on. In these cases a sensible solution has often been to seperate the specific stuff via an environment variable. This only applies, of course, if it has no value for other users. Something like PERL5DB_EPIC=1 might do the trick, although you might very well have a more suitable suggestion. Then send a patch to p5p for Rafael to consider applying it to bleed. -- Richard Foley Ciao - shorter than aufwiedersehen http://www.rfi.net/
Re: Unreliable breakpoint path specification
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. > > The downsides are the possibly unreliable patching and > > > If it's unreliable, (your word), then you should keep the patch on your local > system, please. If it's reliable, then it might be a useful fix. Is it > possible to make a test case for it? What I meant is that my patching mechanism is unreliable. If the patch were applied by a developer to a well-defined version of perl5db.pl, rather than by my code which grabs the currently installed version from the system, the reliability would not be an issue. > > the fact that I now depend on perl5db.pl internals. > > > I don't know whether Devel::Command would have been useful to you? No, given that I needed to intercept the "on load" event rather than add a new command to the command loop. > > What would be the best way to suggest an API extension to perl5db.pl > > maintainer(s)? > > > The best thing is probably to send a patch to P5P and let them take a look at > it. Ok, in that case I'd have to generalize my on load hook first to make it independent from EPIC. Best regards, Jan Ploski
Re: Unreliable breakpoint path specification
On Tuesday 05 June 2007 19:25, Jan Ploski wrote: > > Thank you for your suggestions. > Did "b subname" not work? > 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? > The downsides are the possibly unreliable patching and > If it's unreliable, (your word), then you should keep the patch on your local system, please. If it's reliable, then it might be a useful fix. Is it possible to make a test case for it? > the fact that I now depend on perl5db.pl internals. > I don't know whether Devel::Command would have been useful to you? > What would be the best way to suggest an API extension to perl5db.pl > maintainer(s)? > The best thing is probably to send a patch to P5P and let them take a look at it. -- Richard Foley Ciao - shorter than aufwiedersehen http://www.rfi.net/
Re: Unreliable breakpoint path specification
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. The downsides are the possibly unreliable patching and the fact that I now depend on perl5db.pl internals. What would be the best way to suggest an API extension to perl5db.pl maintainer(s)? Best regards, Jan Ploski
Re: Unreliable breakpoint path specification
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: h b As you might expect, TMTOWTDI. -- Richard Foley Ciao - shorter than aufwiedersehen http://www.rfi.net/
Re: Unreliable breakpoint path specification
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
The following worked for me:
In t.pm:
package t;
BEGIN {
debug: $DB::single=1;
$a = 1;
}
debug: $DB::single=1;
$a = 3;
1;
In t.pl:
require 't.pm';
print "done\n";
When I run:
perl -d t.pl
The debugger correctly breaks at the lines labeled 'debug' above.
Best,
Jay Rifkin
Jan Ploski wrote:
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.
I thought I could work around this issue using a custom watchfunction
to do the path resolution. I did. It worked, but it made the debugger
potentially orders of magnitude slower (even an empty watchfunction
has this effect). Wrong approach.
Next I thought I could just hack perl5db.pl to break on all loaded
filenames and do the path resolution then myself. Well, it seems to
work and is faster, but it has an unfortunate side-effect that "step"
commands break in strange places instead of finishing where they would
have without this additional hack. Unlike with "continue", where I can
just keep the debugger going in case it breaks on a line without
a real breakpoint, I cannot do the same with "step" commands,
simply because I would have to know where they are supposed to
finish "naturally".
I am now considering throwing away perl5db.pl or rewriting significant
portions of it. But maybe someone has a better idea?
Regards,
Jan Ploski
Unreliable breakpoint path specification
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. I thought I could work around this issue using a custom watchfunction to do the path resolution. I did. It worked, but it made the debugger potentially orders of magnitude slower (even an empty watchfunction has this effect). Wrong approach. Next I thought I could just hack perl5db.pl to break on all loaded filenames and do the path resolution then myself. Well, it seems to work and is faster, but it has an unfortunate side-effect that "step" commands break in strange places instead of finishing where they would have without this additional hack. Unlike with "continue", where I can just keep the debugger going in case it breaks on a line without a real breakpoint, I cannot do the same with "step" commands, simply because I would have to know where they are supposed to finish "naturally". I am now considering throwing away perl5db.pl or rewriting significant portions of it. But maybe someone has a better idea? Regards, Jan Ploski
