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

Re: [Pharo-dev] Some Memory Leak

by Tudor Girba

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 Sven Van Caekenberghe

> On 24 Mar 2015, at 16:13, 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). Yes, it is the latter. We have seen it in a couple of places, but we can't seem to find the culprit. Many people do not keep images very long, but it seems to be visible in one to two days, which is obviously too fast. >> 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 >> >> > >

March 24, 2015

Re: [Pharo-dev] Some Memory Leak

by Max Leske

> 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 > >

March 24, 2015

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

by Alain Plantec

> 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 <mailto:dionisiydk@gmail.com>>: > > 2015-03-24 17:36 GMT+03:00 Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@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. maybe one example would help > 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) 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] Which one to use? [WAS: Re: GLMBrick whats next?]

by Thierry Goubier

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 ZOrdering -> nothing says that submorphs in Morphic can't overlay each other. 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] Which one to use? [WAS: Re: GLMBrick whats next?]

by Thierry Goubier

Hi, 2015-03-24 15:27 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > >> >> I think I do not understand this point. Why do you say that the future > solution will be less than Morphic? > > Because we're driving it with uses which are less than Morphic requirements were. Because you don't need Morphic power to do GT tools; it justs gets in the way: slow, over-engineered for that use case. As a consequence, you end up with Rubricks: dedicated, ad-hoc solution which is a far better match for its use case. That Rubricks proudly present its Z layering where Morphic was / is probably the easiest toolkit ever to do layering of arbitrary widgets on top of another? (*) Thierry (*) Even if we're not doing it(**). (**) Well, I did. Nobody's interested, so what ? > Doru > > >> >> Thierry >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

March 24, 2015

Re: [Pharo-dev] Slots and MethodWrappers

by Norbert Hartl

> Am 24.03.2015 um 15:26 schrieb Johan Fabry <jfabry(a)dcc.uchile.cl>: > > > I would say that they are different although related. Slots are for the interception of accessing instance variables (for read and write), and method wrappers for the interception of accessing methods (for execution). > +1 Very precise and short. Conceptional some might see overlap when it comes to getters and setters :) Norbert >> On Mar 24, 2015, at 09:02, phil(a)highoctane.be <mailto:phil@highoctane.be> wrote: >> >> I wondered how these two things are related. >> >> Will slots be giving MWs facilities out of the box? >> >> When should I use both? >> >> Phil >> > > > > ---> Save our in-boxes! http://emailcharter.org <http://emailcharter.org/> <--- > > Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/~jfabry> > PLEIAD lab - Computer Science Department (DCC) - University of Chile >

March 24, 2015

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

by Johan Fabry

> On Mar 24, 2015, at 10:29, kilon alios <kilon.alios(a)gmail.com> wrote: > > [Spec] does not support custom made GUIs which is what I want Thatâs simply not true. Spec supports the embedding of whatever Morph you want inside your GUI. So you can easily mix and match your custom components with all the standard Spec components. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

March 24, 2015

Re: [Pharo-dev] Update question

by Norbert Hartl

> Am 24.03.2015 um 13:02 schrieb Sean P. DeNigris <sean(a)clipperadams.com>: > > NorbertHartl wrote >> What would be better using PharoLauncher? > > I was a hold out, but I've finally started using it and it's really nice. > For things that don't have an automated build process, it's much better than > downloading from file.pharo.org by hand. You can set the folder to which the > images get saved, and choose to make new images from e.g. Pharo 4, 3, 2, > moose, anything on the contribution CI server, and a few others. > > I really like Peter's idea to act from a startup script based on the image > name. That sounds like a powerful combination. > Oh, I didn't know that you can choose the folder where the images live. I might take another peek at it. But then I'm using something like that for a very long time. - make a folder projects in you home directory - in that folder create symlink to any of your smalltalk project directory that you are working at the moment - drop that folder in the dock - you click the icon on the dock, a list of projects pops up, you select one and you get the contents of that the directory. You click on an image and it starts So I'm not sure I'll gain something but I will try again. Norbert

March 24, 2015

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

by Denis Kudriashov

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?

March 24, 2015