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

[Mark Anthony BROWN]

Erwan Jahier writes:
> 
> | 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). 

I don't understand.


> 
> | > 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 ?)


No, this could be done.  But I forgot to mention my main point:  I
think this could be done more easily in Opium.


[...]

> 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.

I disagree.  If you record the most recent internal event at each depth,
then when you get an external event at depth N you have:
	i) the immediate ancestor (ie the procedure of the most
		recent internal event at depth N - 1),
	ii) the path to the called atom within the body of the
		ancestor (ie the goal path of the most recent
		internal event at depth N - 1), and
	iii) the procedure being called (ie the procedure of the current
		event).


The atom b, above, is executed if and only if a 'CALL b' event is reached
at depth N (for some N) when the most recent event at depth N - 1 has
procedure p and goal path "?;d1".

However, as I mentioned previously, there is no way to distinguish
between two calls to the same procedure in the same conjunction.


> 
> 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).

My suggestion would require more state than just the set of paths to be
covered, but I think it would still be SMOP in Opium.


[...]

> 
> 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.

Valid point, but the issue you raise is relevant to other contexts as
well.  Does anybody have any comments on how source linking should
be implemented?


Cheers,
Mark
-- 
Mark Brown  (dougl at cs.mu.oz.au)       )O+   |  For Microsoft to win,
MEngSc student,                             |  the customer must lose
Dept of Computer Science, Melbourne Uni     |          -- Eric S. Raymond