On Thursday, July 19, 2001, at 03:48 PM, Hans-Martin Mosner wrote:

> Hello,
> since I think that the Squeak debuger misses some very important
> features, I started to implement them. The attached changeset is my
> first shot at the issue; it implement the following features:

Cool stuff.  These changes already look handy enough for me to keep them 
loaded while doing other stuff, so I'll let you know if I see any bugs.  
It'd be nice to see these improvements added to the base image at some 
point.

> 1. Debugger inspector panes are updated on every step. (that was an easy
> one)

Obviously a good thing.

> 2. PC highlighting is improved for loops, blocks, variable assignments.
> No more highlighting of the instruction after the loop block

The PC highlighting does seem to be improved. (e.g. the right bracket is 
highlighted at the end of each iteration of a loop block)

> 3. Fast step method executes the message using perform:, not by
> simulation. Mucho mucho quicker!

This is a big improvement.  (Andres Valloud mentioned in another message 
that is it sometimes useful to be able to do a simulating step.  For 
those rare cases, maybe a "simulating step" command or something in the 
debugger stack pop-up menu would be worth having.)

> 4. Exceptions caught within stepped methods are properly displayed in
> the debugger. No more 'Cant simulate halt.  Proceed to bypass it.'

Hooray!  (I would have been happy enough if it simply had proceeded 
without telling me. :) )

> 5. nonlocal returns are caught.

It may be that I'm up too late right now... could you give an example of 
this?

> There are almost certainly bugs in my code; I did not have much time for
> testing and so rely on you to find them :-) I have thought about writing
> unit test code, but for the most tricky aspects I have difficulties
> setting up test cases in my mind, let alone in code...
>
> Some more things I would like to do are:
> - a 'reset' menu function which resets the selected context, without
> proceeding immediately.
> - a 'skip to caret' menu function which steps until the pc is just
> before the selected point in the method.
> - true breakpoints which can be added and removed without requiring
> recompilation, and without losing existing context's state.

> However, these will require some more time. If you have any additional
> suggestions, please let us discuss them here on the list.

One other nice thing to fix at some point would be the PC highlighting 
for NonBoolean receiver errors.  For example, if you Do this in a 
workspace:

nil ifTrue: [x _ 'asdfas' asSortedCollection].

The NonBoolean receiver debugger comes up, but the #asSortedCollection 
method is currently highlighted, when it seems that #ifTrue: should be 
highlighted instead.

- Doug Way
   dway at riskmetrics.com


> Cheers,
> Hans-Martin
>
> Note that the methods in the changeset are carefully arranged not to
> break on file-in. If you just file out the changeset, the resulting file
> will almost certainly not work. That's what one deserves for messing
> with the Parser...
<Attachment missing><Attachment missing>
-------------- next part --------------
Skipped content of type multipart/mixed