[ESS] interactive evaluation of embedded code blocks

Yihui Xie xie at yihui.name
Wed Aug 8 04:23:02 CEST 2012


Well, I thought I had to do a lot of work in knitr for this feature,
but it turns out that I need to do nothing: to interactively evaluate
a code block, you just need to pass that block to the 'text' argument
of knit() directly. I believe this should be trivial to implement for
ESS developers.

For example, you can

library(knitr)
# you'll get figure/test.pdf
knit(text = '
<<test>>=
x <- rnorm(100)
mean(x)
par(mar=c(4, 4, .1, .1)); plot(x)
@
')

After you change the code, you just ask ESS to send it to knitr again
in the same R session. You will have all the side effects as expected
(e.g. plots and cache). There is nothing tricky and nothing to
remember here. Everything is still like Sweave, except Sweave() does
not have a 'text' argument.

Regards,
Yihui
--
Yihui Xie <xieyihui at gmail.com>
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Sat, Jun 2, 2012 at 12:37 PM, Michael Lawrence
<lawrence.michael at gene.com> wrote:
> Interesting to hear the chatter about knitr today. Related to this is the
> desire to evaluate Sweave, knitr, etc reports incrementally and
> interactively. It is of course currently possible to evaluate the *body* of
> a block, but what about the other parameters of the block with side
> effects? This is essentially a generalization of the report generator to
> the notion of "annotated code blocks".
>
> My primary use case is interactive data analysis using a literate
> programming document instead of a simple script. This is often a convenient
> way to work, because it's easy to record thoughts, plans, observations and
> the code in a single document, and then the final result can be generated
> as a report. The analysis itself is an iterative and interactive process,
> so continually regenerating a report, even with caching, is not very
> efficient or convenient.
>
> Here are some concrete benefits:
>
> Figure files could be generated outside of the report generation, i.e.,
> when fig=TRUE. I am constantly having to write pdf()/dev.off() around by
> code blocks. Utilities like ggsave() help a little in some cases, but using
> the code block name to name the figure automatically would be even more
> convenient.
>
> Caching support, as implemented by knitr or Seth's weaver package, could be
> useful for saving intermediate results, for either passing to a colleague
> or for resuming later.
>
> The extensibility of knitr opens up additional possibilities.
>
> These annotated meta blocks effectively separate the accidental issues of
> saving and distributing results from the analysis itself. What do you guys
> think? Are code blocks only for generating reports, or could we use them in
> other ways?
>
> Michael
>



More information about the ESS-help mailing list