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

Re: [Pharo-dev] MCVersionInfo: 10% of the image

by Thierry Goubier

2015-02-26 10:44 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 26 Feb 2015, at 10:15, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > Ok, > > > > a first slice is in, it's the first solution for now (second is just > extending the scheme). > > > > Loading the slice should install the lazy version and flush the caches > (does merging would initialize the class?) > > > > Works fine with merge, too. > > The 511 image is 23.2MB after. This means with the Scriptloader fix from > 510 together we would over 10MB... or nearly 1/3. Nice! > Ok. Second scheme (get it to work everywhere, everytime) seems to just need to change MCWorkingAncestry>>addAncestor: and MCWorkingCopy>> addStepChild: Thierry > > Marcus > > >

Feb. 26, 2015

Re: [Pharo-dev] MCVersionInfo: 10% of the image

by Marcus Denker

> On 26 Feb 2015, at 10:15, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Ok, > > a first slice is in, it's the first solution for now (second is just extending the scheme). > > Loading the slice should install the lazy version and flush the caches (does merging would initialize the class?) > Works fine with merge, too. The 511 image is 23.2MB after. This means with the Scriptloader fix from 510 together we would over 10MBâ¦ or nearly 1/3. Nice! Marcus

Feb. 26, 2015

Re: [Pharo-dev] Using Pharo to Save Human Life

by Onil Goubier

Hi Alexandre, Thank you very much, we have just started and there is still much work to be done. Of course, we will ask pharo community if we need help ... Regards, Onil On Thu, Feb 26, 2015 at 2:50 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Yeah, I have changed the subject for a more accurate one. > > Onil, you are doing a fantastic work: monitoring flood in Jakarta in real > time is impressive. > I have enjoyed very much your presentation. Pity the network did not work, > but the effect is still very strong. I feel humble and respectful when I > see your goal and vision. > > I am happy that we, as a community, are able to help you. And really, feel > free to complain about the system you are using. Just ask for help if you > need. > > Big big clap!!!! > > I would love to see your presentation at ESUG. > > Alexandre > > > > On Feb 25, 2015, at 5:07 PM, stephan <stephan(a)stack.nl> wrote: > > > > The first FOSDEM video has arrived: > > > > http://mirrors.dotsrc.org/fosdem/2015/devroom-smalltalk/cirela.mp4 > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- Onil Goubier Engineer CIRELA Association Communication and Information technology for REsiLience to disAsters and climate change 25, rue Paulhan 78140 VÃ©lizy-Villacoublay, France Ph. +33 6 67 77 49 93

Feb. 26, 2015

Re: [Pharo-dev] MCVersionInfo: 10% of the image

by Thierry Goubier

Ok, a first slice is in, it's the first solution for now (second is just extending the scheme). Loading the slice should install the lazy version and flush the caches (does merging would initialize the class?) Thierry 2015-02-26 9:33 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > >> > And it behaves as the non-lazy one. > > There are a few things to change GUI-side to avoid an unnecessary loading > of the complete ancestry of all the packages in the image, but this is > workable. > > I see two ways of using it: > > as an "install, flush package cache before release and gain 5MB of RAM". > If you start regularly developping (loading packages, etc...) then new > packages will revert to non-lazy version info (without: 'please wait, I'm > loading ancestry' moments). > > as a permanent change in MC. The change is a bit more intrusive (need to > change how working copies are created) but, well, as long as the worked on > packages are inside the in-memory MC package cache, behavior is exactly the > same as a non-lazy version info. > > As you prefer. > > > My focus is that we ship an image that is not growing indefinitely... so > this means it needs to be part of the release. > > I don't care too much that the image is large when I work, but it should > not come with all this data in memory when it can be calculated (or lazyly > loaded) when needed. > > I added an issue: > > https://pharo.fogbugz.com/default.asp?14997 > > > Thanks! > > Marcus > >

Feb. 26, 2015

Re: [Pharo-dev] MCVersionInfo: 10% of the image

by Marcus Denker

