Hi David,<br><br><div class="gmail_quote">On Tue, Aug 24, 2010 at 5:24 AM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Eliot,<br>
<br>
I am afraid that I may have misunderstood your original request<br>
to retract the change.<br>
<br>
I assumed that you were refering to Time class>>primUtcWithOffset<br>
that I had added to trunk (and I did remove that method), but<br>
in rereading your note I think you may have been referring to<br>
the earlier VMMaker updates that introduced the primitives<br>
#primitiveMicrosecondClock and #primitiveUtcWithOffset. In<br>
particular, #primitiveMicrosecondClock seems similar to the<br>
Cog primitives, which include #primitiveUTCMicrosecondClock<br>
and #primitiveLocalMicrosecondClock.<br>
<br>
Apologies for my misunderstanding, but can you please clarify<br>
which methods you were suggesting should be retracted?<br>
<br>
Interpreter>>primitiveMicrosecondClock<br>
Interpreter>>primitiveUtcWithOffset<br>
Time class>>primMicrosecondClock<br>
Time class>>primUtcWithOffset<br></blockquote><div><br></div><div>If primitiveMicrosecondClock answers 64-bit UTC microseconds since 1901 this is the same as Cog's primitiveUTCMicrosecondClock and should be retained. It also needs a 64-bit local microseconds since 1901 which would be the same as Cog's primitiveLocalMicrosecondClock and a primitiveSignalAtUTCMicroseconds which is for 64-bit microseconds since 1901 what primitiveSignalAtMilliseconds is for 30-bit wrapping milliseconds (again see Cog). We then need to agree on some primitive numbers or primitive names. In Cog these three are</div>
<div><br></div><div><div><span class="Apple-tab-span" style="white-space:pre"> </span>(240 primitiveUTCMicrosecondClock)<span class="Apple-tab-span" style="white-space:pre"> </span>"was serial port primitive"</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>(241 primitiveLocalMicrosecondClock)<span class="Apple-tab-span" style="white-space:pre"> </span>"was serial port primitive"</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>(242 primitiveSignalAtUTCMicroseconds)</div>
<div><br></div><div>Cog also has</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>(243 primitiveUpdateTimezone) "primStringtranslatefromtotable"</div></div><div><br></div><div><div>primitiveUpdateTimezone</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>"Update the VMs notion of the current timezone. The VM sets its notion</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> of the timezone once at start-up. If one wants the VM to keep its notion</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span> up-to-date arrange to invoke this primitive periodically."</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>self ioUpdateVMTimezone</div>
</div><div><br></div><div>which causes the VM to reevaluate the delta between UTC and local microseconds.</div><div><br></div><div>With these four one has a non-wrapping synchronised timebase with potentially microsecond resolution that marries well with Squeak's 64-bit integer support. This approach worked very well for VisualWorks where we got rid of lots of customer problems every 49.7 days (2^32 milliseconds). There has been some concern expressed about the performance impact of long integers but at least in VW that simply wasn't an issue.</div>
<div><br></div><div>best</div><div>Eliot </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Thanks,<br>
Dave<br>
<div><div></div><div class="h5"><br>
<br>
On Mon, Aug 23, 2010 at 11:04:57AM -0700, Eliot Miranda wrote:<br>
><br>
> On Sun, Aug 22, 2010 at 7:39 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
><br>
> ><br>
> > Eliot,<br>
> ><br>
> > Yes, it can be retracted. I may not get to it for a few days so feel<br>
> > free to do so on my behalf. I introduced the change in trunk to put<br>
> > some visibility on the new primitives, which appears to have achieved<br>
> > the intended purpose ;)<br>
> ><br>
> > With respect to the Squeak epoch, we do have an issue that needs to<br>
> > be clarified. In the Squeak implementation, we have the 1901 epoch,<br>
> > but AFAIK there is no specification of the time zone in which the epoch<br>
> > is defined. In the Squeak implementation, local time has consistently<br>
> > been used in the platform interface, and the actual values of the<br>
> > Squeak clock for any real point in time are different depending on<br>
> > the time zone in which the image happens to be running.<br>
> ><br>
><br>
> It's implicit that it is GMT/UTC. So the Squeak epoch is the start of 1901<br>
> in Greenwich.<br>
><br>
> To put it another way, there is no such thing as "UTC & local<br>
> > microseconds from the Smalltalk epoch" unless there is a clearly<br>
> > defined transformation between the Smalltalk epoch and the posix<br>
> > epoch, and in practice (in Squeak at least) this is not the case.<br>
> > Midnight on January 1, 1901 in Palo Alto, California was a different<br>
> > point in time from midnight January 1, 1901 in London, and I cannot<br>
> > determine which of the two was the "real" Smalltalk epoch.<br>
> ><br>
><br>
> The latter is the only one that makes good sense.<br>
><br>
><br>
> > This begs the question of why, in implementing the interface to<br>
> > the underlying platform, we would *not* want use the posix epoch<br>
> > as a reference point. The Posix epoch is well defined, well documented,<br>
> > well understood, and easily translated to any existing definition of<br>
> > the Smalltalk epoch. In contrast, the Smalltalk epoch is ambiguously<br>
> > defined, poorly documented, and widely misunderstood.<br>
> ><br>
><br>
> I think its easy to fix; just define it to be the start of the 20th century<br>
> in UTC. That's what we did with VW and its easy to do with Squeak. For me<br>
> backwards compatibility pushes strongly for keeping with the Squeak epoch,<br>
> i.e. Time seconds = Time milliseconds / 1000000.<br>
><br>
> best,<br>
> Eliot<br>
><br>
><br>
> ><br>
> > Dave<br>
> ><br>
> > On Sat, Aug 14, 2010 at 05:28:28PM -0700, Eliot Miranda wrote:<br>
> > ><br>
> > > Hi David,<br>
> > ><br>
> > > any chance of getting you to retract this? The Cog VM has 64-bit UTC<br>
> > &<br>
> > > local microseconds from the Smalltalk epoch (1901), which are hence<br>
> > easier<br>
> > > to use as a basis for the Squeak clock and still last for ~ 54,000 years.<br>
> > > I'd like to see the Cog and standard VMs converge on a primitive set.<br>
> > This<br>
> > > is an issue for me since changing the epoch is, I think, an unnecessary<br>
> > > change.<br>
> > ><br>
> > > best<br>
> > > Eliot<br>
> > ><br>
> > > On Sat, Aug 14, 2010 at 4:55 PM, <<a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a>> wrote:<br>
> > ><br>
> > > > Changes to Trunk (<a href="http://source.squeak.org/trunk.html" target="_blank">http://source.squeak.org/trunk.html</a>) in the last 24<br>
> > > > hours:<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > <a href="http://lists.squeakfoundation.org/pipermail/packages/2010-August/003596.html" target="_blank">http://lists.squeakfoundation.org/pipermail/packages/2010-August/003596.html</a><br>
> > > ><br>
> > > > Name: Kernel-dtl.476<br>
> > > > Ancestors: Kernel-eem.475<br>
> > > ><br>
> > > > Add Time class>>primMicrosecondClock and Time class>>primUtcWithOffset<br>
> > for<br>
> > > > access to microsecond clock primitives available in newer Squeak VMs.<br>
> > > ><br>
> > > > primMicrosecondClock provides a system clock with nominal microsecond<br>
> > > > precision.<br>
> > > ><br>
> > > > primUtcWithOffset answers UTC time as microseconds since the Posix<br>
> > epoch<br>
> > > > and offset as seconds offset from GMT. The Squeak clock is<br>
> > traditionally<br>
> > > > implemented in terms of platform local time. Use of UTC time and offset<br>
> > is<br>
> > > > advantageous if time zones and daylight saving time offsets are to be<br>
> > > > considered.<br>
> > > ><br>
> > > > Example:<br>
> > > > { Time primMillisecondClock .<br>
> > > > Time primMicrosecondClock .<br>
> > > > Time primUtcWithOffset } ==> #(6932757 6932757830 #(1281815075538304<br>
> > > > -14400))<br>
> > > ><br>
> > > ><br>
> > > > =============================================<br>
> > > ><br>
> > > ><br>
> ><br>
> ><br>
<br>
</div></div></blockquote></div><br>