No, old timers are equally upset by false/wrong visual feedback, especially when they remember this used to work 25 years ago ;)
Nicolas 2012/12/9 adrians <[email protected]>: > Hi, > > I'm a Smalltalk newbie and I would like to help fix some simpler issues. For > example, I've recently logged some issues surrounding smart character use. I > set a breakpoint in NECController>>#smartCharacterWithEvent: and proceeded > to debug. > > Now, I understand that for the old-timers stepping through a selector is > straightforward, no matter what help the debugger gives you. For myself, and > likely many other Smalltalk noobs who'd like to help, I need all the help I > can get. One such support is an accurate indication of where the PC is as > you step through a body of code. Currently, in the 2.0 one-click image > (build 20431), things seem quite broken wrt getting accurate visual feedback > of where you are. > > First, as you step over message sends, the highlighted selection is shown in > a totally incorrect spot. Sometimes, just a bit off from where you expect to > be, but sometimes quite a bit off, for example in a block that should not > even be entered. In the selector I mentioned above, the highlighted location > enters the "editor hasSelection ifTrue: []" block when "editor hasSelection" > returns false. > > Second, the PC location highlight is removed when you click somewhere inside > the code. This should never turn off - it's as if you switch the lights off, > for people not familiar with some particular code. I know you can use the > "Where" button to re-establish the highlight, but other than the fact that > you shouldn't have to do this, the highlighted selection is sometimes shown > in the wrong place. > > Third, as you step through code, you would expect that the values of > variables as shown in the bottom right panel of the debugger are accurately > updated as state changes. I've seen cases, relatively frequent, where this > is not so. Current values are shown only after some further advancement > through code. > > There is an old issue tracking debugger selection, > http://code.google.com/p/pharo/issues/detail?id=709 > <http://code.google.com/p/pharo/issues/detail?id=709> , but fixing the > problem seems to have stalled. Additionally, I'm not sure that this > particular issue addresses the third point I made about stale variable > values being shown. > > Could I ask that making the debugger work be made a priority? Of course one > can muddle through some code even with visually broken indicators, but it > should not be so, IMO. The old timers can make the case that there are other > more pressing issues to be addressed, but IMO it makes sense to make the > actual tool used to fix problems as helpful as possible for everyone so that > even non-experts can be productive and lend a helping hand. > > > Cheers, > Adrian > > > > -- > View this message in context: > http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4658666.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >
