On Mon, Mar 25, 2013 at 11:01 AM, Ista Zahn <istaz...@gmail.com> wrote: > On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte <schulte.e...@gmail.com> wrote: >> John Hendy <jw.he...@gmail.com> writes: >> >>> On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos <nicholas.do...@hp.com> wrote: >>>> Eric Schulte <schulte.e...@gmail.com> 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/emacs-orgmode@gnu.org/msg68238.html Eric, your example fails for me. I get: >>> 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. John > > Best, > Ista > >> >> -- >> Eric Schulte >> http://cs.unm.edu/~eschulte >>
