David T. Lewis wrote:
On Mon, Apr 16, 2007 at 04:42:25PM -0700, Andreas Raab wrote:
I have been experimenting with this idea recently and the bottom line is that all you *really* need is access to the millisecond clock primitive (for Delay and friends). Pretty much everything else can be built on top of that without access to more elaborate Date and Time classes. Moving #millisecondClockValue into, say, Delay would make a great starting point to rip out all of the Chronology classes for a minimal image.
This is true if and only if the millisecond clock is a monotonically increasing function. That is not the case for the Squeak VM, which presents a "local time" version of the clock. Thus for example durations that cross daylight savings time transitions are problematic. If we change to a millisecond clock that represents UTC time rather than local time, then you are absolutely right.
I'm not getting your point. Why is having a monotonically increasing msecs clock a requirement? What I meant to say is that the only dependency I can't think to get rid of is the millisecond clock and only because it's tied so intrinsically to Delay which itself is tied intrinsically to Semaphore and Process. Which, even for a minimal image, you probably can't get rid of ;-) But it seems to me that whether the msecs clock is monotonically increasing or not is independent of that.
Cheers, - Andreas