Adjusting Morphic Alarm Times

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Adjusting Morphic Alarm Times

marcel.taeumel
Hi, there!

There is this method WorldState >> #adjustAlarmTimes: to correct larger drifts between the nowTime and the lastAlarmTime. A check and this correction is performed in every world cycle.

Here is, where it works fine:
1. You set an alarm to go off in 5 seconds.
2. You immediately close the Squeak image.
3. You wait a minute.
4. You open Squeak again.
5. You wait 5 seconds.
6. Alarm goes off.

I think we can agree that a closed Squeak image freezes all Morphic behavior.

Now, here is, where it seems annoying:
1. You set an alarm to go off in 5 seconds.
2. You immediately start a longer running operation from the workspace in the UI process.
3. You wait that operation to complete. Maybe some minutes.
4. You still have to wait 5 seconds.
5. Alarm goes off.

This is not acceptable. Think of larger alarm delays. We cannot just ignore the fact that time has passed while working inside the image. It think we should only adjust alarm times when:

- Starting a Squeak image.
- Entering a Morphic project.

Because in both cases, the respective Morphic world freezed. Any thoughts on this?

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: Adjusting Morphic Alarm Times

Chris Muller-3
That sounds logical to me.  It makes me curious, though, what is the
purpose of doing this adjustment in the first place?  For in case the
image was exited and restarted later?  If only for that, then on every
world cycle seems unnecessarily inefficient..

On Fri, Apr 8, 2016 at 11:37 AM, marcel.taeumel <[hidden email]> wrote:

> Hi, there!
>
> There is this method WorldState >> #adjustAlarmTimes: to correct larger
> drifts between the nowTime and the lastAlarmTime. A check and this
> correction is performed in *every *world cycle.
>
> Here is, where it works fine:
> 1. You set an alarm to go off in 5 seconds.
> 2. You immediately close the Squeak image.
> 3. You wait a minute.
> 4. You open Squeak again.
> 5. You wait 5 seconds.
> 6. Alarm goes off.
>
> I think we can agree that a closed Squeak image freezes all Morphic
> behavior.
>
> Now, here is, where it seems annoying:
> 1. You set an alarm to go off in 5 seconds.
> 2. You immediately start a longer running operation from the workspace in
> the UI process.
> 3. You wait that operation to complete. Maybe some minutes.
> *4. You still have to wait 5 seconds.*
> 5. Alarm goes off.
>
> This is not acceptable. Think of larger alarm delays. We cannot just ignore
> the fact that time has passed while working inside the image. It think we
> should only adjust alarm times when:
>
> - Starting a Squeak image.
> - Entering a Morphic project.
>
> Because in both cases, the respective Morphic world freezed. Any thoughts on
> this?
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/Adjusting-Morphic-Alarm-Times-tp4889145.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: Adjusting Morphic Alarm Times

marcel.taeumel
Hi Chris,

according to the method comment, this was the purpose:

"Adjust the alarm times after some clock weirdness (such as roll-over, image-startup etc)"

Does "Time millisecondClockValue" has time zone in it?
What happes to alarms if we switch from summer to winter time while using Squeak?

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: Adjusting Morphic Alarm Times

marcel.taeumel
In reply to this post by Chris Muller-3
Hi, there!

That adjustment is only done if necessary:

World >> #triggerAlarmsBefore:
   ...
   (nowTime < lastAlarmTime or:[nowTime - lastAlarmTime > 10000])
                ifTrue:[self adjustAlarmTimes: nowTime].
   ...

That 10 seconds is suspicious, too.

Best,
Marcel