emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Eric Schulte <eric.schulte@gmx.com>
To: Matthew Landis <landis@isciences.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Selectively export RESULTS
Date: Fri, 02 Mar 2012 12:33:58 -0700	[thread overview]
Message-ID: <87399qn6ft.fsf@gmx.com> (raw)
In-Reply-To: loom.20120302T191703-521@post.gmane.org

Matthew Landis <landis@isciences.com> writes:

> Eric Schulte <eric.schulte <at> gmx.com> writes:
>
>> 
>> Matthew Landis <landis <at> isciences.com> writes:
>> 
>> Have you tried this?  The cache header argument has special handling of
>> code blocks with sessions to handle such cases.
>
> Fair enough!  I hadn't tried it.  But I did just try this example:
>
> -------------------------------------
> #+TITLE: Super simple example using cache header arguments
> #+PROPERTIES: eval no
>

The above line should be #+PROPERTY: singular.  That explains why
file-wide settings aren't working for you.

>
> Here is a really simple example.
>
> #+begin_src R :session :results silent :exports code :cache yes
> x <- rnorm(100)
> cat('ran this code block')
> #+end_src
>
> here is code block two.
>
> #+begin_src R :session :results graphics :exports both :file hist.png :cache yes
> hist(x, main = 'A new title' )
> #+end_src
>
> #+results[1987d49b46ffd8b7263dc04e7c7b5d25f90342aa]:
> [[file:hist.png]]
> ---------------------------------
>

Thanks for the example, after working through it I now know what is
causing this issue.  The first code block will always be run for two
reasons.
1. it is run in a session, which means that Babel can not guess at to
   what state it could be changing internal to the session, so it
   defaults to the safest option which is allowing the code block to run
2. since this code block returns no results, there is no place for Babel
   to store the hash key holding the information on the code block and
   arguments used to produce the results.  Remember that Org-mode is
   nothing more than the text in the file, so without this stored hash,
   there is no way for Babel to know that the code block was previously
   run, or that it may have results.

For these reasons I would suggest either fixing the properties issue
above, which will allow you to set eval to "no" before export when you
are content with your current results, or I would suggest that you
switch from session based evaluation to explicitly passing the values
through Org-mode, which will allow babel to cache results.

I will update the ":cache" section of the manual so that it mentions the
issues around mixing ":session" and ":cache" header arguments.

Best,

>
> RESULTS:
> On 1st export to html, both code blocks are run, and #+results block is *not* 
> created.  
>
> On 2nd export, both code blocks are run again, counter to my desires.
>
> IF I run the code blocks interactively first using C-c C-c, the #+results block 
> is created for the code block 2.  After that, subsequent exports run code block 
> 1 but not code block 2.  Again, this is counter to my desires because I want 
> code block 1 to be ignored as well.  I understand why code block 1 is rerun, 
> because I have :results silent, but I'd rather not have to change that.  
> Generally, code block 1 is producing large R data.frames which don't need to be 
> viewed anywhere.
>
>> Are you requesting a new option to :cache, such that even if the code
>> block has changes the old results are used anyway?
>
> Sort of.  I think I'm asking for a file wide option to decide whether to run any 
> code blocks, or just do the export based on whatever is currently existing in 
> the #+results blocks.
>
> As in this example, I tried #+PROPERTIES: eval no but it is ignored.  It would 
> be great if I could set an eval argument at the top of the file to be either 
> 'no' (don't run any code blocks) 'yes' (run all code blocks) or 'block' respect 
> block level eval settings 
>
> Maybe such functionality exists in some other way - I claim only beginners 
> knowledge of org-babel.
>
>
>
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

  reply	other threads:[~2012-03-02 19:34 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-29  5:04 Selectively export RESULTS cberry
2012-02-29  7:05 ` Thomas S. Dye
2012-02-29 16:50   ` cberry
2012-02-29 17:06     ` Eric Schulte
2012-02-29 20:24       ` cberry
2012-03-02 17:24         ` Matthew Landis
2012-03-02 17:48           ` Eric Schulte
2012-03-02 18:33             ` Matthew Landis
2012-03-02 19:33               ` Eric Schulte [this message]
2012-03-02 20:12                 ` Matthew Landis
2012-03-02 20:20                   ` Eric Schulte
2012-03-03 10:43                     ` Sebastien Vauban
2012-03-03 14:52                       ` Achim Gratz
2012-03-03 23:01                         ` Sebastien Vauban
2012-03-04 10:37                           ` Achim Gratz
2012-03-04 20:44                             ` Sebastien Vauban
2012-03-02 19:42             ` cberry
2012-03-02 20:26               ` Eric Schulte
2012-03-02 21:08               ` cberry
2012-03-02 21:26                 ` Nick Dokos
2012-03-02 21:35                   ` cberry
2012-03-02 23:01                     ` Nick Dokos
2012-03-02 17:59           ` Christophe Pouzat
2012-03-02 18:53             ` Matthew Landis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87399qn6ft.fsf@gmx.com \
    --to=eric.schulte@gmx.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=landis@isciences.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).