Migration Guide


Packager 'do not reduce' rule behavior changed

The "do not reduce" rule in packager did not include the methods from the specified class in the computing of the transitive closure. As such, it could produce a non-working image with messages being sent to methods which have been "accidentally" reduced out. This often, but not always, showed up as errors when running the Examine & Fix Problems step of the packager.

So, for example, if there is a class 'A' that defines these methods:

 #main (class method)
 ^super new method1
 
 #method1
 | a |
 a := Array new: 10.
 ^a
 
 #method2
 | a |
 a := Bag new.
 ^a

When packaging a normal "runtime reduced image" with startup code 'A main', then these methods would be included:

 A class>>#main
 A>>#method1

Also, the Array class would be included in the packaged image.

If a packaging rule like the following were added:

 packagingRulesFor: aPackagedImage
 "Define rules for the given packaged image."
 
 aPackagedImage doNotReduceClassNamed: self name  

and the packager rerun, then these methods would be included:

 A class>>#main
 A>>#method1
 A>>#method2

But, the class Bag would not be included (as the user might expect) even though it is referenced by #method2. The reason is that the reduction algorithm only considered "explicitly" included methods to be starting points for reduction. Implicitly included methods were effectively added after the runtime reduction - i.e. runtime reduction is done as always and then the remainder of any methods/classes/apps which have "do not reduce" rules are added.

The implementation of the 'do not reduce' rule has been changed such that all the methods in the unreduced components are used as seeds in the reduction algorithm.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]