- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] What is WeakActionSequence?

by StÃ©phane Ducasse

On Oct 5, 2013, at 12:28 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Oct 5, 2013, at 9:44 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On Oct 4, 2013, at 7:28 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> What is that class? No comments, two single methods on Object that refer to it? >> >> unknownâ¦ there are far too many event systems in the imageâ¦ > > this is why we should have a discussion because I want to know if announcements can be used to replace > triggerEvent: So we should pay attention because this is not simple. Now the fact that announcement carn handle symbol is a good news > > the problem is that you have also recurseMessage used by the diff tool. > ExclusiveWeakMessageSend NonReentrantWeakMessageSend

Oct. 5, 2013

Re: [Pharo-dev] What is WeakActionSequence?

by StÃ©phane Ducasse

this related to the eventManager triggerEvent: in Object Stef

Oct. 5, 2013

Re: [Pharo-dev] What is WeakActionSequence?

by StÃ©phane Ducasse

On Oct 5, 2013, at 9:44 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Oct 4, 2013, at 7:28 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> What is that class? No comments, two single methods on Object that refer to it? > > unknownâ¦ there are far too many event systems in the imageâ¦ this is why we should have a discussion because I want to know if announcements can be used to replace triggerEvent: the problem is that you have also recurseMessage used by the diff tool. Stef

Oct. 5, 2013

Re: [Pharo-dev] [update 3.0] #30444

by StÃ©phane Ducasse

On Oct 5, 2013, at 9:36 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Oct 5, 2013, at 9:23 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> On Oct 3, 2013, at 9:22 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On Oct 3, 2013, at 9:19 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>>> marcus for the critics next time please keep them else we will not be able to decide if we used them or not. >>>> This is not three little classes that will change something. Especially when they are part of a large library. >>>> >>> >>> But we don't use them. >> >> Yes but let us the time to think. >> First we should run the critics on everything then fix the problem. > > -> the critic explicitly did not run them (there are more of that kind that i did not remove) > -> I checked them and they where checking for special pragma tagged methods. Some pragmas > that where used in some project but I have never seen them used *ever*. > >> We should reorganize many things. Removing three classes that are well identified is not >> nice because now if I want to know which rules were not good I will have to load I do not know which >> version. >> > > The rules where really useless, they where testing a convention we don't use *and* they where already > omitted by the critic browser. Here are the rationals of the three: > > rationale > ^ 'Checks that methods marked with <modifier: #final> is never overridden.' > rationale > ^ 'Checks that a method marked with <modifier: #override> overrides an actual superclass method.' > rationale > ^ 'Checks that methods marked with <modifier: #super> are always called when overridden.' > yes that ones :) > Marcus > > > > >

Oct. 5, 2013

Re: [Pharo-dev] [update 3.0] #30448

by Benjamin

