emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] python sessions


From: Ista Zahn
Subject: Re: [O] python sessions
Date: Mon, 25 Mar 2013 14:16:07 -0400

On Mon, Mar 25, 2013 at 1:41 PM, John Hendy <address@hidden> wrote:
> On Mon, Mar 25, 2013 at 12:27 PM, Andreas Röhler
> <address@hidden> wrote:
>> Am 25.03.2013 17:43, schrieb Eric Schulte:
>>
>>> 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,
>>>
>>
>> Please give me some time still to investigate. Still doubt it's python.el
>> But if yes, probably will be able to tell more.
>
> Possibly, but know that for me it works with one Emacs version and not
> another, both using the same git version of Org and same minimal
> config/setup/test file. Perhaps those affected here should post their
> Emacs versions?

Worked for me last week with emacs 24.2.1 and org 8.0-pre
(release_8.0-pre-54-gb5a853. Not working now with emacs 24.3.1 and org
8.0-pre (release_8.0-pre-152-g42e1a6

>
>
> John
>
>>
>> Best,
>>
>> Andreas
>>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]