[R] function coverage

[Duncan Murdoch]

On 13-01-14 4:08 PM, Ross Boylan wrote:
> Is there an easy way to identify all the functions called as a result of
> invoking a function?  Getting the calling hierarchy too would be nice,
> but is definitely not essential.

I think codetools could do this reasonably well with the walkCode 
function, but I've never done it so I don't have sample code, and 
walkCode is mostly an internal function.

The other way to do it is to run Rprof.  It's only a sampling profiler, 
so you don't get complete coverage, but it sees what really happens at 
run-time.  The proftools package can generate a call tree.  (In R 3.0.0 
you'll probably be able to extend this coverage analysis to the 
statement level, but it's not there yet.)

>
> I'm trying to understand someone else's package, which is in a namespace
> and has some S3 functions.  I could probably live without tracing the S3
> functions.  All the functions I want to trace are in R.  The code passes
> functions around as arguments, so that the function being called is not
> always obvious from inspection of the source immediately around the
> call.

Right, that makes it hard.  I don't know if walkCode could figure that 
stuff out, and the current Rprof won't know the original name if you do 
something like

f <- mean
f(3)

The new stuff should be able to help in cases where the called function 
is written in R and is slow enough to be caught by the profiler.  If you 
want to try it out and can compile R-devel for yourself, write to me and 
I'll send you a patch offline.

>
> I can imagine a solution that went something like this:
> 1. identify all functions by searching the sources for xxxx <- function(
> (probably only at the left margin, to avoid attempting to trace
> functions defined inside of functions).
> 2. Write a function that wraps another function to record the fact that
> it has been called.
> 3. Somehow replace all functions with their wrapped equivalents.
> 4. make the top level call.
> 5. inspect the data constructed by the wrapper.
>
> The code is recursive and iterative; manual stepping does not seem
> feasible.  The package includes a lot of earlier versions of the code,
> and so I suspect that a lot of the code is not active.

Duncan Murdoch