- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Videos: FileSystem-Git

by Stephan Eggermont

Max wrote: >I noticed that there's a transition in the middle of the video (rotating cube) and then >the entire video is shown again. So the video contains the same sequence twice. >What's the idea behind that? I'm sorry about that. No CI and lack of tests I'm afraid. It looked to me like all rendering was done before the machine ran out of disk space so I thought it safe to start uploading everything asap. I'll put out a fixed version. Stephan

April 14, 2013

Re: [Pharo-project] Videos: FileSystem-Git

by Max Leske

Cool! Thanks Stephan! I noticed that there's a transition in the middle of the video (rotating cube) and then the entire video is shown again. So the video contains the same sequence twice. What's the idea behind that? Cheers, Max On 14.04.2013, at 14:21, Stephan Eggermont <stephan(a)stack.nl> wrote: > FileSystem-Git > https://www.youtube.com/watch?v=4qld2mDIbg4 > and uploading: Taming MongoDB from Pharo >

April 14, 2013

[Pharo-project] Videos: FileSystem-Git

by Stephan Eggermont

FileSystem-Git https://www.youtube.com/watch?v=4qld2mDIbg4 and uploading: Taming MongoDB from Pharo

April 14, 2013

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