Re: [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks

[Eric Schulte <schulte.eric@gmail.com>]

Torsten Wagner <torsten.wagner@gmail.com> 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 <torsten.wagner@gmail.com> 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