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

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

Reply via email to