|
From: | Rick Frankel |
Subject: | Re: [O] [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks |
Date: | Tue, 23 Jul 2013 11:40:51 -0400 |
User-agent: | Roundcube Webmail/0.9.0 |
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 sourcecode blocks.This observation was shared with Rick and I would be glad to help fixingthat. Within the attached file one can see a typical example.It all comes down to a differently interpretation of tables with respectto 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 thegiven example)2. Having no hline, the first row is available, indexing of the first rowworks 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 inpython 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 oftype 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 argsexist 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' linesSo, you clearly needs to add explicit values for some of your header argumentsin 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
[Prev in Thread] | Current Thread | [Next in Thread] |