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

Re: [Pharo-project] Cog builds on Hudson

by Igor Stasenko

On 15 February 2011 18:13, Igor Stasenko <siguctua(a)gmail.com> wrote: > I modified the Cog config made by Marcus to sync with my changes in scripts. > > https://pharo-ic.lille.inria.fr/hudson/view/Cog/ > > i also added a new target for building - Stack VM > (except that it not works now, because Hudson can't pick up the built > artifacts despite VM built successfully -- lets wait for Marcus to fix > that , since i'm not expert in Hudson :) ). > > Adding another two is also a piece of cake - just copy existing > configuration and change > destination directory and configuration class used for generating > sources and build config. oops.. i was to hurry typing. By "another two" i meant - Cog with debug info and - StackVM with debug info > > The script i made for Hudson can work even for macs, > it takes 3 arguments: > Â - git repo url > Â - working subdirectory name where to place everything > Â - cmake configuration class name (which build to perform) > > that's all you need to build VM from scratch using Hudson > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Feb. 15, 2011

[Pharo-project] Cog builds on Hudson

by Igor Stasenko

I modified the Cog config made by Marcus to sync with my changes in scripts. https://pharo-ic.lille.inria.fr/hudson/view/Cog/ i also added a new target for building - Stack VM (except that it not works now, because Hudson can't pick up the built artifacts despite VM built successfully -- lets wait for Marcus to fix that , since i'm not expert in Hudson :) ). Adding another two is also a piece of cake - just copy existing configuration and change destination directory and configuration class used for generating sources and build config. The script i made for Hudson can work even for macs, it takes 3 arguments: - git repo url - working subdirectory name where to place everything - cmake configuration class name (which build to perform) that's all you need to build VM from scratch using Hudson -- Best regards, Igor Stasenko AKA sig.

Feb. 15, 2011

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

by Gary Chambers

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)! Try on a SystemBrowser, for instance... quite cryptic! Regards, Gary ----- Original Message ----- From: laurent laffont To: An open mailing list to discuss any topics related to an open-sourceSmalltalk 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] Working with weak announcements...

by Gary Chambers

Lol, good luck! Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, February 15, 2011 4:46 PM Subject: Re: [Pharo-project] Working with weak announcements... On 15 February 2011 10:00, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > 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. 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] Working with weak announcements...

by Igor Stasenko

On 15 February 2011 10:00, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > 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. 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] Working with weak announcements...

by Tudor Girba

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."

Feb. 15, 2011

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

by Gary Chambers

Note the theme must be reinitialised for this one to cache the forms... UITheme current class beCurrent Regards, Gary ----- Original Message ----- From: "Gary Chambers" <gazzaguru2(a)btinternet.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, February 15, 2011 4:20 PM Subject: Re: [Pharo-project] UI fixes for the day... > 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... > > 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> > >

Feb. 15, 2011

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

by Gary Chambers

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... 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>

Feb. 15, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #74 on issue 3583 by stephane...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 OK doru do you integrate it in Shout?

Feb. 15, 2011

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

by pharo＠googlecode.com

Updates: Status: Fixed Labels: -Fixed Comment #1 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.)

Feb. 15, 2011