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

Re: [Pharo-project] Remove #class as a Compiler optimization

by Stefan Marr

On 05 Apr 2011, at 15:11, Igor Stasenko wrote: > I don't care :) *sigh* then just flip a coin and you have the same amount of insight with less effort. It is always astonishing how few people know about the basics when it comes to empirical experiments. I disagree with Camillo's demand for 100x repetition, but it should be definitely run at least a few times. And then you have to look at the results and see how they vary. Otherwise you don't know anything and are just wasting your own time. I will try at the next sprint to make some progress on the framework front. Perhaps, someone could trow together something like the unit-test runner to make at least the basics fool-proof. And at the same time the message to measure the execution time of a block should become deprecated or raise a warning that you are about to fool yourself... It does not have to be statistically rigorous for small experiments, but at the very least you have to convince yourself that your measurements are actually of any value. The computer in front of you is just to complex to make an educated guess. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

April 5, 2011

Re: [Pharo-project] Issue 3957 in pharo: MethodWrappers left method after uninstall

by pharo＠googlecode.com

Updates: Status: Accepted Comment #3 on issue 3957 by marianopeck: MethodWrappers left method after uninstall http://code.google.com/p/pharo/issues/detail?id=3957 "I think that's ok to follow the lookup, because the inherited selectors are part of the behavior of the class, but i think it's a good idea to have a form to restrict that." yes, because the user can do a mess with that. The easiest way is to trhow an error. Then the user can always do the method lookup by himself and do a installOn: with the correct class and selector. "Anyway, in any of the two cases, after the uninstall process, the class should be clean" I agree. I will try to provide a solution (taking int account yours). I will let you know. Daniel...BTW, which is your particular use for MethodWrappers? I mean, why are you using them for? I am just curious...

April 5, 2011

Re: [Pharo-project] Issue 3937 in pharo: Breaking Announcement system

by pharo＠googlecode.com

Updates: Status: Accepted Mergedinto: Comment #2 on issue 3937 by marcus.d...(a)gmail.com: Breaking Announcement system http://code.google.com/p/pharo/issues/detail?id=3937 (No comment was entered for this change.)

April 5, 2011

Re: [Pharo-project] Issue 3963 in pharo: RPackageOrganizer and announcements

by pharo＠googlecode.com

Comment #2 on issue 3963 by Benjamin...(a)gmail.com: RPackageOrganizer and announcements http://code.google.com/p/pharo/issues/detail?id=3963 Issue 3937 is about another issue not fixed here ...

April 5, 2011

Re: [Pharo-project] Issue 3957 in pharo: MethodWrappers left method after uninstall

by pharo＠googlecode.com

Comment #2 on issue 3957 by lem...(a)gmail.com: MethodWrappers left method after uninstall http://code.google.com/p/pharo/issues/detail?id=3957 I think that's ok to follow the lookup, because the inherited selectors are part of the behavior of the class, but i think it's a good idea to have a form to restrict that. Anyway, in any of the two cases, after the uninstall process, the class should be clean Greetings, Daniel.

April 5, 2011

Re: [Pharo-project] Remove #class as a Compiler optimization

by Camillo Bruni

On 2011-04-05, at 15:11, Igor Stasenko wrote: > I don't care :) > > What i found that measurements confirms my previous expectation: > the 'slowdown' of removing #class from set of optimized selectors lies > in the range of macro-benchmark deviation. > > And running all tests for 100 times is not fun (it could take half of > the day), and i'm not ready to leave my computer for half of the day > and simply wait till it finish, because if i will do something > else,then it will affect the performance, and measurements will be > even more inaccurate. thats why you run it over night :) (or the day, depending on your sleep rhythm). or you reduce the number of runs to something at least bigger than 1 :D. > On 5 April 2011 14:53, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: >> This is exactly why you have to provide some confidence interval / deviation, otherwise it is hard to make any reasonable conclusion. >> >> run it 100 times and take the average and provide the standard deviation. >> >> I am not a big fan of relying on incomplete benchmarking results: >> >> Please read: http://portal.acm.org/citation.cfm?id=1297033 >> >> http://www.squeaksource.com/p.html provides a basic benchmarking framework under the NBenchmark package. You subclass from PBenchmarkSuite implement a method #benchXXX and run it. >> >> r := PBFloat run: 100. >> r asString >> >> which will give decent results back :). This way it is much easier to make sense out of the numbers. >> >> So here again to remember: >> >> - number of samples >> - average run times >> - standard deviation >> >> If one of these results is missing the benchmark results are incomplete. >> >> best regards, >> camillo >> >> >> >> On 2011-04-05, at 13:56, Igor Stasenko wrote: >> >>> VariableNode initialize. >>> Compiler recompileAll. >>> >>> [ >>> TestCase allSubclasses do: [ :cls| >>> cls isAbstract >>> ifFalse: [cls suite run]]. >>> ] timeToRun >>> >>> 178938 >>> 183963 >>> >>> >>> >>> (ParseNode classVarNamed: 'StdSelectors') removeKey: #class ifAbsent: []. >>> Compiler recompileAll. >>> >>> [ >>> TestCase allSubclasses do: [ :cls| >>> cls isAbstract >>> ifFalse: [cls suite run]]. >>> ] timeToRun >>> >>> 187168 >>> 184992 >>> >>> the deviation is too big to see if its really so big overhead. >>> >>> if you compare worst , you got 187/178 ~ 5% >>> and if you compare the best you got >>> 184/183 ~ 0.5% >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

