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

Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)

by Alexandre Bergel

I remember Fred has lazy initialization of variable. All variables are lazy initialized. This means that variables set to nil when you change the class are lazy initialized. It has been a long time I looked at it. Alexandre On 4 Apr 2011, at 16:32, StÃ©phane Ducasse wrote: > In fact he got a better changeClassToThatOf: implementation and got kind of initform for slots. > > Stef > > >> I do read French too, no problem. >> >> I'm having a look at >> >> http://fredrivard.ifrance.com/fredrivard/pub/dicl/dicl.ps >> >> That seems related. >> >> On 04/04/2011 09:20 PM, Alexandre Bergel wrote: >>> he he. I am not sure Fred wrote in English. >>> http://scg.unibe.ch/scgbib?_k=qQPhJdNf&query=rivard >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 4 Apr 2011, at 14:15, Toon Verwaest wrote: >>> >>>> Do you have an exact reference on this? >>>> >>>> On 04/04/2011 05:55 PM, StÃ©phane Ducasse wrote: >>>>>> Another very cool thing that we can do now (which would require 3 lines of change in my system though), is that the slot can also be responsible for instance migration. There are four cases: >>>>>> 1- the instance variable didn't exist and now it does >>>>>> 2- the instance variable existed but disappeared >>>>>> 3- the metaobject changed (new semantics) >>>>>> 4- the metaobject stayed the same >>>>>> >>>>> Did you check the work of fred rivard because he was managing the dynamic change of class and managing slot reinitialization? >>>>> >>>>> >>>>>> Basically the only case that is "handled" by standard Pharo is case 1; and what you do there is putting nil in the field. In our model the slot could do something more interesting when it's migrating the instances. And we could tackle the other cases too. I think it's starting to get ideal to implement an active context on top ;-) >>>>>> >>>>>> cheers, >>>>>> Toon >>>> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 5, 2011

[Pharo-project] abouth nautilus and the removal of CodeHolder hierarchy

by Fernando Olivero

Hi Ben, i was thinking about the discussion of the menus: Since you are using menu pragma builder, and have explicit views for each tool, then the CodeHolder hierarchy is no longer needed. Because the specialized views get the behavior for answering the actions in the menus (which currently is spread across the StringHolder hierarchy). So this is the main reason why you simple need a pluggable text model, for the model of the views. And a pluggable TextModel (or StringHolder in Pharo) would suffice? Is this correct? Thanks, Fernando

April 5, 2011

Re: [Pharo-project] Issue 3953 in pharo: add #ensureCr to new transcript

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3953 by stephane...(a)gmail.com: add #ensureCr to new transcript http://code.google.com/p/pharo/issues/detail?id=3953 in 13132

April 5, 2011

[Pharo-project] [update 1.3] #13132

by StÃ©phane Ducasse

13132 ----- - Issue 3953: add #ensureCr to new transcript - fix world menu

April 5, 2011

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

by Igor Stasenko

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.

April 5, 2011

Re: [Pharo-project] Let's get rid of Core vs. Full

by Esteban Lorenzano

and I wasn't trying to steal marcus... If that's what he proposed, I just didn't understand it the first time... in that case, I say "I agree with Marcus" :) cheers, Esteban El 04/04/2011, a las 5:22p.m., StÃ©phane Ducasse escribiÃ³: >> This is what I understood from what Marcus said, too :) > > sure I did not mean that marcus was stealing me ideas. > But that I was inlined with esteban proposal > > Stef >> >> Cheers, >> Doru >> >> >> On 4 Apr 2011, at 15:57, StÃ©phane Ducasse wrote: >> >>> This is my ideas. >>> >>>> My proposition for 1.3: >>>> 1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea) >>>> 2) Reduce the "full" image to Core+OB+RB+Shout+OCompletion+Finder+MetacelloBrowser >>>> 3) If it is possible, develop Core image into this reduced full image. >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Every thing should have the right to be different." >> >> >> >> > >

April 5, 2011

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

by Marcus Denker

On Apr 5, 2011, at 12:32 PM, Mariano Martinez Peck wrote: > > > On Tue, Apr 5, 2011 at 12:09 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 5 April 2011 11:33, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > So....I tried with running all tests of a PharoCore 1.3 and I've got this: > > > > cog vm with optimization > > Time to run all tests:116506 > > > > cog vm without optimization > > Time to run all tests:121930 > > > > 121930 - 116506 ----> 5424 > > ((5424 * 100) / 116506) asFloat ---> 4.655554220383499 > > > > So...in Cog, running all test, there is an overhead of 4.6% > > > > Do we want to pay it ? > > > > I would...but I am all ears. > > > 5% for #class message? > this is too much. or you also removed other optimized sends? > > > Only that one. For #== I got 4.3. And doing both together (#class and #==) I got 9.05% :( > > And removing the #class optimization in a Interpreter VM gives me almost as in cog: 4.7% > > maybe I am doing something wrong... > can you try in 1.2? We did some compiler changes that are not yet fully done.... e.g. Issue 3940: BlockNode has undeclared ivar optimizedMessageNode -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 5, 2011

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

by Mariano Martinez Peck

