Re: [O] Selectively export RESULTS

2012-03-04 Thread Achim Gratz
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

2012-03-04 Thread Sebastien Vauban
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

2012-03-03 Thread Sebastien Vauban
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

2012-03-03 Thread Achim Gratz
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

2012-03-03 Thread Sebastien Vauban
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

2012-03-02 Thread Matthew Landis
 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

2012-03-02 Thread Eric Schulte
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

2012-03-02 Thread Christophe Pouzat
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

2012-03-02 Thread Matthew Landis
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

2012-03-02 Thread Matthew Landis



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

2012-03-02 Thread Eric Schulte
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

2012-03-02 Thread cberry
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

2012-03-02 Thread Matthew Landis



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

2012-03-02 Thread Eric Schulte
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

2012-03-02 Thread cberry
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

2012-03-02 Thread Eric Schulte

 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

2012-03-02 Thread Nick Dokos
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

2012-03-02 Thread cberry
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

2012-03-02 Thread Nick Dokos
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

2012-02-29 Thread cberry
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

2012-02-29 Thread Eric Schulte
 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

2012-02-29 Thread cberry
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




[O] Selectively export RESULTS

2012-02-28 Thread cberry

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

-- 
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

2012-02-28 Thread Thomas S. Dye
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