Latest Changes in InputSensor/EventSensor "lock up" image after save/restart?

Hi, there!

I cannot use mouse or keyboard anymore after saving and re-opening the image. CMD+. works but this is implemented via a semaphore.

Any ideas? I am on a Windows machine.

Best,
Marcel

Ouch. Whatever the problem is, I'm pretty sure it is my fault.

I did the updates on a Linux platform. But I do not see anything at
all in the original InputSensor or EventSensor that should be platform
dependent.

The updates for InputSensor removal require class initialize methods.
The most likely explanation is that I screwed something up in the update
maps when I moved these changes from inbox to trunk.

The updates involved in InputSensor removal are Kernel-dtl.981, Kernel-dtl.982,
Kernel-dtl.983, Kernel-dtl.984, and Kernel-dtl.985.

The related update maps are update-dtl.346.mcm, update-dtl.347.mcm, and
update-dtl.348.mcm.

My apologies for the disruption, and I hope to have fix soon. Meanwhile
if someone can confirm the problem on a non-Windows platform, I would
appreciate it (I really do not think it is anything related to Windows
but I could be wrong).

Dave


On Wed, Feb 03, 2016 at 10:04:29PM +0100, karl ramberg wrote:
>

> On 03-02-2016, at 7:19 PM, David T. Lewis <[hidden email]> wrote:
>
> Ouch. Whatever the problem is, I'm pretty sure it is my fault.
>
> I did the updates on a Linux platform. But I do not see anything at
> all in the original InputSensor or EventSensor that should be platform
> dependent.

The updates loaded ok on my iMac running a Squeak Cog Spur 5.0.3427 vm. The image restarted ok after a save/quit.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Can't program his way out of a for-loop.

I think that EventSensor class >> #startUp crashes:



Best,
Marcel

Ah, forget it. That suspended UI process has been there before.

Best,
Marcel

Hi David,

You forgot to migrate the new startUp/shutdown code.

Find attached a change set: fix-event-sensor.cs

Best,
Marcel

Hi David,

there was another issue. The EventSensor >> #shutDown code was never called.

fix-event-sensor.2.cs

Nevertheless, the main issue was not initializing the input semaphore in EventSensor >> #startUp. Which raises the question why Mac VMs can sill use the "old way" of fetching events? Windows VMs cannot.

Best,
Marcel

They can, I think, but AFAICT they aren’t, since the fallback code in primGetNextEvent: is not invoked. Guess the VM’s event handling is just a bit more lenient ...

This fixes the double interrupt when pressing cmd-.

Btw, did anyone notice that window dragging is a lot slower in 5.0 compared to 4.6? Both with fastDragWindowForMorphic enabled and disabled. Which points to the VM bundled in the All-in-One.

- Bert -

Hi Marcel,

Thanks /very/ much for finding the fix for this. I'm not sure how I screwed
up that startup code migration, my apologies for the errors.

I just applied your two change sets on Linux and it is good there, so I am
sure that it will be good on OS X also. That covers all the main platforms.

I would be grateful if you can commit the Kernel update to trunk. Otherwise
I will do it about 12 hours from now (I'm tied up with some other issues until
then and I don't want to risk breaking anything else in trunk until then).

Regarding the Windows difference, my guess is that the primitive fallback
code is refering to some old primitives that may have been removed from the
Windows VM but are still present in the Unix and Mac VMs. The references
to old primitives are now in method categories 'primitive-fallback', and
possibly 'primitives-cursor'.

Thank you!

Dave


On Thu, Feb 04, 2016 at 03:48:24AM -0800, marcel.taeumel wrote:

Hi Dave,

okay, I just committed the fix: http://forum.world.st/The-Trunk-Kernel-mt-987-mcz-td4875804.html

Best,
Marcel