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)
debug: {
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")
eval(mc, parent.frame())
}
The value of "mc" that gets executed by eval is this
Browse[2]> mc
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.
pj
--
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas
On Sun, Oct 9, 2011 at 5:29 PM, <Mark.Bravington at csiro.au> wrote:> Hi Paul > > Have you tried > > mvbutils::foodweb( where=asNamespace( 'lavaan')) > > (assuming lavaan has a namespace, otherwise where='package:lavaan')? > > Sounds like it's what you're after-- > > Mark >Thanks, Mark. The foodweb graph for lavaan is a bit overwhelming. The graph shows everything it finds that might be called any time, it doesn't help me trace the path of a specific user call to a particular function. So I'm not entirely sure it is doing what I hope for. While matching the graph against the source code, it seems to me some R language idioms can confuse/break the foodweb. When eval is called on a string object, then I think function calls can escape detection. In the cfa example code I put in the original post, the function "lavaan" is called by eval, and as far as I can tell in the foodweb output, that connection is not found. I'm still studying your package, of course, but here's (I think) an example, I know "cfa" does call "lavaan" though eval, but this code library(lavaan) library(mvbutils) mvbutils::foodweb( where=asNamespace( 'lavaan')) myfw <- mvbutils::foodweb( where=asNamespace( 'lavaan')) callers.of("lavaan", myfw)> [1] "independence.model" "independence.model.fit"[3] "independence.model.fit2" "setLavaanOptions" -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas
Paul, the 'cacher' package might have what you need. The 'graphcode' and 'objectcode' functions might be useful. Granted, this package is not really designed for visualizing code per se, but you can use the functionality nonetheless. -roger On Sun, Oct 9, 2011 at 3:49 PM, Paul Johnson <pauljohn32 at gmail.com> wrote:> 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) > debug: { > ? ?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") > ? ?eval(mc, parent.frame()) > } > > The value of "mc" that gets executed by eval is this > > Browse[2]> mc > 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. > > pj > > -- > Paul E. Johnson > Professor, Political Science > 1541 Lilac Lane, Room 504 > University of Kansas > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >-- Roger D. Peng? |? http://www.biostat.jhsph.edu/~rpeng/