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@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