From: Eric Schulte <schulte.eric@gmail.com>
To: Torsten Wagner <torsten.wagner@gmail.com>
Cc: Org Mode Mailing List <emacs-orgmode@gnu.org>
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 [thread overview]
Message-ID: <87y58voaa7.fsf@gmail.com> (raw)
In-Reply-To: CAPaq-gPE_+7X8i+vgTKcemCOfqoxMj00MoaZM3-4UZxb2NN2JA@mail.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
next prev parent reply other threads:[~2013-07-24 22:39 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
2013-07-24 8:48 ` Torsten Wagner
2013-07-24 22:30 ` Eric Schulte [this message]
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=87y58voaa7.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=torsten.wagner@gmail.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).