On Tue, Aug 24, 2010 at 09:43:54AM -0700, Eliot Miranda wrote:
Hi David,
On Tue, Aug 24, 2010 at 5:24 AM, David T. Lewis lewis@mail.msen.com wrote:
Eliot,
I am afraid that I may have misunderstood your original request to retract the change.
I assumed that you were refering to Time class>>primUtcWithOffset that I had added to trunk (and I did remove that method), but in rereading your note I think you may have been referring to the earlier VMMaker updates that introduced the primitives #primitiveMicrosecondClock and #primitiveUtcWithOffset. In particular, #primitiveMicrosecondClock seems similar to the Cog primitives, which include #primitiveUTCMicrosecondClock and #primitiveLocalMicrosecondClock.
Apologies for my misunderstanding, but can you please clarify which methods you were suggesting should be retracted?
Interpreter>>primitiveMicrosecondClock Interpreter>>primitiveUtcWithOffset Time class>>primMicrosecondClock Time class>>primUtcWithOffset
If primitiveMicrosecondClock answers 64-bit UTC microseconds since 1901 this is the same as Cog's primitiveUTCMicrosecondClock and should be retained.
primitiveMicrosecondClock is like primitiveMillisecondClock in that it answers a value that rolls over periodically, and it not a measure of duration relative to any epoch. The extra precision is of course meaningless for any individual call, but apparently is of value when taken cumulatively for purposes of profiling. I will have to defer to John as to whether it can or should be replaced by primitiveUTCMicrosecondClock.
In any case, the meanings of primitiveMicrosecondClock and primitiveUTCMicrosecondClock are different, and I should think that they could safely coexist as long as we give them detailed method comments to explain the time basis for each.
As long as you have no objection, I strongly prefer to retain primitiveUtcWithOffset in its current form, regardless of whether it actually gets used for anything near term. It's something that Lex Spoon proposed ten years ago and it's near and dear to my heart after my experience implementing the TimeZoneDatabase.
I note that I should change the primitive name in SqueakVM from "primitiveUtcWithOffset" to "primitiveUTCWithOffset" for consistency.
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).
OK. And I would see no reason not to add these to the traditional SqueakVM as well. If you have specific suggestions as to which of the new Cog primitives should go into SqueakVM for consistency, that would help. I am assuming that at some point we want the Squeak trunk to start making use of the new Cog primitives, and that therefore they should also made available in the traditional SqueakVM.
We then need to agree on some primitive numbers or primitive names. In Cog these three are
(240 primitiveUTCMicrosecondClock) "was serial port primitive" (241 primitiveLocalMicrosecondClock) "was serial port primitive" (242 primitiveSignalAtUTCMicroseconds)
Cog also has (243 primitiveUpdateTimezone) "primStringtranslatefromtotable"
primitiveUpdateTimezone "Update the VMs notion of the current timezone. The VM sets its notion of the timezone once at start-up. If one wants the VM to keep its notion up-to-date arrange to invoke this primitive periodically." self ioUpdateVMTimezone
which causes the VM to reevaluate the delta between UTC and local microseconds.
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.
At this point, primitiveMicrosecondClock and primitiveUtcWithOffset are not numbered primitives, and I see no need for them to be numbered. As far as I know, no one else has plans to consume additional primitive numbers, so we are following your lead with respect to assigning primitive numbers (and I should update the SqueakVM table accordingly).
Thanks, Dave