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 >>> > > >>> > > >>> > > >>> > > |
On Mon, Apr 3, 2017 at 11:39 AM, Eliot Miranda <[hidden email]> wrote:
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 |
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 >>>> > > >>>> > > >>>> > > >>>> > >> |
Free forum by Nabble | Edit this page |