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

Re: [Pharo-dev] Pharo contribution CI problem

by Norbert Hartl

Christophe, > Am 01.02.2016 um 12:18 schrieb Christophe Demarey <Christophe.Demarey(a)inria.fr>: > > Hi Norbert, > > Le 1 fÃ©vr. 2016 Ã 11:09, Norbert Hartl a Ã©crit : > >> I created a new build on the pharo contribution CI. But regardless what I enter in the axis for the PHARO variable the build is triggered with "default" as PHARO version. >> >> Any hints how to change that? Is this a bug? > > It is because you only defined one value for the axis. > If you define more than one, you will get the expected values. > By the way, the $PHARO env variable should have the correct value even with only one value for the axis. > I defined "20 30 40 50" as PHARO axis. Norbert

Feb. 1, 2016

Re: [Pharo-dev] Pharo contribution CI problem

by Christophe Demarey

Hi Norbert, Le 1 fÃ©vr. 2016 Ã 11:09, Norbert Hartl a Ã©crit : > I created a new build on the pharo contribution CI. But regardless what I enter in the axis for the PHARO variable the build is triggered with "default" as PHARO version. > > Any hints how to change that? Is this a bug? It is because you only defined one value for the axis. If you define more than one, you will get the expected values. By the way, the $PHARO env variable should have the correct value even with only one value for the axis. Christophe

Feb. 1, 2016

Pharo contribution CI problem

by Norbert Hartl

I created a new build on the pharo contribution CI. But regardless what I enter in the axis for the PHARO variable the build is triggered with "default" as PHARO version. Any hints how to change that? Is this a bug? thanks, Norbert

Feb. 1, 2016

Re: [Pharo-dev] Thanks nicolai and the sprinter for fixing the selectorTable

by Esteban Lorenzano

> On 01 Feb 2016, at 08:24, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-01-31 21:52 GMT+01:00 Cyril Ferlicot Delbecque <cyril.ferlicot(a)gmail.com <mailto:cyril.ferlicot@gmail.com>>: > > > On 31/01/2016 15:23, stepharo wrote: > > Hi guys > > > > Thanks for this fix. > > I will start recording videos. > > > > Stef > > > > > In the last image I get errors all the time when I use unimplemented > methods. > I think this might be related if this was done to add syntax > highlighting for unimplemented methods. > > unlikely, many 'icon'-methods are now rendered as 'unimplemeted' methods, because > ThemeIcons uses #doesNotUnderstand indirection to create the named icons. And that seems to work > well. then this is a good reason to remove those calls (I implemented them like that to provide compatibility, but correct way should be to use #iconNamed:â¦) :) Esteban > And the error about > > RubShoutStylerDecorator(Object)>>doesNotUnderstand: #recomposeFrom:to:delta: > happened already to me, sometimes, before we made this change for the (Symbol SelectorTabe). > > What exactly had you done when this error occured. editing a new method/edit an existing method but > call a new unimplemented method/writing some code in playground, using unimplemented methods? > > > > RubShoutStylerDecorator(Object)>>doesNotUnderstand: #recomposeFrom:to:delta: > [ super doesNotUnderstand: aMessage ] in > RubShoutStylerDecorator(RubParagraphDecorator)>>doesNotUnderstand: > #recomposeFrom:to:delta: in Block: [ super doesNotUnderstand: aMessage ] > BlockClosure>>cull: > Context>>evaluateSignal: > Context>>handleSignal: > MessageNotUnderstood(Exception)>>signal > RubCurrentLineBarDecorator(Object)>>doesNotUnderstand: > #recomposeFrom:to:delta: > [ super doesNotUnderstand: aMessage ] in > RubCurrentLineBarDecorator(RubParagraphDecorator)>>doesNotUnderstand: > #recomposeFrom:to:delta: in Block: [ super doesNotUnderstand: aMessage ] > BlockClosure>>cull: > Context>>evaluateSignal: > Context>>handleSignal: > MessageNotUnderstood(Exception)>>signal > RubExtraSelectionDecorator(Object)>>doesNotUnderstand: > #recomposeFrom:to:delta: > [ super doesNotUnderstand: aMessage ] in > RubExtraSelectionDecorator(RubParagraphDecorator)>>doesNotUnderstand: > #recomposeFrom:to:delta: in Block: [ super doesNotUnderstand: aMessage ] > BlockClosure>>cull: > Context>>evaluateSignal: > Context>>handleSignal: > MessageNotUnderstood(Exception)>>signal > RubOpeningClosingDelimiterDecorator(Object)>>doesNotUnderstand: > #recomposeFrom:to:delta: > [ super doesNotUnderstand: aMessage ] in > RubOpeningClosingDelimiterDecorator(RubParagraphDecorator)>>doesNotUnderstand: > #recomposeFrom:to:delta: in Block: [ super doesNotUnderstand: aMessage ] > BlockClosure>>cull: > Context>>evaluateSignal: > Context>>handleSignal: > MessageNotUnderstood(Exception)>>signal > RubTextMethodLink(Object)>>doesNotUnderstand: #tes > RubTextMethodLink(TextLink)>>= > Array(SequenceableCollection)>>hasEqualElements: > Array(SequenceableCollection)>>= > Array(SequenceableCollection)>>hasEqualElements: > RunArray>>= > > -- > Cyril

