From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: python :session does return Date: Tue, 14 Jan 2014 12:55:45 -0500 Message-ID: <87eh4a5ty6.fsf@alphaville.bos.redhat.com> References: <87lhyi5xt1.fsf@alphaville.bos.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60699) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W38Dh-0004Dw-Qk for emacs-orgmode@gnu.org; Tue, 14 Jan 2014 12:56:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W38DZ-0000NW-Sn for emacs-orgmode@gnu.org; Tue, 14 Jan 2014 12:56:09 -0500 Received: from plane.gmane.org ([80.91.229.3]:39827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W38DZ-0000MS-MT for emacs-orgmode@gnu.org; Tue, 14 Jan 2014 12:56:01 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1W38DY-0005Br-Ql for emacs-orgmode@gnu.org; Tue, 14 Jan 2014 18:56:00 +0100 Received: from nat-pool-bos-t.redhat.com ([66.187.233.206]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Jan 2014 18:56:00 +0100 Received: from ndokos by nat-pool-bos-t.redhat.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Jan 2014 18:56:00 +0100 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 Ken Mankoff writes: > On Tue, Jan 14, 2014 at 11:32 AM, Nick Dokos wrote: > > Ken Mankoff writes: > > > On Tue, 14 Jan 2014, Ken Mankoff wrote: > >> > >> I've seen various historical issues with :session but it seems I may have a > >> different problem. This is the latest org in emacs 24.3. If I do not have > >> :session, then everything works just fine. > >> > >> If I C-c C-c in the following code: > >> > >> #+BEGIN_SRC python :session transect > >> import numpy as np > >> x = np.arange(12) > >> #+END_SRC > >> > >> Emacs hangs the first time with minibuffer message of "Sent > >> python-eldoc-setup-code". If I C-g, I can edit the org buffer again. All > >> other invocations of that code and the minibuffer message is "executing > >> Python code block...", but still emacs hangs until I C-g. > >> > > > > > > Hmm. If I run IPython instead of regular python by setting this: > > (setq org-babel-python-command "ipython --pylab --pdb --nosep") > > > > Then org does not hang. It returns as expected. > > > > In Org, the following: > > > > #+begin_src python :session foo > > x = 42 > > print x > > #+end_src > > > > Produces no RESULTS, and in the Python *foo* buffer I see: > > > > In [8]: x = 42 > > In [9]: print x > > 42 > > In [10]: open('/var/folders/60/jb7kfrsn2jd90hpcgj4m_wrc0000gn/T/babel-35562TZV/python-3$ > > In [11]: 'org_babel_python_eoe' > > Out[11]: 'org_babel_python_eoe' > > > > > > But if I remove the "print" statment in Org: > > > > #+begin_src python :session foo > > x = 42 > > x > > #+end_src > > > > Then the RESULTS shows me 42, and the Python *foo* buffer is: > > > > In [12]: x = 42 > > In [13]: x > > Out[13]: 42 > > In [14]: open('/var/folders/60/jb7kfrsn2jd90hpcgj4m_wrc0000gn/T/babel-35562TZV/python-3$ > > In [15]: 'org_babel_python_eoe' > > In [15]: Out[15]: 'org_babel_python_eoe' > > I believe that's the expected behaviour: the defaults value of :results > for python (and most other) source blocks is "value" and the print statement has no > value. If you want the output to appear in the results, try :results output. > > Nope. If I don't use IPython, everything hangs regardless of :results. > When I do use IPython, ":results output" doesn't show "print" statement.  > The plain "x" showing up in the output goes away if I use ":results output". > I'm not talking about the hang: that's a problem (although I can't reproduce it, so it may -or may not - be a problem with your particular setup.) I was specifically addressing this comment: > However, the capturing of output doesn't seem to work right. Nick