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 05:13:17 +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]:43683) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYtHI-0007jn-8T for emacs-orgmode@gnu.org; Tue, 21 Jun 2011 01:13:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QYtHG-0002tB-KL for emacs-orgmode@gnu.org; Tue, 21 Jun 2011 01:13:32 -0400 Received: from lo.gmane.org ([80.91.229.12]:48675) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYtHG-0002t7-5m for emacs-orgmode@gnu.org; Tue, 21 Jun 2011 01:13:30 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QYtHF-0004e0-5j for emacs-orgmode@gnu.org; Tue, 21 Jun 2011 07:13:29 +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 07:13:29 +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 07:13:29 +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 Eric Schulte gmail.com> writes: > > Babel sessions explicitly are thin wrappers around the interactive mode > of the language in question (whatever that may be). That is why Babel > happily doesn't implement sessions for all languages, the contract > simply is that if a language supports interactive evaluation, Babel will > try to allow access to that functionality. > That the Babel session is only a "thin" wrapper is not clear at all from the docs. The docs do mention 'interactive session'--and even that the output may be slightly different from the non-session mode. The docs don't mention anything about the user needing to do extra preparation to avoid syntax errors in evaluation of already valid code. If I take an existing Org block of non-session code and stick a :session on I don't expect to get syntax errors. If that's the expected behavior then it needs to be emphasized more in the docs, otherwise most users will think something is broken in Org. > If the contract was rather simply "Babel provides session based > evaluation", then we'd be on the hook for implementing session > evaluation where it doesn't already exist and may not make sense (e.g., > C, ditaa), and normalizing everywhere else as you're suggesting here. > Which would in turn requires us to spell out Babel-specific semantics of > session based evaluation -- something we have thus-far avoided. Again, the docs reference 'Session based evaluation' in big bold letters and don't indicate the thinness of the wrapper. > > Some positive points *for* the "thin wrapper" approach include; > > 1. It is the simplest to implement > - easier to implement support for new language > - easier to maintain -- especially if interactive tools change > - easier to reason about -- thinking about bug fixing here > - works with alternate back-ends e.g., ipython > I think I have a solution for Python that gives full "session-based evaluation" and which is better than the current "thin wrapper" for all four concerns above (See bottom of my message for an example.) This same approach, I think, would work for Ruby, but I would need to do a little digging to find exact method. Let me know if you want me to do that digging. > 2. It is the least surprising. I'd maintain that for users familiar > with using Python sessions this behavior is the easiest to quickly > understand and use. As opposed to if we did something fancy (even if > it was an improvement) it would be another environment for language > users to have to familiarize themselves with -- they'd have both > normal session rules and babel session rules As a sometimes Python user it had me totally confused. I don't think of "session-based" as having any essential tie to "interactive shell" at all. Why would I worry about state being maintained between statements in an org block? State is already maintained between statements in non-session Org blocks. The only difference with session-based blocks is the starting state may not be "fresh". When I look at Org and think of "session-based" blocks, I see a potential big benefit in having multiple source-blocks throughout my document share the same session. That way I don't need to use Org's (clever and useful but) somewhat clunky and inflexible method of passing data explicitly. In statistics-based docs, for example, I can imagine that the sheer amount of data would make using Org's explicit variable-passing method unfeasible. Using session-based-evaluation is at the same time both simpler and more heavy-duty. I never thought the use of session-based code blocks as something like a scratchpad was much more than toy. If you're typing in code that's not intended to be an integral part of an Org doc then you could just as well jump to the shell and enter it there. Here's an example of how to run a block of Python code of any length in the interactive session and save its output in a file. Note that this is _not_ interactive, even though the command runs in the interactive shell's session: Start with this block of code: ------------------------------------- #+begin_src python :results output :session mypy x = 1 y = 1 z = 1 for i in range(1,2): x = x + i print x for y in range(10,11): print y # comment here for z in range(5,6): print z while y > 0: print y y=y-1 print "Did it work?" #+end_src ------------------------------------ Strip out the block of empty space at the left side and save in a file in current directory (say, 'pyfile.py') with a couple commands prepended and appended: ----------------------------- # beginning of file # prepend code to redirect stdout to file import sys saveout = sys.stdout fsock = open('pyfile-output.log','w') sys.stdout = fsock # code block here, with beginning space block removed x = 1 y = 1 z = 1 for i in range(1,2): x = x + i print x for y in range(10,11): print y # comment here for z in range(5,6): print z while y > 0: print y y=y-1 print "Did it work?" # end of the org source code block # return stdout to what it was sys.stdout = saveout # and close the log file fsock.close() # end of file ---------------------------- Now you can go into the python shell and execute the code in pyfile.py: >>> execfile('pyfile.py') The output will be saved in the log file in the working directory. I think it should be exactly the same as the output from the non-session based code (assuming the session-based code started from a fresh session). -- Herb