emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* [babel] silent code block evaluation on export
@ 2010-08-31 18:42 Erik Iverson
  2010-09-02  0:15 ` Eric Schulte
  0 siblings, 1 reply; 5+ messages in thread
From: Erik Iverson @ 2010-08-31 18:42 UTC (permalink / raw)
  To: emacs-orgmode

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!

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [babel] silent code block evaluation on export
  2010-08-31 18:42 [babel] silent code block evaluation on export Erik Iverson
@ 2010-09-02  0:15 ` Eric Schulte
  2010-09-02  1:37   ` Eric Schulte
  0 siblings, 1 reply; 5+ messages in thread
From: Eric Schulte @ 2010-09-02  0:15 UTC (permalink / raw)
  To: Erik Iverson; +Cc: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [babel] silent code block evaluation on export
  2010-09-02  0:15 ` Eric Schulte
@ 2010-09-02  1:37   ` Eric Schulte
  2010-09-02  2:09     ` Erik Iverson
  0 siblings, 1 reply; 5+ messages in thread
From: Eric Schulte @ 2010-09-02  1:37 UTC (permalink / raw)
  To: Erik Iverson; +Cc: emacs-orgmode

"Eric Schulte" <schulte.eric@gmail.com> writes:

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

To clarify the above,

if a code block has a :session header argument, then it is assumed that
the block should be evaluated regardless of it's :export header
argument, because it could change the state of the session, so in the
following simple example the first code block is evaluated on export
despite having an :exports none header argument, and this ensure that
the value of x is set for the second code block.

--8<---------------cut here---------------start------------->8---
** :session evaluation on export
This first block is evaluated but /doesn't/ appear in export.

/:session *R* :exports none/
#+begin_src R :session *R* :exports none
  x <- 8
#+end_src

This second block /does/ appear in export.

#+begin_src R :session *R* :exports results
  x
#+end_src
--8<---------------cut here---------------end--------------->8---

Cheers -- Eric

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [babel] silent code block evaluation on export
  2010-09-02  1:37   ` Eric Schulte
@ 2010-09-02  2:09     ` Erik Iverson
  2010-09-02  4:10       ` Eric Schulte
  0 siblings, 1 reply; 5+ messages in thread
From: Erik Iverson @ 2010-09-02  2:09 UTC (permalink / raw)
  To: Eric Schulte; +Cc: emacs-orgmode

On 09/01/2010 08:37 PM, Eric Schulte wrote:
> "Eric Schulte"<schulte.eric@gmail.com>  writes:
>
>> 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.
>>
>
> To clarify the above,
>
> if a code block has a :session header argument, then it is assumed that
> the block should be evaluated regardless of it's :export header
> argument, because it could change the state of the session,


Ahh, I never tried exactly that.  However, this only seems to work
if the :session is named.

E.g., /:session *R* :exports none/ will do what you say,

but not /:session :exports none/ , which may be a bug?



so in the
> following simple example the first code block is evaluated on export
> despite having an :exports none header argument, and this ensure that
> the value of x is set for the second code block.
>
> --8<---------------cut here---------------start------------->8---
> ** :session evaluation on export
> This first block is evaluated but /doesn't/ appear in export.
>
> /:session *R* :exports none/
> #+begin_src R :session *R* :exports none
>    x<- 8
> #+end_src
>
> This second block /does/ appear in export.
>
> #+begin_src R :session *R* :exports results
>    x
> #+end_src
> --8<---------------cut here---------------end--------------->8---
>
> Cheers -- Eric

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [babel] silent code block evaluation on export
  2010-09-02  2:09     ` Erik Iverson
@ 2010-09-02  4:10       ` Eric Schulte
  0 siblings, 0 replies; 5+ messages in thread
From: Eric Schulte @ 2010-09-02  4:10 UTC (permalink / raw)
  To: Erik Iverson; +Cc: emacs-orgmode

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

> On 09/01/2010 08:37 PM, Eric Schulte wrote:
>> "Eric Schulte"<schulte.eric@gmail.com>  writes:
>>
>>> 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.
>>>
>>
>> To clarify the above,
>>
>> if a code block has a :session header argument, then it is assumed that
>> the block should be evaluated regardless of it's :export header
>> argument, because it could change the state of the session,
>
>
> Ahh, I never tried exactly that.  However, this only seems to work
> if the :session is named.
>
> E.g., /:session *R* :exports none/ will do what you say,
>
> but not /:session :exports none/ , which may be a bug?
>

I agree this should be considered a bug.  In general we need to be more
explicit about what happens when a header argument is used without any
explicit argument (this same issue just came up with :noweb).

Noted. Thanks -- Eric

>
>
>
> so in the
>> following simple example the first code block is evaluated on export
>> despite having an :exports none header argument, and this ensure that
>> the value of x is set for the second code block.
>>
>> --8<---------------cut here---------------start------------->8---
>> ** :session evaluation on export
>> This first block is evaluated but /doesn't/ appear in export.
>>
>> /:session *R* :exports none/
>> #+begin_src R :session *R* :exports none
>>    x<- 8
>> #+end_src
>>
>> This second block /does/ appear in export.
>>
>> #+begin_src R :session *R* :exports results
>>    x
>> #+end_src
>> --8<---------------cut here---------------end--------------->8---
>>
>> Cheers -- Eric

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-09-02  4:10 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-31 18:42 [babel] silent code block evaluation on export Erik Iverson
2010-09-02  0:15 ` Eric Schulte
2010-09-02  1:37   ` Eric Schulte
2010-09-02  2:09     ` Erik Iverson
2010-09-02  4:10       ` Eric Schulte

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).