Re^2: bug in the debugger? breakpoints in subroutines ignored if attributes present (work-around)

Indeed that's the obvious solution in this case, but in the real case, the line in question is buried in some class in another file. The reason I want to breakpoint a method is because I can't put a breakpoint there using the line number, at least without stepping through lots of intervening code.

Comment on Re^2: bug in the debugger? breakpoints in subroutines ignored if attributes present (work-around)

Replies are listed 'Best First'.
Re^3: bug in the debugger? breakpoints in subroutines ignored if attributes present (work-around) by tye (Sage) on Apr 23, 2007 at 16:43 UTC
I don't see how what you describe makes what I suggested any less useful. Instead of putting a breakpoint on a method, list the start of the method and put a breakpoint on the first line inside of the method. I certainly didn't step "though lots of intervening code" so I'm not sure why you think you would need to. - tye	[reply]
Re^4: bug in the debugger? breakpoints in subroutines ignored if attributes present (work-around) by wu-lee (Beadle) on Apr 23, 2007 at 17:02 UTC
Ah yes, apologies. I misunderstood what you were suggesting and thought the solution would only work in the example. I didn't realise that the `l` command could take a subroutine as an argument and subsequently let you breakpoint the result. This'll do nicely.	[reply] [d/l]