April 2013 - Pharo-dev - lists.pharo.org

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

by Tristan Bourgois

Thanks for all your advice! I will try them this week :) Tristan 2013/4/13 Eliot Miranda <eliot.miranda(a)gmail.com> > > > 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 13, 2013

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

by Marcus Denker

On Apr 13, 2013, at 7:10 AM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > 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? Yes, every time the image is saved on Jenkins we get one more. There is some other strange problem with saving images from the CommandLine: some things are deferred until the GUI is available, which is when you open it after downloading from jenkins. As for 2.0: we cleaned it by handâ¦ (the release image). Marcus

April 13, 2013

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

by Levente Uzonyi

On Sat, 13 Apr 2013, Igor Stasenko 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. > > (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. > >

April 13, 2013

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

by stephane ducasse

tristan I do not think that without help we will be able to get multiwindowing working within the time of your intern. Now if one guy at your place wants to help it can really change. Stef > > > > 2013/4/12 S Krish <krishnamachari.sudhakar(a)gmail.com> > > From immediate perspective, why not hook up with NativeBoost to a C DLL one can easily parametrize to serve as viable alternative / proof of concept till Igor / Esteban's work becomes core to Pharo. > > Can you explain me fastly how to do that? (Sorry but I'm a terribly newbie on low-level programming) > > Is this Windows / Mac / Linux or multi OS..? For Pharo, they will have to ensure it multi OS compatible so may take time stabilizing. > > > I develop on Windows but we have to be compatible with Linux. (The demo to the client are on Linux machine). > > > On Fri, Apr 12, 2013 at 1:19 PM, 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?) > > 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 > >

April 13, 2013

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

by stephane ducasse

No problem. We want simple and not overly "smart" code. So we should do another pass on it. Stef > 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 13, 2013

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

by stephane ducasse

Igor since we are investing in the fact that we can build better systems now and for the future, I would be rewriting all this ugly code. Stef On Apr 13, 2013, at 12:16 AM, 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. > > (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 13, 2013

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

by stephane ducasse

> > 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? agreed.

April 13, 2013

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