From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: org-babel -- Improper syntax error in session mode? Date: Tue, 21 Jun 2011 10:26:17 -0700 Message-ID: <871uynkqjq.fsf@gmail.com> 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 Return-path: Received: from eggs.gnu.org ([140.186.70.92]:38595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ5LF-0006tJ-DS for emacs-orgmode@gnu.org; Tue, 21 Jun 2011 14:06:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZ5LC-0002Mt-KR for emacs-orgmode@gnu.org; Tue, 21 Jun 2011 14:06:25 -0400 Received: from mail-pw0-f41.google.com ([209.85.160.41]:44782) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ5LC-0002Mk-7q for emacs-orgmode@gnu.org; Tue, 21 Jun 2011 14:06:22 -0400 Received: by pwi12 with SMTP id 12so138081pwi.0 for ; Tue, 21 Jun 2011 11:06:21 -0700 (PDT) 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: Herbert Sitz Cc: emacs-orgmode@gnu.org Hi Herb, I think we're agreed that the documentation should be updated, which I've just done. As for your proposed solution. You are suggesting that code to be run "interactively" should be written to an external file then loaded into the interactive session. This would certainly work around the syntax limitation of the current setup. My two concerns here are that 1. users who use interactive babel blocks side-by-side with the session may be used jumping into the session to play with code interactively and debug, in such cases rather than seeing their code in the session history they would only see execfile('/tmp/blahblah'). Note I do recall discussion on list related to user's reading their session code in the inferior session buffer. 2. similarly error messages would now point into this temporary file, rather than back into the session history Basically you would prefer more decoupling from the interpreter and I'm not sure for the average user if this would be a worthwhile exchange simply to be able to avoid syntax errors like your originally mentioned example (which was the first such post I've seen on this list). I'm disinclined to make such a change without a wider base of support for the request from the Babel/Python user community -- or at least without more complaints about the existing behavior. Best -- Eric Herbert Sitz writes: > 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 > > > > -- Eric Schulte http://cs.unm.edu/~eschulte/