Re: [squeak-dev] Should a long running image notice daylight saving?

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

Re: [squeak-dev] Should a long running image notice daylight saving?

Eliot Miranda-2
 
Hi Levente,

> On Apr 2, 2017, at 11:46 AM, Levente Uzonyi <[hidden email]> wrote:
>
> Hi Dave,
>
> As I mentioned before, the problem with that primitive is that it doesn't update the offset when the time zone changes.

Surely it would be easy to modify the heartbeat and/or the event checking code in the vm to do thus no?  My only questions are a) is this a better place than do it than in the image?  and b) who is volunteering to write and test the code?

> Here's an example from an image which was started in UTC+1, but is in UTC+2 right now:
>
> { Time primPosixMicrosecondClockWithOffset. Locale current primTimezone } "#(#(1491158588541139 3600) 120)"
>
> VM info:
> /squeak/products/cogspur64linuxht/lib/squeak/5.0-201609151123/squeak
> Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.1950]
> Unix built on Sep 15 2016 11:24:50 Compiler: 4.6.3
> platform sources revision VM: 201609151123 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Sep 15 13:23:12 2016 +0200 $ Plugins: 201609151123 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
> CoInterpreter VMMaker.oscog-eem.1950 uuid: b4089b49-1494-49d2-8966-57cba5c92194 Sep 15 2016
> StackToRegisterMappingCogit VMMaker.oscog-eem.1950 uuid: b4089b49-1494-49d2-8966-57cba5c92194 Sep 15 2016

Why are you used my such an ancient vm?  You know the new compactor tie appears that be fixed right?

[add smileys to taste; I do not intend to offend here]

>
> Levente
>
>> On Sun, 2 Apr 2017, David T. Lewis wrote:
>>
>> I think I'm getting myself confused with too many images with different
>> DateAndTime flavors. We already have primitiveLocalMicrosecondClock that
>> can be called with primLocalMicrosecondClock, which hopefully does the
>> same thing as my snippet below.
>>
>> Dave
>>
>>
>>> On Sun, Apr 02, 2017 at 10:48:00AM -0400, David T. Lewis wrote:
>>> Or do it like this, which does not require LocalePlugin:
>>>
>>>  localMicrosecondClockDave
>>>      | timeArray |
>>>      timeArray := self primPosixMicrosecondClockWithOffset.
>>>      ^timeArray first + ((2177452800 + timeArray second) * 1000000).
>>> Dave
>>> On Sun, Apr 02, 2017 at 02:08:07PM +0200, Levente Uzonyi wrote:
>>> > Hi Herbert,
>>> > > This issue was discussed[1] here recently. I suggested[2] a VM change to > solve this problem, but the same thing can be done on the image side too.
>>> > Just change Time class >> #utcMicrosecondClockWithOffset to be:
>>> > > utcMicrosecondClockWithOffset
>>> >    "Answer an array with UTC microseconds since the Smalltalk epoch and >    the
>>> >    current seconds offset from UTC in the local time zone."
>>> > >    | utc currentMinute |
>>> >    utc := self utcMicrosecondClock.
>>> >    currentMinute := utc // 60000000.
>>> >    LastTimeTimeZoneWasUpdated = currentMinute ifFalse: [
>>> >        LastTimeTimeZoneWasUpdated := currentMinute.
>>> >        TimeZoneOffset := Locale current primTimezone * 60 ].
>>> >    ^{ utc. TimeZoneOffset }
>>> > > and Time class >> #localMicrosecondClock to be:
>>> > > localMicrosecondClock
>>> >    "Answer the local microseconds since the Smalltalk epoch (January >    1st 1901, the start of the 20th century).
>>> >     The value is derived from the current UTC wallclock time and the >     image's current notion of time zone."
>>> > >    | utcMicrosecondClockWithOffset |
>>> >    utcMicrosecondClockWithOffset := self utcMicrosecondClockWithOffset.
>>> >    ^(utcMicrosecondClockWithOffset at: 2) * 1000000 + >    (utcMicrosecondClockWithOffset at: 1)
>>> > > > LastTimeTimeZoneWasUpdated and TimeZoneOffset should be class variables. > They don't have to be initialized.
>>> > > Levente
>>> > > [1] > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193594.html
>>> > [2] > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193638.html
>>> > > On Sun, 2 Apr 2017, Herbert K?nig wrote:
>>> > > >Hi all,
>>> > >
>>> > >I have a long running 5.1 image on a Raspi A+ which regularly waits on a > >Delay.
>>> > >
>>> > >Raspbian has noticed daylight saving, Squeak not.
>>> > >
>>> > >Is this expected and what can I do with the running image to make it > >notice? Except waiting for the monthly crash and restart :-)
>>> > >
>>> > >
>>> > >Cheers,
>>> > >
>>> > >Herbert
>>> > >
>>> > >
>>> > >
>>> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Should a long running image notice daylight saving?

Ben Coman
 


On Mon, Apr 3, 2017 at 11:39 AM, Eliot Miranda <[hidden email]> wrote:

Hi Levente,

> On Apr 2, 2017, at 11:46 AM, Levente Uzonyi <[hidden email]> wrote:
>
> Hi Dave,
>
> As I mentioned before, the problem with that primitive is that it doesn't update the offset when the time zone changes.

Surely it would be easy to modify the heartbeat and/or the event checking code in the vm to do thus no?  My only questions are a) is this a better place than do it than in the image?  and b) who is volunteering to write and test the code?

