[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Performing a scene transformation _after_ body transforms...
At 06:14 PM 2/12/2002 -0500, Rhodes H. F. Brown wrote:
>I'm not sure about BodyTransformers masquerading as SceneTransformers.
>However, I would agree with Steve that we need a more powerful way to
>apply transformations. Something along the lines of:
>
> 1. do SceneTr A
> 2. while (cond1)
> do SceneTr B
> do BodyTr a
> while (cond2)
> do BodyTr b
> do BodyTr c
> 3. do BodyTr d
> 4. do SceneTr C n times
> ...
>
>My approach would be to develop a custom Pack (a better name, i.e. a la
>Design Patterns, might be Strategy) object and modify Scene.java and
>Main.java to apply my custom Pack. One might even consider writing a
>small compiler that could create a Strategy class or object from some
>definition file. Perhaps others have some thoughts on how to do this.
So what happens when I want to put a Pack inside another Pack? -> A Pack is
a Composite Transformation, in other words, a transformation made up of
other of other transformations. This is the Hierarchy pattern.
I can't modify Main.java, or Scene.java.... I would suggest instead that
these take a Transformation... I will almost always give them
a Pack as the transformation... The Pack base class implements the current
logic in Scene for executing the transformations inside it:
public interface Transformation {
applyTransform();
}
public class Pack implements Transformation {
applyTransform() {
for(Iterator transforms = _transformList.iterator;
transforms.hasNext();)
transforms.next().applyTransform();
}
private List _transformList;
}
Pack subclasses can implement iteration and conditionals.
If you want naming of packs, one way is to give everything a name:
public interface Nameable {
public String getName();
public void setName(String);
}
public class Transformation extends Nameable;
Ptolemy (http://ptolemy.eecs.berkeley.edu/) uses such named hierarchies
very effectively.
>Rhodes
>
>
>On Tue, 2002-02-12 at 16:55, Stephen Andrew Neuendorffer wrote:
> >
> > Well, it still seems pretty limiting... What if I want to run a
> > SceneTransformation,
> > a BodyTransformation and then another SceneTransformation?
> >
> > What I've done is to implement an Adaptor that turns BodyTransformations
> > into SceneTransformations:
> >
> > public class TransformerAdapter extends SceneTransformer {
> > /** Construct a new transformer
> > */
> > public TransformerAdapter(BodyTransformer transformer) {
> > _transformer = transformer;
> > }
> >
> > protected void internalTransform(String phaseName, Map options) {
> > System.out.println("TransformerAdapter.internalTransform("
> > + phaseName + ", " + options + ")");
> >
> > Iterator classes = Scene.v().getApplicationClasses().iterator();
> > while(classes.hasNext()) {
> > SootClass theClass = (SootClass)classes.next();
> > Iterator methods = theClass.getMethods().iterator();
> > while(methods.hasNext()) {
> > SootMethod m = (SootMethod) methods.next();
> > if(!m.isConcrete())
> > continue;
> >
> > JimpleBody body = (JimpleBody) m.retrieveActiveBody();
> >
> > // FIXME: pass in the options.
> > // Currently this is not possible because the
> > // internalTransform method is protected.
> > _transformer.transform(body, phaseName, "");
> > }
> > }
> > }
> >
> > private BodyTransformer _transformer;
> > }
> >
> > This is much cleaner than the instanceof check that currently exists
> > somewhere (Scene, I think?) to handle
> > the two types of classes separately... it also fixes the annoyance with
> > the required ordering between
> > the two types of transformers...
> >
> > My current problem is that the whole idea of the way transforms are
> > organized in soot:
> > 1) means that I have to know what transformations I want to execute before
> > looking at my program
> > 2) The topology of the transformations is a list...
> >
> > Consider the following.... I want to inline all static methods,
> > unfortunately, static methods may all other static methods.
> > This means I have to iterate until there are no invocations that can be
> > inlined...
> > There is no way to build this within Soot transformation mechanism,
> > starting from a transformation that inlines all the method invocations that
> > are currently available...
> > while(sites can be inlined) {
> > inlineAllAvailableSites();
> > }
> >
> > Another... I write a tranformation that is fast, but makes certain
> > assumptions about the code.... I write another that is slow, but makes no
> > assumptions... I write an analysis that determines if the assumptions
> hold:
> >
> > if(assumptions hold) {
> > doFast();
> > } else {
> > doSlow();
> > }
> > There is no way to build the comparison within the transformation
> mechanism...
> >
> > Yes, I can do both of these by creating an action method, and then calling
> > that action method from a transformation that implements the
> comparison, or
> > the loop, but then I am not leveraging the Transformation mechanism, and
> > the nice interface to the transformations is lost.
> > One way of thinking about this, is that an unconditional sequential
> list is
> > not a terribly rich language for describing the ordering of transformations
> >
> > My actual problem is this problem, scaled up... Basically I am creating
> > classes as copies of other classes and transforming them (approximately 25
> > individual transformations), but I don't
> > know what classes I want to create beforehand (it depends on input to the
> > 'compiler') Furthermore, Some of the generated classes themselves need to
> > be copied and transformed themselves recursively. This can happen an
> > arbitrary number of times... There is (unfortunately) no way to describe
> > this using the transformation mechanism....
> >
> > BTW, any outlook on the new version of soot?
> >
> > Steve
> >
> >
>
>
>--
>Rhodes Brown
>Sable Research - McGill University
>
>Web: http://www.sable.mcgill.ca
>Email: rhodesb@sable.mcgill.ca