On Tue, Apr 5, 2011 at 12:09 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 5 April 2011 11:33, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > So....I tried with running all tests of a PharoCore 1.3 and I've got > this: > > > > cog vm with optimization > > Time to run all tests:116506 > > > > cog vm without optimization > > Time to run all tests:121930 > > > > 121930 - 116506 ----> 5424 > > ((5424 * 100) / 116506) asFloat ---> 4.655554220383499 > > > > So...in Cog, running all test, there is an overhead of 4.6% > > > > Do we want to pay it ? > > > > I would...but I am all ears. > > > 5% for #class message? > this is too much. or you also removed other optimized sends? > > Only that one. For #== I got 4.3. And doing both together (#class and #==) I got 9.05% :( And removing the #class optimization in a Interpreter VM gives me almost as in cog: 4.7% maybe I am doing something wrong... > > Cheers > > > > Mariano > > > > > > > > On Mon, Mar 28, 2011 at 11:08 AM, Camillo Bruni <camillo.bruni(a)inria.fr> > > wrote: > >> > >> >>> I don't care. I have it working for my "usage". This was just an > >> >>> example. > >> >>> > >> >>> And don't compare #class with all the boolean methods like #ifNil: > >> >>> and > >> >>> friends or the bytecodes for integer operations....I think #class > is > >> >> sent > >> >>> far less times than those... > >> >>> > >> >> > >> >> Yes. and i predict that performance impact in macro benchmarks, where > >> >> you running normal code > >> >> (which not sending this message intentionally in a loop) will be at > >> >> the noise level magnitude. > >> >> > >> > > >> > So...what about doing something more real...for example, run all the > >> > testcases and compare time. > >> > Wouldn't that be a good "benchmark" ? > >> > >> sounds already better. make sure to run it something like 100 times, get > >> the average and the standard deviation. otherwise the results don't > provide > >> much information. > >> > >> > BTW, can I run all test from code? (not using the TestRunner UI) > >> > >> > >> something like the following code should do it. > >> > >> TestCase allSubclasses do: [ :cls| > >> cls isAbstract > >> ifFalse: [cls run]]. > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > -- Mariano http://marianopeck.wordpress.com

April 5, 2011

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

by Igor Stasenko

On 5 April 2011 11:33, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > So....I tried with running all tests of a PharoCore 1.3 and I've got this: > > cog vmÂ with optimization > Time to run all tests:116506 > > cog vmÂ without optimization > Time to run all tests:121930 > > 121930 - 116506 ----> 5424 > ((5424 * 100) / 116506) asFloat ---> 4.655554220383499 > > So...in Cog, running all test, there is an overhead of 4.6% > > Do we want to pay it ? > > I would...but I am all ears. > 5% for #class message? this is too much. or you also removed other optimized sends? > Cheers > > Mariano > > > > On Mon, Mar 28, 2011 at 11:08 AM, Camillo Bruni <camillo.bruni(a)inria.fr> > wrote: >> >> >>> I don't care. I have it working for my "usage". This was just an >> >>> example. >> >>> >> >>> And don't compare #class with all the boolean methods like #ifNil: >> >>> Â and >> >>> friends Â or the bytecodes for integer operations....I think #class is >> >> sent >> >>> far less times than those... >> >>> >> >> >> >> Yes. and i predict that performance impact in macro benchmarks, where >> >> you running normal code >> >> (which not sending this message intentionally in a loop) will be at >> >> the noise level magnitude. >> >> >> > >> > So...what about doing something more real...for example, run all the >> > testcases and compare time. >> > Wouldn't that be a good "benchmark" ? >> >> sounds already better. make sure to run it something like 100 times, get >> the average and the standard deviation. otherwise the results don't provide >> much information. >> >> > BTW, can I run all test from code? (not using the TestRunner UI) >> >> >> something like the following code should do it. >> >> TestCase allSubclasses do: [ :cls| >> Â Â Â Â cls isAbstract >> Â Â Â Â Â Â Â Â ifFalse: [cls run]]. > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Best regards, Igor Stasenko AKA sig.

April 5, 2011

Re: [Pharo-project] [COTDC] 40#2 - NonReentrantWeakMessageSend

by Henrik Johansen

NonReentrantWeakMessageSend does what it says, while the message is being executed, additional evaluations will be discarded. It's used by when:sendOnce:to: protocol from Polymorph events, but unused in the base image. when:send:to:exclusive: is used one place though. It's useful when objects are mutually registered to each other's events, but the actions may lead to the others action being triggered. Examples are - two lists whose contents update based on the selection in the other - The DiffMorph (Uses ExclusiveWeakMessageSend) ExclusiveWeakMessageSend are used when the decision whether to process an event is shared between multiple objects. IE 2 objects respond to different events, but if received simultaneously, only the first of them should have it's action executed. With Announcement, the corresponding functionality to non-reentrancy would be achieved using: VW - AnnouncementCollection>>suspendWhile: anActionBlock Pharo - Announcer >> suspend: aSubscriber while: anActionBlock (As we neither have a specific AnnouncementCollection class, nor access to Registry itself. Not implemented yet though :P) The shared state required to achieve Exclusivity would probably have to recide outside of the framework. Cheers, Henry On Apr 4, 2011, at 9:59 56PM, laurent laffont wrote: > Today: NonReentrantWeakMessageSend > > > (ExclusiveWeakMessageSend aborted - no answer) > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent

April 5, 2011