June 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] An ugly question about menu and domain objects

by StÃ©phane Ducasse

for the logger in StephaneDucasse/SystemLogger/ But I'm not really happy. Do not use the configuration since I was editing it. Stef On Jun 30, 2013, at 10:11 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Where can I look at this code? > > Doru > > > On Sun, Jun 30, 2013 at 8:32 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Ok I will look at it or you will show me. > For now I'm in brainstorming and API extension stabilisation phase. > > Stef > > On Jun 30, 2013, at 8:23 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> What I didi for Nautilus was to use pragmas, >> this way I have my domain object (Nautilus), and menus are defined in another class (NautilusRefactoring by example). >> And NautilusRefactoring knows how to communicate with Nautilus. >> >> This way, the domain abject can stay clean, and I have a special class for menu :) >> >> >> Ben >> >> On Jun 30, 2013, at 7:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> yes so far I added >>> >>> menus >>> "ugly just to brainstorm and get something working now" >>> >>> ^ #(('inspect' #inspect)) >>> >>> to build menus but I find that not that nice >>> >>> On Jun 30, 2013, at 7:34 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: >>> >>>> On Sun, Jun 30, 2013 at 7:06 PM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> Now I'm wondering how I could define menu items in a way that I do not polute the domain object with >>>>> menus. >>>> >>>> >>>> you can use double-dispatch and create both a #menuForLogItem: and a >>>> #menuForSubLogItem: on the UI. This means to add a #menuFromUI: method >>>> in each subclass. You can also use a visitor to have a #accept: method >>>> in each subclass instead. >>>> >>>> -- >>>> Damien Cassou >>>> http://damiencassou.seasidehosting.st >>>> >>>> "Success is the ability to go from one failure to another without >>>> losing enthusiasm." >>>> Winston Churchill >>>> >>> >>> >> > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

June 30, 2013

Re: [Pharo-dev] Better Interruption in 2.0

by Tudor Girba

Is this integrated in 2.0 already? Doru On Fri, Jun 28, 2013 at 3:12 PM, Goubier Thierry <thierry.goubier(a)cea.fr>wrote: > Hi Stephan, > > I've put a slice to integrate that and the overall UserInterrupt code to > get it to work. Can you try it? > > It's SLICE-Issue-10569-Backport-20-**Better-Interrruption-**ThierryGoubier.1 > in http://ss3.gemtalksystems.com/**ss/PharoInbox/<http://ss3.gemtalksystems.com/ss/PharoInbox/> > > Thierry > > Le 27/06/2013 00:40, Stephan Eggermont a Ã©crit : > > Using Henry's >> >> processToInterrupt >> "Look for best candidate to interrupt: >> - any scheduled non-finalization process of lower priority >> - the weak-finalization process, if scheduled >> - the UI process >> Never interrupt the idle process, since killing it is fatal" >> >> | fallback | >> >> fallback := UIManager default uiProcess. >> Processor >> scanSchedule: [:p | >> "suspendedContext sender == nil usually means >> that process is only scheduled but had no chance to run" >> ((p ~~ Processor backgroundProcess) and: [ p >> suspendedContext sender notNil]) ifTrue: [ >> p ~~ WeakArray >> runningFinalizationProcess >> ifTrue: [^p] >> ifFalse: [fallback := p]] ] >> startingAt: Processor activePriority. >> ^fallback >> >> in todays Moose 4.8 (on Pharo 20608) on the april 10 VM >> allows for better interruption, up to the point where the system runs out >> of memory >> without a lowspace warning after I assume trying to collect garbage for >> 20 minutes or so. >> >> Stephan >> >> > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > -- www.tudorgirba.com "Every thing has its own flow"

June 30, 2013

Re: [Pharo-dev] An ugly question about menu and domain objects

by Tudor Girba

Where can I look at this code? Doru On Sun, Jun 30, 2013 at 8:32 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Ok I will look at it or you will show me. > For now I'm in brainstorming and API extension stabilisation phase. > > Stef > > On Jun 30, 2013, at 8:23 PM, Benjamin < > benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > What I didi for Nautilus was to use pragmas, > this way I have my domain object (Nautilus), and menus are defined in > another class (NautilusRefactoring by example). > And NautilusRefactoring knows how to communicate with Nautilus. > > This way, the domain abject can stay clean, and I have a special class for > menu :) > > > Ben > > On Jun 30, 2013, at 7:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > yes so far I added > > menus > "ugly just to brainstorm and get something working now" > > ^ #(('inspect' #inspect)) > > to build menus but I find that not that nice > > On Jun 30, 2013, at 7:34 PM, Damien Cassou <damien.cassou(a)gmail.com> > wrote: > > On Sun, Jun 30, 2013 at 7:06 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > Now I'm wondering how I could define menu items in a way that I do not > polute the domain object with > menus. > > > > you can use double-dispatch and create both a #menuForLogItem: and a > #menuForSubLogItem: on the UI. This means to add a #menuFromUI: method > in each subclass. You can also use a visitor to have a #accept: method > in each subclass instead. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

