On Thu, Dec 24, 2009 at 3:03 PM, Nicolas Cellier < [email protected]> wrote:
> 2009/12/24 Mariano Martinez Peck <[email protected]>: > > > > > > On Thu, Dec 24, 2009 at 12:33 PM, Stéphane Ducasse > > <[email protected]> wrote: > >> > >> > Taking that explanation in mind, we can follow this three steps: > >> > > >> > \begin{enumerate} > >> > \item Send the message {\em ImageSegment>>discoverActiveClasses} which > >> > forces a MethodDictionary fault in all classes. Yes! It sends the > message > >> > {\em induceMDFault} to all classes except classes like Array Object > Class > >> > Message MethodDictionary. After this, all classes but those ones, will > have > >> > the {\em methodDict} with {\em nil}. > >> > \item Do a few things, use the system for a while. Maybe even save and > >> > resume the image. > >> > \item Now, it is easy. All classes that still have a nil in the {\em > >> > mehodDict} is because they were not used, and those who have something > >> > different from {\em nil} is because they were. With the message {\em > >> > ImageSegment>>activeClasses} you can restore all remaining > MethodDictionary > >> > faults and return the active classes. And with the message {\em > >> > ImageSegment>>swapOutInactiveClasses} you can make up segments by > grouping > >> > unused classes by system category and write them to disk. > >> > > >> > A very important thing is that if you send the message {\em > >> > discoverActiveClasses} you must then have to send the message {\em > >> > activeClasses} or {\em swapOutInactiveClasses} because otherwise you > will > >> > have a lot of classes with the {\em methodDict} in {\em nil}. > >> > > >> > \end{enumerate} > >> > > >> > > >> > is it clear ? > >> > >> Yes. > >> So may be you should create an ImageSegment package and put the > >> faultDescription as class extensions to this package. > >> > >> Did you try to see what are the inactive classes you get after a full > >> coding sesssion with loading and saving code? > >> > > > > Yes, but the results is all classes are used, which of course is wrong. > > But...investigating a bit, the problem is here. Look this example: > > > > ByteString induceMDFault. > > self assert: (ByteString instVarNamed: 'methodDict') isNil > > > > That assert returns a failure!!! how is that posssible ? if the > > induceMDFault is setting methodDict nil . > > > > weird... > > > > > > Just a guess, I did not look at code, but couldn't it be that > instVarNamed: rely on String>>#= and thus resurrect the > methodDictionary ? > Maybe you should write: > self should: [ByteString instVarNamed: 'methodDict'] raise: MDFault > > Thanks Nicolas. Yes, something like that was happening. I don't know why I was so idiot and took ByteString as an example haha. Now I did some test. Just evaluating this (without any work on an image) ImageSegment discoverActiveClasses. ImageSegment activeClasses. You get 227 classes used (over 3332 in total) I will let this stuff running and work a couple of hours in a normal work and see how much classes do I use. Cheers, 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
