Hi adrian this is not that we do not want to fix issues. This is that some are killing us while others are letting us to breath.
Now we can argue for hours about priority. The best things to do is to try. And I can tell you that the debugger is important for us - this is our best friend. But it gets a bit old. To me having the UI defined in another class was strange for years. We fixed it. And as marcus said we are working :) and quite busy. Stef > 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. >
