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

Re: [Pharo-project] Working with weak announcements...

by StÃ©phane Ducasse

> >> Igor >> >> now the problem is how much time do you expect it may take to introduce ephemerons? >> Else having well documented patterns is also important. > > > I think it is relatively easy to modify VM , since it touching only GC > related stuff. Ok how many weeks? > And also there is already an implementation somewhere made by Ian.. > which can be used as reference. > >> >> Stef >> >> >> On Feb 14, 2011, at 10:33 PM, Igor Stasenko wrote: >> >>> On 14 February 2011 21:52, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> Hi, >>>> I'm working with weak announcements, trying to make it work, and I have a problem in #on:do: protocol (or #when:do:) >>>> I try to explain: >>>> >>>> This method receives a block, not an object/selector, so I can't create a WeakMessageSend which is the appropriate message to handle in other cases. >>>> Well, the real question is... how can I produce a "Weak BlockClosure reference" who can die if receiver dies? >>>> I tried some hacks (really ugly hacks, btw), but fail completely. >>>> Any idea? >>>> >>> >>> Don't even try doing it until we will have ephemerons support at VM side :) >>> >>> I explained this few days ago to Stephane, and also i mentioned about >>> this maybe half of year ago when i took a look at announcements. >>> >>> With ephemerons you can have: >>> - reference a block strongly only if subscriber , which held weakly is alive. >>> >>> Once subscribed dies, you start referencing block weakly. >>> >>> In terms on GC it means, that during mark phase, you are visiting a >>> references which reachable through block closure only if your >>> subscriber are already marked as 'live'. >>> >>> So, this means that you can do weak subscriptions like following: >>> >>> >>> self weakOn: Foo do: [:announcement | self bar ]. >>> >>> A 'self' is a subscriber. But if you create a subscription from a pair of: >>> <subscriber> and <block> >>> without using ephemerons you should make sure that reference to >>> subscriber are not reachable through given block. >>> Otherwise, a weak reference become strong one, because you referencing >>> a block strongly and therefore subscriber too, >>> since block referencing subscriber through one of its vars. >>> >>> So, without ephemerons you have to invent some workarounds by >>> rewriting above code with something like: >>> >>> >>> self weakOn: Foo do: [:announcement :myself | >>> myself bar >>> ]. >>> >>> in the above, a block no longer referencing receiver (a subsriber), >>> and instead it will be passed as extra argument >>> to the block. >>> >>> ( except that still, you will have a problem, if closure keeps a >>> reference to home context, which in own turn referencing subscriber >>> through context's receiver.. so without emphemerons you should be >>> really careful) >>> >>> And of course, i think that the usefulness of Announcements is quite >>> limited without proper weak subscription support, >>> because weak subscriptions makes things a lot more easier: you don't >>> have to explicitly unsubscribe some object, once you no longer using >>> it , >>> which as to me means that about 99% of all subscriptions in system >>> will be weak ones , simply to prevent potential problems with hanging >>> references, and because you don't have to worry about unsubscribing. >>> >>> And of course, without weak-block subscriptions, the ease of use of >>> subscription mechanism is a bit limited. >>> So, instead of writing simple and cool: >>> >>> self weakOn: Foo do: [:announcement | self bar ]. >>> >>> >>> you must do more elaborate (and IMO less elegant) >>> >>> self weakOn: Foo send: #handleFooAnnouncement: . >>> >>> and then in #handleFooAnnouncement: you making 'self bar' >>> >>> P.S. the #weakOn: ... is not part of Announcements protocol , it is >>> just an example of 'meta-message' to reveal an intent to create a weak >>> subscription to some announcer by using receiver as a subscriber. >>> >>> >>>> best, >>>> Esteban >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Feb. 15, 2011

Re: [Pharo-project] UI fixes for the day...

by StÃ©phane Ducasse

