From mboxrd@z Thu Jan 1 00:00:00 1970 From: Torsten Wagner Subject: Re: [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks Date: Wed, 24 Jul 2013 10:48:09 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c3f60c0b9c0504e23df821 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1uk0-0001aq-OM for emacs-orgmode@gnu.org; Wed, 24 Jul 2013 04:48:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1ujz-0002OB-Fl for emacs-orgmode@gnu.org; Wed, 24 Jul 2013 04:48:12 -0400 Received: from mail-ea0-x22c.google.com ([2a00:1450:4013:c01::22c]:33346) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1ujz-0002Nw-4K for emacs-orgmode@gnu.org; Wed, 24 Jul 2013 04:48:11 -0400 Received: by mail-ea0-f172.google.com with SMTP id q10so83537eaj.31 for ; Wed, 24 Jul 2013 01:48:09 -0700 (PDT) In-Reply-To: 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 --001a11c3f60c0b9c0504e23df821 Content-Type: text/plain; charset=ISO-8859-1 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 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 > > > > > > --001a11c3f60c0b9c0504e23df821 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Rick, Hi S= ebastien,

thanks for your inputs.
Well I guess Sebast= ien 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-head= er-args=A0=A0=A0=A0=A0=A0=A0 | ((:session . "none") (:results . &= quot;replace") (:exports . "code") (:cache . "no")= (:noweb . "no") (:hlines . "no") (:tangle . "no&q= uot;) (:padnewline . "yes")) |
| org-babel-default-lob-header-args=A0=A0=A0 | ((:exports . "results&q= uot;))=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 |
| org-babel-default-inline-header-args | ((:session . = "none")(:results . "replace")(:exports . "results&= quot;))=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |

#+END_ORG

As you can see the most prominent cause fo= r trouble might be :hlines
As Rick should in his message it does s= till 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 fin= d this thread and might can give us some idea, whether there was an intenti= on in dealing with tables in that way or whether it is really considered as= a bug.

However, Sebastian pointed out a very important fact. Differ= ent default settings for different ways of calling a source code block. I b= elieve that this should find its way into the manual.

All the = best

Torsten




On 2= 2 July 2013 13:20, Torsten Wagner <torsten.wagner@gmail.com>= wrote:
Hi,

I want to summarize the proble= m I found, using tables as input to source code blocks.
This observation was shared with Rick and I would be glad to help fix= ing 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
Tor= sten


=A0

=


--001a11c3f60c0b9c0504e23df821--