<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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">
<style id="css_styles">blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding-top: 0px; }
a img { border: 0px; }
li[style='text-align: center;'], li[style='text-align: center; '], li[style='text-align: right;'], li[style='text-align: right; '] { list-style-position: inside;}
body { font-family: 'Segoe UI'; font-size: 12pt; }
.quote { margin-left: 1em; margin-right: 1em; border-left: 5px #ebebeb solid; padding-left: 0.3em; }
blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding-top: 0px; }
a img { border: 0px; }
li[style='text-align: center;'], li[style='text-align: center; '], li[style='text-align: right;'], li[style='text-align: right; '] { list-style-position: inside;}
body { font-family: 'Segoe UI'; font-size: 12pt; }
.quote { margin-left: 1em; margin-right: 1em; border-left: 5px #ebebeb solid; padding-left: 0.3em; }
</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">
<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">
<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>
</body>
</html>