From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: Babel: communicating irregular data to R source-code block Date: Mon, 23 Apr 2012 11:41:04 -0400 Message-ID: <87ehrexxpr.fsf@gmx.com> References: <1335039472.9075.YahooMailNeo@web161901.mail.bf1.yahoo.com> <87ipgrn4by.fsf@gmx.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:51023) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SMNGT-0006e8-MT for emacs-orgmode@gnu.org; Mon, 23 Apr 2012 13:41:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SMNGM-0006SI-Ir for emacs-orgmode@gnu.org; Mon, 23 Apr 2012 13:41:29 -0400 Received: from mailout-us.gmx.com ([74.208.5.67]:38460) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1SMNGM-0006Ru-D9 for emacs-orgmode@gnu.org; Mon, 23 Apr 2012 13:41:22 -0400 In-Reply-To: (Thomas S. Dye's message of "Mon, 23 Apr 2012 06:46:50 -1000") 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: "Thomas S. Dye" Cc: Michael Hannon , Org-Mode List [...] > > I'm beginning to see why you have strong feelings about python. Semantically meaningful whitespace is a bad idea for a programming langauge. > 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. 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 | -- Eric Schulte http://cs.unm.edu/~eschulte/