Re: [O] Selectively export RESULTS
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Not sure to understand why you would prefer to have something that you just wrote not taken into account, unlike one would expect? Because I might not have finished editing that part and just moving the cursor away from that line doesn't mean it should be acted upon. I dislike any software that makes guesses as to when I might have finished something or worse, tries to act upon my change _while I change it_ (that's especially bad if the things it does take a long time or produce errors that I have to deal with). Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Selectively export RESULTS
Hi Achim, Achim Gratz wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Not sure to understand why you would prefer to have something that you just wrote not taken into account, unlike one would expect? Because I might not have finished editing that part and just moving the cursor away from that line doesn't mean it should be acted upon. I dislike any software that makes guesses as to when I might have finished something or worse, tries to act upon my change _while I change it_ (that's especially bad if the things it does take a long time or produce errors that I have to deal with). I certainly never said that the automagic C-c C-c should be done after each key press or some such. That certainly would be a killer feature, in its real acception: performance would be unbearable. In my mind, automatically (re-)parsing the meta options should be each time the user presses `C-c C-v C-e' (eval code blocks); that is, when the user expects his options to be taken into account. I guess this makes much sense, but... Best regards, Seb -- Sebastien Vauban
Re: [O] Selectively export RESULTS
Hi Eric, Eric Schulte wrote: especially once I realized that the Property has to be set when the buffer is loaded. You can also press C-c C-c on the #+Property line to apply it's effects. Everybody seems to get bitten by this at least once. Would there be a possibility to avoid this extra step for the user, and have such parameters automagically taken into account, without user involvement? Best regards, Seb -- Sebastien Vauban
Re: [O] Selectively export RESULTS
Sebastien Vauban writes: You can also press C-c C-c on the #+Property line to apply it's effects. Everybody seems to get bitten by this at least once. Would there be a possibility to avoid this extra step for the user, and have such parameters automagically taken into account, without user involvement? I really wouldn't want that, but maybe PROPERTY lines that are out of sync with the effective properties could be highlighted? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Selectively export RESULTS
Hi Achim, Achim Gratz wrote: Sebastien Vauban writes: You can also press C-c C-c on the #+Property line to apply it's effects. Everybody seems to get bitten by this at least once. Would there be a possibility to avoid this extra step for the user, and have such parameters automagically taken into account, without user involvement? I really wouldn't want that, but maybe PROPERTY lines that are out of sync with the effective properties could be highlighted? Not sure to understand why you would prefer to have something that you just wrote not taken into account, unlike one would expect? Anyway, be it set or just shown, that means that a check would have to be done at each babel evaluation of the buffer. Best regards, Seb -- Sebastien Vauban
Re: [O] Selectively export RESULTS
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. 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. For this reason, I'd prefer to be able to decide whether to re-run on a file- wide basis. Many thanks to all of you who have created such an amazing system. M
Re: [O] Selectively export RESULTS
Matthew Landis lan...@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/
Re: [O] Selectively export RESULTS
Matthew Landis lan...@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. 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. For this reason, I'd prefer to be able to decide whether to re-run on a file- wide basis. Many thanks to all of you who have created such an amazing system. M Matthew, I think that you're wrongly expecting babel's cache header argument to behave like the argument of the same name in Sweave code chunks. Babel will cache, in your case, the value of your code block evaluation and there is none in your first code block, therefore nothing gets cached by babel, try that instead: #+name: my-random-vector #+begin_src R :session :cache yes rnorm(100) #+end_src #+headers: :var x=my-random-vector #+headers: :results graphics :exports results :file hist.png #+begin_src R :session :cache yes hist(x) #+end_src Does it work better? In that case you don't even need a session. Christophe -- Président, Nicolas Sarkozy représente une sorte de triomphe bouffon de l'égalitarisme français ; pour la première fois de notre histoire, nous avons un chef de l'État qui se comporte comme s'il ne valait pas mieux que les citoyens. C'est en réalité toujours le cas, mais cette vérité doit être cachée pour que les institutions et le système social tournent de façon, si ce n'est harmonieuse, du moins raisonnable. E. Todd, Après la démocratie. -- Christophe Pouzat MAP5 - Mathématiques Appliquées à Paris 5 CNRS UMR 8145 45, rue des Saints-Pères 75006 PARIS France tel: +33142863828 mobile: +33662941034 web: http://www.biomedicale.univ-paris5.fr/physcerv/C_Pouzat.html
Re: [O] Selectively export RESULTS
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
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]]
-
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.
Re: [O] Selectively export RESULTS
On 3/2/2012 12:59 PM, Christophe Pouzat wrote: Matthew, I think that you're wrongly expecting babel's cache header argument to behave like the argument of the same name in Sweave code chunks. Babel will cache, in your case, the value of your code block evaluation and there is none in your first code block, therefore nothing gets cached by babel, try that instead: #+name: my-random-vector #+begin_src R :session :cache yes rnorm(100) #+end_src #+headers: :var x=my-random-vector #+headers: :results graphics :exports results :file hist.png #+begin_src R :session :cache yes hist(x) #+end_src Does it work better? In that case you don't even need a session. Christophe Christophe - thanks for the suggestion. I haven't messed around much with variables passed between code blocks. When I try this, R tells me that 'x' must be numeric. When I query x in the R buffer, x is a data.frame. So the second code block reads x in as a data.frame instead of a numeric vector. For most purposes this would be OK (since a data.frame is the most usual outcome), but I'm reluctant to use this approach -- I'd like all of the variable passing to be in the R session. Intuitively this seems simpler, less error prone, and more conducive to tangling later. (Of course, I could be totally wrong - since I haven't really tried that approach). M -- ~~ Matthew Landis, Ph.D. Research Scientist ISciences, LLC 61 Main St. Suite 200 Burlington VT 05401 802.864.2999 www.isciences.com ~~
Re: [O] Selectively export RESULTS
Matthew Landis lan...@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/
Re: [O] Selectively export RESULTS
Eric Schulte eric.schu...@gmx.com writes: Matthew Landis lan...@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? [rest deleted] Eric, your response is threaded as a reply to Matthew, but here you have replied to my comment about buffer wide PROPERTY setting of :cache. Here is an example of the difficulty I face: , | #+property: :cache yes | | | #+name: Ablock | #+begin_src emacs-lisp :results value :exports both | (current-time-string) | #+end_src | | #+results[2ca40f0dc0f23e5743133e229d9e8f31b31830c5]: Ablock | : Wed Feb 29 11:57:19 2012 | | | * headline 1 | :PROPERTIES: | :cache: no | :END: | | #+CALL: Ablock() :exports results | ` When I place point under the headline and issue C-c @ C-c C-e a I get , | headline 1 | == | | Author: | Date: 2012-03-02 11:28:54 PST | | | | | Fri Mar 2 11:28:52 2012 | ` showing that Ablock() actually was executed. If the :cache setting under 'headline 1' is omitted then no update of the time string is performed. I understand that this behavior might be considered a *feature*, not a *bug*. Either way, having an easy way to copy results into other parts of a document would help me out. Best, Chuck -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] Selectively export RESULTS
On 3/2/2012 2:33 PM, Eric Schulte wrote: The above line should be #+PROPERTY: singular. That explains why file-wide settings aren't working for you. THANK YOU. That makes it work, especially once I realized that the Property has to be set when the buffer is loaded. Now I have #+PROPERTY: eval no-export 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, This is exactly what I did, and it does exactly what I want. org-babel totally rocks. -- ~~ Matthew Landis, Ph.D. Research Scientist ISciences, LLC 61 Main St. Suite 200 Burlington VT 05401 802.864.2999 www.isciences.com ~~
Re: [O] Selectively export RESULTS
Matthew Landis lan...@isciences.com writes: On 3/2/2012 2:33 PM, Eric Schulte wrote: The above line should be #+PROPERTY: singular. That explains why file-wide settings aren't working for you. THANK YOU. That makes it work, Good to hear. especially once I realized that the Property has to be set when the buffer is loaded. You can also press C-c C-c on the #+Property line to apply it's effects. Now I have #+PROPERTY: eval no-export 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, This is exactly what I did, and it does exactly what I want. org-babel totally rocks. Great, happy this was resolved successfully. -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Selectively export RESULTS
cbe...@tajo.ucsd.edu writes: inline correction below. Eric Schulte eric.schu...@gmx.com writes: Matthew Landis lan...@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? [rest deleted] Eric, your response is threaded as a reply to Matthew, but here you have replied to my comment about buffer wide PROPERTY setting of :cache. Here is an example of the difficulty I face: , | #+property: :cache yes | Of course that should have been #+property: cache yes but the result below is the same. Chuck | | #+name: Ablock | #+begin_src emacs-lisp :results value :exports both | (current-time-string) | #+end_src | | #+results[2ca40f0dc0f23e5743133e229d9e8f31b31830c5]: Ablock | : Wed Feb 29 11:57:19 2012 | | | * headline 1 | :PROPERTIES: | :cache: no | :END: | | #+CALL: Ablock() :exports results | ` When I place point under the headline and issue C-c @ C-c C-e a I get , | headline 1 | == | | Author: | Date: 2012-03-02 11:28:54 PST | | | | | Fri Mar 2 11:28:52 2012 | ` showing that Ablock() actually was executed. If the :cache setting under 'headline 1' is omitted then no update of the time string is performed. I understand that this behavior might be considered a *feature*, not a *bug*. Either way, having an easy way to copy results into other parts of a document would help me out. Best, Chuck -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] Selectively export RESULTS
Eric, your response is threaded as a reply to Matthew, but here you have replied to my comment about buffer wide PROPERTY setting of :cache. Here is an example of the difficulty I face: , | #+property: :cache yes | | | #+name: Ablock | #+begin_src emacs-lisp :results value :exports both | (current-time-string) | #+end_src | | #+results[2ca40f0dc0f23e5743133e229d9e8f31b31830c5]: Ablock | : Wed Feb 29 11:57:19 2012 | | | * headline 1 | :PROPERTIES: | :cache: no | :END: | | #+CALL: Ablock() :exports results | ` When I place point under the headline and issue C-c @ C-c C-e a I get , | headline 1 | == | | Author: | Date: 2012-03-02 11:28:54 PST | | | | | Fri Mar 2 11:28:52 2012 | ` showing that Ablock() actually was executed. If the :cache setting under 'headline 1' is omitted then no update of the time string is performed. I understand that this behavior might be considered a *feature*, not a *bug*. Either way, having an easy way to copy results into other parts of a document would help me out. Hi Chuck, You have a simple syntax error at the top of the file. Replace | #+property: :cache yes with | #+property: cache yes ^ (delete a colon | right there) and you will get the behavior you are seeking. Best, Best, Chuck -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Selectively export RESULTS
cbe...@tajo.ucsd.edu wrote: cbe...@tajo.ucsd.edu writes: inline correction below. Eric Schulte eric.schu...@gmx.com writes: Matthew Landis lan...@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? [rest deleted] Eric, your response is threaded as a reply to Matthew, but here you have replied to my comment about buffer wide PROPERTY setting of :cache. Here is an example of the difficulty I face: , | #+property: :cache yes | Of course that should have been #+property: cache yes but the result below is the same. Did you C-c C-c on the #+property: line after changing it? I think it works as expected. Nick Chuck | | #+name: Ablock | #+begin_src emacs-lisp :results value :exports both | (current-time-string) | #+end_src | | #+results[2ca40f0dc0f23e5743133e229d9e8f31b31830c5]: Ablock | : Wed Feb 29 11:57:19 2012 | | | * headline 1 | :PROPERTIES: | :cache: no | :END: | | #+CALL: Ablock() :exports results | ` When I place point under the headline and issue C-c @ C-c C-e a I get , | headline 1 | == | | Author: | Date: 2012-03-02 11:28:54 PST | | | | | Fri Mar 2 11:28:52 2012 | ` showing that Ablock() actually was executed. If the :cache setting under 'headline 1' is omitted then no update of the time string is performed. I understand that this behavior might be considered a *feature*, not a *bug*. Either way, having an easy way to copy results into other parts of a document would help me out. Best, Chuck -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd eduUC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] Selectively export RESULTS
Nick Dokos nicholas.do...@hp.com writes: cbe...@tajo.ucsd.edu wrote: cbe...@tajo.ucsd.edu writes: inline correction below. Eric Schulte eric.schu...@gmx.com writes: Matthew Landis lan...@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? [rest deleted] Eric, your response is threaded as a reply to Matthew, but here you have replied to my comment about buffer wide PROPERTY setting of :cache. Here is an example of the difficulty I face: , | #+property: :cache yes | Of course that should have been #+property: cache yes but the result below is the same. Did you C-c C-c on the #+property: line after changing it? I think it works as expected. You are right. It reports the cache'd value of the date. I've been bitten by the 'no C-c C-c' after changing a #+property line so many times, you would think I'd learn. :-( Thanks. Chuck Nick Chuck | | #+name: Ablock | #+begin_src emacs-lisp :results value :exports both | (current-time-string) | #+end_src | | #+results[2ca40f0dc0f23e5743133e229d9e8f31b31830c5]: Ablock | : Wed Feb 29 11:57:19 2012 | | | * headline 1 | :PROPERTIES: | :cache: no | :END: | | #+CALL: Ablock() :exports results | ` When I place point under the headline and issue C-c @ C-c C-e a I get , | headline 1 | == | | Author: | Date: 2012-03-02 11:28:54 PST | | | | | Fri Mar 2 11:28:52 2012 | ` showing that Ablock() actually was executed. If the :cache setting under 'headline 1' is omitted then no update of the time string is performed. I understand that this behavior might be considered a *feature*, not a *bug*. Either way, having an easy way to copy results into other parts of a document would help me out. Best, Chuck -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901 -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] Selectively export RESULTS
cbe...@tajo.ucsd.edu wrote: I've been bitten by the 'no C-c C-c' after changing a #+property line so many times, you would think I'd learn. :-( Yup - I don't know why, but for some reason I can see it more easily when others do it than when I do it: I sometimes spend *minutes* bewildered (*how can that be?!?!*). At some point, I get into Terminator mode, go down the list for the appropriate response, remember the C-c C-c problem, whack my head on my desk a few times, and go on. But when next time comes, it's as if it never happened before (well, perhaps things are improving: I generally go into Terminator mode much more quickly nowadays - a couple of times in the more distant past, I gave up in disgust, went to bed and didn't think of C-c C-c until the next day.) It would be so nice if org did the org-mode-restart bit automatically after a change to a #+KEYWORD line: in some cases (e.g. TBLFM lines) you have direct feedback so it doesn't matter too much, but in other cases, that feedback is just nowhere to be found. I don't know how difficult it would be to implement such a facility[fn:1], but maybe it can be added to the GSoC list if somebody has a bright idea on how to do it. Nick Footnotes: [fn:1] ... without making it too expensive to run: I wonder how expensive it would be running org-mode-restart from an idle timer - probably prohibitive if the file is large enough. And I can imagine situations where that would be even *more* confusing: changing behavior apparently without any other change - can you say magic?
Re: [O] Selectively export RESULTS
t...@tsdye.com (Thomas S. Dye) writes: cbe...@tajo.ucsd.edu writes: I sometimes create large documents with many dozens of src blocks and associated #+RESULTS. I'd like to be able to grab some of these results blocks and export them into a document. Since revisions of the src blocks can change the results, I do not want to just and to copy and paste the results in case I need to revise the sub-document(s). And with long running blocks, I do not want to use a noweb strategy to rerun the code in the src blocks. As an example, I might have this in a file with many other headlines and src blocks: , | * Selectively Export Some Results | :PROPERTIES: | :EXPORT_FILE_NAME: Selected_Results.pdf | :EXPORT_TITLE: Selected Results | :END: | | Here are the results from block named Ablock: | | #+CALL: show-results(Ablock) | | and here they are for a block named Bblock: | | #+CALL: show-results(Bblock) ` and if I put point on the headline and type C-c @ C-c C-e d, I'd like to have a document that includes the two results blocks in it after each CALL line. It looks like many of the pieces I need are available, but I don't see how to stitch them together to create the show-results() function. TIA, Chuck Hi Chuck, Thanks for the reply. Does this do what you want? No. When I put point under the headline and type C-c @ C-c C-e d, it prompts me to evaluate each of the blocks, and when I answer 'no' to each, it produces a document that omits the previously computed results. What I want is to grab *existing* results blocks and use them. And if at a later date some of those results blocks have changed, when I again put point under the headline and type C-c @ C-c C-e d, I'd like the newer blocks to be updated. The computations in some blocks run for many minutes, so it is impractical to recompute them every time I want to tweak the format of a document that depends on them. Chuck * Selectively Export Some Results :PROPERTIES: :EXPORT_FILE_NAME: Selected_Results.pdf :EXPORT_TITLE: Selected Results :END: Here are the results from block named Ablock: #+CALL: Ablock() :exports results and here they are for a block named Bblock: #+CALL: Bblock() :exports results All the best, Tom -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] Selectively export RESULTS
Does this do what you want? No. When I put point under the headline and type C-c @ C-c C-e d, it prompts me to evaluate each of the blocks, and when I answer 'no' to each, it produces a document that omits the previously computed results. What I want is to grab *existing* results blocks and use them. And if at a later date some of those results blocks have changed, when I again put point under the headline and type C-c @ C-c C-e d, I'd like the newer blocks to be updated. The computations in some blocks run for many minutes, so it is impractical to recompute them every time I want to tweak the format of a document that depends on them. Hi Chuck, Have you looked at the :cache header argument [1], from my understanding of your use case it should be exactly what you are after. Best, Footnotes: [1] http://orgmode.org/manual/cache.html -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Selectively export RESULTS
Eric Schulte eric.schu...@gmx.com writes: Does this do what you want? No. When I put point under the headline and type C-c @ C-c C-e d, it prompts me to evaluate each of the blocks, and when I answer 'no' to each, it produces a document that omits the previously computed results. What I want is to grab *existing* results blocks and use them. And if at a later date some of those results blocks have changed, when I again put point under the headline and type C-c @ C-c C-e d, I'd like the newer blocks to be updated. The computations in some blocks run for many minutes, so it is impractical to recompute them every time I want to tweak the format of a document that depends on them. Hi Chuck, Thanks for your reply. 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. With org-confirm-babel-evaluate set to t, it prompts for confirmation of each and every block/call it encounters, which is a bit tiresome. I can set this to nil, but the potential for causing mischief by unintenionally evaluating blocks whose results were OK and needed for a quick report worries me. Its pretty clear that the machinery needed to capture results is all there. If I can find time, I'll trace thru what is going on when cache yes is set and see if I can do so more directly. Chuck Best, Footnotes: [1] http://orgmode.org/manual/cache.html -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] Selectively export RESULTS
cbe...@tajo.ucsd.edu writes: I sometimes create large documents with many dozens of src blocks and associated #+RESULTS. I'd like to be able to grab some of these results blocks and export them into a document. Since revisions of the src blocks can change the results, I do not want to just and to copy and paste the results in case I need to revise the sub-document(s). And with long running blocks, I do not want to use a noweb strategy to rerun the code in the src blocks. As an example, I might have this in a file with many other headlines and src blocks: , | * Selectively Export Some Results | :PROPERTIES: | :EXPORT_FILE_NAME: Selected_Results.pdf | :EXPORT_TITLE: Selected Results | :END: | | Here are the results from block named Ablock: | | #+CALL: show-results(Ablock) | | and here they are for a block named Bblock: | | #+CALL: show-results(Bblock) ` and if I put point on the headline and type C-c @ C-c C-e d, I'd like to have a document that includes the two results blocks in it after each CALL line. It looks like many of the pieces I need are available, but I don't see how to stitch them together to create the show-results() function. TIA, Chuck Hi Chuck, Does this do what you want? * Selectively Export Some Results :PROPERTIES: :EXPORT_FILE_NAME: Selected_Results.pdf :EXPORT_TITLE: Selected Results :END: Here are the results from block named Ablock: #+CALL: Ablock() :exports results and here they are for a block named Bblock: #+CALL: Bblock() :exports results All the best, Tom -- Thomas S. Dye http://www.tsdye.com
