From rpeng at jhsph.edu  Mon Oct 17 14:22:46 2011
From: rpeng at jhsph.edu (Roger D. Peng)
Date: Mon, 17 Oct 2011 08:22:46 -0400
Subject: [Rd] "What Calls What" diagram. Flow Chart?
In-Reply-To: <CAErODj9AZS1JnnKXDGP1-Pv0NkT941Rt8sV15o5Gy08Gn-5PDw@mail.gmail.com>
References: <CAErODj9AZS1JnnKXDGP1-Pv0NkT941Rt8sV15o5Gy08Gn-5PDw@mail.gmail.com>
Message-ID: <CAE_NaA22J=ZpCUP1qnjYdmUpoHn2Uvz-4CSgoLR2FdeLkYHUBA@mail.gmail.com>

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/



[Rd] "What Calls What" diagram. Flow Chart?
Roger D. Peng