Feb. 1, 2016

Re: [Pharo-dev] Warning in Pharo 5

by Andrei Chis

Currently GTDebugger doesn't work with the pre-debug window. I'll fix this shortly. Cheers, Andrei On Sun, Jan 31, 2016 at 6:58 PM, Cyril Ferlicot Delbecque < cyril.ferlicot(a)gmail.com> wrote: > > On 31/01/2016 18:33, Esteban Lorenzano wrote: > > probably this is the defaultâ¦ which it should not! > > > > Esteban > > > > GTGenericStackDebugger alwaysOpenFullDebugger. -> false > > I still get the same thing than on the screen. > > -- > Cyril > >

Feb. 1, 2016

Re: [Pharo-dev] 17502. Morph layoutProperties must not be nil by default

by Esteban Lorenzano

but layoutProperties are not immutable so if you receive an instance of NullLayoutProperties (singleton), and you do something like this: myMorph cellInset: 5, you has to check for correct properties anywayâ¦ thatâs why is implemented as this: cellInset: aNumber "Layout specific. This property specifies an extra inset for each cell in the layout." self assureTableProperties cellInset: aNumber. self layoutChanged. I do not think answering a null object here is goodâ¦ it will cause infinite problems and you will need to check for correct properties anyway. In any case, I would reject such a change (specially at this moment). Esteban > On 01 Feb 2016, at 08:20, stepharo <stepharo(a)free.fr> wrote: > > A good solution is to have > share by default and instance-based when needed. > > For that > use a classVariable to instantiate only one NullLayoutProperties > use an instance variable that points to it by default > > one demand change the instance variable to point to a new created instance > > => you can remove all the ifNil: > > >

Feb. 1, 2016

Re: [Pharo-dev] Thanks nicolai and the sprinter for fixing the selectorTable

by Cyril Ferlicot Delbecque

