From mboxrd@z Thu Jan 1 00:00:00 1970 From: Herbert Sitz Subject: Re: org-babel -- Improper syntax error in session mode? Date: Tue, 21 Jun 2011 15:35:28 +0000 (UTC) Message-ID: References: <87k4chwgpa.fsf@gmail.com> <23747.1308539849@alphaville.dokosmarshall.org> <87ei2ouwxk.fsf@gmail.com> <87aadcxl05.fsf@gmail.com> <87fwn4vsd6.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([140.186.70.92]:43641) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ2zT-0006bZ-C2 for emacs-orgmode@gnu.org; Tue, 21 Jun 2011 11:35:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZ2zR-0008AM-23 for emacs-orgmode@gnu.org; Tue, 21 Jun 2011 11:35:47 -0400 Received: from lo.gmane.org ([80.91.229.12]:50807) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ2zQ-0008AC-Lp for emacs-orgmode@gnu.org; Tue, 21 Jun 2011 11:35:45 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QZ2zO-0003uH-Eb for emacs-orgmode@gnu.org; Tue, 21 Jun 2011 17:35:42 +0200 Received: from c-24-22-131-140.hsd1.wa.comcast.net ([24.22.131.140]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Jun 2011 17:35:42 +0200 Received: from hsitz by c-24-22-131-140.hsd1.wa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Jun 2011 17:35:42 +0200 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: emacs-orgmode@gnu.org Thomas S. Dye tsdye.com> writes: > > Aloha Herbert, > > I think you're right about the potential to improve the documentation. > That's an on-going process. Could you suggest some specific changes? > > All the best, > Tom Tom -- I would suggest just adding specific warnings that session-based evaluation may throw syntax errors with valid code. Here's what Org manual says regarding :session evaluation with :results output': "The code is passed to the interpreter running as an interactive Emacs inferior process. The result returned is the concaOrg tenation of the sequence of (text) output from the interactive interpreter. Notice that this is not necessarily the same as what would be sent to STDOUT if the same code were passed to a non-interactive interpreter running as an external process. . . ." [http://orgmode.org/manual/Results-of-evaluation.html#Results-of-evaluation] All that needs to be added is a warning: "IMPORTANT: Note that Org provides only a thin wrapper around a language's interactive shell, so valid code that executes properly in non-session mode may fail in :session mode. This is because Org feeds the lines in a :session block to the interactive interpreter exactly as written. In come cases the lines may require special formatting in the source block to be executed properly in the interactive shell. For example: . . . " I think the above issue should be moot for some of the main interpreted languages (viz., Python, Perl, Ruby) where there are various ways to execute a block of code non-interactively despite being in the interactive shell. (One of those methods is the example I gave in previous message.) In that case identical code will run the same whether it's in an interactive-interpreter session or not. It seems to me that switching to that approach for languages that support it should both (1) simplify the Org Babel code, and (2) provide Org users with more flexibility and power. Also, it seems the real power of :session evaluation is to share state between Org/Babel source code blocks, not merely to act as a kind of Org-internal scratchpad. As a user trying to take advantage of that state-sharing power I would generally want my Org document exports to start from fresh sessions. That is, I would write my :session blocks so that they depended on results of code run in previous :session blocks, BUT I would want the first :session block to start with a fresh session,with a known state. So on export I would generally want any existing named session to be closed and restarted anew for an Org export. I hope that all makes sense. I should say I'm not a big Babel user, and I could easily be misunderstanding something. But it seems this is the way the :session-based stuff should work, when possible. -- Herb