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

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

by Levente Uzonyi

On Sat, 13 Apr 2013, Igor Stasenko wrote: > On 13 April 2013 21:36, Levente Uzonyi <leves(a)elte.hu> wrote: >> On Sat, 13 Apr 2013, Igor Stasenko wrote: >> >>> >>> 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. >> >> >> The only thing I wanted to point out is that the value of #primSecondsClock >> changes when the actual second changes (the difference is less than 1ms). So >> while its resolution is just 1 second, it's accuracy is better than 1ms. >> Here's another example using the microsecond clock: >> >> >> (1 to: 10) collect: [ :e | >> | start | >> Time secondsWhenClockTicks. >> start := Time primUTCMicrosecondClock. >> Time secondsWhenClockTicks. >> Time primUTCMicrosecondClock - start ]. "==> #(1000136 999914 >> 999961 999926 1000029 999988 999991 999985 998089 1000034)" >> > > My gut feeling that here you are rather measuring accuracy of 1ms > Delay operation (in secondsWhenClockTicks method). No. I just wanted to show that this method works in practice (yeah, it's there for years and actually noone had any problems with it). And even though there's a slight chance for it to drift away by a few milliseconds, your statement - using a random number for the millisecond part is not worse than using this method - is not true. Levente > by sampling it using system time function. > Because for both primitives (primUTCMicrosecondClock and primSecondsClock) > the source is system time. > But Delay, inside also uses system time at some point... > > so, here we're trying to reason about how to measure accuracy of some > function (which stays behind all of these) by using very same > function.. > > I am not genius in rules of correct measurement, but doesn't it sounds > silly to you? > >> >>> >>> 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. >> >> >> Of course Delays are not ideal here, but there was nothing better to use >> when the code was written. As you can see in the above example, in 1 out of >> 10 cases the difference was less than 999 ms. >> >> >> Levente >> >> >>> >>>> >>>> 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. >>> >>> >> > > > > -- > Best regards, > Igor Stasenko. > >

April 14, 2013

Re: [Pharo-project] Video uploads PharoConf & MooseDay resuming

by phil＠highoctane.be

Spec!!! 2013/4/14 Stephan Eggermont <stephan(a)stack.nl> > Hi all, > > Raw versions of > Building UIs with Spec > https://www.youtube.com/watch?v=P98-qpLUvQQ > Data Migration with Moose > https://www.youtube.com/watch?v=8SGHV1lCry0 > Pharo Roadmap > https://www.youtube.com/watch?v=9xRVzzjgPu8 > are now online > Uploading now is FileSystem-Git > >

April 14, 2013

[Pharo-project] Video uploads PharoConf & MooseDay resuming

by Stephan Eggermont

Hi all, Raw versions of Building UIs with Spec https://www.youtube.com/watch?v=P98-qpLUvQQ Data Migration with Moose https://www.youtube.com/watch?v=8SGHV1lCry0 Pharo Roadmap https://www.youtube.com/watch?v=9xRVzzjgPu8 are now online Uploading now is FileSystem-Git

April 14, 2013

[Pharo-project] Seabreeze users?

by StÃ©phane Ducasse

Hi guys I was watching again this video and I found the concepts and system really interesting. http://www.youtube.com/watch?v=wI1UcwJrJLc Does anybody use SeaBreeze? Stef

April 14, 2013

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

by stephane ducasse

Hi igor and levente I want to thank you because I love this thread. Why because it makes me think and I learn things :) I will reread it several time and browse the system... to learn again Thanks >>> 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. >> >> >> The only thing I wanted to point out is that the value of #primSecondsClock >> changes when the actual second changes (the difference is less than 1ms). So >> while its resolution is just 1 second, it's accuracy is better than 1ms. >> Here's another example using the microsecond clock: >> >> >> (1 to: 10) collect: [ :e | >> | start | >> Time secondsWhenClockTicks. >> start := Time primUTCMicrosecondClock. >> Time secondsWhenClockTicks. >> Time primUTCMicrosecondClock - start ]. "==> #(1000136 999914 >> 999961 999926 1000029 999988 999991 999985 998089 1000034)" >> > > My gut feeling that here you are rather measuring accuracy of 1ms > Delay operation (in secondsWhenClockTicks method). > by sampling it using system time function. > Because for both primitives (primUTCMicrosecondClock and primSecondsClock) > the source is system time. > But Delay, inside also uses system time at some point... > > so, here we're trying to reason about how to measure accuracy of some > function (which stays behind all of these) by using very same > function.. > > I am not genius in rules of correct measurement, but doesn't it sounds > silly to you? > >> >>> >>> 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. >> >> >> Of course Delays are not ideal here, but there was nothing better to use >> when the code was written. As you can see in the above example, in 1 out of >> 10 cases the difference was less than 999 ms. >> >> >> Levente >> >> >>> >>>> >>>> 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. >>> >>> >> > > > > -- > Best regards, > Igor Stasenko. >