I logged the following issue intending to work on the VM clock, but I got distracted learning more about the VM and trying to use Clang via UFFI to analyse the cross platform differences.  I mean to get back to it, but anyone can feel free to preempt me.

cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Should a long running image notice daylight saving?

Levente Uzonyi
In reply to this post by Eliot Miranda-2
 
Hi Eliot,

On Sun, 2 Apr 2017, Eliot Miranda wrote:

>
> Hi Levente,
>
>> On Apr 2, 2017, at 11:46 AM, Levente Uzonyi <[hidden email]> wrote:
>>
>> Hi Dave,
>>
>> As I mentioned before, the problem with that primitive is that it doesn't update the offset when the time zone changes.
>
> Surely it would be easy to modify the heartbeat and/or the event checking code in the vm to do thus no?  My only questions are a) is this a better place than do it than in the image?  and b) who is volunteering to write and test the code?

I still think that the mechanism I described in this thread (and the
previous thread) should be implemented in primitive 241 and
primitiveUtcWithOffset unless there's an event-based mechanism provided by
the OS.

>
>> Here's an example from an image which was started in UTC+1, but is in UTC+2 right now:
>>
>> { Time primPosixMicrosecondClockWithOffset. Locale current primTimezone } "#(#(1491158588541139 3600) 120)"
>>
>> VM info:
>> /squeak/products/cogspur64linuxht/lib/squeak/5.0-201609151123/squeak
>> Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.1950]
>> Unix built on Sep 15 2016 11:24:50 Compiler: 4.6.3
>> platform sources revision VM: 201609151123 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Sep 15 13:23:12 2016 +0200 $ Plugins: 201609151123 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
>> CoInterpreter VMMaker.oscog-eem.1950 uuid: b4089b49-1494-49d2-8966-57cba5c92194 Sep 15 2016
>> StackToRegisterMappingCogit VMMaker.oscog-eem.1950 uuid: b4089b49-1494-49d2-8966-57cba5c92194 Sep 15 2016
>
> Why are you used my such an ancient vm?  You know the new compactor tie appears that be fixed right?

It's running on a server, and it works, so I'd rather not restart it.

Levente

>
> [add smileys to taste; I do not intend to offend here]
>>
>> Levente
>>
>>> On Sun, 2 Apr 2017, David T. Lewis wrote:
>>>
>>> I think I'm getting myself confused with too many images with different
>>> DateAndTime flavors. We already have primitiveLocalMicrosecondClock that
>>> can be called with primLocalMicrosecondClock, which hopefully does the
>>> same thing as my snippet below.
>>>
>>> Dave
>>>
>>>
>>>> On Sun, Apr 02, 2017 at 10:48:00AM -0400, David T. Lewis wrote:
>>>> Or do it like this, which does not require LocalePlugin:
>>>>
>>>>  localMicrosecondClockDave
>>>>      | timeArray |
>>>>      timeArray := self primPosixMicrosecondClockWithOffset.
>>>>      ^timeArray first + ((2177452800 + timeArray second) * 1000000).
>>>> Dave
>>>> On Sun, Apr 02, 2017 at 02:08:07PM +0200, Levente Uzonyi wrote:
>>>> > Hi Herbert,
>>>> > > This issue was discussed[1] here recently. I suggested[2] a VM change to > solve this problem, but the same thing can be done on the image side too.
>>>> > Just change Time class >> #utcMicrosecondClockWithOffset to be:
>>>> > > utcMicrosecondClockWithOffset
>>>> >    "Answer an array with UTC microseconds since the Smalltalk epoch and >    the
>>>> >    current seconds offset from UTC in the local time zone."
>>>> > >    | utc currentMinute |
>>>> >    utc := self utcMicrosecondClock.
>>>> >    currentMinute := utc // 60000000.
>>>> >    LastTimeTimeZoneWasUpdated = currentMinute ifFalse: [
>>>> >        LastTimeTimeZoneWasUpdated := currentMinute.
>>>> >        TimeZoneOffset := Locale current primTimezone * 60 ].
>>>> >    ^{ utc. TimeZoneOffset }
>>>> > > and Time class >> #localMicrosecondClock to be:
>>>> > > localMicrosecondClock
>>>> >    "Answer the local microseconds since the Smalltalk epoch (January >    1st 1901, the start of the 20th century).
>>>> >     The value is derived from the current UTC wallclock time and the >     image's current notion of time zone."
>>>> > >    | utcMicrosecondClockWithOffset |
>>>> >    utcMicrosecondClockWithOffset := self utcMicrosecondClockWithOffset.
>>>> >    ^(utcMicrosecondClockWithOffset at: 2) * 1000000 + >    (utcMicrosecondClockWithOffset at: 1)
>>>> > > > LastTimeTimeZoneWasUpdated and TimeZoneOffset should be class variables. > They don't have to be initialized.
>>>> > > Levente
>>>> > > [1] > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193594.html
>>>> > [2] > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193638.html
>>>> > > On Sun, 2 Apr 2017, Herbert K?nig wrote:
>>>> > > >Hi all,
>>>> > >
>>>> > >I have a long running 5.1 image on a Raspi A+ which regularly waits on a > >Delay.
>>>> > >
>>>> > >Raspbian has noticed daylight saving, Squeak not.
>>>> > >
>>>> > >Is this expected and what can I do with the running image to make it > >notice? Except waiting for the monthly crash and restart :-)
>>>> > >
>>>> > >
>>>> > >Cheers,
>>>> > >
>>>> > >Herbert
>>>> > >
>>>> > >
>>>> > >
>>>> >
>>