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

Re: [Pharo-project] Issue 3620 in pharo: Settings: OCompletion settings appear twice

by pharo＠googlecode.com

Comment #5 on issue 3620 by marcus.d...(a)gmail.com: Settings: OCompletion settings appear twice http://code.google.com/p/pharo/issues/detail?id=3620 So who commits this? me?

Feb. 15, 2011

Re: [Pharo-project] [COTDC] 12 - PluggableListMorphByItem

by Norbert Hartl

On 15.02.2011, at 19:08, laurent laffont wrote: > I hope one day we will have a comment like "I rock. I do wonderful things you never dream of. I'm an incredible well-designed piece of software...." :) > But that is a contradiction in itself. How can it rock if the comment sucks? :) Norbert > > > On Tue, Feb 15, 2011 at 7:03 PM, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > "Essentially useless in its current form. Probably intended to eventually deal with actual objects in the list rather than indexing/string-forms." > > Regards, Gary > ----- Original Message ----- > From: laurent laffont > To: An open mailing list to discuss any topics related to an open-sourceSmalltalk > Sent: Tuesday, February 15, 2011 5:37 PM > Subject: [Pharo-project] [COTDC] 12 - PluggableListMorphByItem > > 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

[Pharo-project] Issue 3707 in pharo: Syntax highlighting looks strange

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.2-DevImage New issue 3707 by marcus.d...(a)gmail.com: Syntax highlighting looks strange http://code.google.com/p/pharo/issues/detail?id=3707 ... especially using BOLD for variables (both global and local), but arguments use different color... messages are colored (and the same as arguments). I attach old and new png All very strange. Especially the bold is horrible. The only bold thing in a method should be the method signature at the top. Attachments: old.png 20.9 KB new.png 25.5 KB

Feb. 15, 2011

Re: [Pharo-project] [COTDC] 12 - PluggableListMorphByItem

by laurent laffont

I hope one day we will have a comment like "I rock. I do wonderful things you never dream of. I'm an incredible well-designed piece of software...." :) Laurent On Tue, Feb 15, 2011 at 7:03 PM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > "Essentially useless in its current form. Probably intended to eventually > deal with actual objects in the list rather than indexing/string-forms." > > 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:* Tuesday, February 15, 2011 5:37 PM > *Subject:* [Pharo-project] [COTDC] 12 - PluggableListMorphByItem > > 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] [COTDC] 12 - PluggableListMorphByItem

by Gary Chambers

"Essentially useless in its current form. Probably intended to eventually deal with actual objects in the list rather than indexing/string-forms." Regards, Gary ----- Original Message ----- From: laurent laffont To: An open mailing list to discuss any topics related to an open-sourceSmalltalk Sent: Tuesday, February 15, 2011 5:37 PM Subject: [Pharo-project] [COTDC] 12 - PluggableListMorphByItem 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] weak announcements

by Tudor Girba

Hi, Yes, it is meant to be integrated in Pharo 1.3. Ok, but then PharoTaskForces should not delete the packages after they are integrated. The reason is that I want to use these announcements before you release 1.3, and thus it will appear in ConfigurationOfGlamour. Is that Ok? Cheers, Doru On 15 Feb 2011, at 18:53, StÃ©phane Ducasse wrote: > if this is to be integrated in 1.3 (which I hope :)) then I would prefer PharoTaskForces > > Stef > > >> 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." >> >> >> >> >> > > -- www.tudorgirba.com "Some battles are better lost than fought."

Feb. 15, 2011

[Pharo-project] Issue 3706 in pharo: In OB: Text in comment pane of Browser uses syntax highlighting

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.2-DevImage New issue 3706 by marcus.d...(a)gmail.com: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706 In OB: Text in comment pane of Browser uses syntax highlighting ... dificult to write class comments like that

Feb. 15, 2011

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

by Gary Chambers

Sadly not ;-) Less than a few lines though.. Regards, Gary ----- Original Message ----- From: laurent laffont To: Pharo-project(a)lists.gforge.inria.fr Sent: Tuesday, February 15, 2011 5:31 PM Subject: Re: [Pharo-project] [COTDC] 11 - ColorMappingCanvas 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 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] Issue 3705 in pharo: UI Enhancements

by pharo＠googlecode.com

Comment #3 on issue 3705 by stephane...(a)gmail.com: UI Enhancements http://code.google.com/p/pharo/issues/detail?id=3705 UITheme current class beCurrent

Feb. 15, 2011

Re: [Pharo-project] weak announcements

by StÃ©phane Ducasse

if this is to be integrated in 1.3 (which I hope :)) then I would prefer PharoTaskForces Stef > 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