[m-dev.] add goal path at external ports

[Erwan Jahier]

| In each case the goal path for an external port at depth N is the same as
| the most recent goal path for an internal port at depth N - 1.  So if
| you remember the most recent goal path for each depth less (shallower)
| than the current depth, you can reconstruct that context information.

Sure. But if I want to work out the coverage ratio of a several millions events 
execution, it would be far more too inneffective (see after). 

| > How hard do you think it is to add this information to the current trace ?
| > Is this information still available when generating external events ? 
| 
| You could reserve a stack slot, store the information there for
| every internal port, then look it up at every external port.  
| I wouldn't recommend this though, since for large conjunctions you
| may wind up sending the same goal path through the socket many
| times.  You would pay for the extra stack slot 

Well, is there any reason why this can't be done at compile time (i.e. when 
generating the code and the MR_trace statements ?)

| and socket traffic
| whether you wanted the extra information or not.

Good point. 
Maybe we could have a compiling option that can turn on and off 
the fact that we fill that slot.


| > Maybe once we've got that, we don't need internal ports anymore... (?)
| 
| Maybe, but with internal ports we don't need the extra goal paths (!)

I don't agree (See the following of my message).


| > The current goal paths information is not sufficient : if you consider my
| > exemple, all the possible goalpaths that can be generated are
| > {"?;d1","?;d2","e","t"}. Now suppose you have other input values to p such that
| > c fails. Then in that case the else branch is entered, and all the possible
| > goal paths have generated. Nervertheless, the goal b has never been entered ! I
| 
| Your proposed change doesn't add to that set of possible goal paths, so
| you would still have this problem.

OK, I think I need to tell a little bit more...

In fact my first idea was to stop at every internal port and collect the goal
paths as a set of pair : (procedure, goalpath). Since all the possible goal
paths can be generated staticly from the HLDS, we then just have to compare the
2 sets of goal paths to have a coverage ratio.

But then you have the problem caused with my exemple (((a,b);c) -> d ; e). With 
this proposal, you have no way to check b has been executed if b doesn't 
generate any internal event.

So what I propose is in fact to define a path as being a quadruplet (procedure,
ancestor of this procedure, goal path, list of ports exit and fail).

for example (foo, bar, "t", [exit,exit,fail]) means that for the occurence of
foo that appears in the "then" branch of the predicate bar, we want to check
that this goal succeed twice and fails once (because it is nondet ; if it is
det, then we could only require one success ; and so on for the other
determinisms. All those paths to be covered can again be generated automaticly
for the HLDS and the determinism declarations, for every goals in every
procedures of the program under 
test).

To check that those paths are covered, just stop at call and exit ports, retrie
ve the curent pred, port, goalpath and ancestor, and add that current path
to set of paths to be covered (the opium code that does that is 10 lines, provided
I have goalpath information at exit and fail ports).
 

| > think what I really need is the information about the context I was just
| > requesting about (I could elaborate on that but I think it is enough for this
| > time...).
| > 
| 
| I think I understand the difficulty.  Here is another problematic
| example:
| 
| p(X, Y) :-
| 	( c(X), c(Y) ->
| 		d
| 	;
| 		e
| 	).
| 
| If the condition fails, how do we know which call to c/1 failed?  We
| could always inspect the arguments of p and c, but this is asking
| a fair bit from the user...

I think in such a context (test coverage), we don't have to care about what a 
user can do but about what can be done automaticly in a reasonable amount of 
times.

Retriving automaticly the arguments is easy to do automaticly within opium, 
but it migth be expensive with a several million events execution.

I think this problematic is more difficult (so maybe more interesting 
;) than mine (data). It would certainly be the next step to work out the 
coverage of test suite.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

| >            ----------------
| > ps :
| > The reason I am asking that is that I try to work out some kind of path
| > coverage rate of a test suite. Most of the time, this is done by source code
| > instrumentation. But here, I think we can take advantage of the information
| > contained in the trace and particulary the goalpath attribute. 
| 
| That is a good idea.  But I think there is already enough information
| in the trace for what you want.
| 

Yes we do, but as I said it would be too innefective (I could elaborate on 
that, but maybe you've got enough for today ;)



-- 
R1.