Re: [abc-users] Tracematch trace output

I guess it may actually be nice to be able to generate a "history
trace" the same way one would normally have access to a stack trace, I
guess. It would probably not even be too hard to implement, I think
we could just piggyback JoinPoint or JoinPointStaticPart objects on
the disjuncts or something similar.

Eric

On 24/02/2008, Alan Teoh <alan.teoh07_at_imperial.ac.uk> wrote:
> Hi Eric,
>
> I'm investigating the properties of tracematches, and I'm just asking
> out of interest.
> Thanks for the reply.
>
>
> Eric Bodden wrote:
> > Hi, Alan.
> >
> > As far as I know this trace was just produced using pen and paper and
> > the implementation currently supports no such tracing. Do you have an
> > actual use case where would need a trace or are you just asking out of
> > interest?
> >
> > Eric
> >
> > On 24/02/2008, Alan Teoh <alan.teoh07_at_imperial.ac.uk> wrote:
> >
> >> Hi again,
> >>
> >> Is it possible for me to produce a trace output(perhaps via an argument
> >> on the abc compiler) via tracematches like the one in the paper(Adding
> >> Trace Matching with Free Variables to AspectJ)?
> >> I'm talking about the one produced in page 10:
> >>
> >> Given tracematch
> >> tracematch (X x) {
> >> sym f before:
> >> call (* f(..)) && target(x);
> >> sym g after:
> >> call (* g(..)) && target(x);
> >> f g
> >> {
> >> System.out.println("fg!");
> >> }
> >> }
> >>
> >> And the following method calls
> >> v.f(); v.h(); w.g(); w.f(); v.g();
> >>
> >> The trace is then as follows:
> >>
> >> e1 enter: call(void FG.f()) on v
> >> e2 enter: execution(void FG.f()) on v
> >> e3 exit: execution(void FG.f()) on v
> >> e4 exit: call(void FG.f()) on v
> >> e5 enter: call(void FG.h()) on v
> >> e6 enter: execution(void FG.h()) on v
> >> e7 exit: execution(void FG.h()) on v
> >> e8 exit: call(void FG.h()) on v
> >> e9 enter: call(void FG.g()) on v
> >> e10 enter: execution(void FG.g()) on w
> >> e11 exit: execution(void FG.g()) on w
> >> e12 exit: call(void FG.g()) on w
> >> e13 enter: call(void FG.f()) on w
> >> e14 enter: execution(void FG.f()) on w
> >> e15 exit: execution(void FG.f()) on w
> >> e16 exit: call(void FG.f()) on w
> >> e17 enter: call(void FG.g()) on v
> >> e18 enter: execution(void FG.g()) on v
> >> e19 exit: execution(void FG.g()) on v
> >> e20 exit: call(void FG.g()) on v
> >>
> >> Or was that just a theoretical trace?
> >> Thanks.
> >>
> >>
> >>
> >
> >
> >
>
>
>

-- 
Eric Bodden
Sable Research Group
McGill University, Montréal, Canada