emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [babel] Trouble with :cache yes


From: Eric Schulte
Subject: Re: [O] [babel] Trouble with :cache yes
Date: Wed, 23 Mar 2011 11:28:05 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Rainer M Krug <address@hidden> writes:

> On Wed, Mar 23, 2011 at 3:50 AM, Eric Schulte <address@hidden> 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
>>
>> <address@hidden> 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
>>
>>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]