[Cuis-dev] FW: FW: FW: Freezing UI - can't interrupt via Alt+.

[Juan Vuletich]

Hi Jaromir,

On 7/14/2022 4:49 PM, Jaromir Matas via Cuis-dev wrote:
>
> Hi Juan,
>
> Gosh, this is amazing! I couldn't wait to see :)
>
> I ran out of mean examples :D
>

Fun, Fun, Fun!

> One observation though: Sometimes, although rarely and irregularly, 
> this happens:
>
> I run an example (in the Workspace), e.g. this one:
>
> [1/0] fork.
>
> 5 seconds asDelay wait.
>
> self error: 'error'
>
> 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.
>

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.

> --
>
> 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?
>

Yes. The base image doesn't even include networking code. It will only 
access local files.

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

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.

> --
>
> Well, actually, what would think about situations like this:
>
> [1/0] fork.
>
> [ 10000 factorial. Processor yield ] repeat
>
> would you expect, or consider reasonable to expect, the UI to process 
> the 1/0 exception during the long computation?
>
> I'd tend to say no but then when I look at this example:
>
> [1/0] fork.
>
> [ 10000 factorial. 5 seconds asDelay wait ] repeat
>
> 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…
>
> And if you run the former example forked:
>
> [[1/0] fork.
>
> [ 10000 factorial. Processor yield ] repeat] fork
>
> 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.
>
> I'm curious to know your opinion.
>
> Many thanks,
>
> jaromir
>

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!

-- 
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
https://twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220714/20dbea2d/attachment.htm>