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

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

Re: [Pharo-project] [Metacello] FTP repo without storing username/pass in ConfigurationOf

by Dale Henrichs

Mariano, I would think that you'd treat the FTP repository like the HTTP repository, i.e., if you add the repository in the MetacelloBrowser and set the username/password there, then Metacello should honor that (like it does for the HTTP repository) ... so instead of adding some sort of repository override to the load script, simply create the FTP repository with username/password inline in your load script. Dale ----- Original Message ----- | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> | To: metacello(a)googlegroups.com, "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> | Sent: Monday, April 15, 2013 11:11:09 AM | Subject: [Metacello] FTP repo without storing username/pass in ConfigurationOf | | Hi all, | | I have the code of an app in a FTP repo which has username/password. | I am doing a ConfigurationOfMyApp now and I would need to define in the | baseline something like | | spec repository: 'ftp.mydomainapp.com ...etc'. | | I know I have a similar method for also specifying the username/pass. But I | don't want that because it means storing the username/pass in the | ConfigurationOf code. | | So....how can I manage this with metacello? the only thing I found (which I | am not sure if it works) is to use repositoryOverride so when I am about to | load my project I do a #repositoryOverride: passing as argument a FTP with | my username/password. | | What do you think? | | best, | | -- | Mariano | http://marianopeck.wordpress.com | | -- | You received this message because you are subscribed to the Google Groups | "Metacello" group. | To unsubscribe from this group and stop receiving emails from it, send an | email to metacello+unsubscribe(a)googlegroups.com. | For more options, visit https://groups.google.com/groups/opt_out. | | |

April 16, 2013

Re: [Pharo-project] Versionner in 2.0 again

by Christophe Demarey

Hi Sean, Le 15 avr. 2013 Ã 20:39, Sean P. DeNigris a Ã©crit : > stephane ducasse wrote >>> What you need : >>> 1/ Load (don't merge) Metacello-ToolBox-dkh.130 from >>> http://seaside.gemstone.com/ss/metacello in your Pharo2 image. >>> 2/ Load ConfigurationOfVersionner from >>> http://ss3.gemstone.com/ss/Versionner >>> 3/ ConfigurationOfVersionner load > > So is this the best way to load Versionner in 2.0? Yes. There might be some remaining issues but it is difficult to track without having metacello tests running on Pharo2. > Can we streamline that > i.e. put the preload in the config? I was wondering if it is possible to downgrade an already installed package in a configuration. Is it possible with a preload directive? Thanks, Christophe.

April 15, 2013

Re: [Pharo-project] RFB server and 2.0

by Norbert Hartl

Am 15.04.2013 um 20:43 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > damn :( > > I have a connection refused (in pharo it looks like running, but...) > What does netstat -atn | grep 5900 say? Norbert > Esteban > > On Apr 15, 2013, at 8:39 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> It worked for me when I tried 2 or 3 weeks ago.... >> >> >> On Mon, Apr 15, 2013 at 3:37 PM, 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 >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >

April 15, 2013