<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 Juan, <o:p> </o:p> In our previous discussion we discussed a few examples: <o:p> </o:p> [1/0] fork. [ 10000 factorial. 5 seconds asDelay wait ] repeat <o:p> </o:p> This one represents a situation where the UI is blocked and we (mostly you indeed) modified the code to create a new UI to open the debugger for the [1/0] process request while the old UI is idly waiting. <o:p> </o:p> [1/0] fork. [ 10000 factorial. Processor yield ] repeat <o:p> </o:p> This one represents a different situation where, again, the [1/0] process starts executing but the debug request gets stuck (deferred) in the UI process because the UI process is "busy" executing its Workspace task. <o:p> </o:p> We concluded that this looks like a more complex scenario than the "blocked UI" scenario presented above. <o:p> </o:p> The more I think about it the more I lean toward treating both scenarios equally, i.e. create a new UI in both scenarios, in other words create a new UI for every debug request. <o:p> </o:p> The main difference between the two scenarios is *where* - at which queue the UI process is waiting when the debug request occurs: whether on a Semaphore or on a Processor's ready list (apologies for stating the obvious: the UI process is waiting somewhere by definition when a debug request from another process occurs). I'm aware my experience is very limited but I can't come up with any argument why *not* treat them equally :) Treating them equally looks to me cleaner, simpler and may even allow some more simplifications. <o:p> </o:p> Here's my suggestion (as usual I'm not sure I'm placing my modification at the most appropriate location but you get the idea): <o:p> </o:p> newUIProcessIfNeeded "If the system needs a UIProcess (we know because UIProcess is not nil), then ensure that the UIProcess is ready to run, in order to have a responsive UI. If we needed to create a new UI process, answer the old one, as it is most likely the process the user is interested in debugging. See senders." <o:p> </o:p> UIProcess ifNotNil: [ :oldUIProcess | self spawnNewMorphicProcessFor: UI. ^oldUIProcess ]. ^nil <o:p> </o:p> With this change the following examples work: <o:p> </o:p> [1/0] fork. Processor yield. [ 10000 factorial ] repeat <o:p> </o:p> [1/0] fork. [ 10000 factorial. Processor yield ] repeat <o:p> </o:p> <o:p> </o:p> Surprisingly, even the following example works, i.e. opens a debugger instead of getting stuck, but in this case it is also thanks to some unrelated interrupts at play preempting the old UI and allowing the new UI run.. <o:p> </o:p> [1/0] fork. [ 10 factorial ] repeat <o:p> </o:p> <o:p> </o:p> An interesting observation: <o:p> </o:p> The suggested modification works under the assumption that Smalltalk processPreemptionYields returns true, which is Cuis's default (unlike Squeak's); once you change it to false, i.e. once you change the order ready processes are placed in the Processor's ready queue, it won't work; the preemption mode is critical in this case so I'll have to figure out how to make this work for Squeak :D Or better yet how to make it independent of the processPreemptionYields setting. <o:p> </o:p> <o:p> </o:p> To conclude: if you won't find some fatal flaw with this approach it seems to me it allows to run code fragments in the UI as usual but once a more complex scenario occurs, like a parallel process requesting a debugger, a new UI is created to take over so that the old UI process can continue executing its unfinished task without the need to act as a UI any longer (and will automatically terminate once it finishes its current cycle). <o:p> </o:p> Again, I'll very much appreciate any comments or suggestions you might have; thanks for your time and patience reading such long message :) <o:p> </o:p> Best, Jaromir <o:p> </o:p> -- Jaromír Matas<o:p></o:p> mail@jaromir.net <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:JuanVuletich@zoho.com">Juan Vuletich</a> Sent: Friday, July 15, 2022 1:26 To: <a href="mailto:cuis-dev@lists.cuis.st">Discussion of Cuis Smalltalk</a> Cc: <a href="mailto:JuanVuletich@zoho.com">Juan Vuletich</a>; <a href="mailto:mail@jaromir.net"> Jaromir Matas</a> Subject: Re: [Cuis-dev] FW: FW: FW: Freezing UI - can't interrupt via Alt+. </div> <o:p> </o:p> Hi Jaromir, On 7/14/2022 4:49 PM, Jaromir Matas via Cuis-dev wrote: <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <o:p></o:p> Hi Juan,<o:p></o:p> <o:p></o:p> Gosh, this is amazing! I couldn't wait to see :)<o:p></o:p> <o:p></o:p> I ran out of mean examples :D<o:p></o:p> </blockquote> Fun, Fun, Fun! <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> One observation though: Sometimes, although rarely and irregularly, this happens:<o:p></o:p> <o:p></o:p> I run an example (in the Workspace), e.g. this one:<o:p></o:p> <o:p></o:p> [1/0] fork.<o:p></o:p> 5 seconds asDelay wait.<o:p></o:p> self error: 'error'<o:p></o:p> <o:p></o:p> and then I move the first debugger window and close it before the 5 second delay expires and when the second debugger opens I get an MNU error concerning drawing - I'm enclosing a snip (if I knew how to file out the debugger's stack contents I'd send it too). And the next time you run the same example it may happen again or may not... Can't figure out any pattern except you have to move the first debugger window before closing it.<o:p></o:p> </blockquote> Oh, yes. Letting the old Morphic process end by itself may mean that there is more than one process trying to draw the world. And if some higher priority process wakes up, maybe the other morphic process is scheduled next. Just pushed a couple of tweaks to reduce the risk as much as possible. <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> --<o:p></o:p> One stupid question: How do you make the image download the latest changes you made at github? I thought this would work: World menu -> changes -> install new updates but it doesn't... Now I think it's maybe not supposed to download from github but just locally from the CoreUpdates folder... Is that so?<o:p></o:p> </blockquote> Yes. The base image doesn't even include networking code. It will only access local files. <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> What I do now (sorry if it sounds too stupid) is I download a new image which contains the latest changes in the CoreUpdates folder already...<o:p></o:p> <o:p></o:p> The thing is I'm on Windows and don't do any git stuff or any command line stuff ;) Is there a way for users like me to update easily?<o:p></o:p> </blockquote> The alternative would be to grab the update files from github using the web browser. Could be even more tedious that grabbing a full zip file each time. The alternative is to use git, of course. I use git in Windows each time I save new Cuis images, as it is easier to run 32 bit systems than in Linux or MacOS. Just open the git bash and do git pull. Actually, I wouldn't be surprised if the Linux subsystem for Windows already includes git. <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> --<o:p></o:p> Well, actually, what would think about situations like this:<o:p></o:p> <o:p></o:p> [1/0] fork.<o:p></o:p> [ 10000 factorial. Processor yield ] repeat<o:p></o:p> <o:p></o:p> would you expect, or consider reasonable to expect, the UI to process the 1/0 exception during the long computation?<o:p></o:p> <o:p></o:p> I'd tend to say no but then when I look at this example:<o:p></o:p> <o:p></o:p> [1/0] fork.<o:p></o:p> [ 10000 factorial. 5 seconds asDelay wait ] repeat<o:p></o:p> <o:p></o:p> I'm not so sure... The delay blocks the UI and a thus a new UI is created etc. while in the former case yield just allows other processes of the same priority to run etc… which are implementation details… <o:p></o:p> <o:p></o:p> And if you run the former example forked:<o:p></o:p> <o:p></o:p> [[1/0] fork.<o:p></o:p> [ 10000 factorial. Processor yield ] repeat] fork<o:p></o:p> <o:p></o:p> You won’t be surprised the 1/0 exception is executed immediately after the first yield. Which leads me closer to expecting the 1/0 exception appear after the first yield even in the former example. I believe the computation’s result shouldn’t depend on whether it runs in the UI or not. <o:p> </o:p> <o:p></o:p> I'm curious to know your opinion.<o:p></o:p> <o:p></o:p> Many thanks,<o:p></o:p> jaromir<o:p></o:p> </blockquote> Interesting examples. I think there are arguments to support both sides. So, far, I'm OK with firing a new UI process if the current one is blocked, suspended or terminated. Likely the user is trying to recover control using cmd+. But starting a new UI process only because the current one is busy, is something that would require making all morphic fully multithreading. I don't think the complexity is worth, at least unless we see a "real world" need. If the programmer started a long computation in the UI process by mistake, they can cmd + . to recover control, and then try something better (perhaps fork the workload). If they did it on purpose, well, then they actually asked for the UI to be unresponsive during that time. If we changed this, not only the Morphic framework should be multithreading safe. Also all application code: Application level code could be busy updating data, while on a separate process the user tries to use it or modify it in some other way. We'd be forcing all app developers to be "parallel processing aware", even if they are writing simple code. I prefer to let those, willing to do heavy processing -and- have a responsive UI at the same time, find a suitable design. Hope this makes sense to you. Cheers! <o:p></o:p> <pre>-- </pre> <pre>Juan Vuletich</pre> <pre><a href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a></pre> <pre><a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a></pre> <pre><a href="https://github.com/jvuletich">https://github.com/jvuletich</a></pre> <pre><a href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a></pre> <pre><a href="https://independent.academia.edu/JuanVuletich">https://independent.academia.edu/JuanVuletich</a></pre> <pre><a href="https://www.researchgate.net/profile/Juan-Vuletich">https://www.researchgate.net/profile/Juan-Vuletich</a></pre> <pre><a href="https://patents.justia.com/inventor/juan-manuel-vuletich">https://patents.justia.com/inventor/juan-manuel-vuletich</a></pre> <pre><a href="https://twitter.com/JuanVuletich">https://twitter.com/JuanVuletich</a></pre> <o:p> </o:p> </div> </body> </html>