Nicolas Cellier uploaded a new version of ToolBuilder-Kernel to project The Inbox:
http://source.squeak.org/inbox/ToolBuilder-Kernel-nice.145.mcz

==================== Summary ====================

Name: ToolBuilder-Kernel-nice.145
Author: nice
Time: 28 April 2021, 9:23:48.35444 pm
UUID: f27e3b02-2905-d94b-97f3-93e95bd58880
Ancestors: ToolBuilder-Kernel-nice.141

Fix ProgressInitiationException>>sendNotificationsTo: so that:
- the ProgressInitiationException remains inactive during workBlock evaluation
- unless explicitely rearmed
- active inner handlers remain active during workBlock evaluation

For the last goal, it is necessary to first resume, then evaluate the workBlock, hence usage of #resumeEvaluating:
This goes with Kernel-nice.1394 which implements this method as well as upgraded signal handling.

But if we resume, then we also unwind the stack and evaluate all the ensure: blocks...
This will reactivate current handler, and desarm it if we rearmed, in other words, the exact contrary of what was requested!
Hence the intricated activate/deactivate dance.

If the purpose is to completely suppress Progress bars and progress notifications, then provide an appropriate handling action that will do so: #resumeSuppressingProgress

=============== Diff against ToolBuilder-Kernel-nice.141 ===============

Item was added:
+ ----- Method: ProgressInitiationException>>resumeSuppressingProgress (in category 'handling') -----
+ resumeSuppressingProgress
+ 	"Catch and suppress every ProgressInitiationException and ProgressNotification
+ 	during the evaluation of workBlock"
+ 
+ 	^self resumeEvaluating:
+ 		[self rearmHandlerDuring:
+ 			[[workBlock value: [ :barVal | "do nothing"]]
+ 				on: ProgressNotification do: [:e | e resume]]]!

Item was changed:
+ ----- Method: ProgressInitiationException>>sendNotificationsTo: (in category 'handling') -----
- ----- Method: ProgressInitiationException>>sendNotificationsTo: (in category 'initialize-release') -----
  sendNotificationsTo: aNewBlock
+ 	"Resume execution using aNewBlock as workBlock value.
+ 	Note that the execution is resumed in signalContext (or outerContext).
+ 	This is done so that inner exception handlers be active during workBlock execution.
+ 	However, our own handlerContext should be deactivated, unless explicitely rearmed."
+ 	| mustDeactivateHandler |
+ 	mustDeactivateHandler := handlerContext notNil and: [handlerContext isHandlerActive not].
+ 	mustDeactivateHandler
+ 		ifTrue:
+ 			["The handlerContext is de-activated during handleSignal:
+ 			But it will be reactivated during unwinding when we will resumeEvaluating:
+ 			That's unwanted, we don't generally want to rearm the handler during workBlock evaluation.
+ 			Hence we have to deactivate it again inside the deferred block."
+ 			self resumeEvaluating:
+ 				[handlerContext deactivateHandler.
+ 				[workBlock value: [ :barVal |
+ 					aNewBlock value: minVal value: maxVal value: barVal]]
+ 						ensure: [handlerContext reactivateHandler]]]
+ 		ifFalse:
+ 			["If the handler is active at this step, then it must have been rearmed
+ 			with a #rearmHandlerDuring:
+ 			It's thus intentional to keep the handler active during workBlock evaluation
+ 			But the ensure: [self desarmHandler] will be evaluated during unwinding when we will resumeEvaluating:
+ 			It is thus necessary to rearm again inside the evaluated block"
+ 			self resumeEvaluating:
+ 				[self rearmHandlerDuring:
+ 					[workBlock value: [ :barVal |
+ 						aNewBlock value: minVal value: maxVal value: barVal]]]]!
- 
- 	self reactivateHandlers; resumeUnchecked: (
- 		workBlock value: [ :barVal |
- 			aNewBlock value: minVal value: maxVal value: barVal
- 		]
- 	)
- !