- Pharo-dev - lists.pharo.org

[Pharo-project] [COTDC] 42 - ExpanderMorphContracted

by laurent laffont

Today: ExpanderMorphContracted 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

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

by laurent laffont

Thanks a lot Henrik. Laurent. On Tue, Apr 5, 2011 at 12:02 PM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > 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

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

by Tudor Girba

And I did not mean that you were trying to steal anyone's ideas. I just wanted to point out that people might have misunderstood what I understood Marcus said :). Cheers, Doru On 5 Apr 2011, at 13:37, Esteban Lorenzano wrote: > 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." >>> >>> >>> >>> >> >> > > -- www.tudorgirba.com "We are all great at making mistakes."

April 5, 2011

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

by Igor Stasenko

On 5 April 2011 16:31, Stefan Marr <pharo(a)stefan-marr.de> wrote: > > 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. > that's what i did. i run two times and found that slowdown is at scale of deviation. This is why i don't care about exact slowdown anymore, because it is at the level of noise on macro benchmarks. > 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 > > > -- Best regards, Igor Stasenko AKA sig.

April 5, 2011

[Pharo-project] A lil simplification of MorphTreeNodeMorph

by Igor Stasenko

Cut out some code and extra morphs. It speeds up rendering to 60% of original. @Benjamin Please verify if it positioning stuff correctly. Because in my image Settings are now OK. @all I need your feedback to know if it works correctly in other places, where tree morph used. -- Best regards, Igor Stasenko AKA sig.

April 5, 2011

Re: [Pharo-project] Issue 3965 in pharo: Turn off Smart Characters in Full Image by default

by Mariano Martinez Peck

I would not do that. This is the expected behavior since ages. And there is a nice way to disable for those who don't like it. I even wrote this once...but seems people don't read the book as much as we would like: http://book.pharo-project.org/book/CustomizingPharo/SmartCharactersAutocomp… On Tue, Apr 5, 2011 at 6:03 PM, <pharo(a)googlecode.com> wrote: > Status: Accepted > Owner: marcus.d...(a)gmail.com > Labels: Milestone-1.2.2-DevImage > > New issue 3965 by marcus.d...(a)gmail.com: Turn off Smart Characters in Full > Image by default > http://code.google.com/p/pharo/issues/detail?id=3965 > > .. because they make it very hard to type for many people > > > -- Mariano http://marianopeck.wordpress.com

April 5, 2011

[Pharo-project] Issue 3965 in pharo: Turn off Smart Characters in Full Image by default

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.2.2-DevImage New issue 3965 by marcus.d...(a)gmail.com: Turn off Smart Characters in Full Image by default http://code.google.com/p/pharo/issues/detail?id=3965 .. because they make it very hard to type for many people

April 5, 2011

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

by Alexandre Bergel

Running the all unit test is probably a better benchmark. Alexandre On 5 Apr 2011, at 07: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. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 5, 2011

Re: [Pharo-project] Status of Weak enhancements in Pharo

by Miguel CobÃ¡

Ok, thanks. I was reviewing the Magma code (not working yet in Pharo 1.2, sadly) and found several checks for new finalization code before execution some parts of magma. So, as Chris said that Magma 1.2 is the only supported version (no support for old versions), then I thought that I should remove the checks given that Squeak 4.2 and Pharo 1.2 already have the new finalization code. Cheers El mar, 05-04-2011 a las 09:37 +0200, Igor Stasenko escribiÃ³: > On 5 April 2011 06:30, Miguel CobÃ¡ <miguel.coba(a)gmail.com> wrote: > > What is the status of the Weak enhancements that were applied to Squeak > > 4.2 (by Levente and Igor, mainly) and were targeted for inclusion in > > Pharo? Is there a list of them somewhere? which ones are integrated and > > which ones are not yet? > > > > Yes, they are already in Pharo. > > To check if you running VM which supports new finalization, use: > > WeakFinalizationList hasNewFinalization > > > Other question, is the plan to take the enhancements as they are and > > apply them on Pharo, that is, the versions in Squeak are the reference > > or there are conflicting versions in Pharo that are to be keep instead. > > I remember that some changes were made to Pharo in this regard. > > > > Do not worry about it. We reviewed the code with Stephane, before > integrating it. It was back in Dec 2010 (if i remember). > > > > > Cheers > > -- > > Miguel CobÃ¡ > > http://twitter.com/MiguelCobaMtz > > http://miguel.leugim.com.mx > > > > > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

April 5, 2011

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

by Alexandre Bergel

Hi Guys, Maybe I missed part of the discussion, but what is Nautilus? Squeaksource simply says "A new browser" Cheers, Alexandre On 5 Apr 2011, at 08:32, Fernando Olivero wrote: > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 5, 2011