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
