[abc] RE: RV05 publication (fwd)

and a response...

---------- Forwarded message ----------
Date: Fri, 15 Apr 2005 18:25:38 +0100 (BST)
From: Oege de Moor <Oege.de.Moor@comlab.ox.ac.uk>
To: Eric Bodden <eric@bodden.de>
Cc: 'Oege de Moor' <Oege.de.Moor@comlab.ox.ac.uk>
Subject: RE: RV05 publication

On Fri, 15 Apr 2005, Eric Bodden wrote:

> is "stutter-free". So we do *not* allow one do express if there has
> been one single call v.f() or a sequence of those. Maybe this did not
> become clear in our paper, but we will allow the "Next" operator "X"
> only in combination with another temporal operator, e.g. "XF
> call(c.f())". Thus, things like "call(v.f()) && X call(v.f())" cannot
> be expressed. So in fact the trace "v.f(); v.g(); v.g(); v.h();"
> *would* in our semantics match the trace "call(v.f()) && XF(
> call(v.g()) && XF (call(v.h()) ))". I think this is the major
> difference and might be why I feel we need no "skip". Does that make
> sense?

To be honest, I don't quite understand.

How do you decide whether a joinpoint has nothing to do with the
LTL formula in hand? For us, we ignore all events that *after the
complete variable instantiation is known* do not match any of the
declared symbols. What is the equivalent criterion in your setting?

I'm also not sure what the "stutter-free" condition is precisely.
Can you elaborate?

> >> General comments on trace matches: You model events "which prevent
> >> a tracematch from matching" by symbols which do not occur in the
> >> pattern.
> >> I would maybe find one *distinct* "exit" symbol or somthing like
> >> this more intuitive. Using or (|) it could fulfill the same
> >> purpose.

ok, thanks, I get that now. It's a possibility, but I'm not too
keen on the new keyword.

> By the way: Interesting trick with the some()-pointcut, because we
> had a similar problem, when it came to "matching several pointcuts on
> a single joinpoint", which basically broke down to generating all 2^n
> boolean combinations of pointcuts or "gather a list of pointcuts that
> match" adding one affter the other as you do with n+1 pieces of
> advice. Obviously the latter is much better.

Right! We had a 2^n combinations implementation at some stage
too... Clearly there's a lot of overlap in what we're doing, so
let's keep the discussion going.

Thanks,

-Oege
Received on Fri Apr 15 18:43:03 2005