the goal of pharo is also to avoid VW runtime packager (because the package tries to statically find how to reduce image size which is ***really*** difficult in a dynamic language. Now Pavel got a 2mb image based on pharo: I imagine that we will be able to start from this one to build up pharo in the future :)
On Aug 23, 2009, at 3:14 AM, Carlos Crosetti wrote: > Mariano, Ivery value those scripts! > > My image is small, but anyway I couldn't resist the challenge and > tried so far, > I got my image shrunk down from 20.7mb to 18.2mb. > > This is probably a candidate for extending something I may > call "the Pharo equivalent to VW Runtime Packager" - I am not so > familiar to Pharo to know > if such a feature exist. > > Regards, Carlos > -----Mensaje original----- > De: [email protected] > [mailto:[email protected] > ]En nombre de Mariano Martinez Peck > Enviado el: Sábado, 22 de Agosto de 2009 05:53 p.m. > Para: [email protected] > Asunto: Re: [Pharo-project] over bloated image workaround > > > > On Sat, Aug 22, 2009 at 5:42 AM, Stéphane Ducasse <[email protected] > > wrote: > We should check that. > Can you open a ticket? > > > Ok, done: http://code.google.com/p/pharo/issues/detail?id=1083 > > > > > Stef > On Aug 21, 2009, at 11:25 PM, Mariano Martinez Peck wrote: > > > Hi folks: Sometimes, my Pharo images grows a lot. Size like 80MB or > > similar. Marcelo Cortez gave me a couple of changes (fileouts) that > > make my images go back to their original size or similar. For > > example, it was tasted in a 87 MB and after this changes and this > > stuff, it become in 24 MB. The same with another one from 65M to > 35M. > > > > If you have a big Pharo image, save a copy and do this tests: > > > > 1) File in all the changes I attach. > > 2) Go to a workspace and evaluate: > > > > OBDPAbstract reinitAllCache. > > LocalSends allInstances first initialize. > > EventManager resetMap. > > Smalltalk garbageCollect. > > > > Did this make your image too much smaller? > > > > When I evaluate SystemNavigation default obsoleteBehavio size I > > get a a number of 3 digits. > > > > Perhaps it is a matter with the OB. I guess it generates dependences > > while you are developing a class and it creates on the fly an > > obsolteClassXXX when there is something that doesn't exist. Then > > they are processes and they are never garbage collected. > > > > When SmalltalkImage tries to fix the obsoletes delegates to the > > literal frames of the compiled methods so that to search references > > to the obsoletes. But references were not gone because they weren't > > garbage collected. The same method finishes with error if the > > obsoletes > 0. > > > > Does anyone has a comment for this? > > > > I tried to do my best to write in English from what Marcelo told me > > and from what I can understand from the changesets. > > > > Best, > > > > Mariano _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
