Hi,
Yes, we should improve the debugger…
There are some nice things happening around the debugger
-> In Berne, Andrei made a DebuggerModel and a Glamour UI for it.
In the current Debugger, Model and View
are completely mixed (and the implementation is kind of old style,
that is, very
low level and complex)
Last week He and Ben did an experiment to get a second UI working
(Spec).
-> Clement and Camillo did an AST Interpreter for the RB AST. We are
evaluating
if this can not replace the context step simulator based parts…
-> For later, we would like to integrate the idea of object centric
debugging
(halt on next ivar change, halt on next message…)
-> …
The problem right now is that the debugger infrastructure is far more
complicated than
it should be, making is hard to change, fix and improve it.
Marcus
On Dec 9, 2012, at 11:07 PM, adrians <nman...@gmail.com> wrote:
> 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.
>