June 30, 2013

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

by kilon

I am not going to post my code here cause it has become too big , you can find it here http://www.smalltalkhub.com/#!/~kilon/GLTutorial <http://www.smalltalkhub.com/#!/~kilon/GLTutorial> I tried adding newlines with String cr to my shaders strings, but apparently opengl is not convinced. It looks like smalltalk cr is not converted to C "\n" newlines. So how I do that ? -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696465.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 30, 2013

Re: [Pharo-dev] An ugly question about menu and domain objects

by StÃ©phane Ducasse

Ok I will look at it or you will show me. For now I'm in brainstorming and API extension stabilisation phase. Stef On Jun 30, 2013, at 8:23 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > What I didi for Nautilus was to use pragmas, > this way I have my domain object (Nautilus), and menus are defined in another class (NautilusRefactoring by example). > And NautilusRefactoring knows how to communicate with Nautilus. > > This way, the domain abject can stay clean, and I have a special class for menu :) > > > Ben > > On Jun 30, 2013, at 7:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> yes so far I added >> >> menus >> "ugly just to brainstorm and get something working now" >> >> ^ #(('inspect' #inspect)) >> >> to build menus but I find that not that nice >> >> On Jun 30, 2013, at 7:34 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> >>> On Sun, Jun 30, 2013 at 7:06 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> Now I'm wondering how I could define menu items in a way that I do not polute the domain object with >>>> menus. >>> >>> >>> you can use double-dispatch and create both a #menuForLogItem: and a >>> #menuForSubLogItem: on the UI. This means to add a #menuFromUI: method >>> in each subclass. You can also use a visitor to have a #accept: method >>> in each subclass instead. >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Success is the ability to go from one failure to another without >>> losing enthusiasm." >>> Winston Churchill >>> >> >> >

June 30, 2013

Re: [Pharo-dev] An ugly question about menu and domain objects

by Benjamin

What I didi for Nautilus was to use pragmas, this way I have my domain object (Nautilus), and menus are defined in another class (NautilusRefactoring by example). And NautilusRefactoring knows how to communicate with Nautilus. This way, the domain abject can stay clean, and I have a special class for menu :) Ben On Jun 30, 2013, at 7:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > yes so far I added > > menus > "ugly just to brainstorm and get something working now" > > ^ #(('inspect' #inspect)) > > to build menus but I find that not that nice > > On Jun 30, 2013, at 7:34 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > >> On Sun, Jun 30, 2013 at 7:06 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Now I'm wondering how I could define menu items in a way that I do not polute the domain object with >>> menus. >> >> >> you can use double-dispatch and create both a #menuForLogItem: and a >> #menuForSubLogItem: on the UI. This means to add a #menuFromUI: method >> in each subclass. You can also use a visitor to have a #accept: method >> in each subclass instead. >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." >> Winston Churchill >> > >

June 30, 2013

Re: [Pharo-dev] An ugly question about menu and domain objects

by StÃ©phane Ducasse

yes so far I added menus "ugly just to brainstorm and get something working now" ^ #(('inspect' #inspect)) to build menus but I find that not that nice On Jun 30, 2013, at 7:34 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Sun, Jun 30, 2013 at 7:06 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Now I'm wondering how I could define menu items in a way that I do not polute the domain object with >> menus. > > > you can use double-dispatch and create both a #menuForLogItem: and a > #menuForSubLogItem: on the UI. This means to add a #menuFromUI: method > in each subclass. You can also use a visitor to have a #accept: method > in each subclass instead. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

June 30, 2013

Re: [Pharo-dev] An ugly question about menu and domain objects

by Damien Cassou

On Sun, Jun 30, 2013 at 7:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Now I'm wondering how I could define menu items in a way that I do not polute the domain object with > menus. you can use double-dispatch and create both a #menuForLogItem: and a #menuForSubLogItem: on the UI. This means to add a #menuFromUI: method in each subclass. You can also use a visitor to have a #accept: method in each subclass instead. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 30, 2013

An ugly question about menu and domain objects

by StÃ©phane Ducasse

Hi I have domain objects for example logs. And I have a UI. Now I would like to let the programmer to extend the Log items (either by subclassing or extensions) and add new actions. For example I would like that the compiler is able to define errors as log items so that after we can go to the log panel and press 'identify' and that we jump to the place in the code. Now I'm wondering how I could define menu items in a way that I do not polute the domain object with menus. Stef

June 30, 2013

Re: [Pharo-dev] SqueakSource3 with new server name

by Dale K. Henrichs

June 30, 2013