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

Fri Jul 15 11:26:11 PDT 2022

Sorry, here’s the snip…

From: Jaromir Matas via Cuis-dev<mailto:cuis-dev at lists.cuis.st>
Sent: Friday, July 15, 2022 20:24
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] FW: FW: FW: Freezing UI - can't interrupt via Alt+.

Hi Juan,

Many thanks for sharing your opinion. I agree a UI busy with a long computation is a bit different situation (and complexity level most likely) than an idle UI being blocked. I'm thrilled you've made it possible for a system to keep interacting even if its UI is blocked on a semaphore (or a condition variable in a general case). I think this is a very nice improvement from a user perspective; I remember it baffled me some computations worked differently when run forked compared to "straight" (without fork). Then someone explained "yeah, that's because it is run in the UI" and it really didn't help me understand why the difference :) Now I know, of course, but for a beginner (or at least for me) the concept of running a Workspace example "in the UI" is far from trivial.

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

Thank you :)

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

That helped indeed :) A little new glitch appeared though:
When you do
self halt
the world redraw's incomplete or something - see attached snip. Clicking World Menu -> Restore Display fixes it.

--
A small suggestion: the old UI process still identifies as 'Morhic UI' in the Process Browser; would it make sense to rename the old UI to e.g. 'Inactive Morphic UI' ?

--
Then there's something I believe has nothing to do with the latest UI modifications but I only noticed it recently by accident:
If you open an image and then open the same image again (to be precise: in my case I doubleclick on squeak.exe, the image opens, then I doubleclick squeak.exe again) then the second OS process starts running in the background taking 100% of one CPU's core capacity (and nothing opens) and it needs to be killed from the OS (Windows process explorer etc)
It happens in my image Cuis6.0.5171 with the latest VM 3184 but doesn't in Cuis6.0.5069 with VM 3184 (I've just checked - it's regardless of the VM)

Juan, thanks so much for this experience! I look forward to studying your code :)
best,
Jaromir

--

Jaromír Matas

mail at jaromir.net

From: Juan Vuletich<mailto:JuanVuletich at zoho.com>
Sent: Friday, July 15, 2022 1:26
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] FW: FW: FW: Freezing UI - can't interrupt via Alt+.

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

https://twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220715/8915b1cb/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drawing glitch after self halt.png
Type: image/png
Size: 110030 bytes
Desc: drawing glitch after self halt.png
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220715/8915b1cb/attachment-0001.png>