Le Mon, 21 Apr 2008 21:58:18 +0200, Frederik Deweerdt <[EMAIL PROTECTED]> a écrit :
> On Sun, Apr 20, 2008 at 02:26:49PM +0200, Eric Noulard wrote: > [...] > Just finished reading the research paper :). More to come stay tuned :=) > > Practically TAP only gives us vision of the "ok" steps, > > I want to be able to trace ALL steps: ok, barrier, expect, > > send, .... As an example I may want to define something like an > > "observer step" which may gives me [non-intrusively] state > > values/counters from a running DTester, > > using these values I may implement an ok step in order to validate > > the range of the values. > Ok, I see. Didier seems to prefer a more versatile interface too. > Just for arguments's sake, couldn't that be run like this: > > Client -------------- Server > \ / \------ Invariant observer > TAP TAP | > \-> DTestMaster <---TAP--/ > > Even though what the observer observes is more than simple Ok/Nok > steps. The answer to "did we perform y before x" is still Ok/Nok. > I've got no strong feelings to keep TAP, I'm basically OK with TAP output as a "default" behaviour. In order to keep it simple I will add a TraceHandler and a TraceManager to DTest with a "relatively open" API which may handle "every kind of steps". This is easy to do in python since we may pass "callable" to a function and dynamically inspect its prototype. (which is the task currently done with the stepmethod in DTester::addRunStep(self, stepmethod,*args, **kwargs) method) TAPTraceHandler will inherit from TraceHandler (which does basically nothing beside defining the appropriate API callable by TraceManager). TAPTraceHandler will only handle "ok" steps and ignore other steps which is the inherited behaviour. > I just want to make sure that we're not over engineering here. I don't think the scheme is over engineered since you won't see the "over-engineered API" if you dont wan't to. I'll try a first implementation of TraceManager, TraceHandler and TAPTraceHandler in a day or 2. -- Erk _______________________________________________ Tsp-devel mailing list Tsp-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tsp-devel
