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 10:48:29 -0700	[thread overview]
Message-ID: <87mx7ynbbm.fsf@gmx.com> (raw)
In-Reply-To: <loom.20120302T181328-40@post.gmane.org> (Matthew Landis's message of "Fri, 2 Mar 2012 17:24:44 +0000 (UTC)")

Matthew Landis <landis@isciences.com> writes:

>  <cberry <at> tajo.ucsd.edu> writes:
>
>> 
>> Eric Schulte <eric.schulte <at> gmx.com> writes:
>> 
>> >>> Does this do what you want?
>
>> >
>> > Have you looked at the :cache header argument [1], from my understanding
>> > of your use case it should be exactly what you are after.
>> >
>> 
>> Its a step in the right direction.
>> 
>> It seems I have to set :cache yes on every block I use before I invoke
>> it. My attempt to use a buffer-wide PROPERTY setting for cache did not
>> pan out. 
>> 

Were these technical problems with the implementation of :cache, or
logistical problems specific to your organization of code blocks?

>
> I'd like to put in a vote for the kind of functionality that cberry is 
> describing.  I have a very similar situation - a large org file that uses R to 
> do a lot of time consuming data manipulation and model fitting, resulting in 
> statistical tables and graphs.  I run a lot of the code blocks as I'm writing 
> it, resulting in :results in the org file.  
>
> In the end, I'd like to export the org file to html or ODT, but I'd like to be 
> able to choose buffer-wide whether to rerun all of the code blocks or just use 
> the results that are already in the buffer.  I tried setting #+PROPERTY: eval no 
> at the top of the buffer in the hopes that on export, it would ignore all my 
> code blocks and just incorporate the :results, but this was ignored and my code 
> blocks were rerun.
>
> The cache argument only partially deals with the problem, as this example 
> illustrates:
>
> #+begin_src R :session :cache yes
> x <- rnorm(100)
> #+end_src
> #+begin_src R :session :results graphics :exports results :file hist.png :cache yes
> hist(x)
> #+end_src
>
> Now after the first export, I change code block 2, but not code block 1.  If I 
> understand how cache works correctly, code block 2 will be rerun, but it will 
> fail because code block 1 is not rerun, so x doesn't exist in the R session.  
>

Have you tried this?  The cache header argument has special handling of
code blocks with sessions to handle such cases.

>
> For this reason, I'd prefer to be able to decide whether to re-run on a file-
> wide basis.
>

I'm not clear on why file-wide setting of cache does not work.

Are you requesting a new option to :cache, such that even if the code
block has changes the old results are used anyway?

>
> Many thanks to all of you who have created such an amazing system.
>

Thanks,

>
> M
>
>
>

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

  reply	other threads:[~2012-03-02 17:48 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 [this message]
2012-03-02 18:33             ` Matthew Landis
2012-03-02 19:33               ` Eric Schulte
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=87mx7ynbbm.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).