From: Rick Frankel <rick@rickster.com>
To: Sebastien Vauban <sva-news@mygooglest.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks
Date: Tue, 23 Jul 2013 11:40:51 -0400 [thread overview]
Message-ID: <7d4de772e2fbed72bc049c69fea174cf@mail.rickster.com> (raw)
In-Reply-To: <86li4x4g63.fsf@somewhere.org>
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
next prev parent reply other threads:[~2013-07-23 15:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7d4de772e2fbed72bc049c69fea174cf@mail.rickster.com \
--to=rick@rickster.com \
--cc=emacs-orgmode@gnu.org \
--cc=sva-news@mygooglest.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).