Hi Marcel,

On 4/27/22 15:34, Marcel Taeumel wrote:
> Hi Lauren --
> 
> -1 on this version/implementation
> +1 on the idea
> 
> I like the overall direction to keep the system running and not annoy the user too much if they make a mistake.
> 
> Yet, I think this one needs more discussion and iteration. I challenge the intrusive way you use to count the open debuggers. I would like to see a more lightweight watcher process.
The rolling process creation and recursiveError was very heavy-handed,
yes.  Especially the recursive error.

> I don't think that either "number of max open debuggers" nor "min delay between debuggers" etc. is an option that a user can come up with for their current system and scenario.
It was the first one I came up with after needing to recover changes and
losing world state twice in an hour.  It's very 1st-draft material.

> Well, not even the input-timeout for our list filters is really good. This is a kind of tricky UX challenge. The false-positive might be dangerous. The n+1-th debugger might be the one with useful information.
The false positive is probably the biggest challenge.  From personal
experience, the CPU watcher is my sworn enemy because it opens a menu
every time I switch projects, but every so often you actually need it.
Usually within a minute of turning it off.

> We might need domain-specific groups of debuggers. One window for each group.
This could work... but what would a domain look like?

> Can you provide an example? How to trigger a flood of debuggers. Maybe we can find a way to group new debuggers somehow? For Morphic drawing errors, I already implemented such a domain-specific rule. See WorldState >> #displayWorldSafely:.
I got one from balloon help on method lists in the Protocol Browser...
let me see if I can reproduce it.  Squeak doesn't write a debug.log file
when it happens... probably for the best... but that leaves me with
nothing to investigate.  At least with the heavy hand I can see what the
debugger is being opened for.

I also got one from pressing Proceed on accident on a Method Already
Returned... let me see if I can write a method that does it 100% of the
time.

This might take a while to reproduce, so I'm just sending this now.