Selectively export RESULTS

Selectively export RESULTS

[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. Berry                            Dept of Family/Preventive Medicine
cberry at ucsd edu			    UC San Diego
http://famprevmed.ucsd.edu/faculty/cberry/  La Jolla, San Diego 92093-0901

Re: Selectively export RESULTS

[Thomas S. Dye]

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

Re: Selectively export RESULTS

[cberry]

tsd@tsdye.com (Thomas S. Dye) writes:

> cberry@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. Berry                            Dept of Family/Preventive Medicine
cberry at ucsd edu			    UC San Diego
http://famprevmed.ucsd.edu/faculty/cberry/  La Jolla, San Diego 92093-0901

Re: Selectively export RESULTS

[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: Selectively export RESULTS

[cberry]

Eric Schulte <eric.schulte@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. Berry                            Dept of Family/Preventive Medicine
cberry at ucsd edu			    UC San Diego
http://famprevmed.ucsd.edu/faculty/cberry/  La Jolla, San Diego 92093-0901

Re: Selectively export RESULTS

[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: Selectively export RESULTS

[Eric Schulte]

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/

Re: Selectively export RESULTS

[Christophe Pouzat]

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. 
>> 
>
> 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: Selectively export RESULTS

[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: Selectively export RESULTS

[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: Selectively export RESULTS

[Eric Schulte]

Matthew Landis <landis@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: Selectively export RESULTS

[cberry]

Eric Schulte <eric.schulte@gmx.com> writes:

> 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?
>
[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. Berry                            Dept of Family/Preventive Medicine
cberry at ucsd edu			    UC San Diego
http://famprevmed.ucsd.edu/faculty/cberry/  La Jolla, San Diego 92093-0901

Re: Selectively export RESULTS

[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: Selectively export RESULTS

[Eric Schulte]

Matthew Landis <landis@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: Selectively export RESULTS

[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: Selectively export RESULTS

[cberry]

cberry@tajo.ucsd.edu writes:

inline correction below.

> Eric Schulte <eric.schulte@gmx.com> writes:
>
>> 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?
>>
> [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. Berry                            Dept of Family/Preventive Medicine
cberry at ucsd edu			    UC San Diego
http://famprevmed.ucsd.edu/faculty/cberry/  La Jolla, San Diego 92093-0901

Re: Selectively export RESULTS

[Nick Dokos]

cberry@tajo.ucsd.edu wrote:

> cberry@tajo.ucsd.edu writes:
> 
> inline correction below.
> 
> > Eric Schulte <eric.schulte@gmx.com> writes:
> >
> >> 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?
> >>
> > [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. Berry                            Dept of Family/Preventive Medicine
> cberry at ucsd edu			    UC San Diego
> http://famprevmed.ucsd.edu/faculty/cberry/  La Jolla, San Diego 92093-0901
> 
> 

Re: Selectively export RESULTS

[cberry]

Nick Dokos <nicholas.dokos@hp.com> writes:

> cberry@tajo.ucsd.edu wrote:
>
>> cberry@tajo.ucsd.edu writes:
>> 
>> inline correction below.
>> 
>> > Eric Schulte <eric.schulte@gmx.com> writes:
>> >
>> >> 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?
>> >>
>> > [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. Berry                            Dept 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. Berry                            Dept of Family/Preventive Medicine
cberry at ucsd edu			    UC San Diego
http://famprevmed.ucsd.edu/faculty/cberry/  La Jolla, San Diego 92093-0901

Re: Selectively export RESULTS

[Nick Dokos]

cberry@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: Selectively export RESULTS

[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: Selectively export RESULTS

[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: Selectively export RESULTS

[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: Selectively export RESULTS

[Achim Gratz]

"Sebastien Vauban"
<wxhgmqzgwmuf@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: Selectively export RESULTS

[Sebastien Vauban]

Hi Achim,

Achim Gratz wrote:
> "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> 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