- Pharo-dev - lists.pharo.org

Re: [Pharo-project] RFB server and 2.0

by Esteban Lorenzano

no idea, it looks like listen, but I still cannot connect. anyway, should be a problem in my machine, if it works for everybody else... I will check what can be happening :) thanks guys , Esteban On Apr 16, 2013, at 8:30 AM, Milan Mimica <milan.mimica(a)gmail.com> wrote: > I did and it works with no problem. Only tried it locally, but doesn't matter. > > > On 15 April 2013 20:37, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Someone has tried RFB in 2.0? I installed it, but looks like it is not working :( > > Esteban > > > > -- > Milan Mimica > http://sparklet.sf.net

April 16, 2013

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

by Igor Stasenko

On 16 April 2013 11:32, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Apr 15, 2013, at 4:50 PM, Igor Stasenko wrote: > >> On 15 April 2013 16:43, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> On 15 April 2013 16:32, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>>> >>>> On Apr 15, 2013, at 3:25 PM, Igor Stasenko wrote: >>>> >>>>> On 15 April 2013 12:14, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>>>>> >>>>>> On Apr 13, 2013, at 12:16 AM, Igor Stasenko wrote: >>>>>> >>>>>>> >>>>>>> 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) >>>>>> >>>>>> Because, as Levente said in code, resolution != accuracy. >>>>>> When you measure a single sample, sure, that value has an error of max resolution / 2. >>>>>> But when you measure when that value _changes_, you have an error of the underlying accuracy / 2. >>>>>> Clock s value: 1 2 >>>>>> resolution: |_______|_______| >>>>>> accuracy: ||||||||||||||||||||||||||||||||||| >>>>>> ^ >>>>>> Here's to hoping the above ascii art(?) worked! >>>>>> >>>>>> So no, that method is not complete nonsense. >>>>>> >>>>> Okay. >>>>> Now i rewriting the code which uses new primitive (primUTCMicrosecondClock), >>>>> and then we will no longer need this startup logic nor wrap around >>>>> check & other gory details... >>>>> just use a primitive. >>>> >>>> Sounds clearer, yes. >>>> >>>> However, be aware, at least on my VM: >>>> [Time millisecondClockValue] bench '34,600,000 per second.' >>>> [Time primUTCMicrosecondClock] bench '12,400,000 per second.' >>>> >>>> Which in my case translated to that in a Time2 class with #now defined: >>>> now >>>> >>>> | microSecondsToday | >>>> microSecondsToday := self primUTCMicrosecondClock \\ 86400000000. >>>> ^ self seconds: microSecondsToday // 1000000 nanoSeconds: microSecondsToday * 1000 >>>> >>>> and changing the relatively low-hanging fruit in standard Time (removing Duration creation and other crap): >>>> >>>> seconds: seconds nanoSeconds: nanoCount >>>> "Answer a Time from midnight." >>>> >>>> ^ self basicNew >>>> seconds: seconds nanoSeconds: nanoCount >>>> >>>> To benchmarks that looked like this: >>>> "Old code" >>>> [Time now ] bench '7,330,000 per second.' '7,280,000 per second.' '7,170,000 per second.' >>>> "Using microsecondClock every call" >>>> [Time2 now ] bench '2,280,000 per second.''2,300,000 per second.' '2,180,000 per second.' >>>> >>>> Also note, Time2 lacked translation to Local time, which would be needed for consistency with Time now. >>>> >>> >>> Well, i am not started modifying Time now, (will start in couple minutes ;) >>> but here results of DateAndTime now >>> before and after: >>> >>> before: >>> >>> >>> [ DateAndTime now ] bench '316,000 per second.' >>> >>> after: >>> >>> [ DateAndTime now ] bench '414,000 per second.' >>> >>> >>> with Time now, i think even if it will be "2,300,000" answers per second, >>> it is fairly acceptable , when accuracy of primitive is 1 microsecond, >>> you actually don't need more than 1 million answers per second, or you >>> will receive same answers. >>> >>> But aside of it, may i ask, why performance is so important/critical >>> for those? What is use case? >>> >> >> everything is good in comparison: >> >> [ self yourself ] bench '58,800,000 per second.' >> >> does nothing and just 25 times faster.. than Time now, >> so what is the point? :) > > The point was raising awareness that performance differences are also worthy of measuring when doing a reimplementation, not just code cleanliness. > A 3x decrease in performance is worth at least consideration as part of a reimplementation, even when the conclusion is "it's plenty fast enough for most uses anyways". > > Not to mention, "Made X Y% faster" looks better in the release notes than "Restructured the internals of X" :) > RIght. So, it is 3x slower , 1000x more accurate (milli vs micro), do not requires startup code do not need to account for counter wrapping and day change => much cleaner and nicer. + less buggy. As to me , the choice is obvious. > Cheers, > Henry > > -- Best regards, Igor Stasenko.

