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