[Cuis-dev] Improved version of #terminate
Juan Vuletich
JuanVuletich at zoho.com
Wed Feb 23 07:47:16 PST 2022
Doh! There it is!
Thanks,
On 2/2/2022 9:17 PM, Jaromir Matas via Cuis-dev wrote:
>
> Hi Juan,
>
> apologies, forgot to enclose a helper method to Eliot’s MNU fix for
> your review.
>
> Best,
>
> Jaromir
>
> *From: *Jaromir Matas via Cuis-dev <mailto:cuis-dev at lists.cuis.st>
> *Sent: *Thursday, February 3, 2022 0:49
> *To: *Juan Vuletich <mailto:JuanVuletich at zoho.com>; Discussion of Cuis
> Smalltalk <mailto:cuis-dev at lists.cuis.st>
> *Cc: *Jaromir Matas <mailto:mail at jaromir.net>
> *Subject: *Re: [Cuis-dev] Improved version of #terminate
>
> Hi Juan,
>
> Works perfectly, thanks! I’m reviewing all examples and updating the
> expected results. I’ve also replaced strings with symbols so we won’t
> have to struggle with the quotes :)
>
> I’d like to ask you to make two additional changes:
>
> 1. revert MethodContext >> cannotReturn: back to your original version
> (enclosed fileout fyi). The latest #terminate doesn’t need the newer
> modified version any longer and works better with the original one
> and, what’s more important, the newer one breaks one of the examples
> (interestingly doesn’t break any test). Generally it’s better if
> #terminate’s good behavior is not dependent on #cannotReturn (the new
> terminate detects and avoids executing it).
>
> 2. please review the enclosed Eliot’s modification of Object >>
> doesNotUnderstand dealing with infinite recursion of the MNU error if
> you keep proceeding the error without doing any modification to the
> message not understood. The current doesNotUnderstand recursive
> behavior impacts some terminate examples with the MNU error involved
> and Eliot’s modification fixes it – what it does it checks whether the
> next MNU error has identical conditions and prevents the loop. If you
> agree to merge it I’ll update the examples accordingly. The loop only
> occurs when the MNU error happens inside an unwind block, which is
> rare but I’d prefer to have it clean :)
>
> Thanks very much,
>
> Jaromir
>
> *From: *Juan Vuletich <mailto:JuanVuletich at zoho.com>
> *Sent: *Wednesday, February 2, 2022 23:32
> *To: *Discussion of Cuis Smalltalk <mailto:cuis-dev at lists.cuis.st>
> *Cc: *Juan Vuletich <mailto:JuanVuletich at zoho.com>; Jaromir Matas
> <mailto:mail at jaromir.net>
> *Subject: *Re: [Cuis-dev] Improved version of #terminate
>
> Thanks Jaromir.
>
> The test is integrated. I also fixed the format in #terminateExamples.
>
> WRT User Interrupt, in Cuis I recently changed to usually interrupt
> whatever process was running the moment Alt + . was pressed. I think
> this makes sense. If the process happens to be the background process,
> it refuses to do it, as the VM requires a runnable background process
> at all times.
>
> What it seems I left out, and the old code somehow did, is to create a
> new UI process if the previous one was terminated by any reason. Just
> pushed a change to do that. With the new updates, Alt + . again
> recovers control.
>
> Thanks for reporting the problem!
>
> Cheers,
> On 2/2/2022 2:36 PM, Jaromir Matas via Cuis-dev wrote:
>
> Hi Juan,
>
> I’m reviewing the set of terminate examples and this one behaves
> suspiciously – it suspends the UI as expected but then the system
> refuses to recover via Alt + .
>
> In Squeak the Alt + . recovery works fine. Could you please take
> look? Thanks!
>
> Jaromir
>
> [ ] ensure: [
>
> [Processor activeProcess terminate] ensure: [
>
> Transcript show: #x1].
>
> Transcript show: #x2
>
> ]
>
> "prints x1 x2 and suspends the UI; in Cuis NOT recoverable via
> Alt+. and prints Can not interrupt backgroundProcess (!)"
>
> *From: *Jaromir Matas via Cuis-dev <mailto:cuis-dev at lists.cuis.st>
> *Sent: *Tuesday, February 1, 2022 20:59
> *To: *Juan Vuletich <mailto:JuanVuletich at zoho.com>; Discussion of
> Cuis Smalltalk <mailto:cuis-dev at lists.cuis.st>
> *Cc: *Jaromir Matas <mailto:mail at jaromir.net>
> *Subject: *Re: [Cuis-dev] Improved version of #terminate
>
> Hi Juan,
>
> Thank you!
>
> I'm sending the test I owe you - #testProcessFaithfulTermination -
> this is a new feature of the latest terminate; the test shows the
> same process that created the unwind blocks also executes them
> during termination.
>
> I’ll be reviewing the terminate examples and get back later.
>
> Thanks again.
>
> Best,
>
> Jaromir
>
> *From: *Juan Vuletich <mailto:JuanVuletich at zoho.com>
> *Sent: *Thursday, January 27, 2022 19:21
> *To: *Discussion of Cuis Smalltalk <mailto:cuis-dev at lists.cuis.st>
> *Cc: *Jaromir Matas <mailto:mail at jaromir.net>
> *Subject: *Re: [Cuis-dev] Improved version of #terminate
>
> Hi Jaromir, Folks,
>
> This is integrated and pushed to GitHub now.
>
> Thanks,
>
> On 1/24/2022 3:51 PM, Jaromir Matas via Cuis-dev wrote:
>
> Hi Juan, all,
>
> Happy to hear from you :)
>
>
> Hello Jaromir, Folks,
>
>
> I took a look at the code, and it looks correct to me,
> although I don't understand this well enough to be sure.
> All the tests you wrote last year pass, and that is great.
>
>
> I think we'd integrate this. Still, I think it could be
> good to keep the current #terminate as a separate method,
> maybe #terminateFromForkedProcess, just in case it proves
> useful in the future.
>
>
> Thanks very much for reviewing the code; I think this is a
> good idea to keep the older version, at least for a while. I'm
> really happy it's been stable and nobody
> complained :)
>
>
> This new approach of one process using two stacks simplifies
> the code substantially but let's keep an eye on it, for sure.
> Later, if this terminate proves as
> stable as the current one, the exact same approach could be
> used for exception unwinds too (ContextPart>>resume: etc).
>
>
> I'd be very thankful if others could take a look, and
> better yet, try it and see if it brings any trouble.
>
>
> That would be great, thanks again; any concerns or suspicions,
> please tell me.
>
>
> Best regards,
>
>
> Jaromir
>
>
> --
>
>
> Jaromir Matas
>
> *From: *Juan Vuletich via Cuis-dev <mailto:cuis-dev at lists.cuis.st>
> *Sent: *Monday, January 24, 2022 18:15
> *To: *Discussion of Cuis Smalltalk <mailto:cuis-dev at lists.cuis.st>
> *Cc: *Juan Vuletich <mailto:JuanVuletich at zoho.com>; Andres
> Valloud <mailto:ten at smallinteger.com>; Jaromir Matas
> <mailto:mail at jaromir.net>; Hernan Wilkinson
> <mailto:hernan.wilkinson at 10pines.com>
> *Subject: *Re: [Cuis-dev] Improved version of #terminate
>
> On 1/18/2022 4:07 PM, Jaromir Matas via Cuis-dev wrote:
>
> Hi Juan, all,
>
> I'm enclosing a new version of #terminate; I thought you
> might be interested to take a look and indeed, I'd be very
> much interested in your opinion. The termination
> functionality and semantics remains intact but the code is
> simplified and addresses Eliot's concerns regarding active
> process termination being done via another process. The
> enclosed code executes both active and suspended process’s
> termination directly by the process being terminated thus
> maintaining the invariant that the unwind blocks are
> executed by the same process that created them (this is
> the only real disadvantage of the current terminate; it’s
> not process faithful). The technique used is to create a
> parallel stack for the process being terminated and run
> the unwinds conveniently from there :) (thorough comments
> included).
>
> I'm also enclosing some updated tests to reflect the new
> approach to the active process termination. If you were
> interested, I'd be happy to also provide updated examples
> and add some more tests later.
>
> Best regards,
>
> Jaromir
>
>
> Hello Jaromir, Folks,
>
> I took a look at the code, and it looks correct to me,
> although I don't understand this well enough to be sure. All
> the tests you wrote last year pass, and that is great.
>
> I think we'd integrate this. Still, I think it could be good
> to keep the current #terminate as a separate method, maybe
> #terminateFromForkedProcess, just in case it proves useful in
> the future.
>
> I'd be very thankful if others could take a look, and better
> yet, try it and see if it brings any trouble.
>
> Thanks!
>
> --
>
> Juan Vuletich
>
> www.cuis-smalltalk.org <http://www.cuis-smalltalk.org>
>
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>
> https://github.com/jvuletich
>
> https://www.linkedin.com/in/juan-vuletich-75611b3
>
> https://independent.academia.edu/JuanVuletich
>
> https://www.researchgate.net/profile/Juan-Vuletich
>
> https://patents.justia.com/inventor/juan-manuel-vuletich
>
> @JuanVuletich
>
>
>
> --
>
> Juan Vuletich
>
> www.cuis-smalltalk.org <http://www.cuis-smalltalk.org>
>
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>
> https://github.com/jvuletich
>
> https://www.linkedin.com/in/juan-vuletich-75611b3
>
> https://independent.academia.edu/JuanVuletich
>
> https://www.researchgate.net/profile/Juan-Vuletich
>
> https://patents.justia.com/inventor/juan-manuel-vuletich
>
> @JuanVuletich
>
>
>
> --
> Juan Vuletich
> www.cuis-smalltalk.org <http://www.cuis-smalltalk.org>
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> https://github.com/jvuletich
> https://www.linkedin.com/in/juan-vuletich-75611b3
> https://independent.academia.edu/JuanVuletich
> https://www.researchgate.net/profile/Juan-Vuletich
> https://patents.justia.com/inventor/juan-manuel-vuletich
> @JuanVuletich
>
--
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
https://independent.academia.edu/JuanVuletich
https://www.researchgate.net/profile/Juan-Vuletich
https://patents.justia.com/inventor/juan-manuel-vuletich
@JuanVuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220223/3f048a3c/attachment-0001.htm>
More information about the Cuis-dev
mailing list