<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Hi Levente,</p>
<p><br>
</p>
<p>I'm still not sure how this can reliably work if some other unknown process is scheduling deferred UI messages at the same time ...</p>
<p><br>
</p>
<p>Also, maybe you could use a closure for the <span>uiUpdateBlock variable instead of bloating the whole object's state, but that could be a subjective thing, too.
<span>😊</span></span></p>
<p><br>
</p>
<p>Best,</p>
<p>Christoph</p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div class="x__rp_U4 x_ms-font-weight-regular x_ms-font-color-neutralDark x_rpHighlightAllClass x_rpHighlightBodyClass" id="x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="x_divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="x_Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont">
<div><font size="3" color="black"><span style="font-size:12pt"><a href="http://www.hpi.de/" target="_blank" rel="noopener noreferrer" id="LPNoLP"><font size="2"><span id="LPlnk909538"><font color="#757B80"></font></span></font></a></span></font></div>
</font></div>
</div>
</font></div>
</div>
</div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von commits@source.squeak.org <commits@source.squeak.org><br>
<b>Gesendet:</b> Samstag, 19. September 2020 22:35:37<br>
<b>An:</b> squeak-dev@lists.squeakfoundation.org<br>
<b>Betreff:</b> [squeak-dev] The Inbox: Tools-eem.986.mcz</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">A new version of Tools was added to project The Inbox:<br>
<a href="http://source.squeak.org/inbox/Tools-eem.986.mcz">http://source.squeak.org/inbox/Tools-eem.986.mcz</a><br>
<br>
==================== Summary ====================<br>
<br>
Name: Tools-eem.986<br>
Author: eem<br>
Time: 19 September 2020, 1:35:34.572026 pm<br>
UUID: b33a2312-24e5-4cfa-a4e3-7f409ce8f5d4<br>
Ancestors: Tools-ct.985<br>
<br>
Use the lastDeferredUIMessage mechanism for avoiding updating the debugger UI too frequently. Alas this only solves the run to here case; it doesn't fix the rapid clicking issue. Hence this is in the inbox. Christoph, this may be useful to you.<br>
<br>
=============== Diff against Tools-ct.985 ===============<br>
<br>
Item was changed:<br>
CodeHolder subclass: #Debugger<br>
+ instanceVariableNames: 'interruptedProcess contextStack contextStackIndex contextStackList receiverInspector receiverInspectorState contextVariablesInspector contextVariablesInspectorState externalInterrupt proceedValue selectingPC savedCursor isolationHead
failedProject labelString message untilExpression uiUpdateBlock'<br>
- instanceVariableNames: 'interruptedProcess contextStack contextStackIndex contextStackList receiverInspector receiverInspectorState contextVariablesInspector contextVariablesInspectorState externalInterrupt proceedValue selectingPC savedCursor isolationHead
failedProject labelString message untilExpression'<br>
classVariableNames: 'ContextStackKeystrokes ErrorReportServer FullStackSize InterruptUIProcessIfBlockedOnErrorInBackgroundProcess NotifierStackSize SavedExtent StackSizeLimit WantsAnnotationPane'<br>
poolDictionaries: ''<br>
category: 'Tools-Debugger'!<br>
<br>
!Debugger commentStamp: 'mt 12/17/2019 12:19' prior: 0!<br>
I represent the machine state at the time of an interrupted process. I also represent a query path into the state of the process. The debugger is typically viewed through a window that views the stack of suspended contexts, the code for, and execution point
in, the currently selected message, and inspectors on both the receiver of the currently selected message, and the variables in the current context.<br>
<br>
Special note on recursive errors:<br>
Some errors affect Squeak's ability to present a debugger. This is normally an unrecoverable situation. However, if such an error occurs in an isolation layer, Squeak will attempt to exit from the isolation layer and then present a debugger. Here is the
chain of events in such a recovery.<br>
<br>
* A recursive error is detected.<br>
* The current project is queried for an isolationHead<br>
* Changes in the isolationHead are revoked<br>
* The parent project of isolated project is returned to<br>
* The debugger is opened there and execution resumes.<br>
<br>
If the user closes that debugger, execution continues in the outer project and layer. If, after repairing some damage, the user proceeds from the debugger, then the isolationHead is re-invoked, the failed project is re-entered, and execution resumes in that
world. <br>
<br>
---<br>
<br>
In September 2019, we added MorphicDebugger and MVCDebugger to untangle framework-specific features in our debugger infrastructure. However, this is just an intermediate step. The overall goal would be to remove those two subclasses again while preserving
their functionality. Mostly, MVC and Morphic differ in their GUI-process management. This means that "proceed" and "close" work differently depending on the process that is being debugged. --- One idea is to attach that framework-specific information to the
process objects. See Process >> #environmentAt: and #environmentAt:put:. Also see ToolSet's #handle* and #debug* methods.!<br>
<br>
Item was changed:<br>
----- Method: Debugger>>doStep (in category 'context stack menu') -----<br>
doStep<br>
"Send the selected message in the accessed method, and regain control <br>
after the invoked method returns."<br>
<br>
| currentContext newContext |<br>
self okToChange ifFalse: [^ self].<br>
self checkContextSelection.<br>
currentContext := self selectedContext.<br>
newContext := self handleLabelUpdatesIn: [interruptedProcess completeStep: currentContext]<br>
whenExecuting: currentContext.<br>
newContext == currentContext ifTrue:<br>
[newContext := interruptedProcess stepToSendOrReturn].<br>
self contextStackIndex > 1<br>
ifTrue: [self resetContext: newContext]<br>
ifFalse:<br>
[newContext == currentContext<br>
+ ifTrue: [self scheduleUIUpdate]<br>
- ifTrue: [self changed: #contentsSelection.<br>
- self updateInspectors]<br>
ifFalse: [self resetContext: newContext]].<br>
!<br>
<br>
Item was added:<br>
+ ----- Method: Debugger>>scheduleUIUpdate (in category 'context stack menu') -----<br>
+ scheduleUIUpdate<br>
+ uiUpdateBlock ifNil:<br>
+ [uiUpdateBlock := [self changed: #contentsSelection.<br>
+ self updateInspectors]].<br>
+ WorldState lastDeferredUIMessage ~~ uiUpdateBlock ifTrue:<br>
+ [WorldState addDeferredUIMessage: uiUpdateBlock]!<br>
<br>
<br>
</div>
</span></font>
</body>
</html>