From mboxrd@z Thu Jan 1 00:00:00 1970 From: tsd@tsdye.com (Thomas S. Dye) Subject: Re: Babel: communicating irregular data to R source-code block Date: Mon, 23 Apr 2012 09:17:55 -1000 Message-ID: References: <1335039472.9075.YahooMailNeo@web161901.mail.bf1.yahoo.com> <87ipgrn4by.fsf@gmx.com> <87ehrexxpr.fsf@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([208.118.235.92]:59183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SMOm3-00080p-6n for emacs-orgmode@gnu.org; Mon, 23 Apr 2012 15:18:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SMOm1-0001YT-6F for emacs-orgmode@gnu.org; Mon, 23 Apr 2012 15:18:10 -0400 Received: from oproxy8-pub.bluehost.com ([69.89.22.20]:53787) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1SMOm0-0001Y1-Ss for emacs-orgmode@gnu.org; Mon, 23 Apr 2012 15:18:09 -0400 In-Reply-To: <87ehrexxpr.fsf@gmx.com> (Eric Schulte's message of "Mon, 23 Apr 2012 11:41:04 -0400") 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 Eric Schulte 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