April 16, 2013

[Pharo-project] Phobos on retina display

by Pavel Krivanek

Hi, please can you check the latest Phobos demo bundle for Mac on a device with retina display and maybe send me some screenshots? https://ci.inria.fr/pharo-contribution/view/Phobos/job/PhobosDemo-Mac/ Thanks, -- Pavel

April 16, 2013

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

by Henrik Johansen

On Apr 15, 2013, at 4:50 PM, Igor Stasenko wrote: > On 15 April 2013 16:43, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 15 April 2013 16:32, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>> >>> On Apr 15, 2013, at 3:25 PM, Igor Stasenko wrote: >>> >>>> On 15 April 2013 12:14, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>>>> >>>>> On Apr 13, 2013, at 12:16 AM, Igor Stasenko wrote: >>>>> >>>>>> >>>>>> 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) >>>>> >>>>> Because, as Levente said in code, resolution != accuracy. >>>>> When you measure a single sample, sure, that value has an error of max resolution / 2. >>>>> But when you measure when that value _changes_, you have an error of the underlying accuracy / 2. >>>>> Clock s value: 1 2 >>>>> resolution: |_______|_______| >>>>> accuracy: ||||||||||||||||||||||||||||||||||| >>>>> ^ >>>>> Here's to hoping the above ascii art(?) worked! >>>>> >>>>> So no, that method is not complete nonsense. >>>>> >>>> Okay. >>>> Now i rewriting the code which uses new primitive (primUTCMicrosecondClock), >>>> and then we will no longer need this startup logic nor wrap around >>>> check & other gory details... >>>> just use a primitive. >>> >>> Sounds clearer, yes. >>> >>> However, be aware, at least on my VM: >>> [Time millisecondClockValue] bench '34,600,000 per second.' >>> [Time primUTCMicrosecondClock] bench '12,400,000 per second.' >>> >>> Which in my case translated to that in a Time2 class with #now defined: >>> now >>> >>> | microSecondsToday | >>> microSecondsToday := self primUTCMicrosecondClock \\ 86400000000. >>> ^ self seconds: microSecondsToday // 1000000 nanoSeconds: microSecondsToday * 1000 >>> >>> and changing the relatively low-hanging fruit in standard Time (removing Duration creation and other crap): >>> >>> seconds: seconds nanoSeconds: nanoCount >>> "Answer a Time from midnight." >>> >>> ^ self basicNew >>> seconds: seconds nanoSeconds: nanoCount >>> >>> To benchmarks that looked like this: >>> "Old code" >>> [Time now ] bench '7,330,000 per second.' '7,280,000 per second.' '7,170,000 per second.' >>> "Using microsecondClock every call" >>> [Time2 now ] bench '2,280,000 per second.''2,300,000 per second.' '2,180,000 per second.' >>> >>> Also note, Time2 lacked translation to Local time, which would be needed for consistency with Time now. >>> >> >> Well, i am not started modifying Time now, (will start in couple minutes ;) >> but here results of DateAndTime now >> before and after: >> >> before: >> >> >> [ DateAndTime now ] bench '316,000 per second.' >> >> after: >> >> [ DateAndTime now ] bench '414,000 per second.' >> >> >> with Time now, i think even if it will be "2,300,000" answers per second, >> it is fairly acceptable , when accuracy of primitive is 1 microsecond, >> you actually don't need more than 1 million answers per second, or you >> will receive same answers. >> >> But aside of it, may i ask, why performance is so important/critical >> for those? What is use case? >> > > everything is good in comparison: > > [ self yourself ] bench '58,800,000 per second.' > > does nothing and just 25 times faster.. than Time now, > so what is the point? :) The point was raising awareness that performance differences are also worthy of measuring when doing a reimplementation, not just code cleanliness. A 3x decrease in performance is worth at least consideration as part of a reimplementation, even when the conclusion is "it's plenty fast enough for most uses anyways". Not to mention, "Made X Y% faster" looks better in the release notes than "Restructured the internals of X" :) Cheers, Henry

April 16, 2013

Re: [Pharo-project] Metacello configuration conventions

by Frank Shearar

On 16 April 2013 09:53, Stephan Eggermont <stephan(a)stack.nl> wrote: > Hi, > > While working with Diego on some configurations, we noticed two different styles > of describing the latest non-baseline versions. > > In one, the versionString version of a dependency is used. > That is a defensive strategy, where you want to specify the exact version that > will be loaded (and has been tested). > > In the other the #stable version is used. That is an optimistic strategy. > This is much less brittle (but might suddenly not work anymore). > > Seaside uses defensive/mixed, while Magritte uses optimistic > > Based on what criteria should I choose which one to use (in a Pharo context)? I'd argue that since you're declaring that a certain set of versions of packages work together, you should _always_ use explicit versions. The "optimistic" strategy leaves you vulnerable to third parties making seemingly innocuous changes that break your code. (I've been bitten by this, by making such an apparently innocuous change.) frank > Stephan & Diego

April 16, 2013

[Pharo-project] Metacello configuration conventions

by Stephan Eggermont

Hi, While working with Diego on some configurations, we noticed two different styles of describing the latest non-baseline versions. In one, the versionString version of a dependency is used. That is a defensive strategy, where you want to specify the exact version that will be loaded (and has been tested). In the other the #stable version is used. That is an optimistic strategy. This is much less brittle (but might suddenly not work anymore). Seaside uses defensive/mixed, while Magritte uses optimistic Based on what criteria should I choose which one to use (in a Pharo context)? Stephan & Diego

April 16, 2013

[Pharo-project] [update 3.0] #30040

by Marcus Denker

30040 ----- 10290 Typo in selector Exit class>>#signalFaillure: http://pharo.fogbugz.com/f/cases/10290 10258 DivideByZero in SystemProgressMorph https://pharo.fogbugz.com/f/cases/10258 10272 Monticello should provide a proper UI dialog to ask for username and password https://pharo.fogbugz.com/f/cases/10272/ Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Monticello-MarcusDenker.787 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/MonticelloGUI-MarcusDenker.2… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Kernel-MarcusDenker.1361

April 16, 2013

Re: [Pharo-project] RFB server and 2.0

by Milan Mimica

I did and it works with no problem. Only tried it locally, but doesn't matter. On 15 April 2013 20:37, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Someone has tried RFB in 2.0? I installed it, but looks like it is not > working :( > > Esteban > -- Milan Mimica http://sparklet.sf.net

April 16, 2013

Re: [Pharo-project] Spec DropLists

by stephane ducasse

I did not check but we should avoid isKindOf: and we should avoid different protocol that after leads to ugly code. > > > > Now @ > https://pharo.fogbugz.com/f/cases/6489/Spec-ify-DropListModel-TextModel > Fix in inbox: > SLICE-Issue-6489-Spec-ify-DropListModel--TextModel-SeanDeNigris.1 > > It's a little ugly because I wanted to preserve the old raw-string behavior > for now. > > Instead of: > colorItems := #('Green' 'Red' 'Yellow') collect: [ :e | DropListItem named: > e do: [] ]. > colorModel > items: colorItems. > And then matching the strings that come back (yuck)... > > You can now say: > colorModel > items: { Color green. Color red. Color yellow }; > displayBlock: [ :e | e name capitalized ]. > > And then: > colorModel whenSelectedItemChangedDo: [ :color | Transcript show: color > brightness ]. > > I also uploaded a version for 2.0 to the old > (http://ss3.gemstone.com/ss/PharoInbox/) inbox and at > http://ss3.gemstone.com/ss/PharoSpd for those (like me) who can't wait until > 3.0 to use it ;) > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Spec-DropLists-tp4643694p4681720.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 16, 2013

Re: [Pharo-project] Spec DropLists

by Sean P. DeNigris

Sean P. DeNigris wrote > Issue 6551: [ENH Spec]: Spec-ify DropListModel > http://code.google.com/p/pharo/issues/detail?id=6551 > > Currently: > self instantiateModels: #(dropList #DropListModel). > > item1 := DropListItem named: 'Red morph' do: self redMorphBlock. > item2 := DropListItem named: 'Blue morph' do: self blueMorphBlock. > item3 := DropListItem named: 'Green morph' do: self greenMorphBlock. > > dropList items: {item1. item2. item3}. > > I'd prefer if DropLists were uniform with the rest of Spec, namely: > I'd have my domain class > MyColor>>description > ^ nameOfColor > > dropList > items: {myRedColor. myBlueColor. myGreenColor}; > displayBlock: [ :e | e description, ' morph' ]; > whenSelectionChanged: [ :e | self showMorphFor: e ]. Now @ https://pharo.fogbugz.com/f/cases/6489/Spec-ify-DropListModel-TextModel Fix in inbox: SLICE-Issue-6489-Spec-ify-DropListModel--TextModel-SeanDeNigris.1 It's a little ugly because I wanted to preserve the old raw-string behavior for now. Instead of: colorItems := #('Green' 'Red' 'Yellow') collect: [ :e | DropListItem named: e do: [] ]. colorModel items: colorItems. And then matching the strings that come back (yuck)... You can now say: colorModel items: { Color green. Color red. Color yellow }; displayBlock: [ :e | e name capitalized ]. And then: colorModel whenSelectedItemChangedDo: [ :color | Transcript show: color brightness ]. I also uploaded a version for 2.0 to the old (http://ss3.gemstone.com/ss/PharoInbox/) inbox and at http://ss3.gemstone.com/ss/PharoSpd for those (like me) who can't wait until 3.0 to use it ;) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spec-DropLists-tp4643694p4681720.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 16, 2013