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: Thu, 25 Jul 2013 13:40:23 +0200 Message-ID: References: <87y58voaa7.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=001a11c367d6e3910204e2547d2b Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47605) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2JuF-00075T-Qm for emacs-orgmode@gnu.org; Thu, 25 Jul 2013 07:40:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2JuD-0008L9-Kl for emacs-orgmode@gnu.org; Thu, 25 Jul 2013 07:40:27 -0400 Received: from mail-ea0-x231.google.com ([2a00:1450:4013:c01::231]:37980) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2JuD-0008Ky-B6 for emacs-orgmode@gnu.org; Thu, 25 Jul 2013 07:40:25 -0400 Received: by mail-ea0-f177.google.com with SMTP id f10so289123eak.22 for ; Thu, 25 Jul 2013 04:40:24 -0700 (PDT) In-Reply-To: <87y58voaa7.fsf@gmail.com> 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: Eric Schulte Cc: Org Mode Mailing List --001a11c367d6e3910204e2547d2b Content-Type: multipart/alternative; boundary=001a11c367d6e390fd04e2547d29 --001a11c367d6e390fd04e2547d29 Content-Type: text/plain; charset=ISO-8859-1 Dear Eric, please find attached a patch, to describe the different standard values for system-wide header arguments in the manual. Hope that might help to avoid confusion in the future. All the best Torsten On 25 July 2013 00:30, Eric Schulte wrote: > 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 > --001a11c367d6e390fd04e2547d29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Eric,

please find at= tached a patch, to describe the different standard values for system-wide h= eader arguments in the manual.
Hope that might help to avoid confu= sion in the future.

All the best

Torsten


On 25 July 2013 00:30, Eric Schulte= <schulte.eric@gmail.com> wrote:
Torsten Wagner <torsten.wagner@gmail.com> write= s:

> Hi Rick, Hi Sebastien,
>
> thanks for your inputs.
> Well I guess Sebastien is half-right. The different settings make at l= east
> 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 =A0 =A0 =A0 =A0| ((:session . "no= ne") (:results .
> "replace") (:exports . "code") (:cache . "no&= quot;) (:noweb . "no") (:hlines .
> "no") (:tangle . "no") (:padnewline . "yes&qu= ot;)) |
> | org-babel-default-lob-header-args =A0 =A0| ((: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= =3D74175.

>
> 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 defaul= t
> 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 =A0wit= h 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=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. 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 fi= rst 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 table= s in
>> python is list for the entire table, however, indexing a table wit= h 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

--001a11c367d6e390fd04e2547d29-- --001a11c367d6e3910204e2547d2b Content-Type: application/octet-stream; name="babel_standard_header_settings_doc.patch" Content-Disposition: attachment; filename="babel_standard_header_settings_doc.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hjjw35vc0 ZGlmZiAtLWdpdCBhL2RvYy9vcmcudGV4aSBiL2RvYy9vcmcudGV4aQppbmRleCA1NWM0MjFkLi5k ODk4N2Q2IDEwMDY0NAotLS0gYS9kb2Mvb3JnLnRleGkKKysrIGIvZG9jL29yZy50ZXhpCkBAIC0x NDA2Niw2ICsxNDA2NiwxNiBAQCBibG9ja3MuCiAgICAgICAgICAgICAoYXNzcS1kZWxldGUtYWxs IDpub3dlYiBvcmctYmFiZWwtZGVmYXVsdC1oZWFkZXItYXJncykpKQogQGVuZCBsaXNwCiAKK1Ro ZSBkaWZmZXJlbnQgd2F5cyBvZiBjYWxsaW5nIGEgc291cmNlIGNvZGUgYmxvY2sgbWlnaHQgY29t ZSB3aXRoIGRpZmZlcmVudCBzeXN0ZW0td2lkZSB2YWx1ZXMgb2YgaGVhZGVyIGFyZ3VtZW50cy4K K1RodXMsIHRoZSBiZWhhdmlvdXIgb2YgYSBzb3VyY2UgY29kZSBibG9jayBtaWdodCBkaWZmZXIs IGRlcGVuZGluZyBvbiB0aGUgd2F5IGhvdyBpdCB3YXMgY2FsbGVkLiBUaGUgdGFibGUgYmVsb3cg ZGVwaWN0cyB0aGUgdmFyaWFibGVzIGFuZCBzdGFuZGFyZCB2YWx1ZXMgZm9yIHRoZSBkaWZmZXJl bnQgd2F5cyB0byBleGVjdXRlIGEgc291cmNlIGNvZGUgYmxvY2suCisKK0BtdWx0aXRhYmxlIEBj b2x1bW5mcmFjdGlvbnMgMC4xIDAuMSAwLjMgCitAaXRlbSBAYntNZXRob2R9IEB0YWIgQGJ7VmFy aWFibGV9IEB0YWIgQGJ7VmFsdWVzfQorQGl0ZW0gc291cmNlIGNvZGUgYmxvY2sgQHRhYiBvcmct YmFiZWwtZGVmYXVsdC1oZWFkZXItYXJncyAgQHRhYiA6c2Vzc2lvbiAibm9uZSIsIDpyZXN1bHRz ICJyZXBsYWNlIiwgOmV4cG9ydHMgImNvZGUiLCA6Y2FjaGUgIm5vIiwgOm5vd2ViICJubyIsIDpo bGluZXMgIm5vIiwgOnRhbmdsZSAibm8iLCA6cGFkbmV3bGluZSAieWVzIgorQGl0ZW0gaW5saW5l IGNhbGwgICAgICAgICAgIEB0YWIgIG9yZy1iYWJlbC1kZWZhdWx0LWlubGluZS1oZWFkZXItYXJn cyAgQHRhYiAgOmV4cG9ydHMgInJlc3VsdHMiCitAaXRlbSBmdW5jdGlvbiBjYWxscyAgICAgICAg QHRhYiAgb3JnLWJhYmVsLWRlZmF1bHQtbG9iLWhlYWRlci1hcmdzICAgICAgQHRhYiA6c2Vzc2lv biAibm9uZSIsIDpyZXN1bHRzICJyZXBsYWNlIiwgOmV4cG9ydHMgInJlc3VsdHMiCitAZW5kIG11 bHRpdGFibGUKKwogQG5vZGUgTGFuZ3VhZ2Utc3BlY2lmaWMgaGVhZGVyIGFyZ3VtZW50cywgSGVh ZGVyIGFyZ3VtZW50cyBpbiBPcmcgbW9kZSBwcm9wZXJ0aWVzLCBTeXN0ZW0td2lkZSBoZWFkZXIg YXJndW1lbnRzLCBVc2luZyBoZWFkZXIgYXJndW1lbnRzCiBAc3Vic3ViaGVhZGluZyBMYW5ndWFn ZS1zcGVjaWZpYyBoZWFkZXIgYXJndW1lbnRzCiBFYWNoIGxhbmd1YWdlIGNhbiBkZWZpbmUgaXRz IG93biBzZXQgb2YgZGVmYXVsdCBoZWFkZXIgYXJndW1lbnRzIGluIHZhcmlhYmxlCg== --001a11c367d6e3910204e2547d2b--