- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Installing Rubrik into 3alpha

by Tudor Girba

Just make sure it still works on Pharo 2.0 for a little while. Doru On Thu, Aug 15, 2013 at 12:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Hi, > > I tried to install Rubrik in 3alpha (yes, yes, I know... is development, > etc., etc., but I wanted to test precisely how it is behaving a text > package with the changes we are introducing :) ) > Well... configuration fails because there is a "repeated slot", > enabledHolder. > > This is because RubTextModel is shadowing a property that already exists > on AbstractBasicWidget (and that's not allowed with new opal compiler). > > Now... I just removed it on RubTextModel and everything is working so... I > wonder if this change could be introduced so I can continue playing without > need to hack it each time? ;) > > cheers, > Esteban > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 15, 2013

Installing Rubrik into 3alpha

by Esteban Lorenzano

Hi, I tried to install Rubrik in 3alpha (yes, yes, I know... is development, etc., etc., but I wanted to test precisely how it is behaving a text package with the changes we are introducing :) ) Well... configuration fails because there is a "repeated slot", enabledHolder. This is because RubTextModel is shadowing a property that already exists on AbstractBasicWidget (and that's not allowed with new opal compiler). Now... I just removed it on RubTextModel and everything is working so... I wonder if this change could be introduced so I can continue playing without need to hack it each time? ;) cheers, Esteban

Aug. 15, 2013

Re: [Pharo-dev] doLayoutIn: killing the image

by StÃ©phane Ducasse

On Aug 15, 2013, at 11:42 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Aug 15, 2013, at 10:45 , StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> probably that show: invokes somehow doLayoutIn: >> >> Stef > > Yes, when you show something on screen, its layout usually has to be computed first. > To be on the safe side, never use anything but #haltOnce to debug graphics code, or you WILL end up in infinite loops hanging your image really, really often. > Which should also answer your question of why can interrupt the UI process, it's the only foolproof way to debug UI code in a familiar way ;) ;) I did that. I imagine that I will also try haltIf: and friends. > > Cheers, > Henry

Aug. 15, 2013

Re: [Pharo-dev] doLayoutIn: killing the image

by Henrik Johansen

On Aug 15, 2013, at 10:45 , StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > probably that show: invokes somehow doLayoutIn: > > Stef Yes, when you show something on screen, its layout usually has to be computed first. To be on the safe side, never use anything but #haltOnce to debug graphics code, or you WILL end up in infinite loops hanging your image really, really often. Which should also answer your question of why can interrupt the UI process, it's the only foolproof way to debug UI code in a familiar way ;) Cheers, Henry

Aug. 15, 2013

Re: [Pharo-dev] doLayoutIn: killing the image

by StÃ©phane Ducasse

probably that show: invokes somehow doLayoutIn: Stef On Aug 15, 2013, at 10:23 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > > In this method I just added Transcript show: '.'. > and tried to open a transcript and it freezes the image systematically :( > Any ideas why? > > Stef > > > doLayoutIn: layoutBounds > "Compute a new layout based on the given layout bounds." > > "Note: Testing for #bounds or #layoutBounds would be sufficient to > figure out if we need an invalidation afterwards but #outerBounds > is what we need for all leaf nodes so we use that." > > | layout box priorBounds | > priorBounds := self outerBounds. > submorphs isEmpty ifTrue: [^fullBounds := priorBounds]. > "Send #ownerChanged to our children" > submorphs do: [:m | m ownerChanged]. > layout := self layoutPolicy. > layout ifNotNil: [layout layout: self in: layoutBounds]. > self adjustLayoutBounds. > fullBounds := self privateFullBounds. > box := self outerBounds. > box = priorBounds > ifFalse: [self invalidRect: (priorBounds quickMerge: box)] >

Aug. 15, 2013

Re: [Pharo-dev] XML writer in the default image

by Tudor Girba

+1 On Thu, Aug 15, 2013 at 10:10 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > +1 > > On Aug 15, 2013, at 9:41 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > > > On Aug 15, 2013, at 2:15 AM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > > > >> As reported a while ago ( > https://pharo.fogbugz.com/default.asp?7412#80347) the TestRunner > >> is crashing when test failures accidentally spit out XML sensitive > characters: > >> > >> > https://ci.inria.fr/pharo/view/all/job/Pharo-3.0-Regression-Tests/304/VM=vm… > >> > >> I don't really see a reason to generate XML by concatenating strings, > so I wonder > >> whether we could include the XMLWriter in the default image? > > > > Why don't we load HDTestRunner when needed? And HDTestRunner could then > use XMLWriter > > > >> This way I could finally fix the HDTestRunner with very little effort. > > > > I will finish to pop up my list and start to work on managing the image > with Metacello > > because we should build it based on subproject > > RB > > Nautilus > > Athens > > NativeBoost > > AsmJit > > Zinc > > OPAL > > were/are managed with metacello so we could be there :) > > > > Stef > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 15, 2013

doLayoutIn: killing the image

by StÃ©phane Ducasse

Hi In this method I just added Transcript show: '.'. and tried to open a transcript and it freezes the image systematically :( Any ideas why? Stef doLayoutIn: layoutBounds "Compute a new layout based on the given layout bounds." "Note: Testing for #bounds or #layoutBounds would be sufficient to figure out if we need an invalidation afterwards but #outerBounds is what we need for all leaf nodes so we use that." | layout box priorBounds | priorBounds := self outerBounds. submorphs isEmpty ifTrue: [^fullBounds := priorBounds]. "Send #ownerChanged to our children" submorphs do: [:m | m ownerChanged]. layout := self layoutPolicy. layout ifNotNil: [layout layout: self in: layoutBounds]. self adjustLayoutBounds. fullBounds := self privateFullBounds. box := self outerBounds. box = priorBounds ifFalse: [self invalidRect: (priorBounds quickMerge: box)]

Aug. 15, 2013

why can we interrupt the UI thread?

by StÃ©phane Ducasse

Aug. 15, 2013

Re: [Pharo-dev] XML writer in the default image

by Esteban Lorenzano

+1 On Aug 15, 2013, at 9:41 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 15, 2013, at 2:15 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> As reported a while ago (https://pharo.fogbugz.com/default.asp?7412#80347) the TestRunner >> is crashing when test failures accidentally spit out XML sensitive characters: >> >> https://ci.inria.fr/pharo/view/all/job/Pharo-3.0-Regression-Tests/304/VM=vm… >> >> I don't really see a reason to generate XML by concatenating strings, so I wonder >> whether we could include the XMLWriter in the default image? > > Why don't we load HDTestRunner when needed? And HDTestRunner could then use XMLWriter > >> This way I could finally fix the HDTestRunner with very little effort. > > I will finish to pop up my list and start to work on managing the image with Metacello > because we should build it based on subproject > RB > Nautilus > Athens > NativeBoost > AsmJit > Zinc > OPAL > were/are managed with metacello so we could be there :) > > Stef > >

Aug. 15, 2013

Re: [Pharo-dev] XML writer in the default image

by StÃ©phane Ducasse

On Aug 15, 2013, at 2:15 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > As reported a while ago (https://pharo.fogbugz.com/default.asp?7412#80347) the TestRunner > is crashing when test failures accidentally spit out XML sensitive characters: > > https://ci.inria.fr/pharo/view/all/job/Pharo-3.0-Regression-Tests/304/VM=vm… > > I don't really see a reason to generate XML by concatenating strings, so I wonder > whether we could include the XMLWriter in the default image? Why don't we load HDTestRunner when needed? And HDTestRunner could then use XMLWriter > This way I could finally fix the HDTestRunner with very little effort. I will finish to pop up my list and start to work on managing the image with Metacello because we should build it based on subproject RB Nautilus Athens NativeBoost AsmJit Zinc OPAL were/are managed with metacello so we could be there :) Stef

Aug. 15, 2013