Feature request: Refresh breakpoint expressions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Feature request: Refresh breakpoint expressions

Richard Sargent
Administrator
I came across a situation - unarguably of my own doing - in which my breakpoints weren't working as they should.

Specifically, I had added a new global to the Smalltalk dictionary and then referenced it from some break-point expressions. Later, I removed the key and still later added a different instance using that same key. e.g. in both cases, something approximating "Smalltalk at: #ST put: SomeTracer new" and the break-points had an expression like "ST record: #something for: self. false".

Naturally, once I removed the global, I broke the cached information for the break-points. In retrospect, I'm not surprised! The problem is that it was very difficult to determine what was wrong, other than "it isn't working". :-)

The ideal solution would include "self healing break-points".
A sufficient solution includes at least a visual indication in the break-point browser that specific break-points are getting errors (perhaps an "error" icon and possibly an error count).
A bonus points feature would be a simple way to recompile the break-points, such as "System image breakpointManager recompileAllBreakpoints". The lack of this leaves one spending considerable time discovering an expression like "System image breakpointManager allBreakpoints do: [:each | each watch: (each recomputeWatch: each watch expression)]".


Thanks,
Richard

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Feature request: Refresh breakpoint expressions

Seth Berman
Hi Richard,

A good suggestion...I'll add a case and look into what it would take

-- Seth

On Tuesday, May 19, 2015 at 5:10:15 PM UTC-4, Richard Sargent wrote:
I came across a situation - unarguably of my own doing - in which my breakpoints weren't working as they should.

Specifically, I had added a new global to the Smalltalk dictionary and then referenced it from some break-point expressions. Later, I removed the key and still later added a different instance using that same key. e.g. in both cases, something approximating "Smalltalk at: #ST put: SomeTracer new" and the break-points had an expression like "ST record: #something for: self. false".

Naturally, once I removed the global, I broke the cached information for the break-points. In retrospect, I'm not surprised! The problem is that it was very difficult to determine what was wrong, other than "it isn't working". :-)

The ideal solution would include "self healing break-points".
A sufficient solution includes at least a visual indication in the break-point browser that specific break-points are getting errors (perhaps an "error" icon and possibly an error count).
A bonus points feature would be a simple way to recompile the break-points, such as "System image breakpointManager recompileAllBreakpoints". The lack of this leaves one spending considerable time discovering an expression like "System image breakpointManager allBreakpoints do: [:each | each watch: (each recomputeWatch: each watch expression)]".


Thanks,
Richard

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Feature request: Refresh breakpoint expressions

Richard Sargent
Administrator

Thanks.

And if you are going to be playing in the break-point browser, adding some method browser menus would be welcome. Examples: browse hierarchy, browse implementers, ...

On May 20, 2015 8:14 AM, "Seth Berman" <[hidden email]> wrote:
Hi Richard,

A good suggestion...I'll add a case and look into what it would take

-- Seth

On Tuesday, May 19, 2015 at 5:10:15 PM UTC-4, Richard Sargent wrote:
I came across a situation - unarguably of my own doing - in which my breakpoints weren't working as they should.

Specifically, I had added a new global to the Smalltalk dictionary and then referenced it from some break-point expressions. Later, I removed the key and still later added a different instance using that same key. e.g. in both cases, something approximating "Smalltalk at: #ST put: SomeTracer new" and the break-points had an expression like "ST record: #something for: self. false".

Naturally, once I removed the global, I broke the cached information for the break-points. In retrospect, I'm not surprised! The problem is that it was very difficult to determine what was wrong, other than "it isn't working". :-)

The ideal solution would include "self healing break-points".
A sufficient solution includes at least a visual indication in the break-point browser that specific break-points are getting errors (perhaps an "error" icon and possibly an error count).
A bonus points feature would be a simple way to recompile the break-points, such as "System image breakpointManager recompileAllBreakpoints". The lack of this leaves one spending considerable time discovering an expression like "System image breakpointManager allBreakpoints do: [:each | each watch: (each recomputeWatch: each watch expression)]".


Thanks,
Richard

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/rQOM065oENU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.