On 01/02/2016 09:01, Nicolai Hess wrote: > > > The problem is, that TextLink is a base class of the RubTextLink classes > and those of course are used during > styling. The debugger message is misleading (due to this awfull > #doesNotUnderstand redirection) but if you > look at the call stack, you see: > > "MessageNotUnderstood: RubTextMethodLink>>classAndMethod" > > Ok thank you. Rubric should get ride of those DNU before the release of Pharo 5. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Feb. 1, 2016

Re: [Pharo-dev] Rubric: spotter with preview leaks some memory

by Nicolai Hess

2016-01-31 14:52 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-01-31 13:46 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> Hmm. I work with Spotter with preview enabled all the timeâ¦ but I do not >> seem to get to the point in which I have to kill the styling process. How >> do the signs look like (maybe I am not looking at the right thing)? >> >> Cheers, >> Doru >> > > Open Spotter > Enable Preview > search for EllipseMorph > dive into class EllipseMorph > dive into (all) instance methods > scroll through the list of methods ~ 1/2 methods per second > close spotter > open Playground > evaluate > RubTextLine allInstances size "-> 140000" (yes 140 THOUSEND) > again evaulate > > Smalltalk garbageCollect. > RubTextLine allInstances size "if you are lucky this goes doewn to ~ < 10 > instances but" > > repeat this (spotter with preview scroll through the list) > maybe scroll faster > > Smalltalk garbageCollect. > RubTextLine allInstances size "->1206704" > and after every new evuation, the count of instances grows instead of > shrink. > And even with no further action, the amount of (system)memory used by > pharo steadily grows. > > The only way to make this list go down again, open process browser and > look for a process like > "a Process in RunArray>>at:setRunOffsetAndValue:" > and terminate this process. > > Smalltalk garbageCollect. > RubTextLine allInstances size "-> 4" > > And (very often) I get this error: OrderedCollection(Object)>>errorSubscriptBounds: OrderedCollection>>at: RubTextComposer>>recomposeFrom:to:delta: [ self composer recomposeFrom: start to: stop delta: delta ] in RubParagraph>>recomposeFrom:to:delta: in Block: [ self composer recomposeFrom: start to: stop delt...etc... RubParagraph>>disableDrawingWhile: RubParagraph>>recomposeFrom:to:delta: Message>>sendTo: [ aMessage sendTo: next ] in RubOpeningClosingDelimiterDecorator(RubParagraphDecorator)>>doesNotUnderstand: #recomposeFrom:to:delta: in Block: [ aMessage sendTo: next ] BlockClosure>>on:do: RubOpeningClosingDelimiterDecorator(RubParagraphDecorator)>>doesNotUnderstand: #recomposeFrom:to:delta: Message>>sendTo: [ aMessage sendTo: next ] in RubExtraSelectionDecorator(RubParagraphDecorator)>>doesNotUnderstand: #recomposeFrom:to:delta: in Block: [ aMessage sendTo: next ] BlockClosure>>on:do: RubExtraSelectionDecorator(RubParagraphDecorator)>>doesNotUnderstand: #recomposeFrom:to:delta: Message>>sendTo: [ aMessage sendTo: next ] in RubCurrentLineBarDecorator(RubParagraphDecorator)>>doesNotUnderstand: #recomposeFrom:to:delta: in Block: [ aMessage sendTo: next ] BlockClosure>>on:do: RubCurrentLineBarDecorator(RubParagraphDecorator)>>doesNotUnderstand: #recomposeFrom:to:delta: Message>>sendTo: [ aMessage sendTo: next ] in RubShoutStylerDecorator(RubParagraphDecorator)>>doesNotUnderstand: #recomposeFrom:to:delta: in Block: [ aMessage sendTo: next ] BlockClosure>>on:do: RubShoutStylerDecorator(RubParagraphDecorator)>>doesNotUnderstand: #recomposeFrom:to:delta: RubShoutStylerDecorator>>stylerStyled: RubShoutStylerDecorator>>stylerStyledInBackground: [ self privateStyle: text. view ifNotNil: [ view stylerStyledInBackground: text ] ] in [ backgroundProcess := [ self privateStyle: text. view ifNotNil: [ view stylerStyledInBackground: text ] ] forkAt: Processor userBackgroundPriority ] in RubSHTextStylerST80(SHTextStyler)>>styleInBackgroundProcess: in Block: [ self privateStyle: text.... [ self value. Processor terminateActive ] in BlockClosure>>newProcess in Block: [ self value.... > > > > >> >> >> > On Jan 31, 2016, at 9:42 AM, Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> > >> > >> > >> > 2016-01-25 20:10 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> > >> > >> > 2016-01-20 23:23 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> > >> > >> > 2016-01-20 19:18 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> > >> > >> > 2016-01-20 14:47 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: >> > Tried it in the last latest image and if I execute before >> #garbageCollect I just get 4 instances. >> > >> > Smalltalk garbageCollect. >> > RubTextLine allInstances size "4" >> > >> > Now indeed if I browse the same class in nautilus I get a much smaller >> number of RubTextLine instances >> > >> > >> > I opened a bugreport >> > 17437 >> > Rubric: spotter with preview leaks some memory >> > >> > >> > I tried to reproduce this behavior with GTInspector instead of Spotter, >> for example, inspect: >> > >> > MethodFinder methods >> > select on entry, -> another inspector pane shows up. Select th >> "Source"-tab. Now >> > scroll through the list of methods in the first inspector pane. For >> every method the second pane updates the >> > source tab with the code of the selected method. >> > >> > This generates many RubTextLine instances too. But not as many and I >> can always clean them up with Smalltalk garbageCollect. >> > So, the is something that spotter does differently. >> > >> > And even if Smalltalk garbageCollect would clean all instances, >> > I don't think it is right, that scrolling through the method list (with >> preview) should create hundred thousends of RubTextLine instances. >> > There is just not enough code visible, we definitly don't need that >> much. There is something wrong. >> > >> > Maybe these are all related >> > >> > 15153 Rubric mutability issue in RubTextComposer binary search >> > 17284 Rubric SubscriptOutOfBounds error >> > 17447 Playground and long number crashes with SubscriptOutOfBounds >> > >> > This may be an issue with text composer, called after styling and (I >> think) concurrent processes access >> > and modifiy the RubTextComposers #lines attribute. >> > >> > some other observations: >> > >> > RubTextComposer>>#needComposition compares prevText / newText >> (attributes) runs >> > ret := prevText runs ~= theText runs >> > >> > but both runs are often "different" even if they are for the same text: >> > The text link classes are compared by identity instead of equality. And >> > code like this >> > RubShoutStyleDecorator>>replaceFrom: start to: stop with: aText >> > self okToStyle >> > ifFalse: [ ^ next replaceFrom: start to: stop with: aText ]. >> > self >> > disableDrawingWhile: [ >> > aText addAttribute: self defaultFontChange. >> "<<<<--------- THIS" >> > text ifNil: [ text := self text ]. >> > text replaceFrom: start to: stop with: (self styler format: >> aText). >> > >> > will *always* add a trailing font change attribute, even if the prior >> styled and new styled text would be actually the same (originate from the >> same raw string)! >> > >> > there are multiple calls like >> > aText addAttribute: self defaultFontChange. >> > in other methods. >> > >> > GLMHighlighterTextStylerDecorator looks similiar with some minor >> changes (for no obvious reason and of course totally undocumented). >> > >> > Debugging this code is a pain with all the doesNotUnderstand redirection >> > Analysing this code is a pain with all the undocumented code, copy and >> pasted to GLM >> (GLMHighlighterTextRubEditingMode/GLMHighlighterTextStylerDecorator/GLMHighlighterTextParserStyler....) >> > copy and pasted *from* old text classes (with no indication if this is >> copied because it is used the same way or just DEAD code). >> > >> > And for real, does anyone work with spotter and preview enabled ? >> > I can not work with it for more than some minutes without triggering >> this allocation of awfull many RubTextLine instances. I have to >> > manually kill the styling process. no one? >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > On Wed, Jan 20, 2016 at 2:32 PM, Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> > Open fresh image 50536 >> > Open Spotter, >> > enable preview (cmd+p) >> > search for EllipseMorph >> > dive in instance-methods >> > scroll through the list one item after another. >> > >> > open playground >> > evaluate >> > RubTextLine allInstances size. "553896" >> > >> > >> > case 17421 is related to this, but does not fully solves this. >> > please review and comment on that fix, >> > so we can integrate this soon. >> > >> > The problem sometimes remains even with this fix. The memory >> > (instance count of RubTextLine) just grows in the background >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Don't give to get. Just give." >> >> >> >> >> >> >> >> >

Feb. 1, 2016

Re: [Pharo-dev] Thanks nicolai and the sprinter for fixing the selectorTable

by Nicolai Hess

2016-02-01 8:57 GMT+01:00 Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: > > > On Monday, 1 February 2016, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > >> >> >> 2016-02-01 8:37 GMT+01:00 Cyril Ferlicot Delbecque < >> cyril.ferlicot(a)gmail.com>: >> >>> >>> >>> On 01/02/2016 08:24, Nicolai Hess wrote: >>> > >>> > unlikely, many 'icon'-methods are now rendered as 'unimplemeted' >>> > methods, because >>> > ThemeIcons uses #doesNotUnderstand indirection to create the named >>> > icons. And that seems to work >>> > well. >>> > And the error about >>> > >>> > RubShoutStylerDecorator(Object)>>doesNotUnderstand: >>> #recomposeFrom:to:delta: >>> > happened already to me, sometimes, before we made this change for the >>> > (Symbol SelectorTabe). >>> > >>> > What exactly had you done when this error occured. editing a new >>> > method/edit an existing method but >>> > call a new unimplemented method/writing some code in playground, using >>> > unimplemented methods? >>> > >>> > >>> > -- >>> > Cyril >>> > >>> > >>> >>> In the class TextLink in the latest image I just typed this method, >>> formated (CMD-Shift-f) and saved: >>> >>> = anObject >>> ^ self species = anObject species and: [ self classAndMethod = >>> anObject >>> classAndMethod ] >>> >>> Then I got other errors at almost each character I typed in other >>> methods. >>> >> >> Maybe because, TextLink has no accessor for #classAndMethod :) >> >> >> > I know, I Wanted to create it latter. But this should not raise a Rubric > error and break the image :) > > I use all the time methods that I implement latter. > The problem is, that TextLink is a base class of the RubTextLink classes and those of course are used during styling. The debugger message is misleading (due to this awfull #doesNotUnderstand redirection) but if you look at the call stack, you see: "MessageNotUnderstood: RubTextMethodLink>>classAndMethod" > > >>> -- >>> Cyril >>> >>> >> > > -- > Cheers > Cyril Ferlicot > >

Feb. 1, 2016

Re: [Pharo-dev] Thanks nicolai and the sprinter for fixing the selectorTable

by Cyril Ferlicot

On Monday, 1 February 2016, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2016-02-01 8:37 GMT+01:00 Cyril Ferlicot Delbecque < > cyril.ferlicot(a)gmail.com > <javascript:_e(%7B%7D,'cvml','cyril.ferlicot(a)gmail.com');>>: > >> >> >> On 01/02/2016 08:24, Nicolai Hess wrote: >> > >> > unlikely, many 'icon'-methods are now rendered as 'unimplemeted' >> > methods, because >> > ThemeIcons uses #doesNotUnderstand indirection to create the named >> > icons. And that seems to work >> > well. >> > And the error about >> > >> > RubShoutStylerDecorator(Object)>>doesNotUnderstand: >> #recomposeFrom:to:delta: >> > happened already to me, sometimes, before we made this change for the >> > (Symbol SelectorTabe). >> > >> > What exactly had you done when this error occured. editing a new >> > method/edit an existing method but >> > call a new unimplemented method/writing some code in playground, using >> > unimplemented methods? >> > >> > >> > -- >> > Cyril >> > >> > >> >> In the class TextLink in the latest image I just typed this method, >> formated (CMD-Shift-f) and saved: >> >> = anObject >> ^ self species = anObject species and: [ self classAndMethod = >> anObject >> classAndMethod ] >> >> Then I got other errors at almost each character I typed in other methods. >> > > Maybe because, TextLink has no accessor for #classAndMethod :) > > > I know, I Wanted to create it latter. But this should not raise a Rubric error and break the image :) I use all the time methods that I implement latter. >> -- >> Cyril >> >> > -- Cheers Cyril Ferlicot

Feb. 1, 2016