emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

* Problem with Babel and sessions
@ 2010-09-09 15:09 Christopher Witte
  2010-09-10 18:06 ` Proposed New Syntax For Calling Code Blocks was: " Eric Schulte
  0 siblings, 1 reply; 7+ messages in thread
From: Christopher Witte @ 2010-09-09 15:09 UTC (permalink / raw)
  To: Org Mode


[-- Attachment #1.1: Type: text/plain, Size: 1828 bytes --]

I'm having a bit of trouble with org bable and R. When I try to execute the
code below (C-c C-c on the call line), as you can see, I get the results
:nil

---------------------------------------
#+tblname: tableTestBabel
|   0 | 4.40 |
|  30 | 4.54 |
|  60 | 7.09 |
|  90 | 9.40 |
| 120 | 9.22 |
| 150 | 6.65 |
| 180 | 4.22 |

#+srcname: chartPolAngle(pol)
#+begin_src R
  angle <- pol[,1]
  energy <- pol[,2]
  plot(angle,energy)
  energy.model <-  nls (energy ~ a1 + a2 * (sin(pi / a3 *(angle-a4)))^2,
start=list(a1=3.0, a2=7.0, a3=180, a4=0.0))
  lines(spline(angle, fitted.values(energy.model)), lwd=2)
  summary(energy.model)
#+end_src

#+call: chartPolAngle(pol=tableTestBabel) :session testBabel:file
testBabel.pdf

#+results: chartPolAngle(pol=tableTestBabel)
: nil
------------------------------------

but If I move the header arguments to the source block, as in the code
below, everything works fine. I also get asked "ESS [S(R): R] starting data
directory? ~/doc/org/" which I don't get with the code above.

---------------------------------------
#+tblname: tableTestBabel
|   0 | 4.40 |
|  30 | 4.54 |
|  60 | 7.09 |
|  90 | 9.40 |
| 120 | 9.22 |
| 150 | 6.65 |
| 180 | 4.22 |

#+call: chartPolAngle(pol=tableTestBabel)

#+results: chartPolAngle(pol=tableTestBabel)
: testBabel.pdf


#+srcname: chartPolAngle(pol)
#+begin_src R :session testBabel :file testBabel.pdf
  angle <- pol[,1]
  energy <- pol[,2]
  plot(angle,energy)
  energy.model <-  nls (energy ~ a1 + a2 * (sin(pi / a3 *(angle-a4)))^2,
start=list(a1=3.0, a2=7.0, a3=180, a4=0.0))
  lines(spline(angle, fitted.values(energy.model)), lwd=2)
  summary(energy.model)
#+end_src
---------------------------------------

Org doesn't appear to respect the head arguments on the call. I pulled from
git a couple days ago. Any ideas why?

Cheers
Chris Witte

[-- Attachment #1.2: Type: text/html, Size: 2079 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 7+ messages in thread

• * Proposed New Syntax For Calling Code Blocks was: Problem with Babel and sessions
    2010-09-09 15:09 Problem with Babel and sessions Christopher Witte
  @ 2010-09-10 18:06 ` Eric Schulte
    2010-09-10 19:58   ` Proposed New Syntax For Calling Code Blocks was Jambunathan K
                       ` (2 more replies)
    0 siblings, 3 replies; 7+ messages in thread
  From: Eric Schulte @ 2010-09-10 18:06 UTC (permalink / raw)
    To: Christopher Witte; +Cc: Org Mode
  
  Hi Christopher,
  
  Thanks for the well documented example.
  
  The header arguments on the call line, are actually being used by the
  call line itself, not by the R block which is called.  To unpack that,
  on evaluation the call line expands to a trivial emacs-lisp code block
  which is equivalent to
  
  #+begin_src emacs-lisp :var results=chartPolAngle(pol=tableTestBabel) :session testBabel:file
    results
  #+end_src
  
  So the :session header argument is used by the emacs-lisp code block in
  the call line, and never propagates to the R code block which is
  evaluated.  Notice that header arguments like :results silent, will have
  the expected results.
  
  So for now you will have to place the header argument on the actual R
  code block.
  
  That said, I think that we should provide a mechanism for passing header
  arguments through to called code blocks making the original
  functionality you described possible.  I'm not sure how best to do that,
  but currently I think we should expand the syntax used to call code
  blocks to be more similar to inline code blocks, s.t. header arguments
  can be placed inside of an optional square bracket section between the
  name of the code block and the arguments.  Using this new proposed
  syntax your example below would be written as
  
  #+call: chartPolAngle[:session testBabel :file testBabel.pdf](pol=tableTestBabel)
  
  I'd be interested to hear what the community thinks of this new syntax.
  
  As an unrelated note, we also need to think of a natural way to allow
  the header argument portion of a code block to span multiple lines.
  
  Best -- Eric
  
  Christopher Witte <chris@witte.net.au> writes:
  
  > I'm having a bit of trouble with org bable and R. When I try to execute the
  > code below (C-c C-c on the call line), as you can see, I get the results
  > :nil
  >
  > ---------------------------------------
  > #+tblname: tableTestBabel
  > |   0 | 4.40 |
  > |  30 | 4.54 |
  > |  60 | 7.09 |
  > |  90 | 9.40 |
  > | 120 | 9.22 |
  > | 150 | 6.65 |
  > | 180 | 4.22 |
  >
  > #+srcname: chartPolAngle(pol)
  > #+begin_src R
  >   angle <- pol[,1]
  >   energy <- pol[,2]
  >   plot(angle,energy)
  >   energy.model <-  nls (energy ~ a1 + a2 * (sin(pi / a3 *(angle-a4)))^2,
  > start=list(a1=3.0, a2=7.0, a3=180, a4=0.0))
  >   lines(spline(angle, fitted.values(energy.model)), lwd=2)
  >   summary(energy.model)
  > #+end_src
  >
  > #+call: chartPolAngle(pol=tableTestBabel) :session testBabel :file testBabel.pdf
  >
  > #+results: chartPolAngle(pol=tableTestBabel)
  > : nil
  > ------------------------------------
  >
  > but If I move the header arguments to the source block, as in the code
  > below, everything works fine. I also get asked "ESS [S(R): R] starting data
  > directory? ~/doc/org/" which I don't get with the code above.
  >
  > ---------------------------------------
  > #+tblname: tableTestBabel
  > |   0 | 4.40 |
  > |  30 | 4.54 |
  > |  60 | 7.09 |
  > |  90 | 9.40 |
  > | 120 | 9.22 |
  > | 150 | 6.65 |
  > | 180 | 4.22 |
  >
  > #+call: chartPolAngle(pol=tableTestBabel)
  >
  > #+results: chartPolAngle(pol=tableTestBabel)
  > : testBabel.pdf
  >
  >
  > #+srcname: chartPolAngle(pol)
  > #+begin_src R :session testBabel :file testBabel.pdf
  >   angle <- pol[,1]
  >   energy <- pol[,2]
  >   plot(angle,energy)
  >   energy.model <-  nls (energy ~ a1 + a2 * (sin(pi / a3 *(angle-a4)))^2,
  > start=list(a1=3.0, a2=7.0, a3=180, a4=0.0))
  >   lines(spline(angle, fitted.values(energy.model)), lwd=2)
  >   summary(energy.model)
  > #+end_src
  > ---------------------------------------
  >
  > Org doesn't appear to respect the head arguments on the call. I pulled from
  > git a couple days ago. Any ideas why?
  >
  > Cheers
  > Chris Witte
  > _______________________________________________
  > Emacs-orgmode mailing list
  > Please use `Reply All' to send replies to the list.
  > Emacs-orgmode@gnu.org
  > http://lists.gnu.org/mailman/listinfo/emacs-orgmode
  
  ^ permalink raw reply	[flat|nested] 7+ messages in thread

• • * Re: Proposed New Syntax For Calling Code Blocks was
      2010-09-10 18:06 ` Proposed New Syntax For Calling Code Blocks was: " Eric Schulte
    @ 2010-09-10 19:58   ` Jambunathan K
      2010-09-10 21:12     ` Jambunathan K
      2010-09-13 12:05   ` Proposed New Syntax For Calling Code Blocks was: Problem with Babel and sessions Christopher Witte
      2010-09-14 19:03   ` Sébastien Vauban
      2 siblings, 1 reply; 7+ messages in thread
    From: Jambunathan K @ 2010-09-10 19:58 UTC (permalink / raw)
      To: Eric Schulte; +Cc: Org Mode
    
    
    Eric
    
    In line with my earlier posts, I would like to think of Babel codeblocks
    filters that take as a textual content and produce another textual
    content. Think of babel codeblocks as indeed custom exporters.
    
    Power of Babel is the flexibility that the user gets in associating
    different code blocks with the same content and have different
    representations produced for the same.
    
    Let's revisit the original example. Let me walk through the whole
    sequence ...
    
    # Input Textual Content
    
    # User need not say that the content is table. It is obvious. In other
    # words babel is dynamically typed and tables are one of the primitive
    # datatypes within Babel runtime environment. Name of the table is the
    # name of the headline.
    
    * tableTestBabel
      |   0 | 4.40 |
      |  30 | 4.54 |
      |  60 | 7.09 |
      |  90 | 9.40 |
      | 120 | 9.22 |
      | 150 | 6.65 |
      | 180 | 4.22 |
    
    
    # Output Textual Content 
    testBabel.pdf
    
    # Babel block named 'charPolAngle' is the custom exporter which would
    # act on the input text and produce an output text. 
    
    # Note that the signature of the chartPolAngle and the use of a reserved
    # babel keyword 'this' which stand for the input textual content.
    
    #+srcname: chartPolAngle()
    #+begin_src R
      angle <- this[,1]
      energy <- this[,2]
      plot(angle,energy)
      energy.model <-  nls (energy ~ a1 + a2 * (sin(pi / a3 *(angle-a4)))^2,
    start=list(a1=3.0, a2=7.0, a3=180, a4=0.0))
      lines(spline(angle, fitted.values(energy.model)), lwd=2)
      summary(energy.model)
    #+end_src
    
    
    # To make a call, the user executes the headline and passes it the
    # custom routine.
    
    # Transform text
    <<tableTestBabel (:fmt chartPolAngle)>>
      ^^^^^^^^^^^^^
    
    With this shift in call syntax one could do these with obvious
    interpretation.
    
    
    <<tabletestBabel>> # identity mapping 
    <<tabletestBabel (:fmt csv)>> # map to csv 
    <<tabletestBabel (:fmt latex)>> # map to latex
    
    
    To summarize Babel srcnames takes the following params as a must (they
    could be implicit)
    
    1. A 'this' parameterw which is input text content. An headline entry in
       the above example.
    
    A babel invocation line takes a ':fmt ' param. It could be one of the
    inbuilt exporters like text, org, latex, pdf etc or left unspecified if
    the babel srcblock always produces only one format.
    
    It would also be usefult to specify how the transformed text is handled
    by a babel srcblock. Let's denote this param as :results
    
    If :results is nil then the exporter creates a side-effect. i.e., it
    produces a pdf file. 
    
    If :results is inline then output text content is inserted inline i.e.,
    wherever the macro invocation occurs.
    
    If :results is a Org Headline then output text content is inserted in
    that headline.
    
    To summarize, Babel macros acts on text blocks and produces text
    blocks. 
    
    A babel macro with names outfmt is invoked as 
    <<org headline (:fmt outfmt :results X)>>
    
    or as 
    
    [[outfmt][input text content]]
    
    Let me know if you have questions.
    
    My lack of understanding of Babel's internals prevents me from being
    more specific or anticipate the issues involved. 
    
    Nevertheless a shift in perspective from
    
    babel-src(intxt)
    
    to 
    
    intxt(babel-src) is what is required.
    
    
    I invite you to go through my earlier mails[1]. Each one of them takes
    examples that have already surfaced in the mailing list and tries to
    reconcile what the user likes to accomplish with Babel macros with what
    the Org's existing world view is.
    
    Let me know whether or not I make sense.
    
    
    ps: I haven't really tried to address issues reported by the original
    poster. I need to have a buyin from you on what I am proposing before I
    am willing to put that effort.
    
    [1] http://article.gmane.org/gmane.emacs.orgmode/30040
    
    Jambunathan K.
    
    >
    > #+call: chartPolAngle[:session testBabel :file testBabel.pdf](pol=tableTestBabel)
    >
    
    > I'd be interested to hear what the community thinks of this new syntax.
    >
    > As an unrelated note, we also need to think of a natural way to allow
    > the header argument portion of a code block to span multiple lines.
    >
    > Best -- Eric
    >
    > Christopher Witte <chris@witte.net.au> writes:
    >
    >> I'm having a bit of trouble with org bable and R. When I try to execute the
    >> code below (C-c C-c on the call line), as you can see, I get the results
    >> :nil
    >>
    >> ---------------------------------------
    >> #+tblname: tableTestBabel
    >> |   0 | 4.40 |
    >> |  30 | 4.54 |
    >> |  60 | 7.09 |
    >> |  90 | 9.40 |
    >> | 120 | 9.22 |
    >> | 150 | 6.65 |
    >> | 180 | 4.22 |
    >>
    >> #+srcname: chartPolAngle(pol)
    >> #+begin_src R
    >>   angle <- pol[,1]
    >>   energy <- pol[,2]
    >>   plot(angle,energy)
    >>   energy.model <-  nls (energy ~ a1 + a2 * (sin(pi / a3 *(angle-a4)))^2,
    >> start=list(a1=3.0, a2=7.0, a3=180, a4=0.0))
    >>   lines(spline(angle, fitted.values(energy.model)), lwd=2)
    >>   summary(energy.model)
    >> #+end_src
    >>
    >> #+call: chartPolAngle(pol=tableTestBabel) :session testBabel :file testBabel.pdf
    >>
    >> #+results: chartPolAngle(pol=tableTestBabel)
    >> : nil
    >> ------------------------------------
    >>
    >> but If I move the header arguments to the source block, as in the code
    >> below, everything works fine. I also get asked "ESS [S(R): R] starting data
    >> directory? ~/doc/org/" which I don't get with the code above.
    >>
    >> ---------------------------------------
    >> #+tblname: tableTestBabel
    >> |   0 | 4.40 |
    >> |  30 | 4.54 |
    >> |  60 | 7.09 |
    >> |  90 | 9.40 |
    >> | 120 | 9.22 |
    >> | 150 | 6.65 |
    >> | 180 | 4.22 |
    >>
    >> #+call: chartPolAngle(pol=tableTestBabel)
    >>
    >> #+results: chartPolAngle(pol=tableTestBabel)
    >> : testBabel.pdf
    >>
    >>
    >> #+srcname: chartPolAngle(pol)
    >> #+begin_src R :session testBabel :file testBabel.pdf
    >>   angle <- pol[,1]
    >>   energy <- pol[,2]
    >>   plot(angle,energy)
    >>   energy.model <-  nls (energy ~ a1 + a2 * (sin(pi / a3 *(angle-a4)))^2,
    >> start=list(a1=3.0, a2=7.0, a3=180, a4=0.0))
    >>   lines(spline(angle, fitted.values(energy.model)), lwd=2)
    >>   summary(energy.model)
    >> #+end_src
    >> ---------------------------------------
    >>
    >> Org doesn't appear to respect the head arguments on the call. I pulled from
    >> git a couple days ago. Any ideas why?
    >>
    >> Cheers
    >> Chris Witte
    >> _______________________________________________
    >> Emacs-orgmode mailing list
    >> Please use `Reply All' to send replies to the list.
    >> Emacs-orgmode@gnu.org
    >> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
    >
    > _______________________________________________
    > Emacs-orgmode mailing list
    > Please use `Reply All' to send replies to the list.
    > Emacs-orgmode@gnu.org
    > http://lists.gnu.org/mailman/listinfo/emacs-orgmode
    
    ^ permalink raw reply	[flat|nested] 7+ messages in thread

  • • * Re: Proposed New Syntax For Calling Code Blocks was
        2010-09-10 19:58   ` Proposed New Syntax For Calling Code Blocks was Jambunathan K
      @ 2010-09-10 21:12     ` Jambunathan K
        0 siblings, 0 replies; 7+ messages in thread
      From: Jambunathan K @ 2010-09-10 21:12 UTC (permalink / raw)
        To: Eric Schulte; +Cc: Org Mode
      
      
      Eric 
      
      I have typed enough. You or the Mailing list wouldn't get any more
      unsolicited mails from me on this little idea of mine.
      
      Some concluding remarks.
      
      As I see it, the crux of my articles is in highlighting the unique and
      (much needed role) that Babel could play or plays within the org
      ecosystem.
      
      In my view (which could be incomplete, flawed or warped),
      
      1. Babel is predominantly a macro environment for 'mashing up of'
         textual content within an orgmode document. 
      
      2. The syntax/grammar of Babel macro calls should not deviate
         significantly from existing Orgmode syntax and more specifically it
         shouldn't invent new syntax (so that parsing becomes spaghettish).
      
      3. The noweb/literate programming face of Babel may not be of much
         interest to 'compositional' demands of Orgmode users and
         vice-versa. i.e, One predominantly writes articles or does literate
         programming. Not both simultaneously. Text mashups are interesting
         for set of first set of users and noweb expansion to the second set.
      
      Just sharing my thoughts ... More of what my mental model of Babel is
      ...
      
      Jambunathan K.
      
      ^ permalink raw reply	[flat|nested] 7+ messages in thread

  • * Re: Proposed New Syntax For Calling Code Blocks was: Problem with Babel and sessions
      2010-09-10 18:06 ` Proposed New Syntax For Calling Code Blocks was: " Eric Schulte
      2010-09-10 19:58   ` Proposed New Syntax For Calling Code Blocks was Jambunathan K
    @ 2010-09-13 12:05   ` Christopher Witte
      2010-09-18 12:24     ` Eric Schulte
      2010-09-14 19:03   ` Sébastien Vauban
      2 siblings, 1 reply; 7+ messages in thread
    From: Christopher Witte @ 2010-09-13 12:05 UTC (permalink / raw)
      To: Eric Schulte; +Cc: Org Mode
    
    
    [-- Attachment #1.1: Type: text/plain, Size: 4743 bytes --]
    
    Thanks for reply Eric.
    
    Thanks for the reply.  The reason why I wanted this was because I have
    multiple sets of data and I would like to be able to apply the same code
    block to the different sets of data and have the results in different pdfs.
    Is there anyway to do this with the current version of org?
    
    Cheers,
    Chris
    
    On 10 September 2010 20:06, Eric Schulte <schulte.eric@gmail.com> wrote:
    
    > Hi Christopher,
    >
    > Thanks for the well documented example.
    >
    > The header arguments on the call line, are actually being used by the
    > call line itself, not by the R block which is called.  To unpack that,
    > on evaluation the call line expands to a trivial emacs-lisp code block
    > which is equivalent to
    >
    > #+begin_src emacs-lisp :var results=chartPolAngle(pol=tableTestBabel)
    > :session testBabel:file
    >  results
    > #+end_src
    >
    > So the :session header argument is used by the emacs-lisp code block in
    > the call line, and never propagates to the R code block which is
    > evaluated.  Notice that header arguments like :results silent, will have
    > the expected results.
    >
    > So for now you will have to place the header argument on the actual R
    > code block.
    >
    > That said, I think that we should provide a mechanism for passing header
    > arguments through to called code blocks making the original
    > functionality you described possible.  I'm not sure how best to do that,
    > but currently I think we should expand the syntax used to call code
    > blocks to be more similar to inline code blocks, s.t. header arguments
    > can be placed inside of an optional square bracket section between the
    > name of the code block and the arguments.  Using this new proposed
    > syntax your example below would be written as
    >
    > #+call: chartPolAngle[:session testBabel :file
    > testBabel.pdf](pol=tableTestBabel)
    >
    > I'd be interested to hear what the community thinks of this new syntax.
    >
    > As an unrelated note, we also need to think of a natural way to allow
    > the header argument portion of a code block to span multiple lines.
    >
    > Best -- Eric
    >
    > Christopher Witte <chris@witte.net.au> writes:
    >
    > > I'm having a bit of trouble with org bable and R. When I try to execute
    > the
    > > code below (C-c C-c on the call line), as you can see, I get the results
    > > :nil
    > >
    > > ---------------------------------------
    > > #+tblname: tableTestBabel
    > > |   0 | 4.40 |
    > > |  30 | 4.54 |
    > > |  60 | 7.09 |
    > > |  90 | 9.40 |
    > > | 120 | 9.22 |
    > > | 150 | 6.65 |
    > > | 180 | 4.22 |
    > >
    > > #+srcname: chartPolAngle(pol)
    > > #+begin_src R
    > >   angle <- pol[,1]
    > >   energy <- pol[,2]
    > >   plot(angle,energy)
    > >   energy.model <-  nls (energy ~ a1 + a2 * (sin(pi / a3 *(angle-a4)))^2,
    > > start=list(a1=3.0, a2=7.0, a3=180, a4=0.0))
    > >   lines(spline(angle, fitted.values(energy.model)), lwd=2)
    > >   summary(energy.model)
    > > #+end_src
    > >
    > > #+call: chartPolAngle(pol=tableTestBabel) :session testBabel :file
    > testBabel.pdf
    > >
    > > #+results: chartPolAngle(pol=tableTestBabel)
    > > : nil
    > > ------------------------------------
    > >
    > > but If I move the header arguments to the source block, as in the code
    > > below, everything works fine. I also get asked "ESS [S(R): R] starting
    > data
    > > directory? ~/doc/org/" which I don't get with the code above.
    > >
    > > ---------------------------------------
    > > #+tblname: tableTestBabel
    > > |   0 | 4.40 |
    > > |  30 | 4.54 |
    > > |  60 | 7.09 |
    > > |  90 | 9.40 |
    > > | 120 | 9.22 |
    > > | 150 | 6.65 |
    > > | 180 | 4.22 |
    > >
    > > #+call: chartPolAngle(pol=tableTestBabel)
    > >
    > > #+results: chartPolAngle(pol=tableTestBabel)
    > > : testBabel.pdf
    > >
    > >
    > > #+srcname: chartPolAngle(pol)
    > > #+begin_src R :session testBabel :file testBabel.pdf
    > >   angle <- pol[,1]
    > >   energy <- pol[,2]
    > >   plot(angle,energy)
    > >   energy.model <-  nls (energy ~ a1 + a2 * (sin(pi / a3 *(angle-a4)))^2,
    > > start=list(a1=3.0, a2=7.0, a3=180, a4=0.0))
    > >   lines(spline(angle, fitted.values(energy.model)), lwd=2)
    > >   summary(energy.model)
    > > #+end_src
    > > ---------------------------------------
    > >
    > > Org doesn't appear to respect the head arguments on the call. I pulled
    > from
    > > git a couple days ago. Any ideas why?
    > >
    > > Cheers
    > > Chris Witte
    > > _______________________________________________
    > > Emacs-orgmode mailing list
    > > Please use `Reply All' to send replies to the list.
    > > Emacs-orgmode@gnu.org
    > > http://lists.gnu.org/mailman/listinfo/emacs-orgmode
    >
    
    
    
    -- 
    Postdoctoral Research Fellow
    Molecular Imaging Group
     Leibniz-Institut für Molekulare Pharmakologie (FMP)
    Campus Berlin-Buch
    Robert-Roessle-Str. 10
    13125 Berlin, Germany
    Phone: 00493094793-279
    
    [-- Attachment #1.2: Type: text/html, Size: 6304 bytes --]
    
    [-- Attachment #2: Type: text/plain, Size: 201 bytes --]
    
    _______________________________________________
    Emacs-orgmode mailing list
    Please use `Reply All' to send replies to the list.
    Emacs-orgmode@gnu.org
    http://lists.gnu.org/mailman/listinfo/emacs-orgmode
    
    ^ permalink raw reply	[flat|nested] 7+ messages in thread

  • • * Re: Proposed New Syntax For Calling Code Blocks was: Problem with Babel and sessions
        2010-09-13 12:05   ` Proposed New Syntax For Calling Code Blocks was: Problem with Babel and sessions Christopher Witte
      @ 2010-09-18 12:24     ` Eric Schulte
        0 siblings, 0 replies; 7+ messages in thread
      From: Eric Schulte @ 2010-09-18 12:24 UTC (permalink / raw)
        To: Christopher Witte; +Cc: Org Mode
      
      Hi Chris,
      
      Christopher Witte <chris@witte.net.au> writes:
      
      > Thanks for reply Eric.
      >
      > Thanks for the reply.  The reason why I wanted this was because I have
      > multiple sets of data and I would like to be able to apply the same code
      > block to the different sets of data and have the results in different pdfs.
      > Is there anyway to do this with the current version of org?
      >
      
      Under the current setup, the only way you would be able to supply
      different file argument to each call of the block, would be to pass the
      file name in as a variable, something like
      
      #+source: the-function
      #+begin_src R :var data=whatever :var file=file-name
        R code...
      #+end_src
      
      and then call the function with the file name passed in as a variable
      assignment
      
      #+call: the-function(data=whatever, file=fig-one.pdf)
      
      Best -- Eric
      
      >
      > Cheers,
      > Chris
      >
      > On 10 September 2010 20:06, Eric Schulte <schulte.eric@gmail.com> wrote:
      >
      >> Hi Christopher,
      >>
      >> Thanks for the well documented example.
      >>
      >> The header arguments on the call line, are actually being used by the
      >> call line itself, not by the R block which is called.  To unpack that,
      >> on evaluation the call line expands to a trivial emacs-lisp code block
      >> which is equivalent to
      >>
      >> #+begin_src emacs-lisp :var results=chartPolAngle(pol=tableTestBabel) :session testBabel:file
      >>  results
      >> #+end_src
      >>
      >> So the :session header argument is used by the emacs-lisp code block in
      >> the call line, and never propagates to the R code block which is
      >> evaluated.  Notice that header arguments like :results silent, will have
      >> the expected results.
      >>
      >> So for now you will have to place the header argument on the actual R
      >> code block.
      >>
      >> That said, I think that we should provide a mechanism for passing header
      >> arguments through to called code blocks making the original
      >> functionality you described possible.  I'm not sure how best to do that,
      >> but currently I think we should expand the syntax used to call code
      >> blocks to be more similar to inline code blocks, s.t. header arguments
      >> can be placed inside of an optional square bracket section between the
      >> name of the code block and the arguments.  Using this new proposed
      >> syntax your example below would be written as
      >>
      >> #+call: chartPolAngle[:session testBabel :file testBabel.pdf](pol=tableTestBabel)
      >>
      >> I'd be interested to hear what the community thinks of this new syntax.
      >>
      >> As an unrelated note, we also need to think of a natural way to allow
      >> the header argument portion of a code block to span multiple lines.
      >>
      >> Best -- Eric
      >>
      >> Christopher Witte <chris@witte.net.au> writes:
      >>
      >> > I'm having a bit of trouble with org bable and R. When I try to
      >> > execute the code below (C-c C-c on the call line), as you can see,
      >> > I get the results :nil
      >> >
      >> > ---------------------------------------
      >> > #+tblname: tableTestBabel
      >> > |   0 | 4.40 |
      >> > |  30 | 4.54 |
      >> > |  60 | 7.09 |
      >> > |  90 | 9.40 |
      >> > | 120 | 9.22 |
      >> > | 150 | 6.65 |
      >> > | 180 | 4.22 |
      >> >
      >> > #+srcname: chartPolAngle(pol)
      >> > #+begin_src R
      >> >   angle <- pol[,1]
      >> >   energy <- pol[,2]
      >> >   plot(angle,energy)
      >> >   energy.model <-  nls (energy ~ a1 + a2 * (sin(pi / a3 *(angle-a4)))^2,
      >> > start=list(a1=3.0, a2=7.0, a3=180, a4=0.0))
      >> >   lines(spline(angle, fitted.values(energy.model)), lwd=2)
      >> >   summary(energy.model)
      >> > #+end_src
      >> >
      >> > #+call: chartPolAngle(pol=tableTestBabel) :session testBabel :file
      >> testBabel.pdf
      >> >
      >> > #+results: chartPolAngle(pol=tableTestBabel)
      >> > : nil
      >> > ------------------------------------
      >> >
      >> > but If I move the header arguments to the source block, as in the code
      >> > below, everything works fine. I also get asked "ESS [S(R): R] starting
      >> data
      >> > directory? ~/doc/org/" which I don't get with the code above.
      >> >
      >> > ---------------------------------------
      >> > #+tblname: tableTestBabel
      >> > |   0 | 4.40 |
      >> > |  30 | 4.54 |
      >> > |  60 | 7.09 |
      >> > |  90 | 9.40 |
      >> > | 120 | 9.22 |
      >> > | 150 | 6.65 |
      >> > | 180 | 4.22 |
      >> >
      >> > #+call: chartPolAngle(pol=tableTestBabel)
      >> >
      >> > #+results: chartPolAngle(pol=tableTestBabel)
      >> > : testBabel.pdf
      >> >
      >> >
      >> > #+srcname: chartPolAngle(pol)
      >> > #+begin_src R :session testBabel :file testBabel.pdf
      >> >   angle <- pol[,1]
      >> >   energy <- pol[,2]
      >> >   plot(angle,energy)
      >> >   energy.model <-  nls (energy ~ a1 + a2 * (sin(pi / a3 *(angle-a4)))^2,
      >> > start=list(a1=3.0, a2=7.0, a3=180, a4=0.0))
      >> >   lines(spline(angle, fitted.values(energy.model)), lwd=2)
      >> >   summary(energy.model)
      >> > #+end_src
      >> > ---------------------------------------
      >> >
      >> > Org doesn't appear to respect the head arguments on the call. I pulled
      >> from
      >> > git a couple days ago. Any ideas why?
      >> >
      >> > Cheers
      >> > Chris Witte
      >> > _______________________________________________
      >> > Emacs-orgmode mailing list
      >> > Please use `Reply All' to send replies to the list.
      >> > Emacs-orgmode@gnu.org
      >> > http://lists.gnu.org/mailman/listinfo/emacs-orgmode
      >>
      
      ^ permalink raw reply	[flat|nested] 7+ messages in thread

  • * Re: Proposed New Syntax For Calling Code Blocks was: Problem with Babel and sessions
      2010-09-10 18:06 ` Proposed New Syntax For Calling Code Blocks was: " Eric Schulte
      2010-09-10 19:58   ` Proposed New Syntax For Calling Code Blocks was Jambunathan K
      2010-09-13 12:05   ` Proposed New Syntax For Calling Code Blocks was: Problem with Babel and sessions Christopher Witte
    @ 2010-09-14 19:03   ` Sébastien Vauban
      2 siblings, 0 replies; 7+ messages in thread
    From: Sébastien Vauban @ 2010-09-14 19:03 UTC (permalink / raw)
      To: emacs-orgmode-mXXj517/zsQ
    
    Hi Eric,
    
    "Eric Schulte" wrote:
    >
    > #+begin_src emacs-lisp :var results=chartPolAngle(pol=tableTestBabel) :session testBabel:file
    >   results
    > #+end_src
    >
    > [...] That said, I think that we should provide a mechanism for passing
    > header arguments through to called code blocks making the original
    > functionality you described possible. I'm not sure how best to do that, but
    > currently I think we should expand the syntax used to call code blocks to be
    > more similar to inline code blocks, s.t. header arguments can be placed
    > inside of an optional square bracket section between the name of the code
    > block and the arguments. Using this new proposed syntax your example below
    > would be written as
    >
    > #+call: chartPolAngle[:session testBabel :file testBabel.pdf](pol=tableTestBabel)
    >
    > I'd be interested to hear what the community thinks of this new syntax.
    
    Why not stay as closely as possible to the syntax of the blocks?
    
    Something like:
    
    #+call: chartPolAngle :session testBabel :file testBabel.pdf :var pol=tableTestBabel
    
    Though, I'm almost sure I don't understand the real point and implications of
    this discussion, hence...
    
    Best regards,
      Seb
    
    -- 
    Sébastien Vauban
    
    
    _______________________________________________
    Emacs-orgmode mailing list
    Please use `Reply All' to send replies to the list.
    Emacs-orgmode-mXXj517/zsQ@public.gmane.org
    http://lists.gnu.org/mailman/listinfo/emacs-orgmode
    
    ^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2010-09-18 12:25 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-09-09 15:09 Problem with Babel and sessions Christopher Witte
2010-09-10 18:06 ` Proposed New Syntax For Calling Code Blocks was: " Eric Schulte
2010-09-10 19:58   ` Proposed New Syntax For Calling Code Blocks was Jambunathan K
2010-09-10 21:12     ` Jambunathan K
2010-09-13 12:05   ` Proposed New Syntax For Calling Code Blocks was: Problem with Babel and sessions Christopher Witte
2010-09-18 12:24     ` Eric Schulte
2010-09-14 19:03   ` Sébastien Vauban

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).