On Dec 11, 2012, at 4:38 PM, Peter H. Meadows <[email protected]> wrote:
> Just out of curiosity.. How does the cutting edge of LISP compare to > what we have in Pharo at the moment? I've read somewhere that > smalltalk has the best refactoring/debugging tools. Would you agree > with that? Are there object centric lisp debuggers? If someone asked > you 'why are you working on a smalltalk implementation and not some > lisp?', what would your answer be? I suppose nicer syntax might be the > first thing that comes to mind, but I don't see that as being super > important. Of course, I realise lispers might use a more functional > style, but you could be writing smalltalk style code in CLOS or > something, right? > > Feel free to ignore these questions if you're not interested. I'm just musing. > my problem is time… > On Tue, Dec 11, 2012 at 8:32 AM, Marcus Denker <[email protected]> wrote: >> 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 <[email protected]> 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. >>> >> >> >
