<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="blue" vlink="#954F72" style="word-wrap:break-word"> <div class="WordSection1"> Hi Juan, <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> 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> 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> Many thanks for all your feedback, <o:p> </o:p> Best regards, <o:p> </o:p> Jaromir <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> <div style="mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> From: <a href="mailto:mail@jaromir.net">Jaromir Matas</a> Sent: Saturday, May 22, 2021 23:16 To: <a href="mailto:juan@jvuletich.org">Juan Vuletich</a>; <a href="mailto:cuis-dev@lists.cuis.st"> Discussion of Cuis Smalltalk</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> 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:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> From: <a href="mailto:juan@jvuletich.org">Juan Vuletich</a> Sent: Friday, May 21, 2021 21:08 To: <a href="mailto:cuis-dev@lists.cuis.st">Discussion of Cuis Smalltalk</a> Cc: <a href="mailto:mail@jaromir.net">Jaromir Matas</a>; <a 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:5.0pt;margin-bottom:5.0pt"> 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:5.0pt;margin-bottom:5.0pt"> 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:5.0pt;margin-bottom:5.0pt"> 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:5.0pt;margin-bottom:5.0pt"> <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, <o:p></o:p> <o:p> </o:p> </div> </body> </html>