Dear Michael and other list members,

I have not written a mail to this list yet as just trying to learn ESS
properly rather then have to say something useful, but I might have some
alternative solutions/POC examples about your question. I would like to
apologise for the long mail/tons of links in advance!

I am currently developing an R package, called
pander<https://github.com/daroczig/pander>:
a Pandoc<http://www.google.hu/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CFQQFjAA&url=http%3A%2F%2Fjohnmacfarlane.net%2Fpandoc%2F&ei=dGvKT8iXCMTrOZLn8QU&usg=AFQjCNEvOD-RkHDmvIL936uCP2LtOknXew>'s
markdown (compatible with traditional markdown with bunch of extra
features) writer, which works like knitr with a brew like syntax (among
some other ways). The main advantage of this alternative report generation
is that you do not have to sign in any way in your  tags that you would
generate an image/plot, as the functions used
(eval<https://github.com/aL3xa/rapport/blob/master/R/eval.R> from
rapport <http://rapport-package.info/> package developed my Aleksandar
Blagotic and me) would auto-recognize that a graphic device was touched and
render that to a png file named to something like "report-name-ID.png" and
also adds a link in the generated markdown document in place of the R code.
Of course all generated images could be pdf, jpg etc. - it's just an option
you set after loading the packages. And the resulting markdown can be
easily converted with a function call to HTML/pdf/docx/odt etc., but it
might be better to checkout some
examples<http://daroczig.github.com/pander/#examples_link>
.

Currently partitioning some parts of rapport to pander, as now the
requirements to run my functions looks like: install Pandoc and two R
packages from GitHub <http://daroczig.github.com/pander/#installation_link>,
which is painful, but once this gets towards pander's first final release
(in a few days), it could go to CRAN hopefully (you can find rapport there
- but unfortunately a quite old build).

But back to your mail, you asked: "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?"
It is IMHO.

First, I would suggest to use the above cited "evals" function, as it
evaluates the R command, grabs the returning R object and anything written
to stdout, besides renders the (optionally) generated image to disk with
controllable file name and options (like resolution etc.) and grabs all
messages/warnings/errors while evaluation and returning all this in a
structured list.

Alex and me have developed a package around this (or: we have created this
function to behave as one of the backends of our package) which quite
differs from "traditional reproducible research" strategies: we are dealing
with templates <http://rapport-package.info/#templates> there which could
be run on any dataset (like crosstabe on two specified variables,
correlation matrix etc.).
This packages uses a brew like syntax too and all R code blocks found would
be passed to "evals" which grabs the above listed values. Besides the fact
that you can export that list of report blocks to markdown/html/pdf etc.
with the help of Pandoc, you still have the structured list of the
evaluated report as an R object with meta-information (used template,
description, author etc., proc.time), the call (optionally with the used
dataset attached) and each report element (text, run R code, results in R
object, messages/errors etc., stdout and generated images path).

There are many ways to deal with that list, in the above cited packages we
are doing printing to console, writing markdown file (quite a wide variety
of R objects automatically transformed to markdown) or other formats.

I hope this could be useful/inspiring.

Best,
Gergely



On Sat, Jun 2, 2012 at 6:37 PM, Michael Lawrence
<lawrence.michael@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
>
>        [[alternative HTML version deleted]]
>
> ______________________________________________
> ESS-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help
>

	[[alternative HTML version deleted]]

