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

* [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks
@ 2013-07-22 11:20 Torsten Wagner
  2013-07-23 12:25 ` Sebastien Vauban
  2013-07-24  8:48 ` Torsten Wagner
  0 siblings, 2 replies; 9+ messages in thread
From: Torsten Wagner @ 2013-07-22 11:20 UTC (permalink / raw)
  To: Org Mode Mailing List


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

Hi,

I want to summarize the problem I found, using tables as input to source
code blocks.
This observation was shared with Rick and I would be glad to help fixing
that.

Within the attached file one can see a typical example.

It all comes down to a differently interpretation of tables  with respect
to horizontal line.

#+TBLNAME: with-hline
| A | B | C |
|---+---+---|
| 1 | 2 | 3 |
| X | Y | Z |

and

#+TBLNAME: without-hline
| A | B | C |
| 1 | 2 | 3 |
| X | Y | Z |

will give different results being called by

#+name: python-element
#+begin_src python :var table=with-hline :exports results
  return table[1]
#+end_src

or

#+CALL: python-echo(with-hline)

Please see the attached file for details.

From what I was able to observe:

1. Calling a table with hline, the result of the source code block miss the
first row. Indexing is possible only for the second and third row (in the
given example)

2. Having no hline, the first row is available, indexing of the first row
works too.

Using a Call construct:
1. for a table without hline, indexing works but it does not work for a
table with hline.
2. Interestingly, using the CALL functions, the type of both tables in
python is list for the entire table, however, indexing a table with hlines,
the type becomes NoneType whereas for a table without hline it is still of
type list.


Hope that can somehow help to get an idea what is going on.


Greetings

Torsten

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

[-- Attachment #2: table-calls.org --]
[-- Type: application/octet-stream, Size: 1556 bytes --]


* Define some tables to illustrate the problem

#+TBLNAME: with-hline
| A | B | C |
|---+---+---|
| 1 | 2 | 3 |
| X | Y | Z |

#+TBLNAME: without-hline
| A | B | C |
| 1 | 2 | 3 |
| X | Y | Z |

* Function

#+name: python-type
#+begin_src python :var table=with-hline :exports results 
  return type(table[1])
#+end_src

#+name: python-element
#+begin_src python :var table=with-hline :exports results 
  return table[1]
#+end_src

#+name: python-echo
#+begin_src python :var table=with-hline :exports results
  return table
#+end_src

#+RESULTS: python-return-value
| X | Y | Z |

* Results of direct function calls
#+RESULTS: python-type
: <class 'list'>

#+RESULTS: python-element
| X | Y | Z |

#+RESULTS: python-echo
| 1 | 2 | 3 |
| X | Y | Z |

* Results calling table with hline using a CALL construct
#+CALL: python-type(with-hline)

#+RESULTS: python-type(with-hline)
: <class 'NoneType'>

#+CALL: python-element(with-hline)

#+RESULTS: python-element(with-hline)
: None

#+CALL: python-echo(with-hline)

#+RESULTS: python-echo(with-hline)
| A | B | C |
|---+---+---|
| 1 | 2 | 3 |
| X | Y | Z |


* Results calling table without hline using a CALL construct
#+CALL: python-type(without-hline)

#+RESULTS: python-type(without-hline)
: <class 'list'>

#+CALL: python-element(without-hline)

#+RESULTS: python-element(without-hline)
| 1 | 2 | 3 |

#+CALL: python-echo(without-hline)

#+RESULTS: python-echo(without-hline)
| A | B | C |
| 1 | 2 | 3 |
| X | Y | Z |


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

• * Re: [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks
    2013-07-22 11:20 [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks Torsten Wagner
  @ 2013-07-23 12:25 ` Sebastien Vauban
    2013-07-23 15:40   ` Rick Frankel
    2013-07-24  8:48 ` Torsten Wagner
    1 sibling, 1 reply; 9+ messages in thread
  From: Sebastien Vauban @ 2013-07-23 12:25 UTC (permalink / raw)
    To: emacs-orgmode-mXXj517/zsQ
  
  Hi Torsten,
  
  Torsten Wagner wrote:
  > I want to summarize the problem I found, using tables as input to source
  > code blocks.
  > This observation was shared with Rick and I would be glad to help fixing
  > that.
  >
  > Within the attached file one can see a typical example.
  >
  > It all comes down to a differently interpretation of tables  with respect
  > to horizontal line.
  >
  > #+TBLNAME: with-hline
  > | A | B | C |
  > |---+---+---|
  > | 1 | 2 | 3 |
  > | X | Y | Z |
  >
  > and
  >
  > #+TBLNAME: without-hline
  > | A | B | C |
  > | 1 | 2 | 3 |
  > | X | Y | Z |
  >
  > will give different results being called by
  >
  > #+name: python-element
  > #+begin_src python :var table=with-hline :exports results
  >   return table[1]
  > #+end_src
  >
  > or
  >
  > #+CALL: python-echo(with-hline)
  >
  > Please see the attached file for details.
  >
  > From what I was able to observe:
  >
  > 1. Calling a table with hline, the result of the source code block miss the
  > first row. Indexing is possible only for the second and third row (in the
  > given example)
  >
  > 2. Having no hline, the first row is available, indexing of the first row
  > works too.
  >
  > Using a Call construct:
  > 1. for a table without hline, indexing works but it does not work for a
  > table with hline.
  > 2. Interestingly, using the CALL functions, the type of both tables in
  > python is list for the entire table, however, indexing a table with hlines,
  > the type becomes NoneType whereas for a table without hline it is still of
  > type list.
  >
  > Hope that can somehow help to get an idea what is going on.
  
  I think the reason comes from the fact that different default header args
  exist depending on the way the code is eval'ed.
  
  See the contents of the following vars:
  
  - `org-babel-default-header-args' for source blocks
  - `org-babel-default-inline-header-args' for inline source blocks
  - `org-babel-default-lob-header-args' for `#+call' lines
  
  So, you clearly needs to add explicit values for some of your header arguments
  in your call line.
  
  Best regards,
  Seb
  
  -- 
  Sebastien Vauban
  
  ^ permalink raw reply	[flat|nested] 9+ messages in thread

• • * Re: [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks
      2013-07-23 12:25 ` Sebastien Vauban
    @ 2013-07-23 15:40   ` Rick Frankel
      0 siblings, 0 replies; 9+ messages in thread
    From: Rick Frankel @ 2013-07-23 15:40 UTC (permalink / raw)
      To: Sebastien Vauban; +Cc: emacs-orgmode
    
    On 2013-07-23 08:25, Sebastien Vauban wrote:
    > Torsten Wagner wrote:
    > I want to summarize the problem I found, using tables as input to 
    > source
    > code blocks.
    > This observation was shared with Rick and I would be glad to help 
    > fixing
    > that.
    > 
    > Within the attached file one can see a typical example.
    > 
    > It all comes down to a differently interpretation of tables  with 
    > respect
    > to horizontal line.
    > 
    > #+TBLNAME: with-hline
    > | A | B | C |
    > |---+---+---|
    > | 1 | 2 | 3 |
    > | X | Y | Z |
    > 
    > and
    > 
    > #+TBLNAME: without-hline
    > | A | B | C |
    > | 1 | 2 | 3 |
    > | X | Y | Z |
    > 
    > will give different results being called by
    > 
    > #+name: python-element
    > #+begin_src python :var table=with-hline :exports results
    > return table[1]
    > #+end_src
    > 
    > or
    > 
    > #+CALL: python-echo(with-hline)
    > 
    > Please see the attached file for details.
    > 
    > From what I was able to observe:
    > 
    > 1. Calling a table with hline, the result of the source code block miss 
    > the
    > first row. Indexing is possible only for the second and third row (in 
    > the
    > given example)
    > 
    > 2. Having no hline, the first row is available, indexing of the first 
    > row
    > works too.
    > 
    > Using a Call construct:
    > 1. for a table without hline, indexing works but it does not work for a
    > table with hline.
    > 2. Interestingly, using the CALL functions, the type of both tables in
    > python is list for the entire table, however, indexing a table with 
    > hlines,
    > the type becomes NoneType whereas for a table without hline it is still 
    > of
    > type list.
    > 
    > Hope that can somehow help to get an idea what is going on.
    > 
    > I think the reason comes from the fact that different default header 
    > args
    > exist depending on the way the code is eval'ed.
    > 
    > See the contents of the following vars:
    > 
    > - `org-babel-default-header-args' for source blocks
    > - `org-babel-default-inline-header-args' for inline source blocks
    > - `org-babel-default-lob-header-args' for `#+call' lines
    > 
    > So, you clearly needs to add explicit values for some of your header 
    > arguments
    > in your call line.
    
    I don't think this is the cause of the problem. The problem seems to be
    universal in the babel handling of column names (`:colnames') in input
    and output tables and it's application, as well as different handling
    of `call' lines with and without explicit input arguments (see [1] and
    [2].) Regardless, the handling of tables with and without a header
    separated by an hline are definitely affected by the values of the
    `:colnames' and `:hlines' header arguments, but the difference between
    the results from the original source block and the call lines with and
    without an explicit argument are still inconsistent. Just to cover some:
    
    #+BEGIN_ORG
    #+TBLNAME: with-hline
    | A | B | C |
    |---+---+---|
    | 1 | 2 | 3 |
    | X | Y | Z |
    
    #+name: python-echo
    #+header: :colnames '()
    #+begin_src python :var table=with-hline
    return table
    #+end_src
    
    #+RESULTS: python-echo
    | 1 | 2 | 3 |
    | X | Y | Z |
    
    #+header: :colnames no
    #+begin_src python :var table=with-hline
    return table
    #+end_src
    
    #+RESULTS:
    | A | B | C |
    | 1 | 2 | 3 |
    | X | Y | Z |
    
    #+header: :colnames yes
    #+begin_src python :var table=with-hline
    return table
    #+end_src
    
    #+RESULTS:
    | A | B | C |
    |---+---+---|
    | 1 | 2 | 3 |
    | X | Y | Z |
    
    #+call: python-echo()
    
    #+RESULTS:
    | 1 | 2 | 3 |
    | X | Y | Z |
    
    #+call: python-echo() :colnames yes
    
    #+RESULTS:
    | 1 | 2 | 3 |
    |---+---+---|
    | X | Y | Z |
    
    #+call: python-echo[:colnames yes]()
    
    #+RESULTS:
    | A | B | C |
    |---+---+---|
    | 1 | 2 | 3 |
    | X | Y | Z |
    
    #+call: python-echo(table=with-hline)
    
    #+RESULTS:
    | A | B | C |
    |---+---+---|
    | 1 | 2 | 3 |
    | X | Y | Z |
    
    
    #+call: python-echo(table=with-hline) :colnames yes
    
    #+RESULTS:
    | A | B | C |
    |---+---+---|
    | 1 | 2 | 3 |
    | X | Y | Z |
    
    #+call: python-echo[:colnames yes](table=with-hline) :colnames yes
    
    #+RESULTS:
    | A | B | C |
    |---+---+---|
    | A | B | C |
    |---+---+---|
    | 1 | 2 | 3 |
    | X | Y | Z |
    
    #+END_ORG
    
    [1] http://article.gmane.org/gmane.emacs.orgmode/74897
    [2] http://article.gmane.org/gmane.emacs.orgmode/74452
    
    ^ permalink raw reply	[flat|nested] 9+ messages in thread

• * Re: [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks
    2013-07-22 11:20 [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks Torsten Wagner
    2013-07-23 12:25 ` Sebastien Vauban
  @ 2013-07-24  8:48 ` Torsten Wagner
    2013-07-24 22:30   ` Eric Schulte
    1 sibling, 1 reply; 9+ messages in thread
  From: Torsten Wagner @ 2013-07-24  8:48 UTC (permalink / raw)
    To: Org Mode Mailing List
  
  [-- Attachment #1: Type: text/plain, Size: 2887 bytes --]
  
  Hi Rick, Hi Sebastien,
  
  thanks for your inputs.
  Well I guess Sebastien is half-right. The different settings make at least
  it even more tricky to see what is going on.
  Here is a table with the settings as I found them on my system (which I did
  not change)
  
  #+BEGIN_ORG
  
  | org-babel-default-header-args        | ((:session . "none") (:results .
  "replace") (:exports . "code") (:cache . "no") (:noweb . "no") (:hlines .
  "no") (:tangle . "no") (:padnewline . "yes")) |
  | org-babel-default-lob-header-args    | ((:exports .
  "results"))
  |
  | org-babel-default-inline-header-args | ((:session . "none")(:results .
  "replace")(:exports .
  "results"))
  |
  
  #+END_ORG
  
  As you can see the most prominent cause for trouble might be :hlines
  As Rick should in his message it does still not solve all problems but it
  helps to make it more clear.
  
  I assume Eric is on holiday or otherwise busy but I guess he will find this
  thread and might can give us some idea, whether there was an intention in
  dealing with tables in that way or whether it is really considered as a bug.
  
  However, Sebastian pointed out a very important fact. Different default
  settings for different ways of calling a source code block. I believe that
  this should find its way into the manual.
  
  All the best
  
  Torsten
  
  
  
  
  On 22 July 2013 13:20, Torsten Wagner <torsten.wagner@gmail.com> wrote:
  
  > Hi,
  >
  > I want to summarize the problem I found, using tables as input to source
  > code blocks.
  > This observation was shared with Rick and I would be glad to help fixing
  > that.
  >
  > Within the attached file one can see a typical example.
  >
  > It all comes down to a differently interpretation of tables  with respect
  > to horizontal line.
  >
  > #+TBLNAME: with-hline
  > | A | B | C |
  > |---+---+---|
  > | 1 | 2 | 3 |
  > | X | Y | Z |
  >
  > and
  >
  > #+TBLNAME: without-hline
  > | A | B | C |
  > | 1 | 2 | 3 |
  > | X | Y | Z |
  >
  > will give different results being called by
  >
  > #+name: python-element
  > #+begin_src python :var table=with-hline :exports results
  >   return table[1]
  > #+end_src
  >
  > or
  >
  > #+CALL: python-echo(with-hline)
  >
  > Please see the attached file for details.
  >
  > From what I was able to observe:
  >
  > 1. Calling a table with hline, the result of the source code block miss
  > the first row. Indexing is possible only for the second and third row (in
  > the given example)
  >
  > 2. Having no hline, the first row is available, indexing of the first row
  > works too.
  >
  > Using a Call construct:
  > 1. for a table without hline, indexing works but it does not work for a
  > table with hline.
  > 2. Interestingly, using the CALL functions, the type of both tables in
  > python is list for the entire table, however, indexing a table with hlines,
  > the type becomes NoneType whereas for a table without hline it is still of
  > type list.
  >
  >
  > Hope that can somehow help to get an idea what is going on.
  >
  >
  > Greetings
  >
  > Torsten
  >
  >
  >
  >
  >
  >
  
  [-- Attachment #2: Type: text/html, Size: 4345 bytes --]
  
  ^ permalink raw reply	[flat|nested] 9+ messages in thread

• • * Re: [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks
      2013-07-24  8:48 ` Torsten Wagner
    @ 2013-07-24 22:30   ` Eric Schulte
      2013-07-25 11:40     ` Torsten Wagner
      0 siblings, 1 reply; 9+ messages in thread
    From: Eric Schulte @ 2013-07-24 22:30 UTC (permalink / raw)
      To: Torsten Wagner; +Cc: Org Mode Mailing List
    
    Torsten Wagner <torsten.wagner@gmail.com> writes:
    
    > Hi Rick, Hi Sebastien,
    >
    > thanks for your inputs.
    > Well I guess Sebastien is half-right. The different settings make at least
    > it even more tricky to see what is going on.
    > Here is a table with the settings as I found them on my system (which I did
    > not change)
    >
    > #+BEGIN_ORG
    >
    > | org-babel-default-header-args        | ((:session . "none") (:results .
    > "replace") (:exports . "code") (:cache . "no") (:noweb . "no") (:hlines .
    > "no") (:tangle . "no") (:padnewline . "yes")) |
    > | org-babel-default-lob-header-args    | ((:exports .
    > "results"))
    > |
    > | org-babel-default-inline-header-args | ((:session . "none")(:results .
    > "replace")(:exports .
    > "results"))
    > |
    >
    > #+END_ORG
    >
    > As you can see the most prominent cause for trouble might be :hlines
    > As Rick should in his message it does still not solve all problems but it
    > helps to make it more clear.
    >
    
    This is related to
    http://thread.gmane.org/gmane.emacs.orgmode/73976/focus=74175.
    
    >
    > I assume Eric is on holiday or otherwise busy but I guess he will find this
    > thread and might can give us some idea, whether there was an intention in
    > dealing with tables in that way or whether it is really considered as a bug.
    >
    
    Yes, I've been very busy.
    
    >
    > However, Sebastian pointed out a very important fact. Different default
    > settings for different ways of calling a source code block. I believe that
    > this should find its way into the manual.
    >
    
    I'm happy to apply patches to the manual.
    
    >
    > All the best
    >
    > Torsten
    >
    >
    >
    >
    > On 22 July 2013 13:20, Torsten Wagner <torsten.wagner@gmail.com> wrote:
    >
    >> Hi,
    >>
    >> I want to summarize the problem I found, using tables as input to source
    >> code blocks.
    >> This observation was shared with Rick and I would be glad to help fixing
    >> that.
    >>
    >> Within the attached file one can see a typical example.
    >>
    >> It all comes down to a differently interpretation of tables  with respect
    >> to horizontal line.
    >>
    >> #+TBLNAME: with-hline
    >> | A | B | C |
    >> |---+---+---|
    >> | 1 | 2 | 3 |
    >> | X | Y | Z |
    >>
    >> and
    >>
    >> #+TBLNAME: without-hline
    >> | A | B | C |
    >> | 1 | 2 | 3 |
    >> | X | Y | Z |
    >>
    >> will give different results being called by
    >>
    >> #+name: python-element
    >> #+begin_src python :var table=with-hline :exports results
    >>   return table[1]
    >> #+end_src
    >>
    >> or
    >>
    >> #+CALL: python-echo(with-hline)
    >>
    >> Please see the attached file for details.
    >>
    >> From what I was able to observe:
    >>
    >> 1. Calling a table with hline, the result of the source code block miss
    >> the first row. Indexing is possible only for the second and third row (in
    >> the given example)
    >>
    >> 2. Having no hline, the first row is available, indexing of the first row
    >> works too.
    >>
    >> Using a Call construct:
    >> 1. for a table without hline, indexing works but it does not work for a
    >> table with hline.
    >> 2. Interestingly, using the CALL functions, the type of both tables in
    >> python is list for the entire table, however, indexing a table with hlines,
    >> the type becomes NoneType whereas for a table without hline it is still of
    >> type list.
    >>
    >>
    >> Hope that can somehow help to get an idea what is going on.
    >>
    >>
    >> Greetings
    >>
    >> Torsten
    >>
    >>
    >>
    >>
    >>
    >>
    
    -- 
    Eric Schulte
    http://cs.unm.edu/~eschulte
    
    ^ permalink raw reply	[flat|nested] 9+ messages in thread

  • • * Re: [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks
        2013-07-24 22:30   ` Eric Schulte
      @ 2013-07-25 11:40     ` Torsten Wagner
        2013-07-25 12:37       ` Jambunathan K
        2013-07-25 13:43       ` Eric Schulte
        0 siblings, 2 replies; 9+ messages in thread
      From: Torsten Wagner @ 2013-07-25 11:40 UTC (permalink / raw)
        To: Eric Schulte; +Cc: Org Mode Mailing List
      
      
      [-- Attachment #1.1: Type: text/plain, Size: 3844 bytes --]
      
      Dear Eric,
      
      please find attached a patch, to describe the different standard values for
      system-wide header arguments in the manual.
      Hope that might help to avoid confusion in the future.
      
      All the best
      
      Torsten
      
      
      On 25 July 2013 00:30, Eric Schulte <schulte.eric@gmail.com> wrote:
      
      > Torsten Wagner <torsten.wagner@gmail.com> writes:
      >
      > > Hi Rick, Hi Sebastien,
      > >
      > > thanks for your inputs.
      > > Well I guess Sebastien is half-right. The different settings make at
      > least
      > > it even more tricky to see what is going on.
      > > Here is a table with the settings as I found them on my system (which I
      > did
      > > not change)
      > >
      > > #+BEGIN_ORG
      > >
      > > | org-babel-default-header-args        | ((:session . "none") (:results .
      > > "replace") (:exports . "code") (:cache . "no") (:noweb . "no") (:hlines .
      > > "no") (:tangle . "no") (:padnewline . "yes")) |
      > > | org-babel-default-lob-header-args    | ((:exports .
      > > "results"))
      > > |
      > > | org-babel-default-inline-header-args | ((:session . "none")(:results .
      > > "replace")(:exports .
      > > "results"))
      > > |
      > >
      > > #+END_ORG
      > >
      > > As you can see the most prominent cause for trouble might be :hlines
      > > As Rick should in his message it does still not solve all problems but it
      > > helps to make it more clear.
      > >
      >
      > This is related to
      > http://thread.gmane.org/gmane.emacs.orgmode/73976/focus=74175.
      >
      > >
      > > I assume Eric is on holiday or otherwise busy but I guess he will find
      > this
      > > thread and might can give us some idea, whether there was an intention in
      > > dealing with tables in that way or whether it is really considered as a
      > bug.
      > >
      >
      > Yes, I've been very busy.
      >
      > >
      > > However, Sebastian pointed out a very important fact. Different default
      > > settings for different ways of calling a source code block. I believe
      > that
      > > this should find its way into the manual.
      > >
      >
      > I'm happy to apply patches to the manual.
      >
      > >
      > > All the best
      > >
      > > Torsten
      > >
      > >
      > >
      > >
      > > On 22 July 2013 13:20, Torsten Wagner <torsten.wagner@gmail.com> wrote:
      > >
      > >> Hi,
      > >>
      > >> I want to summarize the problem I found, using tables as input to source
      > >> code blocks.
      > >> This observation was shared with Rick and I would be glad to help fixing
      > >> that.
      > >>
      > >> Within the attached file one can see a typical example.
      > >>
      > >> It all comes down to a differently interpretation of tables  with
      > respect
      > >> to horizontal line.
      > >>
      > >> #+TBLNAME: with-hline
      > >> | A | B | C |
      > >> |---+---+---|
      > >> | 1 | 2 | 3 |
      > >> | X | Y | Z |
      > >>
      > >> and
      > >>
      > >> #+TBLNAME: without-hline
      > >> | A | B | C |
      > >> | 1 | 2 | 3 |
      > >> | X | Y | Z |
      > >>
      > >> will give different results being called by
      > >>
      > >> #+name: python-element
      > >> #+begin_src python :var table=with-hline :exports results
      > >>   return table[1]
      > >> #+end_src
      > >>
      > >> or
      > >>
      > >> #+CALL: python-echo(with-hline)
      > >>
      > >> Please see the attached file for details.
      > >>
      > >> From what I was able to observe:
      > >>
      > >> 1. Calling a table with hline, the result of the source code block miss
      > >> the first row. Indexing is possible only for the second and third row
      > (in
      > >> the given example)
      > >>
      > >> 2. Having no hline, the first row is available, indexing of the first
      > row
      > >> works too.
      > >>
      > >> Using a Call construct:
      > >> 1. for a table without hline, indexing works but it does not work for a
      > >> table with hline.
      > >> 2. Interestingly, using the CALL functions, the type of both tables in
      > >> python is list for the entire table, however, indexing a table with
      > hlines,
      > >> the type becomes NoneType whereas for a table without hline it is still
      > of
      > >> type list.
      > >>
      > >>
      > >> Hope that can somehow help to get an idea what is going on.
      > >>
      > >>
      > >> Greetings
      > >>
      > >> Torsten
      > >>
      > >>
      > >>
      > >>
      > >>
      > >>
      >
      > --
      > Eric Schulte
      > http://cs.unm.edu/~eschulte
      >
      
      [-- Attachment #1.2: Type: text/html, Size: 5700 bytes --]
      
      [-- Attachment #2: babel_standard_header_settings_doc.patch --]
      [-- Type: application/octet-stream, Size: 1360 bytes --]
      
      diff --git a/doc/org.texi b/doc/org.texi
      index 55c421d..d8987d6 100644
      --- a/doc/org.texi
      +++ b/doc/org.texi
      @@ -14066,6 +14066,16 @@ blocks.
                   (assq-delete-all :noweb org-babel-default-header-args)))
       @end lisp
       
      +The different ways of calling a source code block might come with different system-wide values of header arguments.
      +Thus, the behaviour of a source code block might differ, depending on the way how it was called. The table below depicts the variables and standard values for the different ways to execute a source code block.
      +
      +@multitable @columnfractions 0.1 0.1 0.3 
      +@item @b{Method} @tab @b{Variable} @tab @b{Values}
      +@item source code block @tab org-babel-default-header-args  @tab :session "none", :results "replace", :exports "code", :cache "no", :noweb "no", :hlines "no", :tangle "no", :padnewline "yes"
      +@item inline call           @tab  org-babel-default-inline-header-args  @tab  :exports "results"
      +@item function calls        @tab  org-babel-default-lob-header-args      @tab :session "none", :results "replace", :exports "results"
      +@end multitable
      +
       @node Language-specific header arguments, Header arguments in Org mode properties, System-wide header arguments, Using header arguments
       @subsubheading Language-specific header arguments
       Each language can define its own set of default header arguments in variable
      
      ^ permalink raw reply related	[flat|nested] 9+ messages in thread

    • • * Re: [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks
          2013-07-25 11:40     ` Torsten Wagner
        @ 2013-07-25 12:37       ` Jambunathan K
          2013-07-25 13:43       ` Eric Schulte
          1 sibling, 0 replies; 9+ messages in thread
        From: Jambunathan K @ 2013-07-25 12:37 UTC (permalink / raw)
          To: Torsten Wagner; +Cc: Org Mode Mailing List, Eric Schulte
        
        Torsten Wagner <torsten.wagner@gmail.com> writes:
        
        > The different ways of calling a source code block might come with
        > different system-wide values of header arguments.  Thus, the behaviour
        > of a source code block might differ, depending on the way how it was
        > called. The table below depicts the variables and standard values for
        > the different ways to execute a source code block.
        
        I don't understand the current context.  Nor do I understand Babel. But
        purely from a copy-editing perspective, you can say something like
        
            You can modify the behaviour of a source block by customizing
            system-wide header arguments.  The table below summarizes these
            variables and their standard values
        
        or something like 
        
            The behaviour of a source block depends on the values of system-wide
            header arguments.  The table below depicts these variables and their
            standard values
        
        Btw, is it "system-wide values of header arguments" or
                   "values of system-wide header arguments"?
        
        The first suggestion starts with a "You" - and this style is very
        typical of Emacs manuals.  The second paragraph will put one to sleep.
        Not a criticism.  Just a suggestion from someone who is bored.
        
        ^ permalink raw reply	[flat|nested] 9+ messages in thread

      • * Re: [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks
          2013-07-25 11:40     ` Torsten Wagner
          2013-07-25 12:37       ` Jambunathan K
        @ 2013-07-25 13:43       ` Eric Schulte
          1 sibling, 0 replies; 9+ messages in thread
        From: Eric Schulte @ 2013-07-25 13:43 UTC (permalink / raw)
          To: Torsten Wagner; +Cc: Org Mode Mailing List
        
        Torsten Wagner <torsten.wagner@gmail.com> writes:
        
        > Dear Eric,
        >
        > please find attached a patch, to describe the different standard values for
        > system-wide header arguments in the manual.
        > Hope that might help to avoid confusion in the future.
        >
        > All the best
        >
        
        Thanks for sending this along.  Would you mind making two small changes?
        
        1. Format the patch by first committing it to your local git repo, and
           then generating the patch with "git format-patch -o /tmp/ HEAD~1",
           which will write the patch to your /tmp/ directory.  That way it will
           easily apply (this version does not apply for me).
        
           Also, please put the string TINYCHANGE in your commit message,
           because the patch is small and you haven't signed the FSF papers.
        
           see http://orgmode.org/worg/org-contribute.html
        
        2. I we shouldn't put the actual values in the manual, as they will
           likely change in the code at some point, and then the manual and code
           will be incomplete.  The values of any emacs variable are easily
           looked up, either with elisp or through the customization interface.
        
        Thanks,
        
        >
        > Torsten
        >
        >
        > On 25 July 2013 00:30, Eric Schulte <schulte.eric@gmail.com> wrote:
        >
        >> Torsten Wagner <torsten.wagner@gmail.com> writes:
        >>
        >> > Hi Rick, Hi Sebastien,
        >> >
        >> > thanks for your inputs.
        >> > Well I guess Sebastien is half-right. The different settings make at
        >> least
        >> > it even more tricky to see what is going on.
        >> > Here is a table with the settings as I found them on my system (which I
        >> did
        >> > not change)
        >> >
        >> > #+BEGIN_ORG
        >> >
        >> > | org-babel-default-header-args        | ((:session . "none") (:results .
        >> > "replace") (:exports . "code") (:cache . "no") (:noweb . "no") (:hlines .
        >> > "no") (:tangle . "no") (:padnewline . "yes")) |
        >> > | org-babel-default-lob-header-args    | ((:exports .
        >> > "results"))
        >> > |
        >> > | org-babel-default-inline-header-args | ((:session . "none")(:results .
        >> > "replace")(:exports .
        >> > "results"))
        >> > |
        >> >
        >> > #+END_ORG
        >> >
        >> > As you can see the most prominent cause for trouble might be :hlines
        >> > As Rick should in his message it does still not solve all problems but it
        >> > helps to make it more clear.
        >> >
        >>
        >> This is related to
        >> http://thread.gmane.org/gmane.emacs.orgmode/73976/focus=74175.
        >>
        >> >
        >> > I assume Eric is on holiday or otherwise busy but I guess he will find
        >> this
        >> > thread and might can give us some idea, whether there was an intention in
        >> > dealing with tables in that way or whether it is really considered as a
        >> bug.
        >> >
        >>
        >> Yes, I've been very busy.
        >>
        >> >
        >> > However, Sebastian pointed out a very important fact. Different default
        >> > settings for different ways of calling a source code block. I believe
        >> that
        >> > this should find its way into the manual.
        >> >
        >>
        >> I'm happy to apply patches to the manual.
        >>
        >> >
        >> > All the best
        >> >
        >> > Torsten
        >> >
        >> >
        >> >
        >> >
        >> > On 22 July 2013 13:20, Torsten Wagner <torsten.wagner@gmail.com> wrote:
        >> >
        >> >> Hi,
        >> >>
        >> >> I want to summarize the problem I found, using tables as input to source
        >> >> code blocks.
        >> >> This observation was shared with Rick and I would be glad to help fixing
        >> >> that.
        >> >>
        >> >> Within the attached file one can see a typical example.
        >> >>
        >> >> It all comes down to a differently interpretation of tables  with
        >> respect
        >> >> to horizontal line.
        >> >>
        >> >> #+TBLNAME: with-hline
        >> >> | A | B | C |
        >> >> |---+---+---|
        >> >> | 1 | 2 | 3 |
        >> >> | X | Y | Z |
        >> >>
        >> >> and
        >> >>
        >> >> #+TBLNAME: without-hline
        >> >> | A | B | C |
        >> >> | 1 | 2 | 3 |
        >> >> | X | Y | Z |
        >> >>
        >> >> will give different results being called by
        >> >>
        >> >> #+name: python-element
        >> >> #+begin_src python :var table=with-hline :exports results
        >> >>   return table[1]
        >> >> #+end_src
        >> >>
        >> >> or
        >> >>
        >> >> #+CALL: python-echo(with-hline)
        >> >>
        >> >> Please see the attached file for details.
        >> >>
        >> >> From what I was able to observe:
        >> >>
        >> >> 1. Calling a table with hline, the result of the source code block miss
        >> >> the first row. Indexing is possible only for the second and third row
        >> (in
        >> >> the given example)
        >> >>
        >> >> 2. Having no hline, the first row is available, indexing of the first
        >> row
        >> >> works too.
        >> >>
        >> >> Using a Call construct:
        >> >> 1. for a table without hline, indexing works but it does not work for a
        >> >> table with hline.
        >> >> 2. Interestingly, using the CALL functions, the type of both tables in
        >> >> python is list for the entire table, however, indexing a table with
        >> hlines,
        >> >> the type becomes NoneType whereas for a table without hline it is still
        >> of
        >> >> type list.
        >> >>
        >> >>
        >> >> Hope that can somehow help to get an idea what is going on.
        >> >>
        >> >>
        >> >> Greetings
        >> >>
        >> >> Torsten
        >> >>
        >> >>
        >> >>
        >> >>
        >> >>
        >> >>
        >>
        >> --
        >> Eric Schulte
        >> http://cs.unm.edu/~eschulte
        >>
        >
        > diff --git a/doc/org.texi b/doc/org.texi
        > index 55c421d..d8987d6 100644
        > --- a/doc/org.texi
        > +++ b/doc/org.texi
        > @@ -14066,6 +14066,16 @@ blocks.
        >              (assq-delete-all :noweb org-babel-default-header-args)))
        >  @end lisp
        >  
        > +The different ways of calling a source code block might come with different system-wide values of header arguments.
        > +Thus, the behaviour of a source code block might differ, depending on the way how it was called. The table below depicts the variables and standard values for the different ways to execute a source code block.
        > +
        > +@multitable @columnfractions 0.1 0.1 0.3 
        > +@item @b{Method} @tab @b{Variable} @tab @b{Values}
        > +@item source code block @tab org-babel-default-header-args  @tab :session "none", :results "replace", :exports "code", :cache "no", :noweb "no", :hlines "no", :tangle "no", :padnewline "yes"
        > +@item inline call           @tab  org-babel-default-inline-header-args  @tab  :exports "results"
        > +@item function calls        @tab  org-babel-default-lob-header-args      @tab :session "none", :results "replace", :exports "results"
        > +@end multitable
        > +
        >  @node Language-specific header arguments, Header arguments in Org mode properties, System-wide header arguments, Using header arguments
        >  @subsubheading Language-specific header arguments
        >  Each language can define its own set of default header arguments in variable
        
        -- 
        Eric Schulte
        http://cs.unm.edu/~eschulte
        
        ^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks
@ 2013-07-25 17:02 Rick Frankel
  0 siblings, 0 replies; 9+ messages in thread
From: Rick Frankel @ 2013-07-25 17:02 UTC (permalink / raw)
  To: emacs-orgmode

Sorry for breaking the thread, i deleted the prior message.

On 2013-07-23 08:25, Sebastien Vauban wrote:


> See the contents of the following vars:
> 
> - `org-babel-default-header-args' for source blocks
> - `org-babel-default-inline-header-args' for inline source blocks
> - `org-babel-default-lob-header-args' for `#+call' lines

Tracing through the function `org-babel-lob-execute', it seems that
`org-babel-default-lob-header-args' are not actually referenced or
used, but the variable `org-babel-default-header-args:emacs-lisp'
(default to `((:hlines . "yes") (:colnames . "no"))') is.

`org-babel-default-lob-header-args' is only reference in the function
`org-babel-exp-non-block-element' (used for export only), so i don't
think it actually has any effect.


So, given the above, and the following example:

#+name: test
#+BEGIN_SRC emacs-lisp
"foo"
#+END_SRC

#+call: test()

the complete list of header arguments for the call line are:

#+BEGIN_EXAMPLE
(:comments . #1="")
(:shebang . #1#)
(:cache . "no")
(:padline . #1#)
(:noweb . "no")
(:tangle . "no")
(:exports . "results")
(:results . "replace")
(:var . "results=test()")
(:colnames . "no")
(:hlines . "yes")
(:padnewline . "yes")
(:session . "none")
#+END_EXAMPLE

rick

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

end of thread, other threads:[~2013-07-25 17:08 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-22 11:20 [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks Torsten Wagner
2013-07-23 12:25 ` Sebastien Vauban
2013-07-23 15:40   ` Rick Frankel
2013-07-24  8:48 ` Torsten Wagner
2013-07-24 22:30   ` Eric Schulte
2013-07-25 11:40     ` Torsten Wagner
2013-07-25 12:37       ` Jambunathan K
2013-07-25 13:43       ` Eric Schulte
  -- strict thread matches above, loose matches on Subject: below --
2013-07-25 17:02 Rick Frankel

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