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 - ] - ) - ! |
Free forum by Nabble | Edit this page |