[Babel][Bug] Inconsistent output from babel function depending on how called

[Babel][Bug] Inconsistent output from babel function depending on how called

[Ethan Ligon]

I'd like to call a simple babel code block to generate org-code
If I define a list thusly:

#+results: list1
 - foo
 - bar

Then I define a code block thusly, and execute it by C-c C-c on the
"source" line.  That yields the desired result: a sequence of headings
under "#+results: print_list".

#+source: print_list(lst=list1)
#+begin_src sh :results output org
  for i in $lst; do
    echo "* $i"
  done
#+end_src

#+results: print_list
#+BEGIN_ORG
* foo
* bar
#+END_ORG

Now I want to reuse the code block to generate other sequences of
headings.  But even if I call it with the *same* list, instead of the
desired headings, I get a literal, as below.

#+call: print_list(lst=list1)

#+results: print_list(lst=list1)
: * foo
: * bar

I think this qualifies as a bug---surely the method of calling the
code block shouldn't affect the output?

Thoughts, patches, or work-arounds welcomed!

Thanks,
-Ethan

-- 
Ethan Ligon, Associate Professor
Agricultural & Resource Economics
University of California, Berkeley

Re: [Babel][Bug] Inconsistent output from babel function depending on how called

[Eric Schulte]

Ethan Ligon <ligon@are.berkeley.edu> writes:

> I'd like to call a simple babel code block to generate org-code
> If I define a list thusly:
>
> #+results: list1
>  - foo
>  - bar
>
> Then I define a code block thusly, and execute it by C-c C-c on the
> "source" line.  That yields the desired result: a sequence of headings
> under "#+results: print_list".
>
> #+source: print_list(lst=list1)
> #+begin_src sh :results output org
>   for i in $lst; do
>     echo "* $i"
>   done
> #+end_src
>
> #+results: print_list
> #+BEGIN_ORG
> * foo
> * bar
> #+END_ORG
>
> Now I want to reuse the code block to generate other sequences of
> headings.  But even if I call it with the *same* list, instead of the
> desired headings, I get a literal, as below.
>
> #+call: print_list(lst=list1)
>
> #+results: print_list(lst=list1)
> : * foo
> : * bar
>
> I think this qualifies as a bug---surely the method of calling the
> code block shouldn't affect the output?
>

No, this is expected (if possibly under-documented behavior).  The
:results header arguments are associated with the code block and *not*
with the #+call line.  To get the desired behavior, you must specify the
:results header argument on the #+call: line thusly.

#+call: print_list(lst=list1) :results output org

Best -- Eric

>
> Thoughts, patches, or work-arounds welcomed!
>
> Thanks,
> -Ethan

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [Babel][Bug] Inconsistent output from babel function depending on how called

[Christian Moe]

> No, this is expected (if possibly under-documented behavior).  The
> :results header arguments are associated with the code block and *not*
> with the #+call line.  To get the desired behavior, you must specify the
> :results header argument on the #+call: line thusly.
>
> #+call: print_list(lst=list1) :results output org
>
> Best -- Eric

Hi,

I recently made the same mistake, and it took me a while to figure 
things out. I had assumed #+CALLs inherited all the header arguments 
from the code blocks they referenced.

