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

[Juan Vuletich]

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

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/20220718/f52ea121/attachment.htm>