Hi Levente,
On Apr 2, 2017, at 11:46 AM, Levente Uzonyi leves@caesar.elte.hu 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.htm...
[2] > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193638.htm...
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
On Mon, Apr 3, 2017 at 11:39 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Levente,
On Apr 2, 2017, at 11:46 AM, Levente Uzonyi leves@caesar.elte.hu
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. https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/36
cheers -ben
Hi Eliot,
On Sun, 2 Apr 2017, Eliot Miranda wrote:
Hi Levente,
On Apr 2, 2017, at 11:46 AM, Levente Uzonyi leves@caesar.elte.hu 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.htm...
[2] > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193638.htm...
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
vm-dev@lists.squeakfoundation.org
-
Ben Coman -
Eliot Miranda -
Levente Uzonyi