<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi Jaromir, I've just pushed your latest to GitHub. I included a note with links to this email thread in #terminate. I also added the new tests; and your examples as a class method in Process, for future reference. This is an important piece of work. Thanks a lot! Cheers, <pre class="moz-signature" cols="72">-- Juan Vuletich <a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a> <a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a> <a class="moz-txt-link-freetext" href="https://github.com/jvuletich">https://github.com/jvuletich</a> <a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a> @JuanVuletich</pre> On 6/1/2021 9:09 AM, Jaromir Matas via Cuis-dev wrote: <blockquote cite="mid:BN7PR08MB38420C9014FAD39538A6FF09EE3E9@BN7PR08MB3842.namprd08.prod.outlook.com" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> <div class="WordSection1"> Hi Juan, <o:p> </o:p> I’m enclosing a finalized version of #terminate with the following changes: <o:p> </o:p> 1) whole termination code wrapped in #valueEnsured as suggested in the previous message <o:p> </o:p> 2) changed approach to BlockCannotReturn: error and adopted Christoph Thiede’s solution allowing the debugger to Proceed from the error to the sender of the failing non-local return. It makes sense in the debugger to leave all choices open for the user – Proceeding means ignoring the failed non-local return but why not - it could have been a typo after all :) So I’m taking back my suggestion to disable the Proceed button during unwinding – too restrictive. This change allows for debugging examples like:<o:p></o:p> [^2] fork<o:p></o:p> Or even:<o:p></o:p> [[self error] ensure: [^2]] fork<o:p></o:p> Previously these would crash the image.<o:p></o:p> To make this work with #terminate and notify the user I added a ProceedBlockCannotReturn warning.<o:p></o:p> <o:p> </o:p> 3) #complete:to: is a helper method to improve readability of #terminte and also to deal with two special exceptions: BlockCannotReturn and MessageNotUnderstood. The latter exception was purposely written to allow for writing methods while debugging which introduced a potential for an infinite recursion I had to deal with (see notes in #complete:to: )<o:p></o:p> <o:p> </o:p> 4) I’ve also integrated a fix to a stepOver bug in this example: [^2] ensure: [Transcript show: 'done'] If you step through and then step over ^2 you get a BlockCannotReturn error – that’s a bug<o:p></o:p> The problem is #return:from: supplies the first unwind context to #aboutToReturn:through: but this first unwind context was determined before the debugger inserted an #ensure context during the stepover simulation. My fix is to supply nil and let #resume:through: find the first unwind context at the right moment.<o:p></o:p> This fix modifies #resume:through: and #return:from: methods only and is independent of the #teminate suite.<o:p></o:p> <o:p> </o:p> Please let me know if you find any inconsistencies… I hope not ;)<o:p></o:p> <o:p> </o:p> My best regards,<o:p></o:p> Jaromir<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <div style="border-right: medium none; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(225, 225, 225) -moz-use-text-color -moz-use-text-color; padding: 3pt 0in 0in;"> From: <a moz-do-not-send="true" href="mailto:cuis-dev@lists.cuis.st">Jaromir Matas via Cuis-dev</a> Sent: Tuesday, May 25, 2021 9:32 To: <a moz-do-not-send="true" href="mailto:juan@jvuletich.org">Juan Vuletich</a>; <a moz-do-not-send="true" href="mailto:cuis-dev@lists.cuis.st"> cuis-dev@lists.cuis.st</a> Cc: <a moz-do-not-send="true" href="mailto:mail@jaromir.net">Jaromir Matas</a> Subject: Re: [Cuis-dev] Unwind mechanism during termination is broken and inconsistent </div> <o:p> </o:p> Hi Juan,<o:p></o:p> <o:p> </o:p> I’ve explored a scenario when you are terminating a process, i.e. unwinding it’s ensure etc contexts and in the middle of it the process running the unwinds gets interrupted and terminated. In such case this process unwinds its stack and terminates but the original process is just left hanging as a suspended process (potentially indefinitely) or as a chain of contexts that get garbage collected eventually.<o:p></o:p> <o:p> </o:p> With the new terminate there’s an elegant solution to this scenario: wrap the whole termination code in #valueEnsured and the intruding process will correctly unwind both the original and the terminator process :) I’ve enclosed a test and modified #terminate only. Please take a look, I can’t see anything wrong with this approach.<o:p></o:p> <o:p> </o:p> Best regards,<o:p></o:p> Jaromir<o:p></o:p> <o:p> </o:p> <div style="border-right: medium none; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(225, 225, 225) -moz-use-text-color -moz-use-text-color; padding: 3pt 0in 0in;"> From: <a moz-do-not-send="true" href="mailto:mail@jaromir.net">Jaromir Matas</a> Sent: Sunday, May 23, 2021 19:10 To: <a moz-do-not-send="true" href="mailto:juan@jvuletich.org">Juan Vuletich</a>; <a moz-do-not-send="true" href="mailto:cuis-dev@lists.cuis.st"> cuis-dev@lists.cuis.st</a> Subject: FW: [Cuis-dev] Unwind mechanism during termination is broken and inconsistent<o:p></o:p> </div> <o:p> </o:p> Hi Juan,<o:p></o:p> <o:p> </o:p> I'm enclosing a test covering a situation where the top context itself is an unwind context. The test explores three scenarios based on the position where the execution was suspended: before entering the unwind block, right after setting complete := true but before executing the unwind block and after returning from the unwind block. #terminate should execute the unwind block in the first two cases but not in the last one.<o:p></o:p> <o:p> </o:p> Squeak has a convenient method Process>>#forBlock:runUntil: to step right into the desired position. So I just inlined its code into the test to make it work the same way :)<o:p></o:p> <o:p> </o:p> Regarding the tests demonstrating the unwind behavior in case of unhandled errors and subsequent Abandoning or Proceeding the debugger - it looks like Squeak has a machinery to do that (debugger tests) but I can't see anything similar in Cuis that would simulate opening and abandoning a debugger... Any advice?<o:p></o:p> <o:p> </o:p> Many thanks for all your feedback,<o:p></o:p> <o:p> </o:p> Best regards,<o:p></o:p> <o:p> </o:p> Jaromir<o:p></o:p> <o:p> </o:p> PS: Yesterday my message bounced back due to it’s size, I’m forwarding it again and trimming history.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <div style="border-right: medium none; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(225, 225, 225) -moz-use-text-color -moz-use-text-color; padding: 3pt 0in 0in;"> From: <a moz-do-not-send="true" href="mailto:mail@jaromir.net">Jaromir Matas</a> Sent: Saturday, May 22, 2021 23:16 To: <a moz-do-not-send="true" href="mailto:juan@jvuletich.org">Juan Vuletich</a>; <a moz-do-not-send="true" href="mailto:cuis-dev@lists.cuis.st"> Discussion of Cuis Smalltalk</a> Subject: RE: [Cuis-dev] Unwind mechanism during termination is broken and inconsistent<o:p></o:p> </div> <o:p> </o:p> Hi Juan,<o:p></o:p> <o:p> </o:p> Many thanks for your feedback.<o:p></o:p> <o:p> </o:p> I've made some final changes to the changeset:<o:p></o:p> <o:p> </o:p> 1) extracted a repeating code to a method called Process>>complete:to: which calls #runUnwindUntilErrorOrReturnFrom: and deals with potential infinite loops caused by some errors.<o:p></o:p> <o:p> </o:p> 2) as a result the unwind code pattern used in #terminate is almost identical to the one in #resume:through: - which I think is better for readability - when people can recognize a pattern right away :)<o:p></o:p> <o:p> </o:p> 3) adjusted the part searching for the outer-most unwind context to catch even the top context if it's an unwind context.<o:p></o:p> <o:p> </o:p> 4) In order to rein in the infinite loops or crashes caused by the BlockCannotReturn error I added a local variable isRecursive to BlockCannotReturn exception to be able to deal with a starting infinite loop. This is an example brought to my attention Christoph Thiede:<o:p></o:p> <o:p> </o:p> ```<o:p></o:p> "Both statements need to be executed separately in a Workspace"<o:p></o:p> a := [true ifTrue: [^ 1] yourself]<o:p></o:p> [a value] on: BlockCannotReturn do: [:ex | ex resume]<o:p></o:p> ```<o:p></o:p> <o:p> </o:p> With the proposed fix there's no need to change the isResumable setting of the BlockCannotReturn I suggested previously. Resuming doesn't hurt any longer :)<o:p></o:p> <o:p> </o:p> Regarding my suggestion to disable the Proceed button when debugging an error that happened during unwind - I'm no longer so sure it's a good idea to limit the freedom of the user in such a border situation like debugging an unwind error :) I suggest to leave it open, "use at your own risk" type of thing, for the moment.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> > I think you are right in the previous email, and we'd integrate your latest change.I have already checked that none of the tests we recently added breaks because of it. If you could turn some of the arguments you provide into tests, it would be great.<o:p></o:p> <o:p> </o:p> I must admit I still haven't learned to build tests involving errors etc. :) But at least I updated and enclosed the list of examples that can be used as test scenarios and added some more extreme ones.<o:p></o:p> <o:p> </o:p> Juan, please review the enclosed changeset and let me know if you find something suspicious. Please feel free to change any names I picked or do any changes you find useful. <o:p></o:p> <o:p> </o:p> Best regards,<o:p></o:p> <o:p> </o:p> Jaromir<o:p></o:p> <o:p> </o:p> <div style="border-right: medium none; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(225, 225, 225) -moz-use-text-color -moz-use-text-color; padding: 3pt 0in 0in;"> From: <a moz-do-not-send="true" href="mailto:juan@jvuletich.org">Juan Vuletich</a> Sent: Friday, May 21, 2021 21:08 To: <a moz-do-not-send="true" href="mailto:cuis-dev@lists.cuis.st">Discussion of Cuis Smalltalk</a> Cc: <a moz-do-not-send="true" href="mailto:mail@jaromir.net">Jaromir Matas</a>; <a moz-do-not-send="true" href="mailto:hernan.wilkinson@10pines.com"> Hernan Wilkinson</a> Subject: Re: [Cuis-dev] Unwind mechanism during termination is broken and inconsistent<o:p></o:p> </div> <o:p> </o:p> Hi Jaromir, On 5/16/2021 5:26 PM, Jaromir Matas via Cuis-dev wrote: <o:p></o:p> <blockquote style="margin-top: 5pt; margin-bottom: 5pt;"> Hi Juan,<o:p></o:p> <o:p></o:p> I'm enclosing an updated changeset (please disregard the previous one); I made a stupid assumption about #runUntilErrorOrReturnFrom:. The new changeset leaves it untouched and adds its replica called #runUnwindUntilErrorOrReturnFrom: with the required functionality.<o:p></o:p> </blockquote> I think you are right in the previous email, and we'd integrate your latest change.I have already checked that none of the tests we recently added breaks because of it. If you could turn some of the arguments you provide into tests, it would be great.<o:p></o:p> <blockquote style="margin-top: 5pt; margin-bottom: 5pt;"> I'd like to point out a little issue with the proposed semantics of nested errors during termination: <o:p></o:p> <o:p></o:p> Below’s a simple example. If you abandon the first debugger it means you want to terminate the execution and unwind the terminated process but an error happens during the unwind. You get another debugger reporting the error and asking you what to do next - to debug the error or proceed. But proceeding a termination really means to proceed with the *unwind business only* and not to proceed with the original computation. Here's my point: Hitting Proceed will resume the original computation beyond the unwind blocks but Abandon will only finish the unwind procedure which is exactly what we want. In Squeak I simply disabled the Proceed button but in Cuis I couldn't see such a simple solution so I left it unresolved.<o:p></o:p> <o:p></o:p> [self error: 'x1'] ensure: [<o:p></o:p> [self error: 'x2'] ensure: [<o:p></o:p> Transcript show: '2'].<o:p></o:p> Transcript show: '1'].<o:p></o:p> Transcript show: '0'<o:p></o:p> <o:p></o:p> ---> you want to see '21' but proceeding the debugger will give you '210' where '0' is printed outside of unwind blocks.<o:p></o:p> <o:p></o:p> So just that you know there's still a little inconsistency in the termination semantics.<o:p></o:p> <o:p></o:p> </blockquote> I see. The issue is how to disable a button so it doesn't act? The simplest way is by saying `aButton lock: true`. We could add #enable and #disable to PluggableButtonMorph (calling self lock: ). Or perhaps call it #isEnabled: like in MenuItemMorph, although it is an ugly name. Can you prepare a change set like this? That would be great. I mean, I don't know where those calls should be made!<o:p></o:p> <blockquote style="margin-top: 5pt; margin-bottom: 5pt;"> One more question: do you have an idea why BlockCannotReturn error is considered resumable? I'd say it's unresumable by definition…? Thanks :)<o:p></o:p> </blockquote> Well, that method is pretty old, and in the mean time, exception handling has gotten a lot better, thanks to several batches of improvements, latter ones by you. So, please provide a patch to change that, so it properly carries your initials.<o:p></o:p> <blockquote style="margin-top: 5pt; margin-bottom: 5pt;"> <o:p></o:p> best regards,<o:p></o:p> <o:p></o:p> Jaromir<o:p></o:p> </blockquote> Thanks again Jaromir for this amazing work. Cheers, </div> </blockquote> </body> </html>