From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks Date: Wed, 24 Jul 2013 16:30:42 -0600 Message-ID: <87y58voaa7.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49645) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V27iA-0008CK-Af for emacs-orgmode@gnu.org; Wed, 24 Jul 2013 18:39:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V27i8-0006Ry-L1 for emacs-orgmode@gnu.org; Wed, 24 Jul 2013 18:39:10 -0400 Received: from mail-pd0-x231.google.com ([2607:f8b0:400e:c02::231]:58639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V27i8-0006R1-Ej for emacs-orgmode@gnu.org; Wed, 24 Jul 2013 18:39:08 -0400 Received: by mail-pd0-f177.google.com with SMTP id u11so916539pdi.36 for ; Wed, 24 Jul 2013 15:39:07 -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: Torsten Wagner Cc: Org Mode Mailing List Torsten Wagner writes: > 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. > This is related to http://thread.gmane.org/gmane.emacs.orgmode/73976/focus=74175. > > 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. > Yes, I've been very busy. > > 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. > I'm happy to apply patches to 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 >> >> >> >> >> >> -- Eric Schulte http://cs.unm.edu/~eschulte