> > > And it behaves as the non-lazy one. > > There are a few things to change GUI-side to avoid an unnecessary loading of the complete ancestry of all the packages in the image, but this is workable. > > I see two ways of using it: > > as an "install, flush package cache before release and gain 5MB of RAM". If you start regularly developping (loading packages, etc...) then new packages will revert to non-lazy version info (without: 'please wait, I'm loading ancestry' moments). > > as a permanent change in MC. The change is a bit more intrusive (need to change how working copies are created) but, well, as long as the worked on packages are inside the in-memory MC package cache, behavior is exactly the same as a non-lazy version info. > > As you prefer. > My focus is that we ship an image that is not growing indefinitelyâ¦ so this means it needs to be part of the release. I donât care too much that the image is large when I work, but it should not come with all this data in memory when it can be calculated (or lazyly loaded) when needed. > I added an issue: > > https://pharo.fogbugz.com/default.asp?14997 <https://pharo.fogbugz.com/default.asp?14997> > Thanks! Marcus

Feb. 26, 2015

Re: [Pharo-dev] MCVersionInfo: 10% of the image

by Thierry Goubier

2015-02-26 7:58 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 25 Feb 2015, at 23:28, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > Hi, > > > > I made a very simple experiment, with a MCLazyVersionInfo, which holds > its ancestors and stepChildren in WeakArray(s), and loads it from > repositories on demand. > > > > Installing it on Pharo 40511, and then flushing the Monticello package > cache, reduces the image by around 5 MB: > > > > Nice! > > Marcus > > And it behaves as the non-lazy one. There are a few things to change GUI-side to avoid an unnecessary loading of the complete ancestry of all the packages in the image, but this is workable. I see two ways of using it: as an "install, flush package cache before release and gain 5MB of RAM". If you start regularly developping (loading packages, etc...) then new packages will revert to non-lazy version info (without: 'please wait, I'm loading ancestry' moments). as a permanent change in MC. The change is a bit more intrusive (need to change how working copies are created) but, well, as long as the worked on packages are inside the in-memory MC package cache, behavior is exactly the same as a non-lazy version info. As you prefer. I added an issue: https://pharo.fogbugz.com/default.asp?14997 Thierry

Feb. 26, 2015

Issue tracker: 13 issues to review

by Marcus Denker

Hi, There are now 660 open issues (after closing 65 the last 7 days). Of those, 13 issues are tagged for review: https://pharo.fogbugz.com/f/filters/45/Review Marcus

Feb. 26, 2015

Re: [Pharo-dev] MCVersionInfo: 10% of the image

by Marcus Denker

> On 25 Feb 2015, at 23:28, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi, > > I made a very simple experiment, with a MCLazyVersionInfo, which holds its ancestors and stepChildren in WeakArray(s), and loads it from repositories on demand. > > Installing it on Pharo 40511, and then flushing the Monticello package cache, reduces the image by around 5 MB: > Nice! Marcus

Feb. 26, 2015

Using Pharo to Save Human Life

by Alexandre Bergel

Yeah, I have changed the subject for a more accurate one. Onil, you are doing a fantastic work: monitoring flood in Jakarta in real time is impressive. I have enjoyed very much your presentation. Pity the network did not work, but the effect is still very strong. I feel humble and respectful when I see your goal and vision. I am happy that we, as a community, are able to help you. And really, feel free to complain about the system you are using. Just ask for help if you need. Big big clap!!!! I would love to see your presentation at ESUG. Alexandre > On Feb 25, 2015, at 5:07 PM, stephan <stephan(a)stack.nl> wrote: > > The first FOSDEM video has arrived: > > http://mirrors.dotsrc.org/fosdem/2015/devroom-smalltalk/cirela.mp4 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 26, 2015

Re: [Pharo-dev] MCVersionInfo: 10% of the image

by Thierry Goubier

Hi, I made a very simple experiment, with a MCLazyVersionInfo, which holds its ancestors and stepChildren in WeakArray(s), and loads it from repositories on demand. Installing it on Pharo 40511, and then flushing the Monticello package cache, reduces the image by around 5 MB: Before: memory 48,583,272 bytes old 40,721,508 bytes (83.80000000000001%) young 1,445,212 bytes (3.0%) used 42,166,720 bytes (86.80000000000001%) free 6,416,552 bytes (13.200000000000001%) After: memory 42,482,984 bytes old 35,484,236 bytes (83.5%) young 1,434,832 bytes (3.4000000000000004%) used 36,919,068 bytes (86.9%) free 5,563,916 bytes (13.100000000000001%) You can browse the history of any package and it will be reloaded on the fly :) But, but, but. When opening a repository inspector, MC will walk through all ancestors of all packages... reloading everything. Arrrg ! So I won't tell you where it is available, yet :( Thierry Le 20/02/2015 15:41, Marcus Denker a Ã©crit : > Hi, > > The current Pharo4 contains *a lot* of MCVersionInfo instances. > > MCVersionInfo allInstances size > > 11095 > > The hold on to strings, Date, UUIDâ¦ a lot of stuff. All in all, this is around 10% of the current > image. > > If you do > > MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. > > you image is a couple of MB smaller. > > In the past, when this information started to be >8MB, we did that. With the bad effect > that we can not merge anymore across this boundary: we kill the past. > > Now this information is of course continained in the last MCZ file, too (all of them contain > the complete historyâ¦) > > So would the following work? > > -> we set the âancestorsâ of MCVersionInfo to #reload > -> the accessor, when it sees #reload, takes the name, deduces from that the package, > and goes to the repo to load the ancestry info from the MCZFile. > > This means that e.g when saving a MCZFile, it would first re-create history info and then save > it completely (like now), yet someone who just uses the system would never need to have this > info in the image. > > Marcus >

Feb. 25, 2015