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. 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. Levente
c) i see it completely stupid to try to do magic tricks trying to be smart and squeeze more precision than underlying system can offer.
For that: i would use non-existing-yet primitive, lets say:
<primitive: 'NanoSecondSystemTimeFrom1Jan1900' module: ''>
and since this primitive fails, because it don't exists, the fallback will use old primitive which currently in VM..
because (repeating again) doing black magick and trickery in image buys us nothing and only serves as a source of bugs.
Can you explain where the black magic happens?
Sure. See initializeOffsets secondsWhenClockTicks and all of the users of LastMilliSeconds class var..
btw, did i mentioned, that if we get rid of that code, DateAndTime will no longer need startup? I am just amazed at the shitloads of code which doing this stuff.. and has nothing to do with correct/precise measurement of system date and time.
Sorry if it offends you or anyone else. As i said before, my attacks is always against bad code, never against people. I just saying how i feel when i see it.
I integrated the cuis changeset back then because I wanted something more fine grained than seconds. Do you think this is already black magic? I think we can make smaller slices today :) That it forces the whole DateAndTime in this precision is probably not necessary and I understand that Sven did his own timestamp. The same goes for timezones. Maybe we need more levels of features in the hierarchy. If the system (or any software) is not dependent on precision below a second it would be good to have such a coarse grained type at hand. But to have the possibility to have at least milliseconds I find important.
What is most funny was that TimeStamp simply erases nanoseconds back to ZERO.. But of course it does it in a very peculiar way, that you don't really understand what it is:
TimeStamp class>>current
| ts ticks | ts := super now.
ticks := ts ticks. ticks at: 3 put: 0. ts ticks: ticks offset: ts offset.
^ ts
instead of something like:
TimeStamp class>>current
^super now clearNanoseconds
That code, btw also offends me a lot , especially "ticks at: 3 put: 0."
My wild guess would be the startup initialization of DateAndTime. It takes quite while to do.
yes, you could call ~ 2^31 milliseconds delay wait time as a "while".. sure , it is still nothing in terms of known universe existence time, which is around 13 bil years :)
So the code forks off the initialization in order not to slow down startup.
hahaha... kind of ;)
the "code" in image uses timestamps everywhere (like showing new startup time in transcript)... and god knows where else in system. The point is that every time you say something like "Date now" or "DateAndTime now" it will be blocked until this fork will finish its work.
Without knowing exactly my gut tells me this is not a good idea. It might be that it produces late jumps of time in startup which makes timeouts inactive. Or jumps the check for negative delays and introduces some negative wait which will native wise quit big. Were we at "wild guessing" or "very wild guessing" again?
yes.. but still we're not guessing what was before big bang.. i hope :)
Norbert
-- Best regards, Igor Stasenko.