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

Mark Anthony BROWN dougl at cs.mu.OZ.AU
Wed Jan 27 17:48:40 AEDT 1999

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

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?

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

More information about the developers mailing list