Regarding documentation, I see now that the correct behavior is at 
least implicitly documented in the first example at 
[[info:org#Header%20arguments%20in%20function%20calls]].

It might rate an explicit explanation at 
[[info:org#Evaluating%20code%20blocks]] as well, though.

Yours,
Christian

Re: [Babel][Bug] Inconsistent output from babel function depending on how called

[Ethan Ligon]

On Thu, May 26, 2011 at 12:17 PM, Christian Moe <mail@christianmoe.com> wrote:
>> No, this is expected (if possibly under-documented behavior).  The
>> :results header arguments are associated with the code block and *not*
>> with the #+call line.  To get the desired behavior, you must specify the
>> :results header argument on the #+call: line thusly.
>>
>> #+call: print_list(lst=list1) :results output org
>>
>> Best -- Eric
>
> Hi,
>
> I recently made the same mistake, and it took me a while to figure things
> out. I had assumed #+CALLs inherited all the header arguments from the code
> blocks they referenced.
>
> Regarding documentation, I see now that the correct behavior is at least
> implicitly documented in the first example at
> [[info:org#Header%20arguments%20in%20function%20calls]].
>
> It might rate an explicit explanation at
> [[info:org#Evaluating%20code%20blocks]] as well, though.
>

I'd be happy to help with the documentation, but I still don't
understand the behavior.  It seems as though some arguments
to :results need to be supplied to the code block, but others have to
be supplied to the call.  In my situation, the "org" option
to :results has to be supplied to the call, while the "output" option
has to be supplied to the code block.

What's the logic?

Here's my setup:

#+results: list1
- Item1
- Item2


#+results: list2
- Item3
- Item4

#+source: print_list(lst)
#+begin_src sh
  for i in $lst; do
    echo "* $i"
  done
#+end_src

Here's a way of calling that works
#+call: print_list[:results output](lst=list1) :results org

#+results: print_list[:results output](lst=list1)
#+BEGIN_ORG
* Item1
* Item2
#+END_ORG

but this way of calling doesn't
#+call: print_list[:results output org](lst=list2)

#+results: print_list[:results output org](lst=list2)
: * Item3
: * Item4

and neither does this way
#+call: print_list[:results org](lst=list2) :results output

#+results: print_list[:results org](lst=list2)

or this way
#+call: print_list(lst=list2) :results output org

#+results: print_list(lst=list2)
#+END_ORG
#+BEGIN_ORG

Thanks for any enlightenment!
-Ethan

-- 
Ethan Ligon, Associate Professor
Agricultural & Resource Economics
University of California, Berkeley

Re: [Babel][Bug] Inconsistent output from babel function depending on how called

[Eric Schulte]

Ethan Ligon <ligon@are.berkeley.edu> writes:

> On Thu, May 26, 2011 at 12:17 PM, Christian Moe <mail@christianmoe.com> wrote:
>>> No, this is expected (if possibly under-documented behavior).  The
>>> :results header arguments are associated with the code block and *not*
>>> with the #+call line.  To get the desired behavior, you must specify the
>>> :results header argument on the #+call: line thusly.
>>>
>>> #+call: print_list(lst=list1) :results output org
>>>
>>> Best -- Eric
>>
>> Hi,
>>
>> I recently made the same mistake, and it took me a while to figure things
>> out. I had assumed #+CALLs inherited all the header arguments from the code
>> blocks they referenced.
>>
>> Regarding documentation, I see now that the correct behavior is at least
>> implicitly documented in the first example at
>> [[info:org#Header%20arguments%20in%20function%20calls]].
>>
>> It might rate an explicit explanation at
>> [[info:org#Evaluating%20code%20blocks]] as well, though.
>>
>
> I'd be happy to help with the documentation, but I still don't
> understand the behavior.  It seems as though some arguments
> to :results need to be supplied to the code block, but others have to
> be supplied to the call.  In my situation, the "org" option
> to :results has to be supplied to the call, while the "output" option
> has to be supplied to the code block.
>
> What's the logic?
>
> Here's my setup:
>
> #+results: list1
> - Item1
> - Item2
>
>
> #+results: list2
> - Item3
> - Item4
>
> #+source: print_list(lst)
> #+begin_src sh
>   for i in $lst; do
>     echo "* $i"
>   done
> #+end_src
>
> Here's a way of calling that works
> #+call: print_list[:results output](lst=list1) :results org
>
> #+results: print_list[:results output](lst=list1)
> #+BEGIN_ORG
> * Item1
> * Item2
> #+END_ORG
>
> but this way of calling doesn't
> #+call: print_list[:results output org](lst=list2)
>
> #+results: print_list[:results output org](lst=list2)
> : * Item3
> : * Item4
>
> and neither does this way
> #+call: print_list[:results org](lst=list2) :results output
>
> #+results: print_list[:results org](lst=list2)
>
> or this way
> #+call: print_list(lst=list2) :results output org
>
> #+results: print_list(lst=list2)
> #+END_ORG
> #+BEGIN_ORG
>
> Thanks for any enlightenment!
> -Ethan

Hi Ethan,

There are two different places for specifying header argument in a
#+call line, these places are marked with XXXX and YYYY in the
following, both are optional...

  #+call: code_bloc_name[XXXX](arguments) YYYY

Header arguments located in these two locations are treated differently.

- XXXX :: Those placed in the XXXX location are passed through and
     applied to the code block being called.  These header arguments
     affect how the code block is evaluated, for example [:results
     output] will collect the results from STDOUT of the called code
     block.

- YYYY :: Those placed in the YYYY location are applied to the call line
     and do not affect the code block being called.  These header
     arguments affect how the results are incorporated into the Org-mode
     buffer when the #+call line is evaluated, and how the #+call line
     is exported.  For example ":results org" at the end of the call
     line will insert the results of the call line in an Org-mode block.

Is this more clear?  Is there a way it can be made more straightforward?
If the above seems reasonable then I can add it to the documentation.

Thanks -- Eric

Re: [Babel][Bug] Inconsistent output from babel function depending on how called

[Eric Schulte]

Christian Moe <mail@christianmoe.com> writes:

>> No, this is expected (if possibly under-documented behavior).  The
>> :results header arguments are associated with the code block and *not*
>> with the #+call line.  To get the desired behavior, you must specify the
>> :results header argument on the #+call: line thusly.
>>
>> #+call: print_list(lst=list1) :results output org
>>
>> Best -- Eric
>
> Hi,
>
> I recently made the same mistake, and it took me a while to figure
> things out. I had assumed #+CALLs inherited all the header arguments
> from the code blocks they referenced.
>
> Regarding documentation, I see now that the correct behavior is at
> least implicitly documented in the first example at
> [[info:org#Header%20arguments%20in%20function%20calls]].
>
> It might rate an explicit explanation at
> [[info:org#Evaluating%20code%20blocks]] as well, though.
>
> Yours,
> Christian

I've just updated the documentation at the following to reflect the full
range of #+call line header argument options.

#+begin_src emacs-lisp
  (info "(org)Evaluating code blocks")
#+end_src

Thanks for the recommendation -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [Babel][Bug] Inconsistent output from babel function depending on how called

[Ethan Ligon]

So, the ":result output org" ought to be associated with the *call*,
not with the function.  That makes good sense.  But perhaps it still
doesn't work quite as it ought...

On Thu, May 26, 2011 at 11:46 AM, Eric Schulte <schulte.eric@gmail.com> wrote:
> Ethan Ligon <ligon@are.berkeley.edu> writes:
>
>> I'd like to call a simple babel code block to generate org-code
>> If I define a list thusly:
>>
>> #+results: list1
>>  - foo
>>  - bar
>>
>> Then I define a code block thusly, and execute it by C-c C-c on the
>> "source" line.  That yields the desired result: a sequence of headings
>> under "#+results: print_list".
>>
>> #+source: print_list(lst=list1)
>> #+begin_src sh :results output org
>>   for i in $lst; do
>>     echo "* $i"
>>   done
>> #+end_src
>>
>> #+results: print_list
>> #+BEGIN_ORG
>> * foo
>> * bar
>> #+END_ORG
>>
>> Now I want to reuse the code block to generate other sequences of
>> headings.  But even if I call it with the *same* list, instead of the
>> desired headings, I get a literal, as below.
>>
>> #+call: print_list(lst=list1)
>>
>> #+results: print_list(lst=list1)
>> : * foo
>> : * bar
>>
>> I think this qualifies as a bug---surely the method of calling the
>> code block shouldn't affect the output?
>>
>
> No, this is expected (if possibly under-documented behavior).  The
> :results header arguments are associated with the code block and *not*
> with the #+call line.  To get the desired behavior, you must specify the
> :results header argument on the #+call: line thusly.
>
> #+call: print_list(lst=list1) :results output org
>

If I do this, I get
#+results: print_list(lst=list1)
#+END_ORG
#+BEGIN_ORG

which is surprising first because there's no proper output, but also
because the end and begin tags are reversed (!).

What *does* work is to omit the "output" header argument.
#+call: print_list(lst=list1) :results org

#+results: print_list(lst=list1)
#+BEGIN_ORG
* foo
* bar
#+END_ORG

So now I definitely have a good work-around, but still think there's a
bug.

Thanks,
-Ethan

-- 
Ethan Ligon, Associate Professor
Agricultural & Resource Economics
University of California, Berkeley

Re: [Babel][Bug] Inconsistent output from babel function depending on how called

[Eric Schulte]

Ethan Ligon <ligon@are.berkeley.edu> writes:

> So, the ":result output org" ought to be associated with the *call*,
> not with the function.  That makes good sense.  But perhaps it still
> doesn't work quite as it ought...
>
> On Thu, May 26, 2011 at 11:46 AM, Eric Schulte <schulte.eric@gmail.com> wrote:
>> Ethan Ligon <ligon@are.berkeley.edu> writes:
>>
>>> I'd like to call a simple babel code block to generate org-code
>>> If I define a list thusly:
>>>
>>> #+results: list1
>>>  - foo
>>>  - bar
>>>
>>> Then I define a code block thusly, and execute it by C-c C-c on the
>>> "source" line.  That yields the desired result: a sequence of headings
>>> under "#+results: print_list".
>>>
>>> #+source: print_list(lst=list1)
>>> #+begin_src sh :results output org
>>>   for i in $lst; do
>>>     echo "* $i"
>>>   done
>>> #+end_src
>>>
>>> #+results: print_list
>>> #+BEGIN_ORG
>>> * foo
>>> * bar
>>> #+END_ORG
>>>
>>> Now I want to reuse the code block to generate other sequences of
>>> headings.  But even if I call it with the *same* list, instead of the
>>> desired headings, I get a literal, as below.
>>>
>>> #+call: print_list(lst=list1)
>>>
>>> #+results: print_list(lst=list1)
>>> : * foo
>>> : * bar
>>>
>>> I think this qualifies as a bug---surely the method of calling the
>>> code block shouldn't affect the output?
>>>
>>
>> No, this is expected (if possibly under-documented behavior).  The
>> :results header arguments are associated with the code block and *not*
>> with the #+call line.  To get the desired behavior, you must specify the
>> :results header argument on the #+call: line thusly.
>>
>> #+call: print_list(lst=list1) :results output org
>>
>
> If I do this, I get
> #+results: print_list(lst=list1)
> #+END_ORG
> #+BEGIN_ORG
>
> which is surprising first because there's no proper output, but also
> because the end and begin tags are reversed (!).
>
> What *does* work is to omit the "output" header argument.
> #+call: print_list(lst=list1) :results org
>
> #+results: print_list(lst=list1)
> #+BEGIN_ORG
> * foo
> * bar
> #+END_ORG
>
> So now I definitely have a good work-around, but still think there's a
> bug.
>

Well yes and no...

There is a bug here, but not in the interpretation of the header
arguments... the interpretation is just so non-intuitive that I also
misunderstood the resulting behavior in my earlier reply.

In the example of

  #+call: print_list(lst=list1) :results output org

both the "org" and "output" header arguments are applied to the call
line, when in fact the output header argument should be applied to the
list1 code block (not the call line).  The results of applying the
"output" header argument to the call line is to return no results (which
makes sense because the call line does not print to STDOUT).  The
correct form of the above would be as follows (explicitly passing the
"output" header argument to the list1 code block)

  #+call: list1[:results output](lst="~/Desktop") :results org

  #+results: list1[:results output](lst="~/Desktop")
  #+BEGIN_ORG
  * ~/Desktop
  #+END_ORG

There is an error however in that when no results are returned the
begin/end parts of the Org-mode code block are flipped...

>
> Thanks,
> -Ethan

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/