[ESS] interactive evaluation of embedded code blocks

[Vitalie Spinu]

Thanks Yihui, 

I have added this feature to my todo list. 

To clarify one thing. Does "text" argument accept only one chunk, or it can
process arbitrary text blocks, possibly with several chunks in it?

Vitalie.


  >> Yihui Xie <xie at yihui.name>
  >> on Tue, 7 Aug 2012 22:23:02 -0400 wrote:

  > 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.nameDepartment 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
  >> 

  > ______________________________________________
  > ESS-help at r-project.org mailing list
  > https://stat.ethz.ch/mailman/listinfo/ess-help