From: "Eric Schulte" <schulte.eric@gmail.com>
To: Rainer M Krug <r.m.krug@gmail.com>
Cc: Ken.Williams@thomsonreuters.com, emacs-orgmode@gnu.org
Subject: Re: [babel] Trouble with :cache yes
Date: Wed, 23 Mar 2011 11:28:05 -0600 [thread overview]
Message-ID: <87oc51enq1.fsf@gmail.com> (raw)
In-Reply-To: AANLkTik7da5EShifwxcX8w2TyABM4+=83=baKt-=MXj2@mail.gmail.com
Rainer M Krug <r.m.krug@gmail.com> writes:
> On Wed, Mar 23, 2011 at 3:50 AM, Eric Schulte <schulte.eric@gmail.com> wrote:
>> Hi Ken,
>>
>> In order for caching to work, the results of the code block must exist
>> in the org-mode file. For example, the following code block will be
>> evaluated when triggered either interactively or during export
>>
>> #+begin_src emacs-lisp :cache yes
>> (+ 2 2)
>> #+end_src
>>
>> alternately, this block will not be evaluated when triggered either
>> interactively or on export, because the cached results are present
>>
>> #+begin_src emacs-lisp :cache yes
>> (+ 2 2)
>> #+end_src
>>
>> #+results[9b77429d6cea71daf37e21ee09170810b9905066]:
>> : 4
>>
>> In your example, for the code block to not be evaluated as part of the
>> export process, you must first evaluate it manually within the Org-mode
>> file, leaving the results (with the hash tag) saved in the Org-mode
>> file.
>
> I will chime in here, because I had a similar problem. This does not
> work for me. When I evaluate manually (C-c c) I get the following:
>
Thanks for pointing this out, your example doesn't work for me either.
I tracked this down to a problem of not finding the cached results of
named code blocks. I've just pushed up a simple fix for this issue, so
caching should now work as expected.
Best -- Eric
>
> * test
> #+source: testcache
> #+begin_src R :cache yes :exports both :results output
> dat <- matrix(runif(12), 3, 4)
> print(dat)
> #+end_src
>
> #+results[cad298135e53df633545d6a32a8b2aab5201721c]: testcache
> : [,1] [,2] [,3] [,4]
> : [1,] 0.4470891 0.2016197 0.1383083 0.6214485
> : [2,] 0.1598936 0.3819967 0.3527698 0.5124687
> : [3,] 0.3040325 0.5906898 0.1611272 0.1702849
>
> Which I saved (just to be save).
>
> When exporting to a pdf, I get the following matrix in the pdf:
>
> [,1] [,2] [,3] [,4]
> [1,] 0.5626863 0.8397120 0.9886886 0.2233873
> [2,] 0.8697064 0.1101432 0.1372992 0.4114674
> [3,] 0.3548678 0.5658843 0.1608864 0.5809167
>
> And it is different after each export. So it seems that the code block
> *is* actually evaluated, despite of the cached info.
>
> Rainer
>
>
>>
>> Best -- Eric
>>
>> <Ken.Williams@thomsonreuters.com> writes:
>>
>>> Hi,
>>>
>>> I'm having some trouble getting ":cache yes" to behave the way I think
>>> it's supposed to. As a test, I have a simple example containing just a
>>> title and one source block:
>>>
>>> #+source: testcache
>>> #+begin_src R :cache yes :exports both :results output
>>> dat <- matrix(runif(12), 3, 4)
>>> print(dat)
>>> #+end_src
>>>
>>>
>>> If I export this document to HTML (C-c C-e b), Emacs asks me "Evaluate
>>> this R code block (testcache) on your system?" If I say 'y' it
>>> re-evaluates, if I say 'n' it doesn't, so it doesn't seem like there's any
>>> role that caching gets to play here.
>>>
>>> In addition, when I export the document as above, the results are not
>>> saved in the original org-mode buffer, so whatever "#+results" block is
>>> there (or not there) from doing C-c C-c is neither used nor overwritten -
>>> and therefore the exported document contains different results than the
>>> source document.
>>>
>>> The behavior I expected (please let me know if my expectation is
>>> incorrect) was for the result of the computation to be cached in the Emacs
>>> buffer when I do the first export, and for that saved result to be
>>> included in the exported content for subsequent exports, until either the
>>> code/inputs change or I delete the results block.
>>>
>>> My configuration is:
>>>
>>> Emacs : GNU Emacs 23.2.50.1 (i386-apple-darwin9.8.0, NS
>>> apple-appkit-949.54)
>>> of 2010-08-18 on braeburn.aquamacs.org - Aquamacs Distribution 2.1
>>> Package: Org-mode version 7.5
>>>
>>> Thanks!
>>>
>>>
>>> --
>>> Ken Williams
>>> Senior Research Scientist
>>> Thomson Reuters
>>> http://labs.thomsonreuters.com
>>
>>
next prev parent reply other threads:[~2011-03-23 17:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-22 15:29 [babel] Trouble with :cache yes Ken.Williams
2011-03-23 2:50 ` Eric Schulte
2011-03-23 6:46 ` Rainer M Krug
2011-03-23 16:00 ` Ken.Williams
2011-03-23 17:46 ` Eric Schulte
2011-03-23 17:28 ` Eric Schulte [this message]
2011-03-23 17:54 ` Ken.Williams
2011-03-23 18:03 ` Eric Schulte
2011-03-23 18:05 ` Ken.Williams
2011-03-23 18:16 ` Eric Schulte
2011-03-23 21:55 ` Ken.Williams
2011-03-23 22:00 ` Erik Iverson
2011-03-23 22:12 ` Ken.Williams
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=87oc51enq1.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=Ken.Williams@thomsonreuters.com \
--cc=emacs-orgmode@gnu.org \
--cc=r.m.krug@gmail.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).