<html><head> <title></title> <style id="css_styles" type="text/css"></style></head> <body><div>Hi Juan, </div><div><br /></div><div>> You're missing almost a year of updates. </div><div><br /></div><div>Well, I actually encountered two weird issues with the latest master, and so just reverted back to the older version to be able to run the tests: </div><div><br /></div><div>1) I can't download CorePackages via `Feature require: 'CorePackages'` - it starts working but after a little while it says `Could not find package file for [SUnitXMLreports].` and fails. See screenshot.:</div><div><br /></div><div><img src="cid:em8d223f8d-ff9d-462d-a012-e7a1f2611f87@ab6ea512.com" border="0" width="640" height="143" /></div><div><br /></div><div>2) When I change the size of GUI elements to 12 (or just anything) and save and close the image, it'll come back as the default 18 when I open the image again. I thought I just missed something but the first issue prevented me from running the tests. </div><div><br /></div><div>Is this something happening to me only? (I'm on Win 11 Pro, PC with Intel i3-1315U) </div><div><br /></div><div>Once I get this running I'll update the changeset (the test comment, #suspendedContext comment, use the latest #runUntilErrorOrReturnFrom) .</div><div><br /></div><div>> In the comment of the test you provided, the argument to on:do: is a symbol. This is not supported in Cuis. </div><div><br /></div><div>Yes, I've noticed the idiom is not supported by Cuis, is it intentional or just not worth the effort? I wondered why the examples and the test were not working in Cuis and then realized it was the #resume idiom ;) </div><div><br /></div><div>Thanks for your help/advice regarding the CorePackages. </div><div><br /></div><div>Best, </div><div>Jaromir</div><div style="clear:both"><br /></div><div><br /></div><div> <div>On 01-Dec-23 5:18:20 PM, "Juan Vuletich via Cuis-dev" <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:</div></div><div><br /></div><div id="xa8dd2ca25b7d42d" style="color: rgb(0, 0, 0);"><blockquote cite="656A074C.7010609@cuis.st" type="cite" class="cite2"> Hi Jaromir,<br /> <br /> Again, thanks for your continued support for Cuis! This is VERY much appreciated. <br /> <br /> (inline)<br /> <br /> On 12/1/2023 10:52 AM, Jaromir Matas via Cuis-dev wrote: <blockquote cite="mid:emc3371710-e22e-43a2-9905-2c2c9b66e2e3@ab6ea512.com" type="cite" class="cite"> <style type="text/css"></style> <div>Hi Juan, all,</div> <div><br /> </div> <div>Question: Was there a particular reason for this definition: </div> <div>``` </div> <div>suspendedContext </div> <div> "Answer the context the receiver has suspended. </div> <div> I am Ready to Run or Suspended. Answer the context I was running when last preempted. </div> <div><br /> </div> <div> Otherwise, (Running or Terminated) answer nil." </div> <div><br /> </div> <div> ^self isTerminated ifFalse: [ suspendedContext ] </div> <div>``` </div> <div>instead of using the simple original: </div> <div>``` </div> <div>suspendedContext </div> <div> "Answer the context the receiver has suspended." </div> <div><br /> </div> <div> ^suspendedContext </div> <div>``` </div> <div><br /> </div> </blockquote> <br /> Well, that method is from 2013. It was modified in 1696-ProcessEnh-JuanVuletich-2013May10-09h59m-jmv.1.cs.st. I just guess it made sense to me at the time. No existing tests are made to fail, so I'm ok with this change. I'd still tell the reason in the method comment, though. <br /> <br /> <blockquote cite="mid:emc3371710-e22e-43a2-9905-2c2c9b66e2e3@ab6ea512.com" type="cite" class="cite"> <div>The reason I'm asking is it messes up with debugging some edge case scenarios I've been working on: </div> <div><br /> </div> <div>With Eliot we've fixed VM crashes when running e.g. </div> <div><br /> </div> <div> [[^ 1] on: BlockCannotReturn do: [:ex | ex resume] ] fork </div> <div><br /> </div> <div>However, even after fixing the crashes the debugging of this scenario remained broken. I've identified the root cause in an incorrect simulation of returns in #return:from:. The fix is enclosed, but the debugging in Cuis still fails in some cases - e.g. if you debug the following example and just keep stepping over until a nonsensical error appears. </div> <div><br /> </div> <div> [[self halt. ^ 1] on: BlockCannotReturn do: [:ex | ex resume] ] fork </div> <div><br /> </div> <div>And here I've tracked the root cause to your version of #suspendedContext. It answers nil for a terminated process but a process may be terminated yet a sender's context chain still hanging there; by nilling the suspended context you lose that information and the debugging fails. </div> <div><br /> </div> <div>I've included the "original" simple version of #suspendedContext in the enclosed changeset but feel free to make any changes, of course. </div> <div><br /> </div> <div>Now debugging of the example works fine for any of stepping over, through or into. </div> </blockquote> <br /> In the comment of the test you provided, the argument to on:do: is a symbol. This is not supported in Cuis. The idiom you used in your email, passing a block, is ok. <br /> <br /> I see that you did your testing and fix on a Cuis system updated to #5670. Latest published Cuis update is #6092. You're missing almost a year of updates. And, for instance, in #6091, Facundo modified #runUntilErrorOrReturnFrom: <br /> <br /> Can you please review and retest your changes on a fully updated Cuis? <br /> <br /> Thanks!!!<br /> <br /> <blockquote cite="mid:emc3371710-e22e-43a2-9905-2c2c9b66e2e3@ab6ea512.com" type="cite" class="cite"> <div><br /> </div> <div>Explanation of the #return:from: bug: </div> <div>Previously the method allowed returning to a dead or nil context, and, in addition, didn't nil the context that can't be returned to. These are two independent bugs. The VM doesn't allow such returns and does nil the context. </div> <div><br /> </div> <div>Fixing #return:from:, however, changes (i.e. fixes) the (incorrect) semantics of some other simulation methods: #stepToCallee won't return to a dead or nil sender now and the same goes for #step. There are cases where this incorrect bahavior has been (mis)used, e.g. in #runUntilErrorOrReturnFrom: </div> <div><br /> </div> <div>In order to fix this the easiest possible way I've created a version of #stepToCallee fulfilling this incorrect expectation - see #stepToCalleeOrNil. Ideally, I think, the use of #stepToCalleeOrNil in #runUntilErrorOrReturnFrom should be replaced with a "standard" (as opposed to a "simulation") code, e.g. using #releaseTo:, as the next step later. </div> <div><br /> </div> <div>Explanation of the VM crash fix: </div> <div>The fix simply nills the context that can't be returned to. This can be done either in #cannotReturn: just by setting pc to nil before returning but Eliot suggested a more conceptual solution: in #cannotReturn:to:. This way we can save the failing context, and the pc where the return failed, inside the BCR exception for further use when debugging. </div> <div><br /> </div> <div>One more note: the direct debugger invocation in #cannotReturn: had to be replaced with raising an error in order to be able to test this situation properly - see the enclosed test. </div> <div><br /> </div> <div>It is possible there are some more cases taking advantage of making an illegal return to a dead or nil context during simulation, especially some debugger tests may be (mis)designed (because simplified) using this "feature" ;) </div> <div><br /> </div> <div>I hope I haven't missed something important; please let me know what you think. </div> <div><br /> </div> <div>Best regards, </div> <div>Jaromir</div> <div><br /> </div> <div id="signature_old" style="clear: both;"> <div id="x57b63d33bbce4a9085be84e73df734d9"> <div> --</div> <div><font face="Segoe UI Light">Jaromir Matas</font></div> <div><font style="font-size: 10pt;" size="2" face="Segoe UI
 Light
"><a moz-do-not-send="true" href="mailto:mail@jaromir.net">mail@jaromir.net</a></font></div> <div><br /> </div> </div> </div> <div><br /> </div> </blockquote> <br /> <br /> <pre class="moz-signature" cols="72">-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich </pre> </blockquote></div></body></html>