From: tsd@tsdye.com (Thomas S. Dye)
To: Herbert Sitz <hsitz@nwlink.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: org-babel -- Improper syntax error in session mode?
Date: Mon, 20 Jun 2011 21:15:32 -1000 [thread overview]
Message-ID: <m1ei2nvenf.fsf@tsdye.com> (raw)
In-Reply-To: <loom.20110621T062744-164@post.gmane.org> (Herbert Sitz's message of "Tue, 21 Jun 2011 05:13:17 +0000 (UTC)")
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
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
>
>
>
>
>
--
Thomas S. Dye
http://www.tsdye.com
next prev parent reply other threads:[~2011-06-21 7:15 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 [this message]
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
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=m1ei2nvenf.fsf@tsdye.com \
--to=tsd@tsdye.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).