On Thu, May 16, 2019 at 09:48:40AM -0700, tim Rowledge wrote:
> 
> 
> > On 2019-05-16, at 12:24 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> > 
> > Hi Chris,
> > 
> > thanks for these suggestions. One major concern is to use *as little
> > code as possible* like in the emergency evaluator. Let's see what's
> > possible in this regard.
> 
> Exactly; it needs to be as insulated from possible side-effects of other
> code as possible, as locked-down as practical and resilient enough to
> make the people that program the lowest levels of interplanetary probes
> feel proud.
>

Indeed, keeping it sufficiently minimal is a challenge.

The user interrupt handler is tricky business. Refreshing my memory from
http://bugs.squeak.org/view.php?id=1041 the four tests that Andreas put
forward for interrupt handling are:

   "[true] whileTrue"
   "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1"
   "Smalltalk createStackOverflow"
   "[Smalltalk createStackOverflow] forkAt: Processor userSchedulingPriority + 1"

All of these are still working after loadling the change set, kudos!

I did find that the results seem confusing if I hit CMD-dot several times
in a row before the menu appears. That is a common thing that happens when
the user (e.g. me) thinks that the image is running away and not responding
to the CMD-dot (easy to do on test #4 for example). Maybe there is something
we can do to to make that better. But overall I think the user interrupt
menu would make the system feel more comfortable for people encountering
these problems for the first time.

Dave