- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] rogue window instances

by stepharo

Le 24/6/15 21:44, stepharo a Ã©crit : > Doru I checked and I think that we have a memory leak with SystemWindow > I checked and we have the same in Pharo 40. > In Pharo 50 after many Smalltalk garbageCollectMost I get 5 windows. I was in Pharo 40 in fact. > when I get only one open. > Le 21/6/15 19:47, Tudor Girba a Ã©crit : >> Hi, >> >> In the latest Pharo #50125, I do this from the command line: >> >> ./pharo Pharo.image eval "SystemWindow allSubInstances" >> ==> >> an OrderedCollection(a RubFindReplaceDialogWindow(534511616) a >> GLMSystemWindow(58720256)) >> >> There are two strange things: >> - the GLMSystemWindow has a nil model, although if you inspect it, it >> visually looks like a Playground window (normal playgrounds have a >> GTPlayground instance as model). >> - the RubFindReplaceDialogWindow has findTextField as nil (while >> normally it should be some PluggableTextFieldMorph). >> >> Does anyone know where these come from? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> "Every thing has its own flow" >

June 25, 2015

Re: [Pharo-dev] Pharo 4 and Roassal

by stepharo

But even if package gets "used" and loaded in the image. We are going to use configuration everywhere. So you should start to really use them and do not put everything in one package :) Stef Le 21/6/15 03:29, Alexandre Bergel a Ã©crit : > I think this is because the latest glamour core was not in the base imageâ¦ I do not remember exactly. > > Alexandre > > >> On Jun 20, 2015, at 10:25 PM, Alejandro Infante <alejandroinfante91(a)gmail.com> wrote: >> >> Exactly, all the customized views are dependent of GlamourCore and also the Easel depends on Glamour for showing the examples. >> >> Alejandro >> >>> On Jun 20, 2015, at 10:22 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> >>> Alejandro, >>> >>> I do not remember why Roassal depends on Glamour? >>> I guess this is because of the GTInspector? >>> >>> Alexandre >>> >>>> On Jun 19, 2015, at 8:11 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: >>>> >>>> On 19-06-15 07:11, Alejandro Infante wrote: >>>>> Hi, >>>>> I did that because when using: >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> Gofer it >>>>> smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; >>>>> configurationOf: 'Roassal2'; >>>>> loadStable >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> It was installing 1.52 even though the stable version of Roassal was 1.12. >>>>> Instead if I used: >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> Gofer new smalltalkhubUser: 'ObjectProfile' >>>>> project: 'Roassal2'; >>>>> package: 'ConfigurationOfRoassal2'; >>>>> load. >>>>> ((Smalltalk at: #ConfigurationOfRoassal2) project version: #stable) load >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> I was getting the right version (1.12). >>>> Gofer>>loadStable does not use the >>>> >>>> ConfigurationOfRoassal2 class>>loadStable >>>> >>>> (which is undefined, but many configurations define as >>>> >>>> self project load: #stable >>>> >>>> but loadVersion: #stable, which uses the latest version marked #stable. >>>> >>>> So yes, that is something you'd want to fix in place. >>>> And warn about on the mailing list. >>>> >>>> In this version 1.12 then we see that Roassal is tightly coupled to >>>> an old version of GlamourCore. So either ConfigurationOfRoassal2 >>>> needs to add a new #stable version every time GlamourCore #stable >>>> for Pharo 4 is updated, or it should depend on GlamourCore #stable. >>>> And ConfigurationOfGlamourCore has actually the same problem, as >>>> #stable currently depends on an old version of Rubric. So that >>>> should have been one or two versions more. And please note that >>>> this is for the released Pharo 4, where we are only supposed to >>>> backport important fixes. >>>> >>>> I strongly suggest to make ConfigurationOfGlamourCore #stable >>>> depend on ConfigurationOfRubric #stable, and to make ConfigurationOfRoassal2 depend on ConfigurationOfGlamourCore #stable. >>>> >>>> Depending on #stable instead of #release1 or so works out ok >>>> here as long there is not supposed to be a new release for Pharo 4. >>>> >>>> Stephan >>>> >>>> >>>> >>>> >>>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>

June 25, 2015

Re: [Pharo-dev] Pharo 4 and Roassal

by stepharo

Le 21/6/15 03:22, Alexandre Bergel a Ã©crit : > Alejandro, > > I do not remember why Roassal depends on Glamour? > I guess this is because of the GTInspector? and this is a bad idea. You should have a package Roassal-GT that is different from Roassal-Core. Stef > > Alexandre > >> On Jun 19, 2015, at 8:11 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> On 19-06-15 07:11, Alejandro Infante wrote: >>> Hi, >>> I did that because when using: >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> Gofer it >>> smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; >>> configurationOf: 'Roassal2'; >>> loadStable >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> It was installing 1.52 even though the stable version of Roassal was 1.12. >>> Instead if I used: >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> Gofer new smalltalkhubUser: 'ObjectProfile' >>> project: 'Roassal2'; >>> package: 'ConfigurationOfRoassal2'; >>> load. >>> ((Smalltalk at: #ConfigurationOfRoassal2) project version: #stable) load >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> I was getting the right version (1.12). >> Gofer>>loadStable does not use the >> >> ConfigurationOfRoassal2 class>>loadStable >> >> (which is undefined, but many configurations define as >> >> self project load: #stable >> >> but loadVersion: #stable, which uses the latest version marked #stable. >> >> So yes, that is something you'd want to fix in place. >> And warn about on the mailing list. >> >> In this version 1.12 then we see that Roassal is tightly coupled to >> an old version of GlamourCore. So either ConfigurationOfRoassal2 >> needs to add a new #stable version every time GlamourCore #stable >> for Pharo 4 is updated, or it should depend on GlamourCore #stable. >> And ConfigurationOfGlamourCore has actually the same problem, as >> #stable currently depends on an old version of Rubric. So that >> should have been one or two versions more. And please note that >> this is for the released Pharo 4, where we are only supposed to >> backport important fixes. >> >> I strongly suggest to make ConfigurationOfGlamourCore #stable >> depend on ConfigurationOfRubric #stable, and to make ConfigurationOfRoassal2 depend on ConfigurationOfGlamourCore #stable. >> >> Depending on #stable instead of #release1 or so works out ok >> here as long there is not supposed to be a new release for Pharo 4. >> >> Stephan >> >> >> >> >>

June 25, 2015

Re: [Pharo-dev] rogue window instances

by stepharo

Doru I checked and I think that we have a memory leak with SystemWindow I checked and we have the same in Pharo 40. In Pharo 50 after many Smalltalk garbageCollectMost I get 5 windows. when I get only one open. Le 21/6/15 19:47, Tudor Girba a Ã©crit : > Hi, > > In the latest Pharo #50125, I do this from the command line: > > ./pharo Pharo.image eval "SystemWindow allSubInstances" > ==> > an OrderedCollection(a RubFindReplaceDialogWindow(534511616) a > GLMSystemWindow(58720256)) > > There are two strange things: > - the GLMSystemWindow has a nil model, although if you inspect it, it > visually looks like a Playground window (normal playgrounds have a > GTPlayground instance as model). > - the RubFindReplaceDialogWindow has findTextField as nil (while > normally it should be some PluggableTextFieldMorph). > > Does anyone know where these come from? > > Cheers, > Doru > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

June 24, 2015

Re: [Pharo-dev] GT needs love

by stepharo

thanks andrei Le 24/6/15 15:38, Andrei Chis a Ã©crit : > I'll have a look a bit later today > > > Cheers, > Andrei > > On Wed, Jun 24, 2015 at 3:33 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > > > > Hi guys > > Nicolas proposed several fixes of GT and we are waiting that > someone with a bit of knowledge integrate them in GT. > I can do it but I would prefer that somebody with knowledge takes > 10 min to do it. > > Stef > >

June 24, 2015

Re: [Pharo-dev] rogue window instances

by stepharo

Le 21/6/15 19:47, Tudor Girba a Ã©crit : > Hi, > > In the latest Pharo #50125, I do this from the command line: > > ./pharo Pharo.image eval "SystemWindow allSubInstances" > ==> > an OrderedCollection(a RubFindReplaceDialogWindow(534511616) a > GLMSystemWindow(58720256)) > > There are two strange things: > - the GLMSystemWindow has a nil model, although if you inspect it, it > visually looks like a Playground window (normal playgrounds have a > GTPlayground instance as model). > - the RubFindReplaceDialogWindow has findTextField as nil (while > normally it should be some PluggableTextFieldMorph). The RubFindReplaceDialogWindow only get its findTextField when the morph is built. newMainPanel "Answer a new main panel." ^self newDialogPanel addMorphBack: self newContentMorph; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ addMorphBack: self newButtonRow; yourself newContentMorph ^(self newColumn: { (self newGroupbox: nil for: (self newColumn: { self newFindTextEntryMorph. (self newRow: { (self newColumn: { (self newCheckboxFor: self getSelected: #isRegex setSelected: #isRegex: getEnabled: nil label: 'Regular expression' translated help: nil). (self newCheckboxFor: self getSelected: #caseSensitive setSelected: #caseSensitive: getEnabled: nil label: 'Case sensitive' translated help: nil). (self newCheckboxFor: self getSelected: #entireWordsOnly setSelected: #entireWordsOnly: getEnabled: nil label: 'Entire words only' translated help: nil) } ). (self newColumn: { (self newCheckboxFor: self getSelected: #searchBackwards setSelected: #searchBackwards: getEnabled: nil label: 'Search backwards' translated help: nil). (self newCheckboxFor: self getSelected: #wrapAround setSelected: #wrapAround: getEnabled: nil label: 'Wrap around' translated help: nil) } ) } ) } ) ). (self newLabelGroup: {'Replace with: ' translated -> self newReplaceTextEntryMorph}) vResizing: #shrinkWrap} ) newFindTextEntryMorph | entryCompletion pt | entryCompletion := EntryCompletion new dataSourceBlock: [:currText | self prevFinds ]; filterBlock: [:currApplicant :currText | currText size = 0 or: [currApplicant asUppercase includesSubstring: currText asString asUppercase]]. pt := (self newAutoAcceptTextEntryFor: self get: #findText set: #findText: class: String getEnabled: nil help: 'Enter the text to find' translated entryCompletion: entryCompletion) acceptOnCR: false; ghostText: 'Text to find'; withDropListButton; crAction: [:t | self find]; yourself. pt textMorph autoFit: true; wrapFlag: false; margins: (2@1 corner: 2@1). textFieldMorph := pt. ^ pt We could initialize and set the variable to the "pt" and avoid to have to do it in the newFindTextEntryMorph but I do not see what we would gain. > > Does anyone know where these come from? > > Cheers, > Doru > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

June 24, 2015

Re: [Pharo-dev] rogue window instances

by stepharo

Doru this is strange because it seems that each time I open an inspector I get a new GLMSystemWindow. Are you holding a reference in Playgorund or inspector? I tried to use pointer to but no chance. Stef Le 21/6/15 19:47, Tudor Girba a Ã©crit : > Hi, > > In the latest Pharo #50125, I do this from the command line: > > ./pharo Pharo.image eval "SystemWindow allSubInstances" > ==> > an OrderedCollection(a RubFindReplaceDialogWindow(534511616) a > GLMSystemWindow(58720256)) > > There are two strange things: > - the GLMSystemWindow has a nil model, although if you inspect it, it > visually looks like a Playground window (normal playgrounds have a > GTPlayground instance as model). > - the RubFindReplaceDialogWindow has findTextField as nil (while > normally it should be some PluggableTextFieldMorph). > > Does anyone know where these come from? > > Cheers, > Doru > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

June 24, 2015

Re: [Pharo-dev] Pharo 4.0 crash

by stepharo

Hi sabina on which OS are you? Stef Le 19/6/15 09:31, Sabine Manaa a Ã©crit : > Hi, > > I have crashes from time to time. Are they useful for you? > If yes, where is the vm-dev list? > > Regards > Sabine > > > > -- > View this message in context: http://forum.world.st/Pharo-4-0-crash-tp4832475p4833169.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

June 24, 2015

Re: [Pharo-dev] rogue window instances

by stepharo

Le 21/6/15 19:47, Tudor Girba a Ã©crit : > Hi, > > In the latest Pharo #50125, I do this from the command line: > > ./pharo Pharo.image eval "SystemWindow allSubInstances" > ==> > an OrderedCollection(a RubFindReplaceDialogWindow(534511616) a > GLMSystemWindow(58720256)) > > There are two strange things: > - the GLMSystemWindow has a nil model, although if you inspect it, it > visually looks like a Playground window (normal playgrounds have a > GTPlayground instance as model). > - the RubFindReplaceDialogWindow has findTextField as nil (while > normally it should be some PluggableTextFieldMorph). > > Does anyone know where these come from? It may be related to the changes I did that removes the use of this ugly findDeeplyMorphSuchThat: [:e | e isKindOf: PluggbaleTextMorph and: [ e respondsTo: xxxx ] We should ban such methods. Stef > > Cheers, > Doru > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

June 24, 2015

Re: [Pharo-dev] does anyone actually uses NewList?

by stepharo

Le 24/6/15 17:18, Peter UhnÃ¡k a Ã©crit : > I use NewListModel, which uses NewList; but feel free to remove it if > there is replacement. yes there is a really nice one :) Fast and with a nice design. > > Peter > > On Wed, Jun 24, 2015 at 4:38 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com > <mailto:yuriy.tymchuk@me.com>> wrote: > > I used it in some places, but you can remove it :) > > Uko > > > On 24 Jun 2015, at 16:27, Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>> wrote: > > > > because we are targeting to remove it from system: it never > worked properly and the design is not satisfactory. > > at the moment Iâm writing this, Stef is integrating the Fast > Tableâ¦ the replacement for lists I started to write and I hope you > (the community) help me finish :P > > > > Esteban > > >

June 24, 2015