- Pharo-dev - lists.pharo.org

Re: [Pharo-project] DateAndTime bug: we should do something about it

by stephane ducasse

Igor I have the impression that this is happening for us because we always download the image from jenkins. Did we experience the same once the processes are cleaned? and we do not get an image from another os/system? Stef On Apr 12, 2013, at 11:25 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 12 April 2013 23:20, Norbert Hartl <norbert(a)hartl.name> wrote: >> funny, I wanted to look at it in my actual 2.0 working image and I don't have a single occurrence of it. It is a 2.0 image? >> > 3.0 latest.. > > it looks like it depends on something .. > (like the way you look, and what you ate today on breakfast ;) > >> Norbert >> >> Am 12.04.2013 um 23:08 schrieb Igor Stasenko <siguctua(a)gmail.com>: >> >>> I tried to find the cause but failed... >>> >>> this thing is annoying.. >>> >>> lets look at the code and brainstorm, about: >>> 1) what happening >>> 2) how we can fix it >>> >>> because i am out of ideas.. >>> and having this crap replicating itself in our images is not tolerable. >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> <Screen Shot 2013-04-12 at 11.05.49 PM.png> >> >> > > > > -- > Best regards, > Igor Stasenko. >

April 13, 2013

Re: [Pharo-project] DateAndTime bug: we should do something about it

by Norbert Hartl

No offense taken. It is not my code. I'm just guilty by resolving a ticket and integrating it. So maybe I should have taken more time looking at it. Norbert Am 13.04.2013 um 00:16 schrieb Igor Stasenko <siguctua(a)gmail.com>: > On 12 April 2013 23:47, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Am 12.04.2013 um 23:23 schrieb Igor Stasenko <siguctua(a)gmail.com>: >> >>> On 12 April 2013 23:14, phil(a)highoctane.be <phil(a)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) > > >> >>> 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. >

April 12, 2013

Re: [Pharo-project] DateAndTime bug: we should do something about it

by Sven Van Caekenberghe

Igor, On 13 Apr 2013, at 00:41, Igor Stasenko <siguctua(a)gmail.com> wrote: > Just another wild guess: > somewhere we introduced a code which uses 'DateAndTime now' > before Delay startup code is run. Yes, my feeling is also that there is Delay has something to do with it. > that means that it will put a very wrong Delay object into schedule > with random delay time. > > -- > Best regards, > Igor Stasenko. In response to all your other mails in this thread: let's please simplify all this and make it understandable. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

April 12, 2013

Re: [Pharo-project] DateAndTime bug: we should do something about it

by Igor Stasenko

Just another wild guess: somewhere we introduced a code which uses 'DateAndTime now' before Delay startup code is run. that means that it will put a very wrong Delay object into schedule with random delay time. -- Best regards, Igor Stasenko.

April 12, 2013

Re: [Pharo-project] Open window out of my pharo environment

by Eliot Miranda

On Fri, Apr 12, 2013 at 12:49 AM, Tristan Bourgois < tristan.bourgois(a)gmail.com> wrote: > Hi! > > all my question is in the object ^^ > > Does exist the possibility to open a window out of my pharo environment? > (Or someone know the way to do that?) > google: Squeak VNC server > > I'm working on a graphic framework and at my work they need a multi screen > support. It's needed to validate Pharo as the smalltalk they will use! > > Thanks! > > Tristan > -- best, Eliot

April 12, 2013

Re: [Pharo-project] DateAndTime bug: we should do something about it

by phil＠highoctane.be

ROFL... just make sure that in the same second we get increasing millisecs 2013/4/13 Igor Stasenko <siguctua(a)gmail.com> > On 13 April 2013 00:16, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 12 April 2013 23:47, Norbert Hartl <norbert(a)hartl.name> wrote: > >> > >> Am 12.04.2013 um 23:23 schrieb Igor Stasenko <siguctua(a)gmail.com>: > >> > >>> On 12 April 2013 23:14, phil(a)highoctane.be <phil(a)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. > > > > yeah.. and if you need millisecond precision so badly, with same success > i could do just: > > MilliSecondOffset := secondsSinceMidnight * 1000 -/+ (1000 atRandom). > > .. you know.. much less to code, after all :) > > > (But i can be wrong with that.. if so, please explain why) > > > > > >> > >>> 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. > > > > -- > Best regards, > Igor Stasenko. > >

April 12, 2013

Re: [Pharo-project] DateAndTime bug: we should do something about it

by Igor Stasenko

On 13 April 2013 00:16, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 12 April 2013 23:47, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Am 12.04.2013 um 23:23 schrieb Igor Stasenko <siguctua(a)gmail.com>: >> >>> On 12 April 2013 23:14, phil(a)highoctane.be <phil(a)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. > yeah.. and if you need millisecond precision so badly, with same success i could do just: MilliSecondOffset := secondsSinceMidnight * 1000 -/+ (1000 atRandom). .. you know.. much less to code, after all :) > (But i can be wrong with that.. if so, please explain why) > > >> >>> 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. -- Best regards, Igor Stasenko.

April 12, 2013

Re: [Pharo-project] DateAndTime bug: we should do something about it

by Igor Stasenko

On 12 April 2013 23:47, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 12.04.2013 um 23:23 schrieb Igor Stasenko <siguctua(a)gmail.com>: > >> On 12 April 2013 23:14, phil(a)highoctane.be <phil(a)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) > >> 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.

April 12, 2013

Re: [Pharo-project] DateAndTime bug: we should do something about it

by phil＠highoctane.be

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(a)hartl.name> > > Am 12.04.2013 um 23:23 schrieb Igor Stasenko <siguctua(a)gmail.com>: > > > On 12 April 2013 23:14, phil(a)highoctane.be <phil(a)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 > > >

April 12, 2013

Re: [Pharo-project] DateAndTime bug: we should do something about it

by Norbert Hartl

Am 12.04.2013 um 23:23 schrieb Igor Stasenko <siguctua(a)gmail.com>: > On 12 April 2013 23:14, phil(a)highoctane.be <phil(a)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

April 12, 2013