From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ivan Andrus Subject: Re: python sessions Date: Mon, 25 Mar 2013 13:30:50 -0600 Message-ID: <10EFD7B1-E46B-48B7-8896-9600394C7938@gmail.com> 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> <51508901.6050806@easy-emacs.de> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:54232) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKD6a-00046L-Tc for emacs-orgmode@gnu.org; Mon, 25 Mar 2013 15:30:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKD6Z-0004W0-5e for emacs-orgmode@gnu.org; Mon, 25 Mar 2013 15:30:52 -0400 Received: from mail-pb0-f48.google.com ([209.85.160.48]:46844) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKD6Y-0004Vi-Fs for emacs-orgmode@gnu.org; Mon, 25 Mar 2013 15:30:50 -0400 Received: by mail-pb0-f48.google.com with SMTP id wy12so4302487pbc.21 for ; Mon, 25 Mar 2013 12:30:49 -0700 (PDT) In-Reply-To: <51508901.6050806@easy-emacs.de> 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 On Mar 25, 2013, at 11:27 AM, Andreas R=F6hler = wrote: > Am 25.03.2013 17:43, schrieb Eric Schulte: >> John Hendy writes: >>=20 >>> 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: >>>>>=20 >>>>>> On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos = wrote: >>>>>>> Eric Schulte wrote: >>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =46rom 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 = =3D#+begin_src R >>>>>>>>> :session foo=3D creates an R session named "foo" whereas doing = the same >>>>>>>>> with =3Dpython=3D instead of =3DR=3D does not yield a named = session. >>>>>>>>>=20 >>>>>>>>> =46rom 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. >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> 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). >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> 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). >>>>>>=20 >>>>>=20 >>>>> 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). >>>>>=20 >>>>> Returns the value of x as expected. >>>>>=20 >>>>> #+begin_src python :session >>>>> x =3D 1 >>>>> return x >>>>> #+end_src >>>>>=20 >>>>> #+RESULTS: >>>>> : 1 >>>>>=20 >>>>> #+begin_src python :session >>>>> return x >>>>> #+end_src >>>>>=20 >>>>> #+RESULTS: >>>>>=20 >>>>> The second code block /should/ have access to the x variable = defined >>>>> previous, but instead it throws an error because x is undefined. >>>>>=20 >>>>> Currently I'd say session support for python is completely broken. >>>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>> $ grep -i emacs /var/log/pacman.log >>>=20 >>> [2013-03-20 12:51] upgraded emacs (24.2-4 -> 24.3-1) >>>=20 >>> 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 >>>=20 >>> Eric, your example fails for me. I get: >>>=20 >>=20 >> 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. >>=20 >>>=20 >>>>>> x =3D 1 >>>>>> return x >>> File "", line 1 >>> SyntaxError: 'return' outside function >>>=20 >>> This works, hoever: >>>=20 >>> #+begin_src python :session >>> x =3D 1 >>> x >>> #+end_src >>>=20 >>> #+RESULTS: >>> : 1 >>>=20 >>> #+begin_src python :session >>> x >>> #+end_src >>>=20 >>> #+RESULTS: >>> : 1 >>>=20 >>> 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. >>>=20 >>=20 >> 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? >>=20 >> Thanks, >>=20 >=20 > Please give me some time still to investigate. Still doubt it's = python.el > But if yes, probably will be able to tell more. I think 24.3 is where they changed python.el to fgallina's python.el. = So I'd be=20 willing to bet that it _is_ the problem since it's a complete rewrite = and many=20 things changed. -Ivan=