<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 again, <o:p> </o:p> Missed the list, sorry. <o:p> </o:p> As we agree to keep the current isTerminated semantics (also consistent with Squeak/Pharo) I’d suggest to use the test as the documentation of the observed behavior; I’ve added a link to the archive in the comment. <o:p> </o:p> Question: is there a way to make a test an “expected failure” like in Squeak? In Squeak I create a method <o:p> </o:p> ProcessTest>>#expectedFailures <o:p> </o:p> ^ #(testTerminateTerminatingProcess testResumeTerminatingProcess) <o:p> </o:p> As a result the two listed tests show green in the test runner if they fail. <o:p> </o:p> If possible, I’d like to post two tests that currently fail as a reminder/documentation. <o:p> </o:p> Thanks, Jaromir <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: Sunday, January 22, 2023 19:37 To: <a href="mailto:juan@cuis.st">Juan Vuletich</a> Subject: RE: [Cuis-dev] Follow-up: #terminate and #suspend update </div> <o:p> </o:p> Hi Juan,<o:p></o:p> <o:p> </o:p> > I think that changing the semantics of #isTerminated or any other such method is likely to break existing code, and create a compatibility problem.<o:p></o:p> <o:p> </o:p> True, another reason to keep the current semantics, thanks!<o:p></o:p> <o:p> </o:p> > Maybe we'd need to add a new possible state to Process, and new testing selector(s).<o:p></o:p> <o:p> </o:p> Let’s see, I’ll keep this in mind, thanks again.<o:p></o:p> <o:p> </o:p> Best,<o:p></o:p> -- Jaromír Matas<o:p></o:p> <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@cuis.st">Juan Vuletich</a> Sent: Sunday, January 22, 2023 18:18 To: <a href="mailto:cuis-dev@lists.cuis.st">Discussion of Cuis Smalltalk</a> Cc: <a href="mailto:mail@jaromir.net">Jaromir Matas</a> Subject: Re: [Cuis-dev] Follow-up: #terminate and #suspend update<o:p></o:p> </div> <o:p> </o:p> Hi Jaromir, On 1/22/2023 10:18 AM, 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> Here’s a test illustrating the situation described below, resulting in executing unwind blocks of a process considered terminated by the current termination semantics. I assume it’s no harm to keep this semantics; an alternative would be to consider a process terminated iff the suspended context is nil or all remaining contexts have their pc atEnd. The downside of this approach would be that a process found not terminated could not be simply resumed to finish because there might be dangerous contexts with pc=nil which could crash the vm when run.<o:p></o:p> <o:p></o:p> Best,<o:p></o:p> --<o:p></o:p> Jaromír Matas<o:p></o:p> </blockquote> I guess you are the first person to realize of this. I think that changing the semantics of #isTerminated or any other such method is likely to break existing code, and create a compatibility problem. Maybe we'd need to add a new possible state to Process, and new testing selector(s). WRT the code in the message below, it looks OK AFAIK. It is now at GitHub. Thanks!!! <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <o:p> </o:p> <o:p></o:p> <div style="border:none;border-top:solid windowtext 1.0pt;padding:3.0pt 0in 0in 0in;border-color:rgb(225, 225, 225) -moz-use-text-color -moz-use-text-color"> From: <a href="mailto:cuis-dev@lists.cuis.st">Jaromir Matas via Cuis-dev</a> Sent: Saturday, January 21, 2023 17:12 To: <a href="mailto:juan@cuis.st">Juan Vuletich</a>; <a href="mailto:cuis-dev@lists.cuis.st"> Discussion of Cuis Smalltalk</a> Cc: <a href="mailto:mail@jaromir.net">Jaromir Matas</a> Subject: Re: [Cuis-dev] Follow-up: #terminate and #suspend update<o:p></o:p> </div> <o:p></o:p> Hi Juan,<o:p></o:p> <o:p></o:p> Thanks for your message.<o:p></o:p> <o:p></o:p> I’m enclosing a test for isTerminated documenting the current semantics.<o:p></o:p> <o:p></o:p> A few notes here:<o:p></o:p> <o:p></o:p> 1) I’ve added MethodContext>>#endpc as an analogue to MethodContext>>#startpc but could you please doublecheck it’s ok? I could have used a temp var assignment "endpc := self closure startpc + self closure size - 1" instead but it seemed a bit awkward.<o:p></o:p> <o:p></o:p> 2) Currently we consider contexts with pc=nil as a sign of terminated processes. In theory a context with pc=nil can still contain a relevant unexecuted code, e.g. unwind blocks: <o:p></o:p> <o:p></o:p> Example: if you terminate a “terminated” process with an unexecuted unwind block(s) and pc=nil in the suspended context (or below in the sender chain) the unwind block(s) will get executed – which may be perfectly appropriate but sounds a bit unexpected. I know these are wildly hypothetical scenarios but I just wanted to make you aware.<o:p></o:p> <o:p></o:p> Best,<o:p></o:p> Jaromir<o:p></o:p> <o:p> </o:p> </blockquote> <o:p> </o:p> <pre>-- </pre> <pre>Juan Vuletich</pre> <pre>cuis.st</pre> <pre>github.com/jvuletich</pre> <pre>researchgate.net/profile/Juan-Vuletich</pre> <pre>independent.academia.edu/JuanVuletich</pre> <pre>patents.justia.com/inventor/juan-manuel-vuletich</pre> <pre>linkedin.com/in/juan-vuletich-75611b3</pre> <pre>twitter.com/JuanVuletich</pre> <o:p> </o:p> <o:p> </o:p> </div> </body> </html>