Quoting "David T. Lewis" lewis@mail.msen.com:
...
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" lewis@mail.msen.com:
...
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
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
vm-dev@lists.squeakfoundation.org
-
Ben Coman -
David T. Lewis -
J. Vuletich (mail lists)