On Feb 15, 2011, at 5:20 PM, Gary Chambers wrote: > And another... > > Watery theme menu box to use multistate button (as per Glamorous). > Must spend some time refactoring system window as much of the control > box things were for Squeak comaptability... Pleassssssse :) > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, February 15, 2011 3:49 PM > Subject: Re: [Pharo-project] UI fixes for the day... > > > thanks Gary > It will be integrated in 1.3. > > Stef > > On Feb 15, 2011, at 2:15 PM, Gary Chambers wrote: > >> Attached cs files for: >> >> Fixup window pane colours wrt faded background windows. (factored over to UITheme). >> >> Fix for hotspot of eydropper cursor when picking colour from screen in ColorSelectorDialogWindow, >> >> Regards, Gary >> <ColorSelectorHotspotFix.1.cs><PaneColorFixes.1.cs> > > <WateryMenuBoxChanges.1.cs>

Feb. 15, 2011

Re: [Pharo-project] Issue 3705 in pharo: UI Enhancements

by pharo＠googlecode.com

Comment #2 on issue 3705 by stephane...(a)gmail.com: UI Enhancements http://code.google.com/p/pharo/issues/detail?id=3705 (No comment was entered for this change.) Attachments: ColorSelectorHotspotFix.1.cs 1021 bytes PaneColorFixes.1.cs 1.8 KB WateryMenuBoxChanges.1.cs 14.0 KB

Feb. 15, 2011

[Pharo-project] [COTDC] 12 - PluggableListMorphByItem

by laurent laffont

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

Feb. 15, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Nicolas Cellier

2011/2/15 Igor Stasenko <siguctua(a)gmail.com>: > On 15 February 2011 12:50, David T. Lewis <lewis(a)mail.msen.com> wrote: >> On Tue, Feb 15, 2011 at 08:00:18AM +0100, St?phane Ducasse wrote: >>> Eliot >>> >>> you use caseOf: for the generation of C in Slang and VM maker. >>> Now this means that >>> Â Â Â - it does not need to be inlined >>> Â Â Â - it could be packaged with VMMaker >>> >>> Are these two points correct? >> >> No. >> >> VMMaker is used in many images, not just Pharo. And #caseOf: >> is used in packages other than VMMaker. So moving it into the >> VMMaker package would be a Bad Thing To Do. >> > > I agree. > Then probably, Pharo should move it to separate 'Crap-compat' package. > > ;-P > Agree, that's the way to go, and you handle it with a Pharo specific ConfigurationOf... Nicolas > You don't need to remove #caseOf: implementation. I can stay. Just > remove a compiler hacks for it :) > > P.S. i patched MessageNode class>>initialize > to test if VMMaker can work without compiler support of caseof: > and as it was expected it works quite well. > > I recompiled VMMaker package and then generated full source code of > everything, and then built VM. No any errors. > >> Dave >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Feb. 15, 2011

[Pharo-project] weak announcements

by Tudor Girba

