[Cuis-dev] Resuming on BlockCannotReturn exception

Fri Dec 1 09:32:58 PST 2023

Hi Juan,

 > You're missing almost a year of updates.

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:

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.:

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.

Is this something happening to me only? (I'm on Win 11 Pro, PC with 
Intel i3-1315U)

Once I get this running I'll update the changeset (the test comment, 
#suspendedContext comment, use the latest #runUntilErrorOrReturnFrom) .

 > In the comment of the test you provided, the argument to on:do: is a 
symbol. This is not supported in Cuis.

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 ;)

Thanks for your help/advice regarding the CorePackages.

Best,
Jaromir

On 01-Dec-23 5:18:20 PM, "Juan Vuletich via Cuis-dev" 
<cuis-dev at lists.cuis.st> wrote:

>Hi Jaromir,
>
>Again, thanks for your continued support for Cuis! This is VERY much 
>appreciated.
>
>(inline)
>
>On 12/1/2023 10:52 AM, Jaromir Matas via Cuis-dev wrote:
>>Hi Juan, all,
>>
>>Question: Was there a particular reason for this definition:
>>```
>>suspendedContext
>>     "Answer the context the receiver has suspended.
>>     I am Ready to Run or Suspended. Answer the context I was running 
>>when last preempted.
>>
>>     Otherwise, (Running or Terminated) answer nil."
>>
>>     ^self isTerminated ifFalse: [ suspendedContext ]
>>```
>>instead of using the simple original:
>>```
>>suspendedContext
>>     "Answer the context the receiver has suspended."
>>
>>     ^suspendedContext
>>```
>>
>
>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.
>
>>The reason I'm asking is it messes up with debugging some edge case 
>>scenarios I've been working on:
>>
>>With Eliot we've fixed VM crashes when running e.g.
>>
>>     [[^ 1] on: BlockCannotReturn do: [:ex | ex resume] ] fork
>>
>>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.
>>
>>     [[self halt. ^ 1] on: BlockCannotReturn do: [:ex | ex resume] ] 
>>fork
>>
>>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.
>>
>>I've included the "original" simple version of #suspendedContext in 
>>the enclosed changeset but feel free to make any changes, of course.
>>
>>Now debugging of the example works fine for any of stepping over, 
>>through or into.
>
>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.
>
>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:
>
>Can you please review and retest your changes on a fully updated Cuis?
>
>Thanks!!!
>
>>
>>Explanation of the #return:from: bug:
>>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.
>>
>>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:
>>
>>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.
>>
>>Explanation of the VM crash fix:
>>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.
>>
>>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.
>>
>>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" ;)
>>
>>I hope I haven't missed something important; please let me know what 
>>you think.
>>
>>Best regards,
>>Jaromir
>>
>>--
>>Jaromir Matas
>>mail at jaromir.net
>>
>>
>
>
>--
>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20231201/c71b6b09/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oeyd0p1d.png
Type: image/png
Size: 41140 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20231201/c71b6b09/attachment-0001.png>