April 14, 2013

Re: [Pharo-project] 2.0 is really nice

by Alexandre Bergel

+1 Alexandre On Apr 13, 2013, at 3:50 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I just ported a project from 20531 to 20597... not too far in calendar time, > but a world of difference in usability :) > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/2-0-is-really-nice-tp4681279.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 14, 2013

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

by Igor Stasenko

On 13 April 2013 21:36, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sat, 13 Apr 2013, Igor Stasenko wrote: > >> >> 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. > > > The only thing I wanted to point out is that the value of #primSecondsClock > changes when the actual second changes (the difference is less than 1ms). So > while its resolution is just 1 second, it's accuracy is better than 1ms. > Here's another example using the microsecond clock: > > > (1 to: 10) collect: [ :e | > | start | > Time secondsWhenClockTicks. > start := Time primUTCMicrosecondClock. > Time secondsWhenClockTicks. > Time primUTCMicrosecondClock - start ]. "==> #(1000136 999914 > 999961 999926 1000029 999988 999991 999985 998089 1000034)" > My gut feeling that here you are rather measuring accuracy of 1ms Delay operation (in secondsWhenClockTicks method). by sampling it using system time function. Because for both primitives (primUTCMicrosecondClock and primSecondsClock) the source is system time. But Delay, inside also uses system time at some point... so, here we're trying to reason about how to measure accuracy of some function (which stays behind all of these) by using very same function.. I am not genius in rules of correct measurement, but doesn't it sounds silly to you? > >> >> 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. > > > Of course Delays are not ideal here, but there was nothing better to use > when the code was written. As you can see in the above example, in 1 out of > 10 cases the difference was less than 999 ms. > > > Levente > > >> >>> >>> 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. >> >> > -- Best regards, Igor Stasenko.

April 13, 2013

[Pharo-project] 2.0 is really nice

by Sean P. DeNigris

I just ported a project from 20531 to 20597... not too far in calendar time, but a world of difference in usability :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/2-0-is-really-nice-tp4681279.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

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: > > 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. The only thing I wanted to point out is that the value of #primSecondsClock changes when the actual second changes (the difference is less than 1ms). So while its resolution is just 1 second, it's accuracy is better than 1ms. Here's another example using the microsecond clock: (1 to: 10) collect: [ :e | | start | Time secondsWhenClockTicks. start := Time primUTCMicrosecondClock. Time secondsWhenClockTicks. Time primUTCMicrosecondClock - start ]. "==> #(1000136 999914 999961 999926 1000029 999988 999991 999985 998089 1000034)" > > 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. Of course Delays are not ideal here, but there was nothing better to use when the code was written. As you can see in the above example, in 1 out of 10 cases the difference was less than 999 ms. Levente > >> >> 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. > >

April 13, 2013

Re: [Pharo-project] Zinc/Zodiac error while doing a get in Windows

by Esteban Lorenzano

just that... all the other tests are fine On Apr 13, 2013, at 8:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 13 April 2013 19:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> On 13 Apr 2013, at 17:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> Hi, >>> >>> yes... it still happen with your fix. >>> It ss weird that it works for you because I tested in two different windows (XP and W7) and in two different networks (work and here). >>> tbh, I don't really need it working, the small program I'm doing will not run in windows anyway (it was just by chance that I tested there)... but since I catched the probable bug, I want to solve it (or demonstrate it is not a bug) :) >> >> I meant that it worked on my Mac. And I just tried and indeed it does fail on Windows (8), while all other Zinc/Zodicac tests pass. >> >> The problem is inside the initial TLS/SSL connect handshake, which is really low level. >> >> I think it is worth to make an issue out of this, but I have no clue as to a solution. >> > > does that means one cannot use SSL on windoze at all? > or it breaks only in some special cases (like with given url)? > > -- > Best regards, > Igor Stasenko. >

April 13, 2013