John Hendy <address@hidden> writes:
On Mon, Mar 25, 2013 at 11:01 AM, Ista Zahn <address@hidden> wrote:
On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte <address@hidden> wrote:
John Hendy <address@hidden> writes:
On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos <address@hidden> wrote:
Eric Schulte <address@hidden> wrote:
From participating in evaluating code throughout the discussion and
catching the comments throughout, I'd say yes, at least in terms of
how other babel languages function. In other words =#+begin_src R
:session foo= creates an R session named "foo" whereas doing the same
with =python= instead of =R= does not yield a named session.
From what others experienced, however, the functionality was working
correctly (results were persistent across blocks and two differently
names blocks created two different sessions), just not named
correctly.
See the cond form starting at line 169 in ob-python.el. Different
session functionality is used based on the `org-babel-python-mode'
variable, and on the version of Emacs in use (prior to 24.1 or not).
The branch taken when `org-babel-python-mode' equals 'python is
certainly broken, as it never saves the name of the newly created
buffer, so session re-use and use of multiple named sessions probably
works only when `org-babel-python-mode' equals 'python-mode.
That's me: org-babel-python-mode's value is python, so it's no wonder
it's broken given what Eric says. I'm on emacs 24.3.50 where there is
python.el but no python-mode.el. I tried the "cheap" workaround of
switching the value to python-mode, but that does a (require
'python-mode) somewhere, so that option is out as well.
I'm on Emacs 24.3.1 and have no python-mode.el, either (only
python.el). My setup is working correctly (again, with the caveat of
not having named sessions).
It sounds like we have the same setup, and the following un-named
session example does not work for me. The first code block evaluates
successfully, but it doesn't appear to be having any impact on the
default session (e.g., in the *Python* buffer).
Returns the value of x as expected.
#+begin_src python :session
x = 1
return x
#+end_src
#+RESULTS:
: 1
#+begin_src python :session
return x
#+end_src
#+RESULTS:
The second code block /should/ have access to the x variable defined
previous, but instead it throws an error because x is undefined.
Currently I'd say session support for python is completely broken.
As of this morning I've joined the "it does not work" crowd. Python
sessions worked for me last week, but are now completely broken for me
in the way Eric and others describe.
Interesting... checked out back to that commit
(eff59a15d76647ce8282626b9eb463dc3706d56e) and it still doesn't work.
On a whim, I checked my pacman log (Arch's install system) and
coincidentally on Mar 20 /after/ I wrote that post in which things
work, I ran a system package update.
$ grep -i emacs /var/log/pacman.log
[2013-03-20 12:51] upgraded emacs (24.2-4 -> 24.3-1)
Using the Arch Rollback Machine, I downloaded Emacs 24.2.4 and
downgraded (also required downgrading imageMagick from 6.8.3.10 ->
6.8.2.3). Now it works again (refer to the reproducible example from
the mailing list post):
- http://www.mail-archive.com/address@hidden/msg68238.html
Eric, your example fails for me. I get:
Yes, because my example only works in external (non session) execution
with the current buggy code, where as your example works with session
execution in the old working code.
x = 1
return x
File "<stdin>", line 1
SyntaxError: 'return' outside function
This works, hoever:
#+begin_src python :session
x = 1
x
#+end_src
#+RESULTS:
: 1
#+begin_src python :session
x
#+end_src
#+RESULTS:
: 1
So, with emacs 24.2.4 and current Org-mode (pulled just now) and clean
make, *both* named and un-named sessions work for me on Arch Linux.
Aha! Thanks for sleuthing this out. So the problem lies in changes to
the python.el distributed with Emacs. I don't suppose we can ask
whoever made these changes to python.el to fix the breakage they've
caused in Org-mode?
Thanks,