- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] potential bug with PackaegSet

by Marcus Denker

On Jun 30, 2013, at 2:46 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I wonder if GRPharoPlatform>>compile: aString into: aClass classified: aSymbol is not just duplicating logic and as such > brings subtle bugs. > > Now the addAllFilesIn: is broken > > Implementing it as > > > compile: aString into: aClass classified: aSymbol > > [aClass compile: aString classified: aSymbol] on: Error do: [:ex | GRError signal: 'syntax error' ] > > works. I sent the information to the seaside mailing-list. > May be there are some other side effects but to me duplicating core logic outside of the core can be dangerous. It makes cleaning up the system very difficultâ¦ e.g. if we are supposed to introduce Opal while being backward compatible so that this methods still works, we can just stop now and do something else. Marcus

July 1, 2013

Re: [Pharo-dev] Better Interruption in 2.0

by Marcus Denker

On Jun 30, 2013, at 10:15 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Is this integrated in 2.0 already? > No: https://pharo.fogbugz.com/f/cases/10569 Slice needs to be checked. > 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/ > > 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"

July 1, 2013

WhatsUp from: 2013-07-01 until: 2013-07-14

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2013-07-14 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

July 1, 2013

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

by Sean P. DeNigris

Marcus Denker-4 wrote > 11060 Introduce WorldMorph as subclass of PasteUpMorph > https://pharo.fogbugz.com/f/cases/11060 Cool!!! I wonder why it was not done like that to begin with... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-update-3-0-30230-tp4696015p4696495.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 1, 2013

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