On 13 April 2013 09:13, Levente Uzonyi <leves@elte.hu> wrote:
On Sat, 13 Apr 2013, Igor Stasenko wrote:
On 12 April 2013 23:47, Norbert Hartl <norbert@hartl.name> wrote:
Am 12.04.2013 um 23:23 schrieb Igor Stasenko <siguctua@gmail.com>:
On 12 April 2013 23:14, phil@highoctane.be <phil@highoctane.be> wrote:
+1. No clue either. But discovered the terminate process shortcut to kill them faster...
Coping over solving ...
One of the "solutions" i proposed is to rewrite the code and get rid of "nano-second" """"synchronization""" of date and time with system clock because a) there is no real users of it (to my knowledge) b) you cannot have precision higher than precision of system primitive we're using, which is in millisecond range..
Where do you see a nanosecond synchronization? It is still millisecond clock as far as I can see. Only the instVar is called nanos.
Ah, sorry.. i mistaken by some orders of magnitude. ;)
The offending code starts from here:
initializeOffsets | durationSinceEpoch secondsSinceMidnight nowSecs | LastTick := 0. nowSecs := self clock secondsWhenClockTicks. LastMilliSeconds := self millisecondClockValue. durationSinceEpoch := Duration days: SqueakEpoch hours: 0 minutes: 0 seconds: nowSecs. DaysSinceEpoch := durationSinceEpoch days. secondsSinceMidnight := (durationSinceEpoch - (Duration days: DaysSinceEpoch hours: 0 minutes: 0 seconds: 0)) asSeconds. MilliSecondOffset := secondsSinceMidnight * 1000 - LastMilliSeconds
(notice that 1000 multiplier, which gives us "nanosecond" precision)
But that's fine.. now look at
secondsWhenClockTicks
"waits for the moment when a new second begins"
| lastSecond |
lastSecond := self primSecondsClock. [ lastSecond = self primSecondsClock ] whileTrue: [ (Delay forMilliseconds: 1) wait ].
^ lastSecond + 1
that is complete nonsense. Sorry.
This code relying on primSecondsClock resolution, which is..... (drum roll..... ) 1 second..
then it is combined with millisecondClockValue , as you see later to get system time with millisecond precision..
I am not genius in math and physics.. but even i understand that if you measurement has error X you cannot get more precision than X, even if you combine it with another measurement with higher precision.
(But i can be wrong with that.. if so, please explain why)
(1 to: 10) collect: [ :e | Time secondsWhenClockTicks. [ Time secondsWhenClockTicks ] timeToRun ]. "==> #(1000 1000 1000 1000 1000 1000 1000 1000 1000 1000)"
It seems like the resolution is 1 seconds, but the accuracy is 1 millisecond or smaller. Which means that the code will give you a millisecond resolution timestamp.
Both #timeToRun and secondsWhenClockTicks (via Delay) using same primitive - #millisecondClockValue. Sure thing, precision of this primitive should be it is 1 millisecond or smaller.. But it has nothing to do with precision of primSecondsClock and you cannot increase precision of it using #millisecondClockValue. Because this code: [ lastSecond = self primSecondsClock ] whileTrue: [ (Delay forMilliseconds: 1) wait ]. actually means: [ lastSecond = self primSecondsClock ] whileTrue: [ block not less than 1 ms ]. but not: [ lastSecond = self primSecondsClock ] whileTrue: [ block exactly 1 ms ]. the upper bound of "(Delay forMilliseconds: 1) wait" is undefined.. and you know it well.
About DateAndTime: having it nanosecond resolution is a future proof idea. It will take a while till software can create better accuracy timestamps. Reducing the resolution to milliseconds is a very bad idea. The VM and external software can give you a microsecond or smaller resolution timestamp which you want to represent as DateAndTime (or whatever class you use to create a timestamp) in the image.
Yes i know. My problem is the amount of code which does something "userful" with nanoseconds while everybody knows that we have no such resolution.. and won't have in 10 years or so.
Levente
-- Best regards, Igor Stasenko.