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

[Jaromir Matas]

Hi Juan,

Thanks very much, all works great; I love you added the states of the processes to the Process Browser - it's so convenient to see right away what is active, what is suspended etc...

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

> Has any other dialect in the Squeak family already fixed this?

Squeak and Pharo simply open the same image as read-only and notify the user... For me it's just a reminder I opened a wrong image and close it. It took a me a while to realize in Cuis there's something invisible running in the background when I by accident opened the same image twice. Now that I know it doesn't bother me; so I'm just reporting :)

Thanks again; it's a real joy to try concurrent prcesses examples in Cuis now :D
Best,

--

Jaromír Matas

mail at jaromir.net

From: Juan Vuletich<mailto:JuanVuletich at zoho.com>
Sent: Monday, July 18, 2022 21:44
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/15/2022 3:24 PM, Jaromir Matas via Cuis-dev wrote:
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.

:) You already contributed lots of stuff that are not "beginner level" at all!



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

Fixed. Now at GitHub.




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

Fixed too.




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

Truth is that I don't know how to do this in a reliable and portable way. Has any other dialect in the Squeak family already fixed this?


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


--

Jaromír Matas

mail at jaromir.net<mailto:mail at jaromir.net>


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/20220718/1efde0e5/attachment-0001.htm>