Hi everyone, So, the current situation is that we can make rather quickly on:send:to: work weakly. There is an almost working version in Lukas' repository, and Esteban and me will try to get it to work. Now, the question is where to publish this. I would suggest to create an official squeaksource.com/announcements repository. Is that Ok for you, or do you prefer to have it in squeaksource.com/PharoTaskForces? Cheers, Doru On 15 Feb 2011, at 18:21, Tudor Girba wrote: > Hi Esteban, > > I finished the Glamour changes to only use on:send:to: between the Glamour model and the Glamour renderer. > > Cheers, > Doru > > > On 15 Feb 2011, at 17:37, Tudor Girba wrote: > >> Hi Esteban, >> >> I started to refactor all usages of on:do: and when:do: into on:send:to: in the core of Glamour. I am almost finished. >> >> Now the only question is if we want to distinguish between WeakAnnouncer and Announcer. Is there a performance penalty or another kind of drawback in merging the two and use the WeakAnnouncer implementation only? >> >> The other thing is that we need to add on:send:to:with: and on:send:to:withAll: because we need to handle extra parameters (given that we cannot access local variables). >> >> Cheers, >> Doru >> >> >> >> On 15 Feb 2011, at 13:45, Esteban Lorenzano wrote: >> >>> Well... not exactly, still something to do: the weak associations on weakannouncer are getting a lot of pairs #selector->nil and we need to think in a way to clean this. But this is doable :) >>> In other order of things, I think we should explicitly forbid the use of #on:do: and #when:do: until the fix for blocks is ready. >>> >>> Cheers, >>> Esteban >>> >>> El 14/02/2011, a las 6:55p.m., Tudor Girba escribiÃ³: >>> >>>> Aha. Thanks a lot. Ok, let's do that. Is it true that the Lukas' Announcements already provide the support for on:send:to: ? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On 14 Feb 2011, at 22:04, Esteban Lorenzano wrote: >>>> >>>>> Hi, >>>>> Well, this means, in the mean time, if we want to solve our issue 492 using weak announcements, we need to replace all #on:do: calls for #on:send:to: >>>>> :( >>>>> >>>>> Cheers, >>>>> Esteban >>>>> >>>>> Inicio del mensaje reenviado: >>>>> >>>>>> De: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>>>> Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00 >>>>>> Para: Pharo-project(a)lists.gforge.inria.fr >>>>>> Asunto: Re: [Pharo-project] Working with weak announcements... >>>>>> Responder a: Pharo-project(a)lists.gforge.inria.fr >>>>>> >>>>>> good question :) >>>>>> >>>>>> On FHi, >>>>>>> I'm working with weak announcements, >>>>>> >>>>>> good we need that. >>>>>> Igor was telling me that the right anwser are ephemerons (but for that: gc change is required). >>>>>> Now it would be good to have first a solution at image level >>>>>> >>>>>>> trying to make it work, and I have a problem in #on:do: protocol (or #when:do:) >>>>>>> I try to explain: >>>>>>> >>>>>>> This method receives a block, not an object/selector, so I can't create a WeakMessageSend which is the appropriate message to handle in other cases. >>>>>>> Well, the real question is... how can I produce a "Weak BlockClosure reference" who can die if receiver dies? >>>>>>> I tried some hacks (really ugly hacks, btw), but fail completely. >>>>>>> Any idea? >>>>>>> >>>>>>> best, >>>>>>> Esteban >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Problem solving efficiency grows with the abstractness level of problem understanding." >>>> >>>> >>>> >>> >> >> -- >> www.tudorgirba.com >> >> "Reasonable is what we are accustomed with." >> > > -- > www.tudorgirba.com > > "Every now and then stop and ask yourself if the war you're fighting is the right one." > > > -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

Feb. 15, 2011

Re: [Pharo-project] [COTDC] 11 - ColorMappingCanvas

by laurent laffont

On Tue, Feb 15, 2011 at 6:09 PM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > Just a thought... > > Note that, by default, for a window with a model object... the "About" > window menu option > will show the class comment for the model. > > Once we have all classes commented, it might be nice to review existing > comments (long job)! > oh.... do you have a script to detect automatically bad comments ? ;) > > Try on a SystemBrowser, for instance... quite cryptic! > arrgggggg Laurent > > Regards, Gary > > ----- Original Message ----- > *From:* laurent laffont <laurent.laffont(a)gmail.com> > *To:* An open mailing list to discuss any topics related to an > open-sourceSmalltalk <pharo-project(a)lists.gforge.inria.fr> > *Sent:* Monday, February 14, 2011 5:45 PM > *Subject:* [Pharo-project] [COTDC] 11 - ColorMappingCanvas > > Today: ColorMappingCanvas > > > 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 > >

Feb. 15, 2011

Re: [Pharo-project] [COTDC] 11 - ColorMappingCanvas

by laurent laffont

So the comment I propose mixing what you said with my understanding: I'm an abstract class which introduce a filter between a drawing request and the final output, handled by #mapColor: For each potential pixel operation like: source -> op -> output it introducing a color mapping stage: source -> op -> mapping -> output Then #mapColor: can be redefined in subclasses to implement more specific behavior. For example: - ShadowDrawingCanvas will replace the rendered color with the color of shadow (if not transparent). - AlphaBlendingCanvas will add or intensify alpha of rendered color. For an easy to understand example see #drawPolygon:color:borderWidth:borderColor: ShadowDrawingCanvas: see ColorMappingCanvas comment. AlphaBlendingCanvas: see ColorMappingCanvas comment. Laurent. On Mon, Feb 14, 2011 at 7:57 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 14 February 2011 18:45, laurent laffont <laurent.laffont(a)gmail.com> > wrote: > > Today: ColorMappingCanvas > > > > As far as i understood, this class is abstract, and its subclasses > implement more specific behavior > - shadow > - semitransparency mapping > > > The idea of is kind of canvas is to modify/filter the final output in > rendering pipe.. > i.e., for each potential pixel operation like: > > source -> op -> output > > it introducing a color mapping stage: > > source -> op -> mapping -> output > > > So, then for instance you could make a subclass which could turn all > colors to be grayscale (disregarding that initial input was in > colors). > > in fact i think this guy took wrong direction. It is much more > effective to let the canvas to draw whatever it wants to some > backup/temporary surface, and once it done, simply blit + color-map > result to destination form using one, single strike. > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Feb. 15, 2011