April 5, 2011

[Pharo-project] jtalk fun

by laurent laffont

Go to http://jtalk-project.org/ Open development tools -> Workspace Evaluate: Tetris new appendToJQuery: 'body' asJQuery play. Laurent.

April 5, 2011

[Pharo-project] Issue 3964 in pharo: Enabling double click on PluggableListMorphOfMany

by pharo＠googlecode.com

Status: FixProposed Owner: Benjamin...(a)gmail.com Labels: Nautilus New issue 3964 by Benjamin...(a)gmail.com: Enabling double click on PluggableListMorphOfMany http://code.google.com/p/pharo/issues/detail?id=3964 Just copy and paste 2 lines ... Attachments: EnableDoubleClickOnPluggableListMorphOfMany.1.cs 1.9 KB

April 5, 2011

Re: [Pharo-project] Remove #class as a Compiler optimization

by Igor Stasenko

I don't care :) What i found that measurements confirms my previous expectation: the 'slowdown' of removing #class from set of optimized selectors lies in the range of macro-benchmark deviation. And running all tests for 100 times is not fun (it could take half of the day), and i'm not ready to leave my computer for half of the day and simply wait till it finish, because if i will do something else,then it will affect the performance, and measurements will be even more inaccurate. On 5 April 2011 14:53, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: > This is exactly why you have to provide some confidence interval / deviation, otherwise it is hard to make any reasonable conclusion. > > run it 100 times and take the average and provide the standard deviation. > > I am not a big fan of relying on incomplete benchmarking results: > > Please read: http://portal.acm.org/citation.cfm?id=1297033 > > http://www.squeaksource.com/p.html provides a basic benchmarking framework under the NBenchmark package. You subclass from PBenchmarkSuite implement a method #benchXXX and run it. > > r := PBFloat run: 100. > r asString > > which will give decent results back :). This way it is much easier to make sense out of the numbers. > > So here again to remember: > > - number of samples > - average run times > - standard deviation > > If one of these results is missing the benchmark results are incomplete. > > best regards, > camillo > > > > On 2011-04-05, at 13:56, Igor Stasenko wrote: > >> VariableNode initialize. >> Compiler recompileAll. >> >> [ >> TestCase allSubclasses do: [ :cls| >> Â Â Â Â cls isAbstract >> Â Â Â Â Â Â Â Â ifFalse: [cls suite run]]. >> ] timeToRun >> >> 178938 >> 183963 >> >> >> >> (ParseNode classVarNamed: Â 'StdSelectors') removeKey: #class ifAbsent: []. >> Compiler recompileAll. >> >> [ >> TestCase allSubclasses do: [ :cls| >> Â Â Â Â cls isAbstract >> Â Â Â Â Â Â Â Â ifFalse: [cls suite run]]. >> ] timeToRun >> >> 187168 >> 184992 >> >> the deviation is too big to see if its really so big overhead. >> >> if you compare worst , you got Â 187/178 ~ 5% >> and if you compare the best you got >> 184/183 Â ~ 0.5% >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > -- Best regards, Igor Stasenko AKA sig.

April 5, 2011

Re: [Pharo-project] Issue 3950 in pharo: SequenceableCollection>>#findBinary and friends (wrong exceptionBlock, delegation)

by pharo＠googlecode.com

Comment #3 on issue 3950 by marcus.d...(a)gmail.com: SequenceableCollection>>#findBinary and friends (wrong exceptionBlock, delegation) http://code.google.com/p/pharo/issues/detail?id=3950 Issue 3345 has been merged into this issue.

April 5, 2011