I use break on entry often because I do not like the method versions being cluttered with "halt versions".
Unfortunately the #breaks are slipping in anyway, when I then edit the code in the debugger and forget about the break. :-(
A confirmation dialog would be nice if a wrapped method is saved and the break is still in the source.
Am 31.03.2017 15:47 schrieb "Bert Freudenberg" bert@freudenbergs.de:
On Thu, Mar 30, 2017 at 12:01 AM, Tobias Pape Das.Linux@gmx.de wrote:
On 29.03.2017, at 23:56, Levente Uzonyi leves@caesar.elte.hu wrote:
Inserting `self half` is still superior.
If i want to half myself, sure ;)
Well, I'd say, it depends. If I'm just exploring the system and dont want to change it, I typically use break on enty.
I'd like to have proper breakpoints that are as convenient as "self halt" but don't modify the method source.
- Bert -
On 03.04.2017, at 20:09, Jakob Reschke jakob.reschke@student.hpi.de wrote:
I use break on entry often because I do not like the method versions being cluttered with "halt versions".
Unfortunately the #breaks are slipping in anyway, when I then edit the code in the debugger and forget about the break. :-(
I think wrapped breakpoints would help here, too
A confirmation dialog would be nice if a wrapped method is saved and the break is still in the source.
Am 31.03.2017 15:47 schrieb "Bert Freudenberg" bert@freudenbergs.de: On Thu, Mar 30, 2017 at 12:01 AM, Tobias Pape Das.Linux@gmx.de wrote:
On 29.03.2017, at 23:56, Levente Uzonyi leves@caesar.elte.hu wrote:
Inserting `self half` is still superior.
If i want to half myself, sure ;)
Well, I'd say, it depends. If I'm just exploring the system and dont want to change it, I typically use break on enty.
I'd like to have proper breakpoints that are as convenient as "self halt" but don't modify the method source.
- Bert -
squeak-dev@lists.squeakfoundation.org