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 
> 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

Reply via email to