On Mon, May 26, 2014 at 02:17:47PM +0000, J. Vuletich (mail lists) wrote: > Hi David, Folks, > > Quoting "David T. Lewis" <[hidden email]>: > > >I have been working on a variation of class DateAndTime that replaces its > >instance variables (seconds offset jdn nanos) with two instance variables, > >utcMicroseconds to represent microseconds elapsed since the Posix epoch, > >and > >localOffsetSeconds to represent the local time zone offset. When > >instantiating > >the time now, A single call primitiveUtcWithOffset is used to obtain these > >two values atomically as reported by the underlying platform. > > > >There are several advantages to this representation of DateAndTime, the > >most > >important of which is that its magnitude is unambiguous regardless > >of daylight > >savings transitions in local time zones. > > > >This is my attempt to address some historical baggage in Squeak. The VM > >reports time related to the local time zone, and the image attempts to > >convert to UTC (sometimes incorrectly). A UTC based representation makes > >the > >implementation of time zone tables more straightforward (see for example > >the Olson time zone tables in TimeZoneDatabase on SqueakMap). > >... > >Dave > > I very much support this approach. I did a bit of testing of > <primitive: 'primitiveUtcWithOffset'> . I found that on a Mac, with > 'Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.331] Squeak > Cog 4.0.2776' 'Mac OS' 'intel' '1092' (from Eliot's site), the second > element I get (time zone offset) is -140473411. > > The correct value would be -10800, as answered in Windows. I could not > test on Linux yet (could not get the vm to run in Ubuntu 14.04 64 bit > :( ). > > Any clue on what's wrong on Mac OS? > > BTW, which would be the current non-Cog VMs to try? > Oops, I mistakenly said that the Cog VMs could be used. But it looks like there is a regression or code merge problem of some sort. I'm afraid that I was testing with my own locally compiled Cog VM and did not notice the problem. A unix Mac VM from squeakvm.org/unix should demonstrate the correct behavior. CC to vm-dev list: Eliot, the fix for this was here (but it seems to have been overridden by a more recent change): Name: VMMaker.oscog-dtl.286 Author: dtl Time: 4 May 2013, 11:29:25.237 am UUID: 8be237d9-7812-4792-9723-90f9cff0c2e9 Ancestors: VMMaker.oscog-eem.285 Replace broken primitiveUtcWithOffset with a version that works. Dave |
Quoting "David T. Lewis" <[hidden email]>: > On Mon, May 26, 2014 at 02:17:47PM +0000, J. Vuletich (mail lists) wrote: >> Hi David, Folks, >> ... >> The correct value would be -10800, as answered in Windows. I could not >> test on Linux yet (could not get the vm to run in Ubuntu 14.04 64 bit >> :( ). >> >> Any clue on what's wrong on Mac OS? >> >> BTW, which would be the current non-Cog VMs to try? >> > > Oops, I mistakenly said that the Cog VMs could be used. But it looks like > there is a regression or code merge problem of some sort. I'm afraid that > I was testing with my own locally compiled Cog VM and did not notice the > problem. > > A unix Mac VM from squeakvm.org/unix should demonstrate the correct behavior. > > CC to vm-dev list: > > Eliot, the fix for this was here (but it seems to have been overridden by > a more recent change): > > Name: VMMaker.oscog-dtl.286 > Author: dtl > Time: 4 May 2013, 11:29:25.237 am > UUID: 8be237d9-7812-4792-9723-90f9cff0c2e9 > Ancestors: VMMaker.oscog-eem.285 > > Replace broken primitiveUtcWithOffset with a version that works. > > Dave Thanks Dave, I could run on 64 bits Ubuntu with the VM from squeakvm.org/unix. I'll try the Mac VM when I get the chance to borrow a Mac again. One thing that seems to be missing is a Windows interpreter with the new primitives, although I don't know if there is a real need for that. Additionally, besides getting rid of <primitive: 137> (primLocalSecondsClock that will overflow in 2037), it would be great to stop using <primitive: 135> (primLocalSecondsClock), that overflows every six days. But for this, we would need a new <primitive: 136> (primSignal:atMilliseconds:) as it uses on the same time base. This would enable a serious simplification of Delay. Cheers, Juan Vuletich |
Quoting "David T. Lewis" <[hidden email]>: > ... >> > > Ian did a build of the Windows VM that should have the necessary support. Try > the Squeak4.1.2.2612 VM from http://squeakvm.org/win32/. That VM fails for <primitive: 'primitiveUtcWithOffset'> <primitive: 240> primUtcMicrosecondClock <primitive: 241> primLocalMicrosecondClock > One thing to note - if the primitive is not present, DateAndTime will fall > back on the old logic, and it should produce reasonable results. Yes, Cuis already does that... I'd prefer to be able to assume that any future VM will provide <primitive: 'primitiveUtcWithOffset'> and clean the code. Would that asking for too much? >> Additionally, besides getting rid of <primitive: 137> >> (primLocalSecondsClock that will overflow in 2037), it would be great >> to stop using <primitive: 135> (primLocalSecondsClock), that overflows >> every six days. But for this, we would need a new <primitive: 136> >> (primSignal:atMilliseconds:) as it uses on the same time base. This >> would enable a serious simplification of Delay. >> > > I think that Eliot is planning to update Squeak to use the microsecond clock > primitive, which removes any 2037 issues. I'm not sure if that would include > a change to primSignal:atMilliseconds: > > Dave I see. But given that the Delay code is fragile and not trivial at all, the advantages of of relying on a clock that never rolls over would be significant. Please, Eliot, consider this when you work on this code. Cheers, Juan Vuletich |
On Mon, May 26, 2014 at 06:16:03PM +0000, J. Vuletich (mail lists) wrote: > > Quoting "David T. Lewis" <[hidden email]>: > > >... > >> > > > >Ian did a build of the Windows VM that should have the necessary support. > >Try > >the Squeak4.1.2.2612 VM from http://squeakvm.org/win32/. > > That VM fails for > <primitive: 'primitiveUtcWithOffset'> > <primitive: 240> primUtcMicrosecondClock > <primitive: 241> primLocalMicrosecondClock > > >One thing to note - if the primitive is not present, DateAndTime will fall > >back on the old logic, and it should produce reasonable results. > > Yes, Cuis already does that... I'd prefer to be able to assume that > any future VM will provide <primitive: 'primitiveUtcWithOffset'> and > clean the code. Would that asking for too much? You should expect the following two primitives to be present in all VMs (comments are from the VMM trunk implementations): primitiveUtcWithOffset "Answer an array with UTC microseconds since the Posix epoch and the current seconds offset from GMT in the local time zone. An empty two element array may be supplied as a parameter. This is a named (not numbered) primitive in the null module (ie the VM)" primitiveUTCMicrosecondClock "Answer the UTC microseconds since the Smalltalk epoch. The value is derived from the Posix epoch (see primitiveUTCMicrosecondClock) with a constant offset corresponding to elapsed microseconds between the two epochs according to RFC 868." Dave > > >>Additionally, besides getting rid of <primitive: 137> > >>(primLocalSecondsClock that will overflow in 2037), it would be great > >>to stop using <primitive: 135> (primLocalSecondsClock), that overflows > >>every six days. But for this, we would need a new <primitive: 136> > >>(primSignal:atMilliseconds:) as it uses on the same time base. This > >>would enable a serious simplification of Delay. > >> > > > >I think that Eliot is planning to update Squeak to use the microsecond > >clock > >primitive, which removes any 2037 issues. I'm not sure if that would > >include > >a change to primSignal:atMilliseconds: > > > >Dave > > I see. But given that the Delay code is fragile and not trivial at > all, the advantages of of relying on a clock that never rolls over > would be significant. > > Please, Eliot, consider this when you work on this code. > > > Cheers, > Juan Vuletich > |
David T. Lewis wrote: Since both answer microseconds, then second seems a little confusing. Calling them something like #primitivePosixUtcWithOffset and #primitiveSmalltalkUtc seems more intention revealing.On Mon, May 26, 2014 at 06:16:03PM +0000, J. Vuletich (mail lists) wrote:Quoting "David T. Lewis" [hidden email]:...Ian did a build of the Windows VM that should have the necessary support. Try the Squeak4.1.2.2612 VM from http://squeakvm.org/win32/.That VM fails for <primitive: 'primitiveUtcWithOffset'> <primitive: 240> primUtcMicrosecondClock <primitive: 241> primLocalMicrosecondClockOne thing to note - if the primitive is not present, DateAndTime will fall back on the old logic, and it should produce reasonable results.Yes, Cuis already does that... I'd prefer to be able to assume that any future VM will provide <primitive: 'primitiveUtcWithOffset'> and clean the code. Would that asking for too much?You should expect the following two primitives to be present in all VMs (comments are from the VMM trunk implementations): primitiveUtcWithOffset "Answer an array with UTC microseconds since the Posix epoch and the current seconds offset from GMT in the local time zone. An empty two element array may be supplied as a parameter. This is a named (not numbered) primitive in the null module (ie the VM)" primitiveUTCMicrosecondClock "Answer the UTC microseconds since the Smalltalk epoch. The value is derived from the Posix epoch (see primitiveUTCMicrosecondClock) with a constant offset corresponding to elapsed microseconds between the two epochs according to RFC 868." cheers -ben |
On Wed, May 28, 2014 at 08:46:08PM +0800, Ben Coman wrote: > >> You should expect the following two primitives to be present in all VMs >> (comments are from the VMM trunk implementations): >> >> primitiveUtcWithOffset >> "Answer an array with UTC microseconds since the Posix epoch and >> the current seconds offset from GMT in the local time zone. An empty >> two element array may be supplied as a parameter. >> This is a named (not numbered) primitive in the null module (ie the VM)" >> >> primitiveUTCMicrosecondClock >> "Answer the UTC microseconds since the Smalltalk epoch. The value is >> derived from the Posix epoch (see primitiveUTCMicrosecondClock) with a >> constant offset corresponding to elapsed microseconds between the two >> epochs according to RFC 868." >> > > > Since both answer microseconds, then second seems a little confusing. > Calling them something like #primitivePosixUtcWithOffset and > #primitiveSmalltalkUtc seems more intention revealing. > > cheers -ben > That's a good suggestion. We could probably rename them now without any ill effects. Eliot, do you have a preference? Dave |
Free forum by Nabble | Edit this page |