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?
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
Ok, in that case I'd have to generalize my on load hook first to make
it independent from EPIC.