Re: [O] python sessions

[John Hendy]

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:

>>> 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
>>