[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [FR] Org babel: mixing multiple outputs (was: Output of R code block
From: |
Berry, Charles |
Subject: |
Re: [FR] Org babel: mixing multiple outputs (was: Output of R code block: only text or plot but not both? And only one "result" can be output?) |
Date: |
Wed, 5 Jun 2024 20:34:07 +0000 |
> On Jun 5, 2024, at 11:17 AM, Ihor Radchenko <yantar92@posteo.net> wrote:
>
> "Berry, Charles" <ccberry@health.ucsd.edu> writes:
>
>>> I am trying to have an R code block output both the results of a numerical
>>> expression AND a plot, but if I set up the header arguments to display the
>>> plot, the numerical outcome is not displayed. A simple example:
>>>
>>> #+begin_src R :file example.png :results output graphics file
>>> x <- rnorm(100)
>>> print(mean(x))
>>> hist(x)
>>> #+end_src
>>>
>>
>>
>> Babel is a great tool, but has some inherent limitations.
>
> While it is currently not directly possible to get a mix output and
> graphics results, this is _not_ inherent limitation.
>
Fair enough, it is not `inherent'.
> One can write a patch for ob-R to produce output type that mixes all the
> block results, including textual output, graphical output, and any other
> perceivable output.
Won't you still have issues like the `:session :results output' conundrum
mentioned below?
>
> Such patch would be a reasonable addition to babel backends like ob-R or
> ob-python.
>
>> Whilst you can work around this by breaking the above block into
>> multiple src blocks, you might have an easier time using ox-ravel
>> [1]. Basically, you export your *.org document to one of the
>> knitr/Rmarkdown/quarto formats (e.g. *.Rmd) and then render the final
>> output using one of those engines. This gives you access to the
>> capabilities of any of those engines. The downside, of course, is
>> that you need to learn a bit about the formatting rules in one of them
>> to fine tune your final output.
>>
>> FWIW, I copy and pasted your query to a `*.org` file, exported it to
>> `*.Rmd` with the latest ox-ravel version and rendered it as html -
>> displaying all the printed output and all three plots. That did not
>> need any modifications to your markup.
>
> Thanks for sharing the project!
> Although, I would not call going through double export, and producing
> html output "easier time".
>
The `easier' part is that knitr/Rmarkdown requires very little markup to
produce nice documents in various formats (pdf, html, Word, ...). And dealing
with R code and markup of the results of R code for use in documents is what
that environment is attuned to, so getting a desired result often seemed easier
to me in that environment.
In terms of my usual workflow, the double export (with ox-ravel and an
`org-render` helper function loaded) requires these keystrokes:
`C-c C-e r m M-x org-render RET`
or subsequently
`C-u C-c C-e M-x M-p RET`
which adds only two keystrokes.
> While we are here, are there any other features you find missing in Org
> babel that are present in knitr/Rmarkdown/quarto?
>
`:session :results output` handling in R lang src blocks can fail as the
heuristics for finding the output of a command in the session buffer and
removing the prompts have limited success. An ECM:
#+begin_src R :session :results output
cat("2 > 1\n")
#+end_src
There are workarounds, of course.
There was discussion here years ago of using an R package (evaluate?) to better
parse the session results. I can't recall why this was dropped - maybe it was
the requirement of additional software.
I recall hearing that `comint.el` would someday be replaced by a hardier
package, so maybe if/when that happens this can be cured.
A big motivation for creating `ox-ravel' was to be able to cache large objects.
I know the `:cache` header arg helps for small objects that require a lot of
computation, but AFAICS does not help once the object size gets large. The
caching options [1] of knitr and friends are flexible and powerful enough to
support the genomics work I do.
I mentioned above that knitr is attuned to working with R code/output. The
handling of warnings, errors, and messages resulting from R code has a number
of useful options under `Text Output` [2].
I guess a rewrite of ob-R.el to implement such features as object caching and
error/warning/message handling is feasible, but would require a lot of effort.
And since those features (and more - like animation support) are already
implemented in the knitr/Rmarkdown domain is it really worth pursuing?
Best,
Chuck
[1] https://yihui.org/knitr/options/#cache
[2] https://yihui.org/knitr/options/#text-output