Re: [Pharo-project] Loading Seaside into Pharo 1.2 core

by Dale Henrichs

On 02/15/2011 01:55 AM, Torsten Bergmann wrote: > Dale wrote: >> I am presently working on Seaside 3.0.4 which will correctly load into >> Pharo1.2, > > According to his mail Mike wants to load it into a Pharo1.2-Core > (maybe for minimal deployment) - not into a Pharo1.2-Developer image. I want to clarify that the 3.0.4 configuration _is_ intended to correctly load into PharoCore1.2. Dale

Feb. 15, 2011

Re: [Pharo-project] Working with weak announcements...

by Tudor Girba

Hi Esteban, I finished the Glamour changes to only use on:send:to: between the Glamour model and the Glamour renderer. Cheers, Doru On 15 Feb 2011, at 17:37, Tudor Girba wrote: > Hi Esteban, > > I started to refactor all usages of on:do: and when:do: into on:send:to: in the core of Glamour. I am almost finished. > > Now the only question is if we want to distinguish between WeakAnnouncer and Announcer. Is there a performance penalty or another kind of drawback in merging the two and use the WeakAnnouncer implementation only? > > The other thing is that we need to add on:send:to:with: and on:send:to:withAll: because we need to handle extra parameters (given that we cannot access local variables). > > Cheers, > Doru > > > > On 15 Feb 2011, at 13:45, Esteban Lorenzano wrote: > >> Well... not exactly, still something to do: the weak associations on weakannouncer are getting a lot of pairs #selector->nil and we need to think in a way to clean this. But this is doable :) >> In other order of things, I think we should explicitly forbid the use of #on:do: and #when:do: until the fix for blocks is ready. >> >> Cheers, >> Esteban >> >> El 14/02/2011, a las 6:55p.m., Tudor Girba escribiÃ³: >> >>> Aha. Thanks a lot. Ok, let's do that. Is it true that the Lukas' Announcements already provide the support for on:send:to: ? >>> >>> Cheers, >>> Doru >>> >>> >>> On 14 Feb 2011, at 22:04, Esteban Lorenzano wrote: >>> >>>> Hi, >>>> Well, this means, in the mean time, if we want to solve our issue 492 using weak announcements, we need to replace all #on:do: calls for #on:send:to: >>>> :( >>>> >>>> Cheers, >>>> Esteban >>>> >>>> Inicio del mensaje reenviado: >>>> >>>>> De: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>>> Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00 >>>>> Para: Pharo-project(a)lists.gforge.inria.fr >>>>> Asunto: Re: [Pharo-project] Working with weak announcements... >>>>> Responder a: Pharo-project(a)lists.gforge.inria.fr >>>>> >>>>> good question :) >>>>> >>>>> On FHi, >>>>>> I'm working with weak announcements, >>>>> >>>>> good we need that. >>>>> Igor was telling me that the right anwser are ephemerons (but for that: gc change is required). >>>>> Now it would be good to have first a solution at image level >>>>> >>>>>> trying to make it work, and I have a problem in #on:do: protocol (or #when:do:) >>>>>> I try to explain: >>>>>> >>>>>> This method receives a block, not an object/selector, so I can't create a WeakMessageSend which is the appropriate message to handle in other cases. >>>>>> Well, the real question is... how can I produce a "Weak BlockClosure reference" who can die if receiver dies? >>>>>> I tried some hacks (really ugly hacks, btw), but fail completely. >>>>>> Any idea? >>>>>> >>>>>> best, >>>>>> Esteban >>>>> >>>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Problem solving efficiency grows with the abstractness level of problem understanding." >>> >>> >>> >> > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

Feb. 15, 2011