Time primitives
Locked
12
12
 
|
Hi All,
CogVM has two really nice time primitives 240 and 241. These are available via Time class >> #primUTCMicrosecondClock and Time class >> #primLocalMicrosecondClock. But there are two problems with them. 1. They are not available in the Interpreter VM (It has a similar named primitive - primitiveUtcWithOffset - available as Time class >> #primPosixMicrosecondClockWithOffset, but that's not supported in Cog, and I'd like to see its behavior changed slightly*) 2. Primitive 240 is available in Pharo under a similar, but slightly different name: #primUTCMicrosecondsClock. There are also derived "primitive" methods: #primUTCSecondsClock and #primUTCMillisecondsClock. Questions: - Which name should we use? - #primUTCMicrosecondClock - #primUTCMicrosecondsClock - something else - Can/should the interpreter VM support primitive 240 and 241? - Can/should CogVM support the name primitive primitiveUtcWithOffset? - Do we want the derived "primitives" #primUTCSecondsClock and #primUTCMillisecondsClock in Squeak? Levente * The primitive could accept an array as argument and fill that with the values if present. This could prevent frequent GCs when the primitive is used repeatedly. |
|
|
I am away and cannot double check the code right now, but the primitives
should be consistent across Cog and the interpreter VM. There had been some confusion due to the early fork between trunk and oscog, but I believe that Eliot and I got it sorted out quite a while ago. These are not necessarily set up as numbered primitives, but the implementations are there, and they can be called as named primitives in Cog/Spur and interpreter VMs. I don't know about the Pharo fork, it's quite possible that things have gotten renamed there. Note, the UTC with offset primitive is important to me because of UTCDateAndTime (http://wiki.squeak.org/squeak/6197), which is designed around the notion of a single primitive answering UTC time and local offset as an atomic call to the VM. Dave > Hi All, > > CogVM has two really nice time primitives 240 and 241. These are available > via Time class >> #primUTCMicrosecondClock and Time class >> > #primLocalMicrosecondClock. > > But there are two problems with them. > 1. They are not available in the Interpreter VM (It has a similar named > primitive - primitiveUtcWithOffset - available as Time class >> > #primPosixMicrosecondClockWithOffset, but that's not supported in Cog, and > I'd like to see its behavior changed slightly*) > 2. Primitive 240 is available in Pharo under a similar, but slightly > different name: #primUTCMicrosecondsClock. There are also derived > "primitive" methods: #primUTCSecondsClock and #primUTCMillisecondsClock. > > Questions: > - Which name should we use? > - #primUTCMicrosecondClock > - #primUTCMicrosecondsClock > - something else > > - Can/should the interpreter VM support primitive 240 and 241? > > - Can/should CogVM support the name primitive primitiveUtcWithOffset? > > - Do we want the derived "primitives" #primUTCSecondsClock and > #primUTCMillisecondsClock in Squeak? > > > Levente > > * The primitive could accept an array as argument and fill that with the > values if present. This could prevent frequent GCs when the primitive is > used repeatedly. > |
|
|
On Tue, 7 Apr 2015, David T. Lewis wrote:
> I am away and cannot double check the code right now, but the primitives > should be consistent across Cog and the interpreter VM. There had been > some confusion due to the early fork between trunk and oscog, but I > believe that Eliot and I got it sorted out quite a while ago. I can confirm this, but the primitives don't work correctly on the Interpreter VM (4.10.2.2614 on linux from squeakvm.org): Time primUTCMicrosecondClock. "==> 2177453298247316" Time primPosixMicrosecondClockWithOffset. "==> #(519745201 7200)" DateAndTime now. "==> 2015-04-07T23:30:28.665+01:00" The same with CogVM: Time primUTCMicrosecondClock. "==> 3605895086935548" Time primPosixMicrosecondClockWithOffset. "==> #(1428442289746346 7200)" DateAndTime now. "==> 2015-04-07T23:31:32.962+01:00" > > These are not necessarily set up as numbered primitives, but the > implementations are there, and they can be called as named primitives in > Cog/Spur and interpreter VMs. > > I don't know about the Pharo fork, it's quite possible that things have > gotten renamed there. The primitives are the same, but the method names in the image are not, and the latter is what matters for me. It's a pain to keep code running in both branches. > > Note, the UTC with offset primitive is important to me because of > UTCDateAndTime (http://wiki.squeak.org/squeak/6197), which is designed > around the notion of a single primitive answering UTC time and local > offset as an atomic call to the VM. It seems like this primitive caches the time zone offset, which is bad when there are daylight savings changes (or when the machine goes to a different time zone). Here's the current value from a long running image: Time primPosixMicrosecondClockWithOffset. "==> #(1428442620344927 3600)" But the LocalePlugin's primitives seem like they know the truth: Locale current primTimezone. "==> 120" Locale current primDST. "==> true" Levente > > Dave > >> Hi All, >> >> CogVM has two really nice time primitives 240 and 241. These are available >> via Time class >> #primUTCMicrosecondClock and Time class >> >> #primLocalMicrosecondClock. >> >> But there are two problems with them. >> 1. They are not available in the Interpreter VM (It has a similar named >> primitive - primitiveUtcWithOffset - available as Time class >> >> #primPosixMicrosecondClockWithOffset, but that's not supported in Cog, and >> I'd like to see its behavior changed slightly*) >> 2. Primitive 240 is available in Pharo under a similar, but slightly >> different name: #primUTCMicrosecondsClock. There are also derived >> "primitive" methods: #primUTCSecondsClock and #primUTCMillisecondsClock. >> >> Questions: >> - Which name should we use? >> - #primUTCMicrosecondClock >> - #primUTCMicrosecondsClock >> - something else >> >> - Can/should the interpreter VM support primitive 240 and 241? >> >> - Can/should CogVM support the name primitive primitiveUtcWithOffset? >> >> - Do we want the derived "primitives" #primUTCSecondsClock and >> #primUTCMillisecondsClock in Squeak? >> >> >> Levente >> >> * The primitive could accept an array as argument and fill that with the >> values if present. This could prevent frequent GCs when the primitive is >> used repeatedly. >> > > > > |
|
|
On Tue, Apr 07, 2015 at 11:42:21PM +0200, Levente Uzonyi wrote:
> On Tue, 7 Apr 2015, David T. Lewis wrote: > > >I am away and cannot double check the code right now, but the primitives > >should be consistent across Cog and the interpreter VM. There had been > >some confusion due to the early fork between trunk and oscog, but I > >believe that Eliot and I got it sorted out quite a while ago. > > I can confirm this, but the primitives don't work correctly on the > Interpreter VM (4.10.2.2614 on linux from squeakvm.org): > > Time primUTCMicrosecondClock. "==> 2177453298247316" > Time primPosixMicrosecondClockWithOffset. "==> #(519745201 7200)" > DateAndTime now. "==> 2015-04-07T23:30:28.665+01:00" > > The same with CogVM: > > Time primUTCMicrosecondClock. "==> 3605895086935548" > Time primPosixMicrosecondClockWithOffset. "==> #(1428442289746346 7200)" > DateAndTime now. "==> 2015-04-07T23:31:32.962+01:00" > Why do you think this is wrong? I suspect that the one hour time zone offset in your image is not in agreement with the three hour offset that your operating system is reporting. The difference in absolute microseconds is due to different origins in the time scale. Eliot's primitive used the Smalltalk epoch UTC as its origin, and mine used Posix. Neither is wrong. > > > >These are not necessarily set up as numbered primitives, but the > >implementations are there, and they can be called as named primitives in > >Cog/Spur and interpreter VMs. > > > >I don't know about the Pharo fork, it's quite possible that things have > >gotten renamed there. > > The primitives are the same, but the method names in the image are not, > and the latter is what matters for me. It's a pain to keep code running in > both branches. > > > > >Note, the UTC with offset primitive is important to me because of > >UTCDateAndTime (http://wiki.squeak.org/squeak/6197), which is designed > >around the notion of a single primitive answering UTC time and local > >offset as an atomic call to the VM. > > It seems like this primitive caches the time zone offset, which is bad > when there are daylight savings changes (or when the machine goes to a > different time zone). Here's the current value from a long running image: > > Time primPosixMicrosecondClockWithOffset. "==> #(1428442620344927 3600)" > > But the LocalePlugin's primitives seem like they know the truth: > > Locale current primTimezone. "==> 120" > Locale current primDST. "==> true" > If you are suggesting that the handling of time zones in the various images is less than perfect, then I will be the first to agree with you. But I don't think that the primitives are wrong. We have this primitive: InterpreterPrimitives>>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)" And the unix platforms sources implement it like this (with ifdefs removed for clarity): sqInt sqUnixUtcWithOffset(sqLong *microSeconds, int *offset) { struct timeval timeval; if (gettimeofday(&timeval, NULL) == -1) return -1; time_t seconds= timeval.tv_sec; suseconds_t usec= timeval.tv_usec; *microSeconds= seconds * 1000000 + usec; *offset= localtime(&seconds)->tm_gmtoff; return 0; } So the operating system is telling you its best estimate of the current time in microseconds since the Posix epoch, as well as the local time zone offset in seconds at the time of the call. This is a single gettimeofday() call to the platform runtime library, which is about as close as we can get to a coherent result on general purpose unix systems. Dave |
|
|
Hi David,
named primitives have overhead that numbered ones don't. Given the importance if time prims can we not have the Cog numbered prims in the interpreter? Eliot (phone) On Apr 7, 2015, at 6:10 PM, "David T. Lewis" <[hidden email]> wrote: > On Tue, Apr 07, 2015 at 11:42:21PM +0200, Levente Uzonyi wrote: >> On Tue, 7 Apr 2015, David T. Lewis wrote: >> >>> I am away and cannot double check the code right now, but the primitives >>> should be consistent across Cog and the interpreter VM. There had been >>> some confusion due to the early fork between trunk and oscog, but I >>> believe that Eliot and I got it sorted out quite a while ago. >> >> I can confirm this, but the primitives don't work correctly on the >> Interpreter VM (4.10.2.2614 on linux from squeakvm.org): >> >> Time primUTCMicrosecondClock. "==> 2177453298247316" >> Time primPosixMicrosecondClockWithOffset. "==> #(519745201 7200)" >> DateAndTime now. "==> 2015-04-07T23:30:28.665+01:00" >> >> The same with CogVM: >> >> Time primUTCMicrosecondClock. "==> 3605895086935548" >> Time primPosixMicrosecondClockWithOffset. "==> #(1428442289746346 7200)" >> DateAndTime now. "==> 2015-04-07T23:31:32.962+01:00" > > Why do you think this is wrong? I suspect that the one hour time zone > offset in your image is not in agreement with the three hour offset that > your operating system is reporting. The difference in absolute microseconds > is due to different origins in the time scale. Eliot's primitive used the > Smalltalk epoch UTC as its origin, and mine used Posix. Neither is wrong. > >>> >>> These are not necessarily set up as numbered primitives, but the >>> implementations are there, and they can be called as named primitives in >>> Cog/Spur and interpreter VMs. >>> >>> I don't know about the Pharo fork, it's quite possible that things have >>> gotten renamed there. >> >> The primitives are the same, but the method names in the image are not, >> and the latter is what matters for me. It's a pain to keep code running in >> both branches. >> >>> >>> Note, the UTC with offset primitive is important to me because of >>> UTCDateAndTime (http://wiki.squeak.org/squeak/6197), which is designed >>> around the notion of a single primitive answering UTC time and local >>> offset as an atomic call to the VM. >> >> It seems like this primitive caches the time zone offset, which is bad >> when there are daylight savings changes (or when the machine goes to a >> different time zone). Here's the current value from a long running image: >> >> Time primPosixMicrosecondClockWithOffset. "==> #(1428442620344927 3600)" >> >> But the LocalePlugin's primitives seem like they know the truth: >> >> Locale current primTimezone. "==> 120" >> Locale current primDST. "==> true" > > If you are suggesting that the handling of time zones in the various images > is less than perfect, then I will be the first to agree with you. But I don't > think that the primitives are wrong. > > We have this primitive: > > InterpreterPrimitives>>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)" > > And the unix platforms sources implement it like this (with ifdefs removed > for clarity): > > sqInt sqUnixUtcWithOffset(sqLong *microSeconds, int *offset) > { > struct timeval timeval; > if (gettimeofday(&timeval, NULL) == -1) return -1; > time_t seconds= timeval.tv_sec; > suseconds_t usec= timeval.tv_usec; > *microSeconds= seconds * 1000000 + usec; > *offset= localtime(&seconds)->tm_gmtoff; > return 0; > } > > So the operating system is telling you its best estimate of the current time > in microseconds since the Posix epoch, as well as the local time zone offset > in seconds at the time of the call. This is a single gettimeofday() call to > the platform runtime library, which is about as close as we can get to a > coherent result on general purpose unix systems. > > Dave > > |
|
|
On 07-04-2015, at 6:21 PM, Eliot Miranda <[hidden email]> wrote: > named primitives have overhead that numbered ones don't. I *thought* I’d fixed that back around ’04 by caching the actual address ? Always possible I didn’t get it right, of course. I do seem to remember some pretty good performance improvements as a result of the changes. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: FA: Failsafe Armed |
|
|
In reply to this post by Eliot Miranda-2
Hi Eliot,
In trunk Interpreter>>initializePrimitiveTable we currently have: (240 primitiveUTCMicrosecondClock) "was serial port primitive" (241 primitiveLocalMicrosecondClock) "was serial port primitive" I think these are the primitives that you wanted to have numbered. Please let me know if I missed some others. Note - I have never suggested adding #primitiveUtcWithOffset because I cannot see any performance impact beyond the initial symbol lookups, so I'm quite happy to leave it as a named primitive. Dave On Tue, Apr 07, 2015 at 06:21:19PM -0700, Eliot Miranda wrote: > Hi David, > > named primitives have overhead that numbered ones don't. Given the importance if time prims can we not have the Cog numbered prims in the interpreter? > > Eliot (phone) > > On Apr 7, 2015, at 6:10 PM, "David T. Lewis" <[hidden email]> wrote: > > > On Tue, Apr 07, 2015 at 11:42:21PM +0200, Levente Uzonyi wrote: > >> On Tue, 7 Apr 2015, David T. Lewis wrote: > >> > >>> I am away and cannot double check the code right now, but the primitives > >>> should be consistent across Cog and the interpreter VM. There had been > >>> some confusion due to the early fork between trunk and oscog, but I > >>> believe that Eliot and I got it sorted out quite a while ago. > >> > >> I can confirm this, but the primitives don't work correctly on the > >> Interpreter VM (4.10.2.2614 on linux from squeakvm.org): > >> > >> Time primUTCMicrosecondClock. "==> 2177453298247316" > >> Time primPosixMicrosecondClockWithOffset. "==> #(519745201 7200)" > >> DateAndTime now. "==> 2015-04-07T23:30:28.665+01:00" > >> > >> The same with CogVM: > >> > >> Time primUTCMicrosecondClock. "==> 3605895086935548" > >> Time primPosixMicrosecondClockWithOffset. "==> #(1428442289746346 7200)" > >> DateAndTime now. "==> 2015-04-07T23:31:32.962+01:00" > > > > Why do you think this is wrong? I suspect that the one hour time zone > > offset in your image is not in agreement with the three hour offset that > > your operating system is reporting. The difference in absolute microseconds > > is due to different origins in the time scale. Eliot's primitive used the > > Smalltalk epoch UTC as its origin, and mine used Posix. Neither is wrong. > > > >>> > >>> These are not necessarily set up as numbered primitives, but the > >>> implementations are there, and they can be called as named primitives in > >>> Cog/Spur and interpreter VMs. > >>> > >>> I don't know about the Pharo fork, it's quite possible that things have > >>> gotten renamed there. > >> > >> The primitives are the same, but the method names in the image are not, > >> and the latter is what matters for me. It's a pain to keep code running in > >> both branches. > >> > >>> > >>> Note, the UTC with offset primitive is important to me because of > >>> UTCDateAndTime (http://wiki.squeak.org/squeak/6197), which is designed > >>> around the notion of a single primitive answering UTC time and local > >>> offset as an atomic call to the VM. > >> > >> It seems like this primitive caches the time zone offset, which is bad > >> when there are daylight savings changes (or when the machine goes to a > >> different time zone). Here's the current value from a long running image: > >> > >> Time primPosixMicrosecondClockWithOffset. "==> #(1428442620344927 3600)" > >> > >> But the LocalePlugin's primitives seem like they know the truth: > >> > >> Locale current primTimezone. "==> 120" > >> Locale current primDST. "==> true" > > > > If you are suggesting that the handling of time zones in the various images > > is less than perfect, then I will be the first to agree with you. But I don't > > think that the primitives are wrong. > > > > We have this primitive: > > > > InterpreterPrimitives>>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)" > > > > And the unix platforms sources implement it like this (with ifdefs removed > > for clarity): > > > > sqInt sqUnixUtcWithOffset(sqLong *microSeconds, int *offset) > > { > > struct timeval timeval; > > if (gettimeofday(&timeval, NULL) == -1) return -1; > > time_t seconds= timeval.tv_sec; > > suseconds_t usec= timeval.tv_usec; > > *microSeconds= seconds * 1000000 + usec; > > *offset= localtime(&seconds)->tm_gmtoff; > > return 0; > > } > > > > So the operating system is telling you its best estimate of the current time > > in microseconds since the Posix epoch, as well as the local time zone offset > > in seconds at the time of the call. This is a single gettimeofday() call to > > the platform runtime library, which is about as close as we can get to a > > coherent result on general purpose unix systems. > > > > Dave > > > > |
|
|
In reply to this post by timrowledge
On Tue, Apr 07, 2015 at 06:30:36PM -0700, tim Rowledge wrote:
> > On 07-04-2015, at 6:21 PM, Eliot Miranda <[hidden email]> wrote: > > named primitives have overhead that numbered ones don't. > > I *thought* I?d fixed that back around ?04 by caching the actual address ? Always possible I didn?t get it right, of course. I do seem to remember some pretty good performance improvements as a result of the changes. > Tim, As far as I can tell, your fixes work fine and there is essentially no performance difference between named and numbered primitives once the function address has been loaded. So for a frequently used primitive, there is no difference at all. I am using UTCDateAndTime in my working images, so #primitiveUtcWithOffset is used heavily as a named primitive. Overall this much faster (and better in various other ways) than the standard Squeak Chronology implemention. I have not actually tried running it with a numbered primitive, but I see no reason to think that we would get additional performance out of adding #primitiveUtcWithOffset to the primitive table. My working assumption is that numbered primitives should be defined only for the absolutely essential primitives needed to bootstrap on a new platform, and that everything else should be a named primitive. Dave |
|
|
On 07-04-2015, at 7:08 PM, David T. Lewis <[hidden email]> wrote: > As far as I can tell, your fixes work fine and there is essentially no performance > difference between named and numbered primitives once the function address has > been loaded. So for a frequently used primitive, there is no difference at all. Good; that was the intention! > > > My working assumption is that numbered primitives should be defined only for > the absolutely essential primitives needed to bootstrap on a new platform, > and that everything else should be a named primitive. I’m for that. I’ve occasionally stared meaningfully off into the distance musing about how one might have no numbered prims at all. Usually, falling over ends the recursion I get stuck in. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim granary - old folks home |
|
|
In reply to this post by timrowledge
Tim,
that fix is fine as far as it goes. I'm talking about the Cogit's assumption that named primitives may call back imply that there is overhead in jitted code. You remember the sideways call that's necessary? I want the numbered prim for that. Eliot (phone) On Apr 7, 2015, at 6:30 PM, tim Rowledge <[hidden email]> wrote: > > On 07-04-2015, at 6:21 PM, Eliot Miranda <[hidden email]> wrote: >> named primitives have overhead that numbered ones don't. > > I *thought* I’d fixed that back around ’04 by caching the actual address ? Always possible I didn’t get it right, of course. I do seem to remember some pretty good performance improvements as a result of the changes. > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Strange OpCodes: FA: Failsafe Armed > > > |
|
|
In reply to this post by David T. Lewis
Hi David,
that's great. That's what I want to see. Thx! Eliot (phone) On Apr 7, 2015, at 6:51 PM, "David T. Lewis" <[hidden email]> wrote: > Hi Eliot, > > In trunk Interpreter>>initializePrimitiveTable we currently have: > > (240 primitiveUTCMicrosecondClock) "was serial port primitive" > (241 primitiveLocalMicrosecondClock) "was serial port primitive" > > I think these are the primitives that you wanted to have numbered. Please > let me know if I missed some others. > > Note - I have never suggested adding #primitiveUtcWithOffset because I cannot > see any performance impact beyond the initial symbol lookups, so I'm quite > happy to leave it as a named primitive. > > Dave > > On Tue, Apr 07, 2015 at 06:21:19PM -0700, Eliot Miranda wrote: >> Hi David, >> >> named primitives have overhead that numbered ones don't. Given the importance if time prims can we not have the Cog numbered prims in the interpreter? >> >> Eliot (phone) >> >> On Apr 7, 2015, at 6:10 PM, "David T. Lewis" <[hidden email]> wrote: >> >>> On Tue, Apr 07, 2015 at 11:42:21PM +0200, Levente Uzonyi wrote: >>>> On Tue, 7 Apr 2015, David T. Lewis wrote: >>>> >>>>> I am away and cannot double check the code right now, but the primitives >>>>> should be consistent across Cog and the interpreter VM. There had been >>>>> some confusion due to the early fork between trunk and oscog, but I >>>>> believe that Eliot and I got it sorted out quite a while ago. >>>> >>>> I can confirm this, but the primitives don't work correctly on the >>>> Interpreter VM (4.10.2.2614 on linux from squeakvm.org): >>>> >>>> Time primUTCMicrosecondClock. "==> 2177453298247316" >>>> Time primPosixMicrosecondClockWithOffset. "==> #(519745201 7200)" >>>> DateAndTime now. "==> 2015-04-07T23:30:28.665+01:00" >>>> >>>> The same with CogVM: >>>> >>>> Time primUTCMicrosecondClock. "==> 3605895086935548" >>>> Time primPosixMicrosecondClockWithOffset. "==> #(1428442289746346 7200)" >>>> DateAndTime now. "==> 2015-04-07T23:31:32.962+01:00" >>> >>> Why do you think this is wrong? I suspect that the one hour time zone >>> offset in your image is not in agreement with the three hour offset that >>> your operating system is reporting. The difference in absolute microseconds >>> is due to different origins in the time scale. Eliot's primitive used the >>> Smalltalk epoch UTC as its origin, and mine used Posix. Neither is wrong. >>> >>>>> >>>>> These are not necessarily set up as numbered primitives, but the >>>>> implementations are there, and they can be called as named primitives in >>>>> Cog/Spur and interpreter VMs. >>>>> >>>>> I don't know about the Pharo fork, it's quite possible that things have >>>>> gotten renamed there. >>>> >>>> The primitives are the same, but the method names in the image are not, >>>> and the latter is what matters for me. It's a pain to keep code running in >>>> both branches. >>>> >>>>> >>>>> Note, the UTC with offset primitive is important to me because of >>>>> UTCDateAndTime (http://wiki.squeak.org/squeak/6197), which is designed >>>>> around the notion of a single primitive answering UTC time and local >>>>> offset as an atomic call to the VM. >>>> >>>> It seems like this primitive caches the time zone offset, which is bad >>>> when there are daylight savings changes (or when the machine goes to a >>>> different time zone). Here's the current value from a long running image: >>>> >>>> Time primPosixMicrosecondClockWithOffset. "==> #(1428442620344927 3600)" >>>> >>>> But the LocalePlugin's primitives seem like they know the truth: >>>> >>>> Locale current primTimezone. "==> 120" >>>> Locale current primDST. "==> true" >>> >>> If you are suggesting that the handling of time zones in the various images >>> is less than perfect, then I will be the first to agree with you. But I don't >>> think that the primitives are wrong. >>> >>> We have this primitive: >>> >>> InterpreterPrimitives>>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)" >>> >>> And the unix platforms sources implement it like this (with ifdefs removed >>> for clarity): >>> >>> sqInt sqUnixUtcWithOffset(sqLong *microSeconds, int *offset) >>> { >>> struct timeval timeval; >>> if (gettimeofday(&timeval, NULL) == -1) return -1; >>> time_t seconds= timeval.tv_sec; >>> suseconds_t usec= timeval.tv_usec; >>> *microSeconds= seconds * 1000000 + usec; >>> *offset= localtime(&seconds)->tm_gmtoff; >>> return 0; >>> } >>> >>> So the operating system is telling you its best estimate of the current time >>> in microseconds since the Posix epoch, as well as the local time zone offset >>> in seconds at the time of the call. This is a single gettimeofday() call to >>> the platform runtime library, which is about as close as we can get to a >>> coherent result on general purpose unix systems. >>> >>> Dave > |
|
|
In reply to this post by David T. Lewis
On Tue, 7 Apr 2015, David T. Lewis wrote:
> On Tue, Apr 07, 2015 at 11:42:21PM +0200, Levente Uzonyi wrote: >> On Tue, 7 Apr 2015, David T. Lewis wrote: >> >>> I am away and cannot double check the code right now, but the primitives >>> should be consistent across Cog and the interpreter VM. There had been >>> some confusion due to the early fork between trunk and oscog, but I >>> believe that Eliot and I got it sorted out quite a while ago. >> >> I can confirm this, but the primitives don't work correctly on the >> Interpreter VM (4.10.2.2614 on linux from squeakvm.org): >> >> Time primUTCMicrosecondClock. "==> 2177453298247316" >> Time primPosixMicrosecondClockWithOffset. "==> #(519745201 7200)" >> DateAndTime now. "==> 2015-04-07T23:30:28.665+01:00" >> >> The same with CogVM: >> >> Time primUTCMicrosecondClock. "==> 3605895086935548" >> Time primPosixMicrosecondClockWithOffset. "==> #(1428442289746346 7200)" >> DateAndTime now. "==> 2015-04-07T23:31:32.962+01:00" >> > > Why do you think this is wrong? I suspect that the one hour time zone Let me reorder the lines to show the actual problems: Time primUTCMicrosecondClock. "==> 2177453298247316" Time primUTCMicrosecondClock. "==> 3605895086935548" The value from the Interpreter VM (first line) is significantly smaller than the value from Cog. The former can't be right. Time primPosixMicrosecondClockWithOffset. "==> #(519745201 7200)" Time primPosixMicrosecondClockWithOffset. "==> #(1428442289746346 7200)" Same here. The microseconds value from the Interpreter VM (first line) is way smaller than what it should be. DateAndTime now. "==> 2015-04-07T23:30:28.665+01:00" DateAndTime now. "==> 2015-04-07T23:31:32.962+01:00" Both values are in the CET(+1) time zone, but the actual time zone is CEST(+2). Both images were started in CEST. > offset in your image is not in agreement with the three hour offset that > your operating system is reporting. The difference in absolute microseconds > is due to different origins in the time scale. Eliot's primitive used the > Smalltalk epoch UTC as its origin, and mine used Posix. Neither is wrong. > >>> >>> These are not necessarily set up as numbered primitives, but the >>> implementations are there, and they can be called as named primitives in >>> Cog/Spur and interpreter VMs. >>> >>> I don't know about the Pharo fork, it's quite possible that things have >>> gotten renamed there. >> >> The primitives are the same, but the method names in the image are not, >> and the latter is what matters for me. It's a pain to keep code running in >> both branches. >> >>> >>> Note, the UTC with offset primitive is important to me because of >>> UTCDateAndTime (http://wiki.squeak.org/squeak/6197), which is designed >>> around the notion of a single primitive answering UTC time and local >>> offset as an atomic call to the VM. >> >> It seems like this primitive caches the time zone offset, which is bad >> when there are daylight savings changes (or when the machine goes to a >> different time zone). Here's the current value from a long running image: >> >> Time primPosixMicrosecondClockWithOffset. "==> #(1428442620344927 3600)" >> >> But the LocalePlugin's primitives seem like they know the truth: >> >> Locale current primTimezone. "==> 120" >> Locale current primDST. "==> true" >> > > If you are suggesting that the handling of time zones in the various images > is less than perfect, then I will be the first to agree with you. But I don't > think that the primitives are wrong. > > We have this primitive: > > InterpreterPrimitives>>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)" > > And the unix platforms sources implement it like this (with ifdefs removed > for clarity): > > sqInt sqUnixUtcWithOffset(sqLong *microSeconds, int *offset) > { > struct timeval timeval; > if (gettimeofday(&timeval, NULL) == -1) return -1; > time_t seconds= timeval.tv_sec; > suseconds_t usec= timeval.tv_usec; > *microSeconds= seconds * 1000000 + usec; > *offset= localtime(&seconds)->tm_gmtoff; > return 0; > } > > So the operating system is telling you its best estimate of the current time > in microseconds since the Posix epoch, as well as the local time zone offset > in seconds at the time of the call. This is a single gettimeofday() call to > the platform runtime library, which is about as close as we can get to a > coherent result on general purpose unix systems. I'm telling that the LocalePlugin can find out the correct time zone in case of DST changes, but it seems like gettimeofday() can't. Levente > > Dave > > > |
|
|
On 08.04.2015, at 10:33, Levente Uzonyi <[hidden email]> wrote:
> > DateAndTime now. "==> 2015-04-07T23:30:28.665+01:00" > DateAndTime now. "==> 2015-04-07T23:31:32.962+01:00" > > Both values are in the CET(+1) time zone, but the actual time zone is CEST(+2). Both images were started in CEST. Interesting. In an Etoys image on an Interpreter on Mac OS I get the right time zone: DateAndTime now ==>2015-04-08T10:49:33+02:00 That one uses LocalePlugin. Trunk image on Cog: DateAndTime now ==> 2015-04-08T10:48:38.991+01:00 > I'm telling that the LocalePlugin can find out the correct time zone in case of DST changes, but it seems like gettimeofday() can't. In Trunk, #useLocale is disabled (enabled in Etoys). Are we seriously all using +01:00 times, and still expecting users to set the right time zone manually?! - Bert - |
smime.p7s (5K) |
|
On Wed, Apr 08, 2015 at 10:56:13AM +0200, Bert Freudenberg wrote:
> On 08.04.2015, at 10:33, Levente Uzonyi <[hidden email]> wrote: > > > > DateAndTime now. "==> 2015-04-07T23:30:28.665+01:00" > > DateAndTime now. "==> 2015-04-07T23:31:32.962+01:00" > > > > Both values are in the CET(+1) time zone, but the actual time zone is CEST(+2). Both images were started in CEST. > > Interesting. In an Etoys image on an Interpreter on Mac OS I get the right time zone: > > DateAndTime now > ==>2015-04-08T10:49:33+02:00 > > That one uses LocalePlugin. > > Trunk image on Cog: > > DateAndTime now > ==> 2015-04-08T10:48:38.991+01:00 > > > I'm telling that the LocalePlugin can find out the correct time zone in case of DST changes, but it seems like gettimeofday() can't. > > In Trunk, #useLocale is disabled (enabled in Etoys). Are we seriously all using +01:00 times, and still expecting users to set the right time zone manually?! > That's a problem for sure, we should fix it in the upcoming release Dave |
|
|
In reply to this post by Levente Uzonyi-2
On Wed, Apr 08, 2015 at 10:33:45AM +0200, Levente Uzonyi wrote:
> On Tue, 7 Apr 2015, David T. Lewis wrote: > > >On Tue, Apr 07, 2015 at 11:42:21PM +0200, Levente Uzonyi wrote: > >>On Tue, 7 Apr 2015, David T. Lewis wrote: > >> > >>>I am away and cannot double check the code right now, but the primitives > >>>should be consistent across Cog and the interpreter VM. There had been > >>>some confusion due to the early fork between trunk and oscog, but I > >>>believe that Eliot and I got it sorted out quite a while ago. > >> > >>I can confirm this, but the primitives don't work correctly on the > >>Interpreter VM (4.10.2.2614 on linux from squeakvm.org): > >> > >>Time primUTCMicrosecondClock. "==> 2177453298247316" > >>Time primPosixMicrosecondClockWithOffset. "==> #(519745201 7200)" > >>DateAndTime now. "==> 2015-04-07T23:30:28.665+01:00" > >> > >>The same with CogVM: > >> > >>Time primUTCMicrosecondClock. "==> 3605895086935548" > >>Time primPosixMicrosecondClockWithOffset. "==> #(1428442289746346 7200)" > >>DateAndTime now. "==> 2015-04-07T23:31:32.962+01:00" > >> > > > >Why do you think this is wrong? I suspect that the one hour time zone > > Let me reorder the lines to show the actual problems: > > > Time primUTCMicrosecondClock. "==> 2177453298247316" > Time primUTCMicrosecondClock. "==> 3605895086935548" > > The value from the Interpreter VM (first line) is significantly smaller > than the value from Cog. The former can't be right. Ah sorry, I see it now. It must have been a problem in the interpreter VM as of 4.10.2-2614 that has long since been fixed. It is fine in any of the interpreter VMs that I am using now, but broken in 4.10.2-2614. So we need an update of the interpreter VM builds on squeakvm.org/unix. Dave |
|
|
In reply to this post by David T. Lewis
> On 08.04.2015, at 14:06, David T. Lewis <[hidden email]> wrote: > > On Wed, Apr 08, 2015 at 10:56:13AM +0200, Bert Freudenberg wrote: >> On 08.04.2015, at 10:33, Levente Uzonyi <[hidden email]> wrote: >>> >>> DateAndTime now. "==> 2015-04-07T23:30:28.665+01:00" >>> DateAndTime now. "==> 2015-04-07T23:31:32.962+01:00" >>> >>> Both values are in the CET(+1) time zone, but the actual time zone is CEST(+2). Both images were started in CEST. >> >> Interesting. In an Etoys image on an Interpreter on Mac OS I get the right time zone: >> >> DateAndTime now >> ==>2015-04-08T10:49:33+02:00 >> >> That one uses LocalePlugin. >> >> Trunk image on Cog: >> >> DateAndTime now >> ==> 2015-04-08T10:48:38.991+01:00 >> >>> I'm telling that the LocalePlugin can find out the correct time zone in case of DST changes, but it seems like gettimeofday() can't. >> >> In Trunk, #useLocale is disabled (enabled in Etoys). Are we seriously all using +01:00 times, and still expecting users to set the right time zone manually?! >> > > That's a problem for sure, we should fix it in the upcoming release > > Dave - Bert - |
|
|
On Thu, Apr 09, 2015 at 12:04:53PM +0200, Bert Freudenberg wrote:
> > On 08.04.2015, at 14:06, David T. Lewis <[hidden email]> wrote: > > On Wed, Apr 08, 2015 at 10:56:13AM +0200, Bert Freudenberg wrote: > >> > >> In Trunk, #useLocale is disabled (enabled in Etoys). Are we seriously all > >> using +01:00 times, and still expecting users to set the right time zone manually?! > > > > That's a problem for sure, we should fix it in the upcoming release > > So you're in a far away time zone, right? Why no, not at all. My time zone is right here in Michigan. It's all the rest of you that are far away ;-) > And yours still gets reported as +01:00? > Yes, that's right. With a SqueakTrunk image, I get this: DateAndTime now ==> 2015-04-09T19:52:01.01+01:00 But it should be this: DateAndTime now ==> 2015-04-09T19:52:01.01-04:00 If I enable the useLocale preference, I get the correct time zone offset: DateAndTime now ==> 2015-04-09T19:58:05.576-04:00 Dave |
|
|
On 09-04-2015, at 5:39 PM, David T. Lewis <[hidden email]> wrote: > > Why no, not at all. My time zone is right here in Michigan. It's all > the rest of you that are far away ;-) How are we going to deal with *my* TZ? Vancouver Island is 7 minutes and 50 years behind the mainland... tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: FR: Flip Record |
|
|
On Thu, Apr 09, 2015 at 07:52:41PM -0700, tim Rowledge wrote:
> > On 09-04-2015, at 5:39 PM, David T. Lewis <[hidden email]> wrote: > > > > Why no, not at all. My time zone is right here in Michigan. It's all > > the rest of you that are far away ;-) > > How are we going to deal with *my* TZ? Vancouver Island is 7 minutes and 50 years behind the mainland... We will need to add a preference for that. |
|
|
In reply to this post by timrowledge
Excerpts from tim Rowledge's message of 2015-04-10 04:52:41 +0200:
> > Why no, not at all. My time zone is right here in Michigan. It's all > > the rest of you that are far away ;-) > How are we going to deal with *my* TZ? Vancouver Island is 7 minutes and 50 years behind the mainland... well, unfortunately that means that you'll have to wait a few more years before you get to use smalltalk. but in the meantime you can try to call up alan kay and find out more details from his work: http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_I.html greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/ |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |