Re: [babel] silent code block evaluation on export

["Eric Schulte" <schulte.eric@gmail.com>]

Hi Erik,

I believe that when a session is specified then all code blocks will be
evaluated but their results will not be included in the exported output.

However you make a good point about the case of
  :exports results :results silent

I would think that in this case it would be useful to guarantee that the
block *will* be evaluated but the results *will not* be included.  I'll
add this as PROPOSED to the Babel task list.

Thanks -- Eric

BTW:
you mention the writing out of results in R even when :results silent
has been specified.  This is because the results are still collected in
this case, they just aren't inserted (not they are echo'd in the message
area during interactive evaluation of a silent block)

Erik Iverson <eriki@ccbr.umn.edu> writes:

> Hello! I have pasted an org-mode file with my question, it's
> easies to explain by copying the below file and exporting it
> to HTML.
>
> Thanks,
> --Erik
>
> ----------------------------------------------------------------
> * Silent code block evaluation on export.
>
> The goal is to /run/ a code block on export for some side effect,
> without any evidence in the exported file that this happened. For
> example, loading some R package, reading in a dataset, or setting R
> options. All this is presumably done with :session in mind, even
> though I don't use it here.
>
> In Sweave, we can specify the code block options echo = FALSE, results
> = hide to faciliate this.
>
> However, there are no command line arguments alone in org-mode that
> can replicate such behavior.  Below are several examples and how they
> fail.  There is also an example of a 'trick' that does work to
> generate the output (or lack thereof) that we want.
>
> /:results value/ tries to coerce its return value to a data.frame, so when
> I reference 'non-conformable object' below, I mean something for which
> the as.data.frame function generates an error.
>
>
> * /:results value/ (the default for code blocks)
>
> ** with a simple object on the last line, a vector
>
> This prints the return object, OK.
>
> /:exports results :results value/
> #+begin_src R :exports results :results value
> 2 + 2
> #+end_src
>
>
> ** with a non-conformable object as the final value
>
> This produces an error, as expected, and no output is produced, but
> only by accident.
>
> /:exports results :results value/
> #+begin_src R :exports results :results value
> summary(lm(1 ~ 1))
> #+end_src
>
> ** using NULL as the last line
>
> This does what we want, but requires a 'trick'. OK.
>
> /:exports results :results value/
> #+begin_src R :exports results :results value
> summary(lm(1 ~ 1))
> NULL
> #+end_src
>
>
> * /:results silent/
>
> ** with a simple object on the last line, a vector
>
> This still prints the return object, it may be debateable if it
> should.  The combination of /:exports results/ and
> /:results silent/ does not seem inherently self-contradictory.
>
> /:exports results :results silent/
> #+begin_src R :exports results :results silent
> 2 + 2
> #+end_src
>
> ** with a non-conformable object as the final value
>
> However, with a non-conformable object on last line, an error is
> produced when the code is evaluated in the buffer. I'm wondering if
> /:results silent/ is specified, why the cast to data.frame is
> occurring? It could be happening for good reason that I'm not aware
> of. The lack of output here is due to an error occurring.
>
> /:exports results :results silent/
> #+begin_src R :exports results :results silent
> summary(lm(1 ~ 1))
> #+end_src
>
> ** using NULL as the last line
>
> This does as we want, using the NULL trick.
>
> /:exports results :results silent/
> #+begin_src R :exports results :results silent
> summary(lm(1 ~ 1))
> NULL
> #+end_src
>
>
> * Ideas
>
> Since the NULL trick is R-only, how could we specify command line
> options to faciliate this use case?
>
> Possible solutions:
> 0) There already exists a solution that I don't list here.
>
> 1) Make /:exports results :results silent/ do it, but note the results
>    above with a non-conformable object!
>
> 2) Make /:exports none/ still evaluate the code block on
>    export. Probably counter-intuitive.
>
> 3) Make export use the /:eval/ argument combined with /:exports/,
>    maybe something like: /:exports none :eval yes/
>
> 4) Another better solution!
>
>
>
>
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode