emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: tsd@tsdye.com (Thomas S. Dye)
To: Eric Schulte <eric.schulte@gmx.com>
Cc: Org-mode <emacs-orgmode@gnu.org>
Subject: Re: Babel: communicating irregular data to R source-code block
Date: Mon, 23 Apr 2012 09:17:55 -1000	[thread overview]
Message-ID: <m1pqayz28s.fsf@tsdye.com> (raw)
In-Reply-To: <87ehrexxpr.fsf@gmx.com> (Eric Schulte's message of "Mon, 23 Apr 2012 11:41:04 -0400")

Eric Schulte <eric.schulte@gmx.com> writes:

> [...]
>>
>> I'm beginning to see why you have strong feelings about python.
>
> Semantically meaningful whitespace is a bad idea for a programming
> langauge.
>

Yes, this makes sense to me.  I suppose I should wean myself from python
now that I use babel as a "glue language."

>> In the code above, the blank line before #+end_src is necessary and
>> must not contain any spaces, and :var n can be set to anything, since
>> it is declared for initialization only.
>>
>> The code in the JSS article doesn't run for me with a recent Org-mode
>> unless I add a blank line before #+end_src, or remove the :return header
>> argument.  If I remove the :return header argument, then the need for
>> the blank line goes away.  The following code block seems to work:
>>
>> #+name: pascals-triangle
>> #+begin_src python :var n=2 :exports none
>> def pascals_triangle(n):
>>     if n == 0:
>>         return [[1]]
>>     prev_triangle = pascals_triangle(n-1)
>>     prev_row = prev_triangle[n-1]
>>     this_row = map(sum, zip([0] + prev_row, prev_row + [0]))
>>     return prev_triangle + [this_row]
>> return pascals_triangle(n)
>> #+end_src
>>
>> #+RESULTS: pascals-triangle
>>
>> | 1 |   |   |
>> | 1 | 1 |   |
>> | 1 | 2 | 1 |
>>
>> I'm guessing that the need for a blank line when using :results has
>> arisen since the JSS article was published, because the article was
>> generated from source code and didn't show any errors.  
>>
>
> I believe that we used to pad code blocks with newlines when they were
> extracted from the buffer, which had the effect of automatically adding
> this extra line.  This behavior however caused problems in some cases
> where the extra line was not desired.
>
>>
>> If I have this right (a big if), then might it be possible to
>> re-establish the old behavior so the JSS code works?  
>>
>
> I've just pushed up a patch in which the addition of the return value in
> python is careful to add this newline itself.  This should restore the
> functionality of the python code from the paper (specifically the
> following now works [1]).  This is applied to the maint branch so
> hopefully it will sync with Emacs before the release of Emacs24.
>

Thanks Eric.  The source block in the paper returns the correct result
with the code in the maint branch.

All the best,
Tom

> Best,
>
>
> Footnotes: 
> [1]  
>
> #+name: pascals-triangle
> #+begin_src python :var n=2 :exports none :return pascals_triangle(n)
> def pascals_triangle(n):
>     if n == 0:
>         return [[1]]
>     prev_triangle = pascals_triangle(n-1)
>     prev_row = prev_triangle[n-1]
>     this_row = map(sum, zip([0] + prev_row, prev_row + [0]))
>     return prev_triangle + [this_row]
> #+end_src
>
> #+RESULTS: pascals-triangle
>
> | 1 |   |   |
> | 1 | 1 |   |
> | 1 | 2 | 1 |

-- 
Thomas S. Dye
http://www.tsdye.com

  reply	other threads:[~2012-04-23 19:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-21 20:17 Babel: communicating irregular data to R source-code block Michael Hannon
2012-04-22  0:44 ` Thomas S. Dye
2012-04-22 15:58   ` Eric Schulte
2012-04-23 16:46     ` Thomas S. Dye
2012-04-23 15:41       ` Eric Schulte
2012-04-23 19:17         ` Thomas S. Dye [this message]
2012-04-23 22:24     ` Michael Hannon
2012-04-23 21:05       ` Eric Schulte
2012-04-24  0:23       ` Thomas S. Dye
2012-04-23 22:55         ` Eric Schulte
2012-04-24  6:44           ` Thomas S. Dye
2012-04-24  7:07             ` Michael Hannon
2012-04-24 17:18               ` Thomas S. Dye
2012-04-24 19:23                 ` Thomas S. Dye
2012-04-25 23:52               ` Thomas S. Dye
2012-04-26  2:06                 ` Michael Hannon
2012-04-26  6:34                   ` Thomas S. Dye

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=m1pqayz28s.fsf@tsdye.com \
    --to=tsd@tsdye.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=eric.schulte@gmx.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).