[Rd] "What Calls What" diagram. Flow Chart?
pauljohn32 at gmail.com
Sun Oct 9 21:49:21 CEST 2011
I don't know the right computer science words for this question, I'm
afraid. Apology in advance.
How do you find your way around in somebody else's code? If the user
runs a specific command, and wants to know how the data is managed
until the result is returned, what to do ?
I've tried this manually with tools like mtrace and browser. This is a
bit frustrating because the browser does not stay in effect until the
work is done. It quits at the end of the function. So you have to
attach the browser to the functions that are called there, and so
forth. But that doesn't quite put everything together.
Example. Recently I was trying to find out where the package lavaan's
calculations for the function cfa are actually done and it was a
maddening chase from one function to the next, as data was
re-organized and options were filled in. lavaan's "cfa" function
reformats some options, then the work gets done by an eval.
cfa> fit <- cfa(HS.model, data=HolzingerSwineford1939)
debugging in: cfa(HS.model, data = HolzingerSwineford1939)
mc <- match.call()
mc$model.type = as.character(mc[[1L]])
if (length(mc$model.type) == 3L)
mc$model.type <- mc$model.type[3L]
mc$int.ov.free = TRUE
mc$int.lv.free = FALSE
mc$auto.fix.first = !std.lv
mc$auto.fix.single = TRUE
mc$auto.var = TRUE
mc$auto.cov.lv.x = TRUE
mc$auto.cov.y = TRUE
mc[[1L]] <- as.name("lavaan")
The value of "mc" that gets executed by eval is this
lavaan(model.syntax = HS.model, data = HolzingerSwineford1939,
model.type = "cfa", int.ov.free = TRUE, int.lv.free = FALSE,
auto.fix.first = TRUE, auto.fix.single = TRUE, auto.var = TRUE,
auto.cov.lv.x = TRUE, auto.cov.y = TRUE)
So then I need to but a debug on "lavaan" and step through that, see
what it does.
Is there a way to make a list of the functions that are called "pop
out", possibly with a flow chart?
Consider lm, I want to know
lm -> lm.fit -> .Fortran("dqrls")
I'm not asking for a conceptual UML diagram, so far as I know.
The kind of trace information you get with gdb in C programs and
shallow steps with "n" would probably help. I would not need to keep
attaching more functions with debug.
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas
More information about the R-devel