From: Eric Schulte <schulte.eric@gmail.com>
To: Herbert Sitz <hsitz@nwlink.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: org-babel -- Improper syntax error in session mode?
Date: Tue, 21 Jun 2011 10:26:17 -0700 [thread overview]
Message-ID: <871uynkqjq.fsf@gmail.com> (raw)
In-Reply-To: loom.20110621T062744-164@post.gmane.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 <hsitz@nwlink.com> writes:
> Eric Schulte <schulte.eric <at> 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/
next prev parent reply other threads:[~2011-06-21 18:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-19 21:54 org-babel -- Improper syntax error in session mode? Herbert Sitz
2011-06-19 23:21 ` Eric Schulte
2011-06-20 1:59 ` Herbert Sitz
2011-06-20 2:12 ` Herbert Sitz
2011-06-20 3:17 ` Nick Dokos
2011-06-20 3:46 ` Herbert Sitz
2011-06-20 19:23 ` Eric Schulte
2011-06-20 20:45 ` Herbert Sitz
2011-06-20 21:15 ` Eric Schulte
2011-06-20 23:16 ` Herbert Sitz
2011-06-21 0:08 ` Nick Dokos
2011-06-21 0:27 ` Herbert Sitz
[not found] ` <hesitz@gmail.com>
2011-06-21 1:17 ` Nick Dokos
2011-06-21 2:19 ` Eric Schulte
2011-06-21 5:13 ` Herbert Sitz
2011-06-21 7:15 ` Thomas S. Dye
2011-06-21 15:35 ` Herbert Sitz
2011-06-21 16:27 ` Thomas S. Dye
2011-06-21 17:42 ` Eric Schulte
2011-06-21 17:51 ` Herbert Sitz
2011-06-21 17:52 ` Eric Schulte
2011-06-27 18:09 ` Herbert Sitz
2011-06-21 17:26 ` Eric Schulte [this message]
2011-06-27 18:22 ` Herbert Sitz
2011-06-20 21:18 ` Jambunathan K
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871uynkqjq.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=hsitz@nwlink.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).