From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-15?Q?Andreas_R=F6hler?= Subject: Re: python sessions Date: Mon, 25 Mar 2013 18:27:29 +0100 Message-ID: <51508901.6050806@easy-emacs.de> References: <514AB9FC.3050601@easy-emacs.de> <87d2ut2o5m.fsf@bzg.ath.cx> <514AC116.7030408@easy-emacs.de> <877gkxrbgn.fsf@gmail.com> <87fvzko0zv.fsf@gmail.com> <22817.1364179114@alphaville> <87vc8fv671.fsf@gmail.com> <87fvzjv3aa.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:46491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKBA6-0003Rk-WD for emacs-orgmode@gnu.org; Mon, 25 Mar 2013 13:26:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKBA5-0002IQ-1D for emacs-orgmode@gnu.org; Mon, 25 Mar 2013 13:26:22 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]:49977) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKBA4-0002Hp-OD for emacs-orgmode@gnu.org; Mon, 25 Mar 2013 13:26:20 -0400 In-Reply-To: <87fvzjv3aa.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Am 25.03.2013 17:43, schrieb Eric Schulte: > John Hendy writes: > >> On Mon, Mar 25, 2013 at 11:01 AM, Ista Zahn wrote: >>> On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte wrote: >>>> John Hendy writes: >>>> >>>>> On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos wrote: >>>>>> Eric Schulte 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: >> > > 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 "", 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. Best, Andreas