Can you point me where to load your code and how to end up in a situation where I can play with the spec ? :P Ben On Oct 4, 2013, at 11:11 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Damn, the last row of the last plugins fills all the window... > > -- Pavel > > 2013/10/4 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> Thanks, this seems to work: >> >> defaultSpec >> >> | layout | >> layout := SpecLayout composed. >> self pluginClasses do: [ :c | >> layout add: {#model. #class. #pluginOf:. c. #defaultSpec} ]. >> >> ^ layout. >> >> >> plugin code on the instance side looks like this: >> >> defaultSpec >> >> ^ SpecLayout composed >> newRow:[: r | >> r add: #finderButtonModel; >> add: #browserButtonModel] >> height: 25. >> >> >> -- Pavel >> >> 2013/10/4 Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com>: >>> Since you are doing some really edge use of Spec, >>> it's not covered by Spec easily. >>> >>> But if on you model you have a method returning your pluginClasses, you could do maybe: >>> >>> | layout | >>> layout := SpecLayout composed. >>> self pluginClasses do: [ :c | >>> layout add: {#model. pluginOf:. c} ] >>> >>> I am not sure it works, but it worth a try :P >>> >>> Ben >>> >>> On Oct 4, 2013, at 9:28 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> >>>> This was the original code for the spec that embeds plugins. As you >>>> can see, it had to use ugly addMorph:. I do not think that I need to >>>> do something special. Has the current Spec a better way how to do >>>> that? >>>> >>>> defaultSpec >>>> >>>> | spec | >>>> spec := OrderedCollection with: #ContainerModel. >>>> spec addAll: {#changeTableLayout. >>>> #listDirection:. #topToBottom. >>>> #hResizing:. #spaceFill. >>>> #vResizing:. #spaceFill.}. >>>> self pluginClasses do: [:c | >>>> spec add: #addMorph:. >>>> spec add: {(self pluginOf: c) defaultSpec}]. >>>> ^ spec asArray. >>>> >>>> 2013/10/4 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>>>> In other words... I have a model that has some plugins. I need to >>>>> generate a spec that embeds specs generated for each plugin. Models >>>>> for this embedded specs must be the plugins, not the original model. >>>>> >>>>> -- Pavel >>>>> >>>>> 2013/10/4 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>>>>> well, and the version with "SpecLayout composed" when I do not need >>>>>> direct fractions? >>>>>> >>>>>> ^ SpecLayout composed >>>>>> newRow:[: r | >>>>>> r add: #finderButtonModel] >>>>>> height: 25 >>>>>> >>>>>> How to send #finderButtonModel to different object than SpecInterpreter model? >>>>>> >>>>>> -- Pavel >>>>>> >>>>>> 2013/10/4 Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com>: >>>>>>> ^{ #ContainerModel. >>>>>>> >>>>>>> #vShrinkWrap. >>>>>>> >>>>>>> #add:. {{self. #finderButtonModel}. >>>>>>> >>>>>>> #layout:. #(FrameLayout >>>>>>> >>>>>>> rightFraction: 0.125)}. >>>>>>> >>>>>>> #add:. {{self. #browserButtonModel}. >>>>>>> >>>>>>> #layout:. #(FrameLayout >>>>>>> >>>>>>> leftFraction: 0.125 >>>>>>> rightFraction: 0.25)}} >>>>>>> >>>>>>> This should work, but looks strange though :P >>>>>>> >>>>>>> Ben >>>>>>> >>>>>>> On Oct 4, 2013, at 8:13 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>>>>>> >>>>>>> Ben, >>>>>>> >>>>>>> how now should look code like this: >>>>>>> >>>>>>> defaultSpec >>>>>>> >>>>>>> ^{ #ComposableSpec. >>>>>>> #vResizing:. #shrinkWrap. >>>>>>> #add:. {{self. #finderButtonModel}. >>>>>>> #layout:. #(FrameLayout >>>>>>> rightFraction: 0.125)}. >>>>>>> #add:. {{self. #browserButtonModel}. >>>>>>> #layout:. #(FrameLayout >>>>>>> leftFraction: 0.125 >>>>>>> rightFraction: 0.25)}} >>>>>>> >>>>>>> -- Pavel >>>>>>> >>>>>>> 2013/10/4 Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com>: >>>>>>> >>>>>>> For Spec users: >>>>>>> >>>>>>> The change is mostly backward compatible :) >>>>>>> 2 things really changed: >>>>>>> - direct access to a model's widget is not returning what it used to return. >>>>>>> This is done on purpose since >>>>>>> it's very often a bad idea to directly access the widget. >>>>>>> - some behaviour on trees are now only available after the tree build. This >>>>>>> is because some properties >>>>>>> have been moved on the adapter directly, which is reachable only after the >>>>>>> model build. >>>>>>> You can use `whenBuiltDo:` to add post-build actions. >>>>>>> >>>>>>> Enjoy this new Spec :P >>>>>>> >>>>>>> Ben >>>>>>> >>>>>>> On Oct 4, 2013, at 2:31 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>>>>> >>>>>>> 30448 >>>>>>> ----- >>>>>>> >>>>>>> 11740 Remove Morphic dependency from Spec >>>>>>> https://pharo.fogbugz.com/f/cases/11740 >>>>>>> >>>>>>> A Huge change from Ben... >>>>>>> >>>>>>> Diff information: >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1292.diff >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tabs-MarcusDenker.33.diff >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.265… >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tools-MarcusDenker.150.d… >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tests-MarcusDenker.35.di… >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-MorphicAdapters-MarcusDe… >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-PolyWidgets-MarcusDenker… >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Layout-MarcusDenker.58.d… >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Inspector-MarcusDenker.1… >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Examples-MarcusDenker.48… >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Debugger-MarcusDenker.16… >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.175.di… >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Builder-MarcusDenker.43.… >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Bindings-MarcusDenker.35… >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/NautilusRefactoring-MarcusDen… >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Adapters-MarcusDenker.3.… >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-CriticBrowser-Marcus… >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Keymapping-Tools-Spec-MarcusD… >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/KeyChain-MarcusDenker.58.diff >>>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/HudsonBuildTools20-MarcusDenk… >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> >>> >>> >

Oct. 5, 2013

Re: [Pharo-dev] [ANN] Mustache templates

by StÃ©phane Ducasse

Norbert I know tat jesus did an implementation of Mustache too. So may be you should have a look at it http://ss3.gemstone.com.ss/SCouchDBViewServer.html Stef On Oct 4, 2013, at 2:16 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Very nice! > > Doru > > > On Fri, Oct 4, 2013 at 1:47 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 04 Oct 2013, at 12:58, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > > Am 04.10.2013 um 12:32 schrieb Alexandre Bergel <alexandre.bergel(a)me.com>: > > > >> What is a mustache template? > >> > > http://norbert.hartl.name/blog/2013/10/03/mustache-templates-for-smalltalk/ > > Nice! > > > Norbert > > > >> On 4 Oct 2013, at 03:56, Torsten Bergmann <astares(a)gmx.de> wrote: > >> > >>>> I like to announce my smalltalk port of mustache templates. > >>> > >>> Cool! > >>> > >>>> To load it do > >>> > >>> Consider making a copy into MetaRepoForPharo20 or MetaReporForPharo30 > >>> if it is working in these versions. > >>> > >>> That way it is easily accessible via Config browser. > >>> > >>> Thx > >>> T. > >>> > >> > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Oct. 5, 2013

[update 3.0] #30453

by Marcus Denker

30453 ----- 11571 Add command line commands for managing the preferences https://pharo.fogbugz.com/f/cases/11571 - change --no-preferences to --no-default-preferences because that's what it does ;) - remove StartupLoader (deprecated) from the startup list Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-CommandLine-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/StartupPreferences-MarcusDenk…

Oct. 5, 2013

Re: [Pharo-dev] additional Milestone label for applications

by Marcus Denker

On Oct 4, 2013, at 7:37 PM, btc(a)openinworld.com wrote: > btc(a)openinworld.com wrote: >> I've been advised that for application related issues tracked on Fogbugz (e.g. for PharoLauncher) to avoid tagging the Milestone as 'Pharo3.0' - which is reserved for image related issues. Fair enough, but the only available alternative 'Later' just doesn't seem a good fit. Can adding another milestone be considered, like 'non-image' or 'application'. >> btw, my reasoning for tagging with Pharo3.0 was to do with the idea of simultaneous release [1] of related tools with the image. With the CI now operating for a lot of projects, it is not unfeasible that such a co-ordinated release occur. This might be good to encourage participation in testing and bug hunting in the final weeks and maybe speed the uptake of 3.0. On the other hand, it might unreasonably stretch resources trying to co-ordinate it. >> >> [1] http://wiki.eclipse.org/Simultaneous_Release >> >> cheers -ben >> > Elsewhere I see a comment by Marcus that "we need to find a way how to use the bug tracker for projects..." I notice there is already a Projects field while the Areas field is entirely unused (perhaps this is from following the guidelines of [2]). One option might be recategorizing many of the existing Projects as Areas under one Project='Image'. Maybe that would require an unreasonable effort to implement, but I float the idea anyway. Perhaps the Fogbugz sysadmins have some tools that could assist. > So the idea is that I want to have filter for "Need to be reviewed" "need to be integrated" that are possible to get to empty (that is: that are only related to the image itself). https://pharo.fogbugz.com/f/filters/36/Review https://pharo.fogbugz.com/f/filters/35/Integration e.g. https://pharo.fogbugz.com/f/filters/35/Integration has two issues that I can't act uppon. So they are not "to be included, because I can not include them. How do we make a filter that shows me not the other projects? Marcus

Oct. 5, 2013

Re: [Pharo-dev] What is WeakActionSequence?

by Marcus Denker

On Oct 4, 2013, at 7:28 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > What is that class? No comments, two single methods on Object that refer to it? unknownâ¦ there are far too many event systems in the imageâ¦ Marcus

Oct. 5, 2013

Re: [Pharo-dev] [update 3.0] #30444

by Marcus Denker

On Oct 5, 2013, at 9:23 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Oct 3, 2013, at 9:22 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On Oct 3, 2013, at 9:19 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> marcus for the critics next time please keep them else we will not be able to decide if we used them or not. >>> This is not three little classes that will change something. Especially when they are part of a large library. >>> >> >> But we don't use them. > > Yes but let us the time to think. > First we should run the critics on everything then fix the problem. -> the critic explicitly did not run them (there are more of that kind that i did not remove) -> I checked them and they where checking for special pragma tagged methods. Some pragmas that where used in some project but I have never seen them used *ever*. > We should reorganize many things. Removing three classes that are well identified is not > nice because now if I want to know which rules were not good I will have to load I do not know which > version. > The rules where really useless, they where testing a convention we don't use *and* they where already omitted by the critic browser. Here are the rationals of the three: rationale ^ 'Checks that methods marked with <modifier: #final> is never overridden.' rationale ^ 'Checks that a method marked with <modifier: #override> overrides an actual superclass method.' rationale ^ 'Checks that methods marked with <modifier: #super> are always called when overridden.' Marcus

Oct. 5, 2013