March 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Some Memory Leak

by Max Leske

> On 24 Mar 2015, at 16:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 24 Mar 2015, at 16:50, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: >> >> There are lot of spotter objects that do not get garbaged collected >> >> GTSpotter allInstances size --> 29 in my image > > I got 10 now. > > But can they cause megabytes to be locked up ? If they work like Nautilus then thereâs a huge tree attached to every one, with morphs, weak references, contextsâ¦ I think there was (and maybe there still is) a problem with detection of circular dependencies and weak references. If you register actions in the EventManager (or whatever itâs called now) make sure that they are cleared. Then, there used to be a class variable somewhere that held on to the single instance of some kind of work space factory (or some such thing) which strongly holds on to stuff and prevents garbage collection. I donât know what has been cleaned by now but thereâs a lot of potential for such thingsâ¦ I had to write some code a while ago to get rid of window instances that wouldnât be garbage collected. Iâve attached the file outs, maybe someone can use them (they are for Pharo 1.3 though, so maybe not of too much useâ¦) Cheers, Max > >> On Tue, Mar 24, 2015 at 4:16 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Yes, there are clearly objects lying around. I suspect it has to do with Playground or Inspector, but I am not sure. >> >> Doru >> >> On Tue, Mar 24, 2015 at 4:13 PM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> On 24 Mar 2015, at 15:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Hi, >>> >>> There seems to be some kind of memory leak in recent Pharo 4.0 images. Image size (as saved on disk) seems to be growing very rapidly under normal use (development with Nautilus, Spotter, GTPlayground, GTInspector and Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and they seem to increase constantly, over a period of days. >> >> Are you saying that the static image size is growing? Dynamic growth could easily be explained by leaks in NativeBoost for instance. But static image size means that there are objects lying around that shouldnât (at least that should be easier to debug). >> >>> >>> One way to look at memory use is with >>> >>> SpaceTally printSpaceAnalysis >>> >>> but that takes a while. >>> >>> Please help us find and fix this issue. >>> >>> Thanks, >>> >>> Sven >>> >>> >> >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

March 24, 2015

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

by kilon alios

" if you read my mail, you will notice that I said BOTH are on the table (and we are actually moving oon both): - Bloc is the redesign - In the mean time we WORK and ENCOURAGE others to work on improve it." Last time I asked about Bloc , I was told not to use it and instead stick with Spec or Morphic. I said it before and will say it again, you guys need to sit down and make a roadmap for Pharo because I am reading a lot of conflicting posts in this mailing list and this is does not give the professional look Pharo wants to show to people outside Pharo. As a user "replace in the long run" is not enough ! The original author of Bloc , Alain, also said that he is pretty much the only one that works on Bloc (with some help from Stef) and if people dont start helping him out he is going to give up. How many more threads should we have about the GUI future of Pharo before people really get the message that we need a roadmap ? Additionally , Pharo needs a roadmap , seriously it does. "but Morphic it self has several fundamental flaws that cannot be fixed and thatâs why in the long, very long way, needs to be replaced. " What flaws , where , when , how , why ? So much discussion that Morphic must go , close to zero discussion what the actual problems are. "First, Athens is not a replace for Morphic, is a replace for the canvas in which morphs are drawn. So is not Morphic or Athensâ¦ is "Morph using DisplayPlugin" or "Morphic using Athens". Second I did not say Athens is to replace Morphic . From my understanding Bloc is based on Athens and Bloc is to replace Morphic. Correct me If I am wrong. "Glamour is very mature and Iâve used it serval timesâ¦ and in theory Brick will be compatible with Glamour (mostly) so even if developers deprecate one for the other you will be able to use your code (mostly). " Brick is called non usable by its own authors. Glamour is framework of building browsers and simplified GUIs , its nowhere near as powerful as Morphic and is based on Morphic. From the looks of its is not even as powerful as Spec. Through the couple years I have been around I have seen at best a couple of question on how to make it work compared to hundreds of questions about Spec and Morphic . How something can be matured if it is not heavily used ? "But anyway, how can Athens be so slow? Why? Can you share some info? " You ask me to tell you why Athens is slow when we have this discussion before ( a few months ago) and you told me that Athens is slow because of how Pharo handles rendering and that as soon as we move to SDL things will be 10 times faster. All I have to do is VGTiger runDemo and my 3Ghz Quad Cores beg me for mercy at 50% consumption. Calling it slow , is an understatement. Other much simpler example are very slow too like the sliding logo example at many more. Of course this problem affects Morphic too so personally I am examining the possibility that no pharo library will satisfy me and instead I will make my own GUI API on top of QT or HTML. Obviously more work for me, obviously a scenario that I want to avoid, but if the alternative is an app that consumes 50% cpu then I dont have much of a choice. Maybe I could take a look at Mars too.

March 24, 2015

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

by Thierry Goubier

2015-03-24 16:43 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > The same in Brick: > > GLMButtonBrick new >> marginLeft: 10; >> text: 'Parse'; >> vAlign: #center; >> hSpaceFill; >> openInBrickWindow > > > Yes, I agree - using composition for margin/padding/aligning is much more > simple, readable, fast and maintainable, than horrible scripting in brick, > sorry for that. > Yes, I'm pretty sure writing the same stuff in Motif or Windows 3.1 works too. Oh, well, maybe not in Windows 3.1 ;) And, so what? Is the contest writing a basic, business gui of the 80's the shortest way? Thierry

March 24, 2015

Re: [Pharo-dev] Some Memory Leak

by Tudor Girba

I also tried this: 1. Create a dummy class: Object subclass: #AAA instanceVariableNames: 'x' classVariableNames: '' category: 'AAA'. 2. Open a Playground and do it and go on this: a := #AAA asClass new. 3. In the second pane go on "self" 4. Close the Playground 5. Execute: 3 timesRepeat: [ Smalltalk garbageCollect ]. 6. Check: #AAA asClass allInstances. 7. Repeat if necessary, and after a while, the result after step 6 is not empty. Cheers, Doru On Tue, Mar 24, 2015 at 4:50 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > There are lot of spotter objects that do not get garbaged collected > > GTSpotter allInstances size --> 29 in my image > > On Tue, Mar 24, 2015 at 4:16 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Yes, there are clearly objects lying around. I suspect it has to do with >> Playground or Inspector, but I am not sure. >> >> Doru >> >> On Tue, Mar 24, 2015 at 4:13 PM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >>> > On 24 Mar 2015, at 15:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> > >>> > Hi, >>> > >>> > There seems to be some kind of memory leak in recent Pharo 4.0 images. >>> Image size (as saved on disk) seems to be growing very rapidly under normal >>> use (development with Nautilus, Spotter, GTPlayground, GTInspector and >>> Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and >>> they seem to increase constantly, over a period of days. >>> >>> Are you saying that the static image size is growing? Dynamic growth >>> could easily be explained by leaks in NativeBoost for instance. But static >>> image size means that there are objects lying around that shouldnât (at >>> least that should be easier to debug). >>> >>> > >>> > One way to look at memory use is with >>> > >>> > SpaceTally printSpaceAnalysis >>> > >>> > but that takes a while. >>> > >>> > Please help us find and fix this issue. >>> > >>> > Thanks, >>> > >>> > Sven >>> > >>> > >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

March 24, 2015

Re: [Pharo-dev] Some Memory Leak

by Sven Van Caekenberghe

> On 24 Mar 2015, at 16:50, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > There are lot of spotter objects that do not get garbaged collected > > GTSpotter allInstances size --> 29 in my image I got 10 now. But can they cause megabytes to be locked up ? > On Tue, Mar 24, 2015 at 4:16 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Yes, there are clearly objects lying around. I suspect it has to do with Playground or Inspector, but I am not sure. > > Doru > > On Tue, Mar 24, 2015 at 4:13 PM, Max Leske <maxleske(a)gmail.com> wrote: > > > On 24 Mar 2015, at 15:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Hi, > > > > There seems to be some kind of memory leak in recent Pharo 4.0 images. Image size (as saved on disk) seems to be growing very rapidly under normal use (development with Nautilus, Spotter, GTPlayground, GTInspector and Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and they seem to increase constantly, over a period of days. > > Are you saying that the static image size is growing? Dynamic growth could easily be explained by leaks in NativeBoost for instance. But static image size means that there are objects lying around that shouldnât (at least that should be easier to debug). > > > > > One way to look at memory use is with > > > > SpaceTally printSpaceAnalysis > > > > but that takes a while. > > > > Please help us find and fix this issue. > > > > Thanks, > > > > Sven > > > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

March 24, 2015

Re: [Pharo-dev] Some Memory Leak

by Andrei Chis

There are lot of spotter objects that do not get garbaged collected GTSpotter allInstances size --> 29 in my image On Tue, Mar 24, 2015 at 4:16 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Yes, there are clearly objects lying around. I suspect it has to do with > Playground or Inspector, but I am not sure. > > Doru > > On Tue, Mar 24, 2015 at 4:13 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> >> > On 24 Mar 2015, at 15:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> > >> > Hi, >> > >> > There seems to be some kind of memory leak in recent Pharo 4.0 images. >> Image size (as saved on disk) seems to be growing very rapidly under normal >> use (development with Nautilus, Spotter, GTPlayground, GTInspector and >> Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and >> they seem to increase constantly, over a period of days. >> >> Are you saying that the static image size is growing? Dynamic growth >> could easily be explained by leaks in NativeBoost for instance. But static >> image size means that there are objects lying around that shouldnât (at >> least that should be easier to debug). >> >> > >> > One way to look at memory use is with >> > >> > SpaceTally printSpaceAnalysis >> > >> > but that takes a while. >> > >> > Please help us find and fix this issue. >> > >> > Thanks, >> > >> > Sven >> > >> > >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

March 24, 2015

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

by Aliaksei Syrel

The same in Brick: GLMButtonBrick new > marginLeft: 10; > text: 'Parse'; > vAlign: #center; > hSpaceFill; > openInBrickWindow Yes, I agree - using composition for margin/padding/aligning is much more simple, readable, fast and maintainable, than horrible scripting in brick, sorry for that. One more time for people who still don't hear us. Brick is internal for GT. We just put in package named "Brick" reusable widgets we built to use in our tools. They just normal subclasses of morph. Nothing fancy. We don't want you to use it and suggest to learn Spec for UI, please. Keep Calm :) Cheers, Alex On Tue, Mar 24, 2015 at 4:28 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-03-24 16:03 GMT+01:00 Alain Plantec via Pharo-dev < > pharo-dev(a)lists.pharo.org>: > >> >> >> ---------- Message transfÃ©rÃ© ---------- >> From: Alain Plantec <alain.plantec(a)yahoo.com> >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> Cc: >> Date: Tue, 24 Mar 2015 16:02:56 +0100 >> Subject: Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?] >> >> Le 24 mars 2015 Ã 15:56, Thierry Goubier <thierry.goubier(a)gmail.com> a >> Ã©crit : >> >> >> >> 2015-03-24 15:39 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> >>> 2015-03-24 17:36 GMT+03:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >>> >>>> IMHO, Rubrics, just from it's layout approach, is already a step >>>> backward. >>> >>> >>> >>> What you mean by this? What's wrong with Rubric layouting? >>> >> >> Padding -> resolved in Morphic by Morph composition: no need to add that >> to the Layout engine of each widget >> >> Aligning -> resolved in Morphic by Morph composition: no need to add that >> to the Layout engine of each widget >> >> >> I donât get it sorry. >> > > Padding by ten pixels to the left: > > | leftMargin aParserButton | > leftMargin := Morph new > width: 10; > hResizing: #shrinkWrap; > vResizing: #spaceFill. > aParserButton := PluggableButtonMorph on: self getState: nil action: > #parse. > aParserButton > hResizing: #spaceFill; > vResizing: #shrinkWrap; > label: 'Parse'. > AlignmentMorph newRow > vResizing: #shrinkWrap; > hResizing: #spaceFill; > layoutInset: 0; > addMorph: aParserButton; > addMorph: leftMargin; > openInWorld > > Aligning to the center, horizontally: add a right and left morph, but > hResizing: #spaceFill this time. > > Some type of constraints are hard to do with that system (*), but... LaTeX > layout exclusively with that, so, maybe it works ;) > > ((*) And this is where someone knowing Rubricks could come with a few > examples of those). > > >> maybe one example would help >> > > From the SmaCC GUI :) > > >> >> >> ZOrdering -> nothing says that submorphs in Morphic can't overlay each >> other. >> >> >> Bloc uses z-ordering exactly as Morphic (the code for adding/removing a >> submorph are nearly the same) >> > > Ok. But do you know why? There is a reason for that choice. > > Spec had a real issue with that ordering, so the pressure will be to get > it 'corrected'. > > Mind you, I consider Bloc a very good choice, but I fear that we're not > able to stress it enough with hard, very advanced GUIs to ensure we're not > loosing power compared to Morphic. > > Thierry > > >> >> Cheers >> Alain >> >> >> One of the issue with Morphic as it stands today is that the API is >> fairly complex if you want to carefully control placement and morph >> behavior under container resizing / move. Oh, and it's very buggy too. >> Rubricks shows an API which is even more complex, which isn't surprising if >> the inspiration is CSS layout. >> >> Thierry >> >> >> >> >

March 24, 2015

Re: [Pharo-dev] String>>howManyMatch: Bug or feature ?

by Nicolas Cellier

2015-03-24 13:53 GMT+01:00 Noury Bouraqadi <bouraqadi(a)gmail.com>: > Hi, > > The normal behavior > 'abc' howManyMatch: 'abd' --> 2. > > I got suprized the way Blanks and new lines are handled. > > '\**' withCRs howManyMatch: '\\**' withCRs. --> 2 instead of 1 > > 'ab\ **' withCRs howManyMatch: 'ab\\**' withCRs. --> 4 instead of 3 > > '\ **' withCRs howManyMatch: '\\**' withCRs. --> 3 instead of 1 > > 'ab\ **' withCRs howManyMatch: 'ab\\**' withCRs. --> 5 instead of 3 > > The behavior is the same in both Pharo 3 and Pharo 4. > > Reading the code of does not help me understand why it's this way > > String>>howManyMatch: string > "Count the number of characters that match up in self and aString." > | count shorterLength | > > count := 0. > shorterLength := self size min: string size. > 1 to: shorterLength do: [:index | > (self at: index) = (string at: index ) > ifTrue: [ count := count + 1 ]]. > ^ count > > > Noury > Noury, I think you're looking after the number of common chars only at beginning. Wouldn't the method finder hit a better match? The method works as advertised in the comment. Though I find it very questionnable: Doesn't "match" imply some other semantic like pattern matching (and thus things like wild character etc...)? Is such specific behavior usefull? Really? Why/Where? > > Afin de contribuer au respect de l'environnement, > merci de n'imprimer ce courriel qu'en cas de necessite > > Please consider the environment before you print > > > >

March 24, 2015

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

by Thierry Goubier

2015-03-24 16:03 GMT+01:00 Alain Plantec via Pharo-dev < pharo-dev(a)lists.pharo.org>: > > > ---------- Message transfÃ©rÃ© ---------- > From: Alain Plantec <alain.plantec(a)yahoo.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Cc: > Date: Tue, 24 Mar 2015 16:02:56 +0100 > Subject: Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?] > > Le 24 mars 2015 Ã 15:56, Thierry Goubier <thierry.goubier(a)gmail.com> a > Ã©crit : > > > > 2015-03-24 15:39 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> 2015-03-24 17:36 GMT+03:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> >>> IMHO, Rubrics, just from it's layout approach, is already a step >>> backward. >> >> >> >> What you mean by this? What's wrong with Rubric layouting? >> > > Padding -> resolved in Morphic by Morph composition: no need to add that > to the Layout engine of each widget > > Aligning -> resolved in Morphic by Morph composition: no need to add that > to the Layout engine of each widget > > > I don't get it sorry. > Padding by ten pixels to the left: | leftMargin aParserButton | leftMargin := Morph new width: 10; hResizing: #shrinkWrap; vResizing: #spaceFill. aParserButton := PluggableButtonMorph on: self getState: nil action: #parse. aParserButton hResizing: #spaceFill; vResizing: #shrinkWrap; label: 'Parse'. AlignmentMorph newRow vResizing: #shrinkWrap; hResizing: #spaceFill; layoutInset: 0; addMorph: aParserButton; addMorph: leftMargin; openInWorld Aligning to the center, horizontally: add a right and left morph, but hResizing: #spaceFill this time. Some type of constraints are hard to do with that system (*), but... LaTeX layout exclusively with that, so, maybe it works ;) ((*) And this is where someone knowing Rubricks could come with a few examples of those). > maybe one example would help > >From the SmaCC GUI :) > > > ZOrdering -> nothing says that submorphs in Morphic can't overlay each > other. > > > Bloc uses z-ordering exactly as Morphic (the code for adding/removing a > submorph are nearly the same) > Ok. But do you know why? There is a reason for that choice. Spec had a real issue with that ordering, so the pressure will be to get it 'corrected'. Mind you, I consider Bloc a very good choice, but I fear that we're not able to stress it enough with hard, very advanced GUIs to ensure we're not loosing power compared to Morphic. Thierry > > Cheers > Alain > > > One of the issue with Morphic as it stands today is that the API is fairly > complex if you want to carefully control placement and morph behavior under > container resizing / move. Oh, and it's very buggy too. Rubricks shows an > API which is even more complex, which isn't surprising if the inspiration > is CSS layout. > > Thierry > > > >

March 24, 2015

Re: [Pharo-dev] Populating/editing list with modal dialogs in Glamour

by Andrei Chis

Hi, GLMActionListPresentation is currently the only mechanism to have a separate list of actions as buttons. However, usually when working with lists we add actions directly in the toolbar of the presentation. There is no default way of opening a pop-up. However, it shouldn't be so difficult to have a special action that opens a pop-up. We are actually adding one now because we need it for something :) Cheers, Andrei On Tue, Mar 24, 2015 at 12:00 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi everyone, > > Iâm playing with glamour, and Iâm trying to construct a list that can be > edited e.g. you can add items, edit them and remove and for adding and > editing you have a custom popup written again in glamour. So first question > is how can I dead with basic actions? Is the GLMActionListPresentation way > to go, or I should look on the other things. Another question is how do you > open a modal window with glamour and how do you get the result from it. > > Iâll be very thankful for any reply. > Cheers. > Uko >

March 24, 2015