In 3.1a.4325, selecting "restart" in the debugger unwinds to the selected context, but doesn't actually proceed from there.
-C
-- Craig Latta composer and computer scientist craig.latta@netjam.org www.netjam.org crl@watson.ibm.com Smalltalkers do: [:it | All with: Class, (And love: it)]
Craig Latta wrote:
In 3.1a.4325, selecting "restart" in the debugger unwinds to the
selected context, but doesn't actually proceed from there.
-C
Sorry, that's my fault. It is a behavioral change in my BetterDebugger stuff. I have decoupled the 'restart' and 'proceed' functionality because I often want to reset the execution stack to the beginning of a method, without immediately proceeding. It's essentially the same behavior as in the VisualAge debugger.
Should there be a preference for this? I prefer the non-proceeding restart, but others might prefer to have it the old way.
Cheers, Hans-Martin
Hans-Martin, A preference item would be desirable. The default behavior should follow the behavior of the current debugger. Keep up the good work! Phil
Craig Latta wrote:
In 3.1a.4325, selecting "restart" in the debugger unwinds to the
selected context, but doesn't actually proceed from there.
-C
Sorry, that's my fault. It is a behavioral change in my BetterDebugger stuff. I have decoupled the 'restart' and 'proceed' functionality because I often want to reset the execution stack to the beginning of a method, without immediately proceeding. It's essentially the same behavior as in the VisualAge debugger.
Should there be a preference for this? I prefer the non-proceeding restart, but others might prefer to have it the old way.
Cheers, Hans-Martin
Hans-Martin Mosner wrote:
Sorry, that's my fault. It is a behavioral change in my BetterDebugger stuff. I have decoupled the 'restart' and 'proceed' functionality because I often want to reset the execution stack to the beginning of a method, without immediately proceeding. It's essentially the same behavior as in the VisualAge debugger.
Should there be a preference for this? I prefer the non-proceeding restart, but others might prefer to have it the old way.
I also greatly prefer the non-proceeding restart, so I guess a preference would be nice.
Probably a dumb question, but when is the usual proceeding restart useful? I have to admit that I've never had (or perceived) a need to use it instead of just using 'proceed'. I guess I can imagine some unusual situations, but it's much more often that I accidentally step over a method I wanted to send into, and I'd like a non-proceeding restart so I can try stepping through things again.
- Doug Way dway@riskmetrics.com
...when is the usual proceeding restart useful? I have to admit that I've never had (or perceived) a need to use it instead of just using 'proceed'.
"Proceed" wouldn't do what I want... It wouldn't unwind to and reset the selected context, it would just proceed from the most recent context. I usually want to re-run from the beginning of the selected context, without having to perform two sets of gestures (and wait for the associated window dance).
...it's much more often that I accidentally step over a method I wanted to send into, and I'd like a non-proceeding restart so I can try stepping through things again.
Interesting. I usually have no idea where I'm going to want to start stepping again, it's typically the "next bug", dozens of (time-consuming :) steps away. But this is certainly a useful feature. I'd add a new action for that, called "reset". "Restart" to me implies that the process under observation will start running again.
-C
-- Craig Latta composer and computer scientist craig.latta@netjam.org www.netjam.org crl@watson.ibm.com Smalltalkers do: [:it | All with: Class, (And love: it)]
Craig Latta wrote:
"Proceed" wouldn't do what I want... It wouldn't unwind to and reset
the selected context, it would just proceed from the most recent context. I usually want to re-run from the beginning of the selected context, without having to perform two sets of gestures (and wait for the associated window dance).
Yeah, that's what I figured. I haven't gotten in the habit of doing this for whatever reason... usually the most recent context is good enough for me (but not always, which probably causes occasional problems).
Interesting. I usually have no idea where I'm going to want to start
stepping again, it's typically the "next bug", dozens of (time-consuming :) steps away. But this is certainly a useful feature. I'd add a new action for that, called "reset". "Restart" to me implies that the process under observation will start running again.
That probably is a better idea than having a preference. On the other hand, the button bar is already a bit crowded. But we could make some room by getting rid of the "Where" button *if* someone improved things so that text selection highlighting in ParagraphEditor was non-global (so that selections stay highlighted when you move the mouse out of a text pane), but then that's a decent bit of work. :)
- Doug Way dway@riskmetrics.com
squeak-dev@lists.squeakfoundation.org