That whole nanos thing in DateAndTime is really weird. I'd love getting millisecs instead (got some trouble with Toothpick logging due to that). 2013/4/12 Norbert Hartl <norbert@hartl.name>
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.
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? 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.
My wild guess would be the startup initialization of DateAndTime. It takes quite while to do. So the code forks off the initialization in order not to slow down startup. 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?
Norbert