On Sat, Jun 2, 2012 at 1:01 PM, Daróczi Gergely wrote: > 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: > a Pandoc'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 from > rapport 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. > This evals() function sounds very similar to the evaluate package that knitr uses, except evaluate() seems like it should be called something more like repl(), since it prints results instead of returning them directly. What's missing for, say, integration with ESS and Sweave, would be a parser for the block that would delegate to evals(). > 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 > . > > 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, > 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). > > Do you think you could make an R package that solely interfaces with pandoc and which embeds pandoc within itself (this would depend on the license)? That avoids the system dependency. > 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 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. > > This automatic, high-level transformation of R objects to markdown is something that I have been seeking in a report generator. The simple print()ing of R objects does not often integrate well with the document. Another thing I've been wanting is a way to output objects in multiple ways, separate from the report itself. Typical side effects would be: generation of an R data package with the result as a dataset, or storage of the result in some other database. It would be cool to be able to specify, on a per-block basis, the output driver (or a list of them). For example, your pander() function could be a dual-dispatch S4 generic, dispatching on both the object to export, and an object representing the target. Thanks a lot for pointing out your package, Michael 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]]