From mboxrd@z Thu Jan 1 00:00:00 1970 From: Torsten Wagner Subject: [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks Date: Mon, 22 Jul 2013 13:20:01 +0200 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=001a1132f610889b8604e217dbe1 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39459) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1E9t-0000wY-A8 for emacs-orgmode@gnu.org; Mon, 22 Jul 2013 07:20:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1E9r-0005Ai-OF for emacs-orgmode@gnu.org; Mon, 22 Jul 2013 07:20:05 -0400 Received: from mail-ee0-x22c.google.com ([2a00:1450:4013:c00::22c]:55236) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1E9r-00054I-FB for emacs-orgmode@gnu.org; Mon, 22 Jul 2013 07:20:03 -0400 Received: by mail-ee0-f44.google.com with SMTP id c13so3786008eek.3 for ; Mon, 22 Jul 2013 04:20:02 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Org Mode Mailing List --001a1132f610889b8604e217dbe1 Content-Type: multipart/alternative; boundary=001a1132f610889b8204e217dbdf --001a1132f610889b8204e217dbdf Content-Type: text/plain; charset=ISO-8859-1 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 --001a1132f610889b8204e217dbdf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=

I want to summarize the problem I found, using tables as inpu= t 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=A0 with res= pect to horizontal line.

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

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

will give different results being called by

#+name: p= ython-element
#+begin_src python :var table=3Dwith-hline :exports results
=A0 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. Callin= g a table with hline, the result of the source code block miss the first ro= w. Indexing is possible only for the second and third row (in the given exa= mple)

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 i= n python is list for the entire table, however, indexing a table with hline= s, 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

<= div>
=A0


--001a1132f610889b8204e217dbdf-- --001a1132f610889b8604e217dbe1 Content-Type: application/octet-stream; name="table-calls.org" Content-Disposition: attachment; filename="table-calls.org" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hjfl1kh30 DQoqIERlZmluZSBzb21lIHRhYmxlcyB0byBpbGx1c3RyYXRlIHRoZSBwcm9ibGVtDQoNCiMrVEJM TkFNRTogd2l0aC1obGluZQ0KfCBBIHwgQiB8IEMgfA0KfC0tLSstLS0rLS0tfA0KfCAxIHwgMiB8 IDMgfA0KfCBYIHwgWSB8IFogfA0KDQojK1RCTE5BTUU6IHdpdGhvdXQtaGxpbmUNCnwgQSB8IEIg fCBDIHwNCnwgMSB8IDIgfCAzIHwNCnwgWCB8IFkgfCBaIHwNCg0KKiBGdW5jdGlvbg0KDQojK25h bWU6IHB5dGhvbi10eXBlDQojK2JlZ2luX3NyYyBweXRob24gOnZhciB0YWJsZT13aXRoLWhsaW5l IDpleHBvcnRzIHJlc3VsdHMgDQogIHJldHVybiB0eXBlKHRhYmxlWzFdKQ0KIytlbmRfc3JjDQoN CiMrbmFtZTogcHl0aG9uLWVsZW1lbnQNCiMrYmVnaW5fc3JjIHB5dGhvbiA6dmFyIHRhYmxlPXdp dGgtaGxpbmUgOmV4cG9ydHMgcmVzdWx0cyANCiAgcmV0dXJuIHRhYmxlWzFdDQojK2VuZF9zcmMN Cg0KIytuYW1lOiBweXRob24tZWNobw0KIytiZWdpbl9zcmMgcHl0aG9uIDp2YXIgdGFibGU9d2l0 aC1obGluZSA6ZXhwb3J0cyByZXN1bHRzDQogIHJldHVybiB0YWJsZQ0KIytlbmRfc3JjDQoNCiMr UkVTVUxUUzogcHl0aG9uLXJldHVybi12YWx1ZQ0KfCBYIHwgWSB8IFogfA0KDQoqIFJlc3VsdHMg b2YgZGlyZWN0IGZ1bmN0aW9uIGNhbGxzDQojK1JFU1VMVFM6IHB5dGhvbi10eXBlDQo6IDxjbGFz cyAnbGlzdCc+DQoNCiMrUkVTVUxUUzogcHl0aG9uLWVsZW1lbnQNCnwgWCB8IFkgfCBaIHwNCg0K IytSRVNVTFRTOiBweXRob24tZWNobw0KfCAxIHwgMiB8IDMgfA0KfCBYIHwgWSB8IFogfA0KDQoq IFJlc3VsdHMgY2FsbGluZyB0YWJsZSB3aXRoIGhsaW5lIHVzaW5nIGEgQ0FMTCBjb25zdHJ1Y3QN CiMrQ0FMTDogcHl0aG9uLXR5cGUod2l0aC1obGluZSkNCg0KIytSRVNVTFRTOiBweXRob24tdHlw ZSh3aXRoLWhsaW5lKQ0KOiA8Y2xhc3MgJ05vbmVUeXBlJz4NCg0KIytDQUxMOiBweXRob24tZWxl bWVudCh3aXRoLWhsaW5lKQ0KDQojK1JFU1VMVFM6IHB5dGhvbi1lbGVtZW50KHdpdGgtaGxpbmUp DQo6IE5vbmUNCg0KIytDQUxMOiBweXRob24tZWNobyh3aXRoLWhsaW5lKQ0KDQojK1JFU1VMVFM6 IHB5dGhvbi1lY2hvKHdpdGgtaGxpbmUpDQp8IEEgfCBCIHwgQyB8DQp8LS0tKy0tLSstLS18DQp8 IDEgfCAyIHwgMyB8DQp8IFggfCBZIHwgWiB8DQoNCg0KKiBSZXN1bHRzIGNhbGxpbmcgdGFibGUg d2l0aG91dCBobGluZSB1c2luZyBhIENBTEwgY29uc3RydWN0DQojK0NBTEw6IHB5dGhvbi10eXBl KHdpdGhvdXQtaGxpbmUpDQoNCiMrUkVTVUxUUzogcHl0aG9uLXR5cGUod2l0aG91dC1obGluZSkN CjogPGNsYXNzICdsaXN0Jz4NCg0KIytDQUxMOiBweXRob24tZWxlbWVudCh3aXRob3V0LWhsaW5l KQ0KDQojK1JFU1VMVFM6IHB5dGhvbi1lbGVtZW50KHdpdGhvdXQtaGxpbmUpDQp8IDEgfCAyIHwg MyB8DQoNCiMrQ0FMTDogcHl0aG9uLWVjaG8od2l0aG91dC1obGluZSkNCg0KIytSRVNVTFRTOiBw eXRob24tZWNobyh3aXRob3V0LWhsaW5lKQ0KfCBBIHwgQiB8IEMgfA0KfCAxIHwgMiB8IDMgfA0K fCBYIHwgWSB8IFogfA0KDQo= --001a1132f610889b8604e217dbe1--