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/
next prev parent 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
* 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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.