Discussion:
[O] python sessions
(too old to reply)
Gary Oberbrunner
2013-03-19 21:40:06 UTC
Permalink
I must be failing to understand something. I'm running Emacs 24.3 on
Windows, with latest trunk org-mode. I can't get python functions to
persist across blocks in session mode. Here's my foo.org:

===============

* My Document
#+BEGIN_SRC python :exports results :results output :session
def foo(x):
return x+1
print "hi"
#+END_SRC

#+RESULTS:
: hi

#+BEGIN_SRC python :exports results :results output :session
print foo(100)
print "bye"
#+END_SRC

========================

In session mode, shouldn't foo be defined in the second python block? When
I export this, I get "NameError: name 'foo' is not defined"

I may be doing something wrong, because if I name my python session, I
never see a buffer of that name, and I expected to. Any help?

--
Gary
John Hendy
2013-03-20 00:04:13 UTC
Permalink
On Tue, Mar 19, 2013 at 4:40 PM, Gary Oberbrunner <***@oberbrunner.com> wrote:
> I must be failing to understand something. I'm running Emacs 24.3 on
> Windows, with latest trunk org-mode. I can't get python functions to
> persist across blocks in session mode. Here's my foo.org:
>
> ===============
>
> * My Document
> #+BEGIN_SRC python :exports results :results output :session
> def foo(x):
> return x+1
> print "hi"
> #+END_SRC
>
> #+RESULTS:
> : hi
>
> #+BEGIN_SRC python :exports results :results output :session
> print foo(100)
> print "bye"
> #+END_SRC
>
> ========================
>
> In session mode, shouldn't foo be defined in the second python block? When
> I export this, I get "NameError: name 'foo' is not defined"
>
> I may be doing something wrong, because if I name my python session, I never
> see a buffer of that name, and I expected to. Any help?
>
> --
> Gary

You should probably post your babel configuration from .emacs. This
works for me (mostly). I'm using python 3.3 and so the print function
has changed to requiring parentheses. I can switch to a buffer called
*Python*, however, and =print("hi")= works fine.

If I change to =print(foo(100))=, I get 101 in the #+RESULTS block.

It's probably got something to do with your setup; taking a look at
your config should help others help you out.


Best regards,
John
Nick Dokos
2013-03-20 03:07:19 UTC
Permalink
John Hendy <***@gmail.com> wrote:

> On Tue, Mar 19, 2013 at 4:40 PM, Gary Oberbrunner <***@oberbrunner.com> wrote:
> > I must be failing to understand something. I'm running Emacs 24.3 on
> > Windows, with latest trunk org-mode. I can't get python functions to
> > persist across blocks in session mode. Here's my foo.org:
> >
> > ===============
> >
> > * My Document
> > #+BEGIN_SRC python :exports results :results output :session
> > def foo(x):
> > return x+1
> > print "hi"
> > #+END_SRC
> >
> > #+RESULTS:
> > : hi
> >
> > #+BEGIN_SRC python :exports results :results output :session
> > print foo(100)
> > print "bye"
> > #+END_SRC
> >
> > ========================
> >
> > In session mode, shouldn't foo be defined in the second python block? When
> > I export this, I get "NameError: name 'foo' is not defined"
> >
> > I may be doing something wrong, because if I name my python session, I never
> > see a buffer of that name, and I expected to. Any help?
> >
> > --
> > Gary
>
> You should probably post your babel configuration from .emacs. This
> works for me (mostly). I'm using python 3.3 and so the print function
> has changed to requiring parentheses. I can switch to a buffer called
> *Python*, however, and =print("hi")= works fine.
>
> If I change to =print(foo(100))=, I get 101 in the #+RESULTS block.
>

I don't - I get the same error as Gary.

And looking at the code of org-babel-python-initiate-session-by-key,
I don't understand how it's supposed to work: python-buffer is nil
to begin with; the cond takes the first branch and starts a python session.
When we come to

(setq org-babel-python-buffers
(cons (cons session python-buffer)
(assq-delete-all session org-babel-python-buffers)))

python-buffer is still nil, so we are cooked.

Maybe python-buffer was set as a side-effect of run-python in earlier
versions of emacs? If so, it does not seem to be the case now.

Nick

Org-mode version 8.0-pre (release_8.0-pre-144-g855dcf.dirty @ /home/nick/elisp/org-mode/lisp/)
GNU Emacs 24.3.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of 2012-12-29 on alphaville
Andreas Röhler
2013-03-20 06:44:43 UTC
Permalink
Am 20.03.2013 04:07, schrieb Nick Dokos:
> John Hendy <***@gmail.com> wrote:
>
>> On Tue, Mar 19, 2013 at 4:40 PM, Gary Oberbrunner <***@oberbrunner.com> wrote:
>>> I must be failing to understand something. I'm running Emacs 24.3 on
>>> Windows, with latest trunk org-mode. I can't get python functions to
>>> persist across blocks in session mode. Here's my foo.org:
>>>
>>> ===============
>>>
>>> * My Document
>>> #+BEGIN_SRC python :exports results :results output :session
>>> def foo(x):
>>> return x+1
>>> print "hi"
>>> #+END_SRC
>>>
>>> #+RESULTS:
>>> : hi
>>>
>>> #+BEGIN_SRC python :exports results :results output :session
>>> print foo(100)
>>> print "bye"
>>> #+END_SRC
>>>
>>> ========================
>>>
>>> In session mode, shouldn't foo be defined in the second python block? When
>>> I export this, I get "NameError: name 'foo' is not defined"
>>>
>>> I may be doing something wrong, because if I name my python session, I never
>>> see a buffer of that name, and I expected to. Any help?
>>>
>>> --
>>> Gary
>>
>> You should probably post your babel configuration from .emacs. This
>> works for me (mostly). I'm using python 3.3 and so the print function
>> has changed to requiring parentheses. I can switch to a buffer called
>> *Python*, however, and =print("hi")= works fine.
>>
>> If I change to =print(foo(100))=, I get 101 in the #+RESULTS block.
>>
>
> I don't - I get the same error as Gary.
>
> And looking at the code of org-babel-python-initiate-session-by-key,
> I don't understand how it's supposed to work: python-buffer is nil
> to begin with; the cond takes the first branch and starts a python session.
> When we come to
>
> (setq org-babel-python-buffers
> (cons (cons session python-buffer)
> (assq-delete-all session org-babel-python-buffers)))
>
> python-buffer is still nil, so we are cooked.
>
> Maybe python-buffer was set as a side-effect of run-python in earlier
> versions of emacs? If so, it does not seem to be the case now.
>
> Nick
>
> Org-mode version 8.0-pre (release_8.0-pre-144-g855dcf.dirty @ /home/nick/elisp/org-mode/lisp/)
> GNU Emacs 24.3.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of 2012-12-29 on alphaville
>
>

AFAIU :session is broken, because Python shell as opened by run-python or py-shell isn't used by ob-babel.
Seems ob-babel sends it's code w/ an own shell command, thus opening a new python shell internally every time.

Did :session ever work? Then I might be wrong with this comment.

Andreas
Ista Zahn
2013-03-20 12:54:31 UTC
Permalink
On Wed, Mar 20, 2013 at 2:44 AM, Andreas Röhler
<***@easy-emacs.de> wrote:
> Am 20.03.2013 04:07, schrieb Nick Dokos:
>
>> John Hendy <***@gmail.com> wrote:
>>
>>> On Tue, Mar 19, 2013 at 4:40 PM, Gary Oberbrunner <***@oberbrunner.com>
>>> wrote:
>>>>
>>>> I must be failing to understand something. I'm running Emacs 24.3 on
>>>> Windows, with latest trunk org-mode. I can't get python functions to
>>>> persist across blocks in session mode. Here's my foo.org:
>>>>
>>>> ===============
>>>>
>>>> * My Document
>>>> #+BEGIN_SRC python :exports results :results output :session
>>>> def foo(x):
>>>> return x+1
>>>> print "hi"
>>>> #+END_SRC
>>>>
>>>> #+RESULTS:
>>>> : hi
>>>>
>>>> #+BEGIN_SRC python :exports results :results output :session
>>>> print foo(100)
>>>> print "bye"
>>>> #+END_SRC
>>>>
>>>> ========================
>>>>
>>>> In session mode, shouldn't foo be defined in the second python block?
>>>> When
>>>> I export this, I get "NameError: name 'foo' is not defined"
>>>>
>>>> I may be doing something wrong, because if I name my python session, I
>>>> never
>>>> see a buffer of that name, and I expected to. Any help?
>>>>
>>>> --
>>>> Gary
>>>
>>>
>>> You should probably post your babel configuration from .emacs. This
>>> works for me (mostly). I'm using python 3.3 and so the print function
>>> has changed to requiring parentheses. I can switch to a buffer called
>>> *Python*, however, and =print("hi")= works fine.
>>>
>>> If I change to =print(foo(100))=, I get 101 in the #+RESULTS block.
>>>
>>
>> I don't - I get the same error as Gary.
>>
>> And looking at the code of org-babel-python-initiate-session-by-key,
>> I don't understand how it's supposed to work: python-buffer is nil
>> to begin with; the cond takes the first branch and starts a python
>> session.
>> When we come to
>>
>> (setq org-babel-python-buffers
>> (cons (cons session python-buffer)
>> (assq-delete-all session org-babel-python-buffers)))
>>
>> python-buffer is still nil, so we are cooked.
>>
>> Maybe python-buffer was set as a side-effect of run-python in earlier
>> versions of emacs? If so, it does not seem to be the case now.
>>
>> Nick
>>
>> Org-mode version 8.0-pre (release_8.0-pre-144-g855dcf.dirty @
>> /home/nick/elisp/org-mode/lisp/)
>> GNU Emacs 24.3.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of
>> 2012-12-29 on alphaville
>>
>>
>
> AFAIU :session is broken, because Python shell as opened by run-python or
> py-shell isn't used by ob-babel.
> Seems ob-babel sends it's code w/ an own shell command, thus opening a new
> python shell internally every time.
>
> Did :session ever work? Then I might be wrong with this comment.

Not only did it work, it currently works for me. I seem to remember
bad interaction with python modes other than the one shipped with
emacs. In my .emacs I have

;; Python
;; there are several modes. Currently using
https://github.com/fgallina/python.el
;; hopefully oneday a glorious default python mode will be shipped
with emacs and we won't need this anymore.

;; (add-to-list 'load-path "~/.emacs.d/izahn")
;; (require 'python)

;; (setq
;; python-shell-interpreter "ipython"
;; python-shell-interpreter-args ""
;; python-shell-prompt-regexp "In \\[[0-9]+\\]: "
;; python-shell-prompt-output-regexp "Out\\[[0-9]+\\]: "
;; python-shell-completion-setup-code
;; "from IPython.core.completerlib import module_completion"
;; python-shell-completion-module-string-code
;; "';'.join(module_completion('''%s'''))\n"
;; python-shell-completion-string-code
;; "';'.join(get_ipython().Completer.all_completions('''%s'''))\n")

;; (require 'python-mode) ;;

;; python auto completion
(require 'ac-python)

All the python-mode and ipython mode stuff is commented out partly
because it did not play nice with org-mode. Using the default python
mode works for me. So, for those of you who are finding that this is
not working, what python mode are you using?

Best,
Ista

>
> Andreas
>
>
>
Nick Dokos
2013-03-20 14:08:23 UTC
Permalink
Ista Zahn <***@gmail.com> wrote:

> >
> > Did :session ever work? Then I might be wrong with this comment.
>
> Not only did it work, it currently works for me. I seem to remember
> bad interaction with python modes other than the one shipped with
> emacs. In my .emacs I have
>
> ...
>
> All the python-mode and ipython mode stuff is commented out partly
> because it did not play nice with org-mode. Using the default python
> mode works for me. So, for those of you who are finding that this is
> not working, what python mode are you using?
>

The one distributed with emacs 24.3.50 (at least afaict: I don't think
I'm doing twisted things but you never know :-) ).

Question for you: what version of org mode?

Nick
Gary Oberbrunner
2013-03-20 14:28:09 UTC
Permalink
I am using a snapshot build of Emacs:
emacs-trunk-r112044-20130314-w32-i386.zip, which says it is GNU Emacs
24.3.50.1 (i386-mingw-nt6.1.7601) of 2013-03-14 on VBOX
on Windows 7/64.

My python-mode comes from the python.el shipped with the above emacs, which
says it is Version: 0.24.2.

Org-mode is from git trunk:
commit 3842b073c332256ebfeecb0b01f859bb720cb68f
Author: Bastien Guerry <***@altern.org>
Date: Mon Mar 18 20:36:46 2013 +0100



On Wed, Mar 20, 2013 at 10:08 AM, Nick Dokos <***@hp.com> wrote:

> Ista Zahn <***@gmail.com> wrote:
>
> > >
> > > Did :session ever work? Then I might be wrong with this comment.
> >
> > Not only did it work, it currently works for me. I seem to remember
> > bad interaction with python modes other than the one shipped with
> > emacs. In my .emacs I have
> >
> > ...
> >
> > All the python-mode and ipython mode stuff is commented out partly
> > because it did not play nice with org-mode. Using the default python
> > mode works for me. So, for those of you who are finding that this is
> > not working, what python mode are you using?
> >
>
> The one distributed with emacs 24.3.50 (at least afaict: I don't think
> I'm doing twisted things but you never know :-) ).
>
> Question for you: what version of org mode?
>
> Nick
>
>
>


--
Gary
Andreas Röhler
2013-03-20 17:21:25 UTC
Permalink
[ ... ]
>> AFAIU :session is broken, because Python shell as opened by run-python or
>> py-shell isn't used by ob-babel.
>> Seems ob-babel sends it's code w/ an own shell command, thus opening a new
>> python shell internally every time.
>>
>> Did :session ever work? Then I might be wrong with this comment.
>
> Not only did it work, it currently works for me.


That's good news, so it might be fixed soon.

I seem to remember
> bad interaction with python modes other than the one shipped with
> emacs.

Shipping should not affect the code ;)
Well, if you feel disturbed by python-mode.el,
please file a bug-report at

https://bugs.launchpad.net/python-mode

python-mode.el prepares some keys and fontifying differently
but should not touch python.el commands.

In case it does, probably should change that...

Andreas

[ ... ]
Andreas Röhler
2013-03-20 07:08:17 UTC
Permalink
Am 20.03.2013 01:04, schrieb John Hendy:
> On Tue, Mar 19, 2013 at 4:40 PM, Gary Oberbrunner <***@oberbrunner.com> wrote:
>> I must be failing to understand something. I'm running Emacs 24.3 on
>> Windows, with latest trunk org-mode. I can't get python functions to
>> persist across blocks in session mode. Here's my foo.org:
>>
>> ===============
>>
>> * My Document
>> #+BEGIN_SRC python :exports results :results output :session
>> def foo(x):
>> return x+1
>> print "hi"
>> #+END_SRC
>>
>> #+RESULTS:
>> : hi
>>
>> #+BEGIN_SRC python :exports results :results output :session
>> print foo(100)
>> print "bye"
>> #+END_SRC
>>
>> ========================
>>
>> In session mode, shouldn't foo be defined in the second python block? When
>> I export this, I get "NameError: name 'foo' is not defined"
>>
>> I may be doing something wrong, because if I name my python session, I never
>> see a buffer of that name, and I expected to. Any help?
>>
>> --
>> Gary
>
> You should probably post your babel configuration from .emacs. This
> works for me (mostly). I'm using python 3.3

Hi John,

let's point out though that matter is not at stake.
As the OP got output, system Python must be a 2...

Best,

Andreas

and so the print function
> has changed to requiring parentheses. I can switch to a buffer called
> *Python*, however, and =print("hi")= works fine.
>
> If I change to =print(foo(100))=, I get 101 in the #+RESULTS block.
>
> It's probably got something to do with your setup; taking a look at
> your config should help others help you out.
>
>
> Best regards,
> John
>
>
John Hendy
2013-03-20 15:38:32 UTC
Permalink
On Wed, Mar 20, 2013 at 2:08 AM, Andreas Röhler
<***@easy-emacs.de> wrote:
> Am 20.03.2013 01:04, schrieb John Hendy:
>
>> On Tue, Mar 19, 2013 at 4:40 PM, Gary Oberbrunner <***@oberbrunner.com>
>> wrote:
>>>
>>> I must be failing to understand something. I'm running Emacs 24.3 on
>>> Windows, with latest trunk org-mode. I can't get python functions to
>>> persist across blocks in session mode. Here's my foo.org:

<snip>

>> You should probably post your babel configuration from .emacs. This
>> works for me (mostly). I'm using python 3.3
>
>
> Hi John,
>
> let's point out though that matter is not at stake.
> As the OP got output, system Python must be a 2...
>

True, which is why I clarified my version. The foo() command still
worked for me; I simply had issues due to print() syntax changes
between 2 -> 3. So... I've tried to eliminate this and retried today
with the following process (note setting the python command to
"python2"):

- Start emacs with `emacs -q`

- M-x load-file ~/Desktop/minimal-config

#+begin_src minimal-config

;; load path
(add-to-list 'load-path "~/.elisp/org.git/lisp/")

;; setup babel languages
(org-babel-do-load-languages
'org-babel-load-languages
'((python .t )))
(setq org-babel-python-command "python2")

#+end_src

- For reference
$ python2 --version
Python 2.7.3

On first I get a syntax error executing the first block:

#+RESULTS:
: first
: ... ... ... File "<stdin>", line 4
: print "end first"
: ^
: SyntaxError: invalid syntax

On a whim, I simply inserted a newline, and it worked. Here is the
full file with my executed results (C-c C-c on each block):

#+begin_src orgmode file

* My Document

The first block says:
#+BEGIN_SRC python :exports results :results output :session *PyFoo*
print "first"
def foo(x):
print "In foo(%s)"%x
return x+1

print "end first"
#+END_SRC

#+RESULTS:
: first
: ... ... ... >>> end first

The result is:
#+BEGIN_SRC python :exports results :results output :session *PyFoo*
print "hello"
print foo(100)
print "bye"
#+END_SRC

#+RESULTS:
: hello
: In foo(100)
: 101
: bye

#+end_src orgmode file

*Note:* I do not get a *PyFoo* session, only a *Python* buffer. When I
got to kill emacs, here is the session info asking me if I want to
kill the running buffer process:

Python run *Python* /dev/pts/2 python2 -i -c import sys; sys.path.remove('')


So, seems to work for me. This is on Arch Linux:

- uname -a
Linux hostname 3.8.3-2-ARCH #1 SMP PREEMPT Sun Mar 17 13:04:22 CET
2013 x86_64 GNU/Linux

- emacs --version
GNU Emacs 24.2.1

- M-x org-version
Org-mode version 8.0-pre (release_8.0-pre-146-g73fe0a @
/home/jwhendy/.elisp/org.git/lisp/)


Best regards,
John


> Best,
>
> Andreas
>
John Hendy
2013-03-20 15:42:21 UTC
Permalink
On Wed, Mar 20, 2013 at 10:38 AM, John Hendy <***@gmail.com> wrote:

<snip>

> I've tried to eliminate this and retried today
> with the following process (note setting the python command to
> "python2"):
>
> - Start emacs with `emacs -q`
>

Just caught this... I used -q accidentally instead of -Q. Re-did with
-Q and get same results (successful block execution).


John
Nick Dokos
2013-03-20 16:06:50 UTC
Permalink
John Hendy <***@gmail.com> wrote:

>
> - M-x org-version
> Org-mode version 8.0-pre (release_8.0-pre-146-g73fe0a @
> /home/jwhendy/.elisp/org.git/lisp/)
>
>

That's pretty close to what I'm using. Can you do me a favor: start
emacs -Q and evaluate the variable org-babel-python-buffers before and
after executing a python block with a :session argument and post
the results?

Thanks,
Nick
Gary Oberbrunner
2013-03-20 16:12:21 UTC
Permalink
[sorry, forgot to reply all]

---------- Forwarded message ----------
From: Gary Oberbrunner <***@oberbrunner.com>
Date: Wed, Mar 20, 2013 at 12:11 PM
Subject: Re: [O] python sessions
To: ***@hp.com


After starting emacs -Q and loading my minimal setup (including require
'org):
((:default))
After loading the .org file and doing nothing else, it's the same.
After evaling one code block:
((*PyFoo*) (:default))

But note that there is no buffer named *PyFoo* (there is one named
*Python*).



On Wed, Mar 20, 2013 at 12:06 PM, Nick Dokos <***@hp.com> wrote:

> John Hendy <***@gmail.com> wrote:
>
> >
> > - M-x org-version
> > Org-mode version 8.0-pre (release_8.0-pre-146-g73fe0a @
> > /home/jwhendy/.elisp/org.git/lisp/)
> >
> >
>
> That's pretty close to what I'm using. Can you do me a favor: start
> emacs -Q and evaluate the variable org-babel-python-buffers before and
> after executing a python block with a :session argument and post
> the results?
>
> Thanks,
> Nick
>
>


--
Gary



--
Gary
Andreas Röhler
2013-03-20 17:08:33 UTC
Permalink
Am 20.03.2013 17:06, schrieb Nick Dokos:
> John Hendy <***@gmail.com> wrote:
>
>>
>> - M-x org-version
>> Org-mode version 8.0-pre (release_8.0-pre-146-g73fe0a @
>> /home/jwhendy/.elisp/org.git/lisp/)
>>
>>
>
> That's pretty close to what I'm using. Can you do me a favor: start
> emacs -Q and evaluate the variable org-babel-python-buffers before and
> after executing a python block with a :session argument and post
> the results?
>
> Thanks,
> Nick
>

Hi,

started from Emacs -Q checking the example given.

Seems `org-babel-execute':python doesn't get the session flag.

Edebug: org-babel-execute:python
org-babel-execute:python
executing Python code block...
[4 times]
Result: ((:comments . #1="") (:shebang . #1#) (:cache . "no") (:padline . #1#) (:noweb . "no") (:tangle . "no") (:exports . "results") (:results . "replace output")
(:hlines . "no") (:padnewline . "yes") (:session) (:result-type . output) (:result-params "output" "replace") (:rowname-names) (:colname-names))

Result: (:session)

Result: nil

HTH,

Andreas

Emacs : GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 2.24.14)
of 2013-03-05
Package: Org-mode version 7.9.3f (release_7.9.3f-17-g7524ef...)

current state:
==============
(setq
org-export-blocks '((src org-babel-exp-src-block nil)
(export-comment org-export-blocks-format-comment t)
(ditaa org-export-blocks-format-ditaa nil)
(dot org-export-blocks-format-dot nil))
org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
org-export-preprocess-before-selecting-backend-code-hook '(org-beamer-select-beamer-code)
org-tab-first-hook '(org-hide-block-toggle-maybe
org-src-native-tab-command-maybe
org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-babel-pre-tangle-hook '(save-buffer)
org-occur-hook '(org-first-headline-recenter)
org-export-interblocks '((src org-babel-exp-non-block-elements))
org-metaup-hook '(org-babel-load-in-session-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-export-latex-format-toc-function 'org-export-latex-format-toc-default
org-export-preprocess-before-normalizing-links-hook '(org-remove-file-link-modifiers)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-export-first-hook '(org-beamer-initialize-open-trackers)
org-mode-hook '(#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook org-show-block-all
append local]
5]
#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook
org-babel-show-result-all append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix-toc
org-beamer-auto-fragile-frames
org-beamer-place-default-actions-for-lists)
org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-babel-tangle-lang-exts '(("python" . "py") ("emacs-lisp" . "el"))
org-babel-load-languages '((sh . t) (python . t))
org-confirm-shell-link-function 'yes-or-no-p
)
Nick Dokos
2013-03-20 17:25:43 UTC
Permalink
Andreas Röhler <***@easy-emacs.de> wrote:

> Seems `org-babel-execute':python doesn't get the session flag.
>
> Edebug: org-babel-execute:python
> org-babel-execute:python
> executing Python code block...
> [4 times]
> Result: ((:comments . #1="") (:shebang . #1#) (:cache . "no")
> (:padline . #1#) (:noweb . "no") (:tangle . "no") (:exports
> . "results") (:results . "replace output") (:hlines . "no")
> (:padnewline . "yes") (:session) (:result-type . output)

Sure it does: ^^^^^^^^^^

What it does with it is another matter however. Am I missing something?

Nick

> (:result-params "output" "replace") (:rowname-names) (:colname-names))
>
> Result: (:session)
>
> Result: nil
>
John Hendy
2013-03-20 17:54:39 UTC
Permalink
On Wed, Mar 20, 2013 at 12:25 PM, Nick Dokos <***@hp.com> wrote:
> Andreas Röhler <***@easy-emacs.de> wrote:
>
>> Seems `org-babel-execute':python doesn't get the session flag.
>>
>> Edebug: org-babel-execute:python
>> org-babel-execute:python
>> executing Python code block...
>> [4 times]
>> Result: ((:comments . #1="") (:shebang . #1#) (:cache . "no")
>> (:padline . #1#) (:noweb . "no") (:tangle . "no") (:exports
>> . "results") (:results . "replace output") (:hlines . "no")
>> (:padnewline . "yes") (:session) (:result-type . output)
>
> Sure it does: ^^^^^^^^^^
>
> What it does with it is another matter however. Am I missing something?

I was thinking the concern was over not having the session named
properly, but might be wrong (Andreas could confirm).

I've not used python prior to this, but I use R almost daily in Org
and if I do #+begin_src R :session R, I get a buffer actually named
=R=. In this case, I expected the buffer name would be *PyFoo*.
Checking if it was an issue with asterisks, I used =:session py= and
still just get the default *Python* buffer created.


John

>
> Nick
>
>> (:result-params "output" "replace") (:rowname-names) (:colname-names))
>>
>> Result: (:session)
>>
>> Result: nil
>>
>
Nick Dokos
2013-03-20 18:15:38 UTC
Permalink
John Hendy <***@gmail.com> wrote:

> On Wed, Mar 20, 2013 at 12:25 PM, Nick Dokos <***@hp.com> wrote:
> > Andreas Röhler <***@easy-emacs.de> wrote:
> >
> >> Seems `org-babel-execute':python doesn't get the session flag.
> >>
> >> Edebug: org-babel-execute:python
> >> org-babel-execute:python
> >> executing Python code block...
> >> [4 times]
> >> Result: ((:comments . #1="") (:shebang . #1#) (:cache . "no")
> >> (:padline . #1#) (:noweb . "no") (:tangle . "no") (:exports
> >> . "results") (:results . "replace output") (:hlines . "no")
> >> (:padnewline . "yes") (:session) (:result-type . output)
> >
> > Sure it does: ^^^^^^^^^^
> >
> > What it does with it is another matter however. Am I missing something?
>
> I was thinking the concern was over not having the session named
> properly, but might be wrong (Andreas could confirm).
>

I guessed Andreas tried with an unnamed session (but I agree it would be
best if he confirms): afaics, if I use a session name, it's passed
correctly in the params argument of org-babel-execute:python as
(:session . "foo"), but in the later processing,
org-babel-python-buffers is not set correctly.

> I've not used python prior to this, but I use R almost daily in Org
> and if I do #+begin_src R :session R, I get a buffer actually named
> =R=. In this case, I expected the buffer name would be *PyFoo*.
> Checking if it was an issue with asterisks, I used =:session py= and
> still just get the default *Python* buffer created.
>

Yes, I think it's ob-python's problem: but as I said before, I don't
understand why it works for you (and Ista Zahn).

Nick
Ista Zahn
2013-03-20 18:32:23 UTC
Permalink
On Wed, Mar 20, 2013 at 2:15 PM, Nick Dokos <***@hp.com> wrote:
> John Hendy <***@gmail.com> wrote:
>
>> On Wed, Mar 20, 2013 at 12:25 PM, Nick Dokos <***@hp.com> wrote:
>> > Andreas Röhler <***@easy-emacs.de> wrote:
>> >
>> >> Seems `org-babel-execute':python doesn't get the session flag.
>> >>
>> >> Edebug: org-babel-execute:python
>> >> org-babel-execute:python
>> >> executing Python code block...
>> >> [4 times]
>> >> Result: ((:comments . #1="") (:shebang . #1#) (:cache . "no")
>> >> (:padline . #1#) (:noweb . "no") (:tangle . "no") (:exports
>> >> . "results") (:results . "replace output") (:hlines . "no")
>> >> (:padnewline . "yes") (:session) (:result-type . output)
>> >
>> > Sure it does: ^^^^^^^^^^
>> >
>> > What it does with it is another matter however. Am I missing something?
>>
>> I was thinking the concern was over not having the session named
>> properly, but might be wrong (Andreas could confirm).
>>
>
> I guessed Andreas tried with an unnamed session (but I agree it would be
> best if he confirms): afaics, if I use a session name, it's passed
> correctly in the params argument of org-babel-execute:python as
> (:session . "foo"), but in the later processing,
> org-babel-python-buffers is not set correctly.
>
>> I've not used python prior to this, but I use R almost daily in Org
>> and if I do #+begin_src R :session R, I get a buffer actually named
>> =R=. In this case, I expected the buffer name would be *PyFoo*.
>> Checking if it was an issue with asterisks, I used =:session py= and
>> still just get the default *Python* buffer created.
>>
>
> Yes, I think it's ob-python's problem: but as I said before, I don't
> understand why it works for you (and Ista Zahn).

I guess it depends on the definition of "works". I don't get python
buffers with the name of the :session variable. But I do get separate
python buffers (.e.g., *Python*, *Python*<2>) for each session, and
python blocks get executed in the right python process. To me that
equals "works", but if the issue is that the buffers don't get named
with the value of :session then no, that doesn't work for me either.

Best,
Ista

>
> Nick
>
>
>
Nick Dokos
2013-03-20 18:39:20 UTC
Permalink
Ista Zahn <***@gmail.com> wrote:

> > Yes, I think it's ob-python's problem: but as I said before, I don't
> > understand why it works for you (and Ista Zahn).
>
> I guess it depends on the definition of "works". I don't get python
> buffers with the name of the :session variable. But I do get separate
> python buffers (.e.g., *Python*, *Python*<2>) for each session, and
> python blocks get executed in the right python process. To me that
> equals "works", but if the issue is that the buffers don't get named
> with the value of :session then no, that doesn't work for me either.
>

For me, it does not work at all: I don't get python buffers, period
(forget about what they are named :-) )

Nick
Andreas Röhler
2013-03-20 18:43:37 UTC
Permalink
> I guess it depends on the definition of "works". I don't get python
> buffers with the name of the :session variable.

Reads as it works only with named sessions, but fails with unnamed

But I do get separate
> python buffers (.e.g., *Python*, *Python*<2>) for each session, and
> python blocks get executed in the right python process. To me that
> equals "works", but if the issue is that the buffers don't get named
> with the value of :session then no, that doesn't work for me either.
>
> Best,
> Ista
>
>>
>> Nick
>>
>>
>>
>
>
Ista Zahn
2013-03-20 19:42:19 UTC
Permalink
On Wed, Mar 20, 2013 at 2:43 PM, Andreas Röhler
<***@easy-emacs.de> wrote:
>
>> I guess it depends on the definition of "works". I don't get python
>> buffers with the name of the :session variable.
>
>
> Reads as it works only with named sessions, but fails with unnamed

It fails to name the python process buffers. Everything else works as
expected. Consider this example:

8<---------cut here------------8<
#+BEGIN_SRC python :exports results :results output :session *foo*
def foo(x):
return(x+1)

#+END_SRC

#+RESULTS:


#+BEGIN_SRC python :exports results :results output :session *bar*
def bar(x):
return(x+2)

#+END_SRC

#+RESULTS:

#+BEGIN_SRC python :exports results :results output :session *foo*
print(foo(100))
print(bar(100))

#+END_SRC

#+RESULTS:
: 101
: Traceback (most recent call last):
: File "<stdin>", line 1, in <module>
: NameError: name 'bar' is not defined

#+BEGIN_SRC python :exports results :results output :session *bar*
print(foo(100))
print(bar(100))

#+END_SRC

#+RESULTS:
: Traceback (most recent call last):
: File "<stdin>", line 1, in <module>
: NameError: name 'foo' is not defined
: 102

8<---------cut here------------8<

the foo function exists when I use :session foo (and not with :session
bar), and the bar function exists when I uses :session bar (and not
with :session foo). That equals "works" in my book. The only thing
that doesn't "work" is that I have buffers

. * tmp.org 1657 Org ~/Desktop/tmp.org
* *Python*<2> 332 Inferior Python:
* *Python* 332 Inferior Python:

instead of

. * tmp.org 1657 Org ~/Desktop/tmp.org
* *foo* 332 Inferior Python:
* *bar* 332 Inferior Python:

This is with GNU Emacs 24.2.1 and Org-mode version 8.0-pre
(release_8.0-pre-54-gb5a853

Best,
Ista

>
>
> But I do get separate
>>
>> python buffers (.e.g., *Python*, *Python*<2>) for each session, and
>> python blocks get executed in the right python process. To me that
>> equals "works", but if the issue is that the buffers don't get named
>> with the value of :session then no, that doesn't work for me either.
>>
>> Best,
>> Ista
>>
>>>
>>> Nick
>>>
>>>
>>>
>>
>>
>
>
Andreas Röhler
2013-03-20 19:53:53 UTC
Permalink
Am 20.03.2013 20:42, schrieb Ista Zahn:
> On Wed, Mar 20, 2013 at 2:43 PM, Andreas Röhler
> <***@easy-emacs.de> wrote:
>>
>>> I guess it depends on the definition of "works". I don't get python
>>> buffers with the name of the :session variable.
>>
>>
>> Reads as it works only with named sessions, but fails with unnamed
>
> It fails to name the python process buffers.

May you try still an unnamed session as sent by OP?

Andreas
Ista Zahn
2013-03-20 20:12:15 UTC
Permalink
On Wed, Mar 20, 2013 at 3:53 PM, Andreas Röhler
<***@easy-emacs.de> wrote:
> Am 20.03.2013 20:42, schrieb Ista Zahn:
>
>> On Wed, Mar 20, 2013 at 2:43 PM, Andreas Röhler
>> <***@easy-emacs.de> wrote:
>>>
>>>
>>>> I guess it depends on the definition of "works". I don't get python
>>>> buffers with the name of the :session variable.
>>>
>>>
>>>
>>> Reads as it works only with named sessions, but fails with unnamed

Oops, sorry I totally misread this before. I guess my last email
didn't make much sense!

>>
>>
>> It fails to name the python process buffers.
>
>
> May you try still an unnamed session as sent by OP?

Unnamed sessions works as expected:


#+BEGIN_SRC python :exports results :results output :session
def foo(x):
return(x+1)

#+END_SRC

#+RESULTS:


#+BEGIN_SRC python :exports results :results output :session
def bar(x):
return(x+2)

#+END_SRC

#+RESULTS:

#+BEGIN_SRC python :exports results :results output :session
print(foo(100))
print(bar(100))

#+END_SRC

#+RESULTS:
: 101
: 102


>
> Andreas
>
Gary Oberbrunner
2013-03-20 20:25:59 UTC
Permalink
Ista, what OS are you on? Maybe this (or part of it anyway) is only a
Windows problem?


On Wed, Mar 20, 2013 at 4:12 PM, Ista Zahn <***@gmail.com> wrote:

> On Wed, Mar 20, 2013 at 3:53 PM, Andreas Röhler
> <***@easy-emacs.de> wrote:
> > Am 20.03.2013 20:42, schrieb Ista Zahn:
> >
> >> On Wed, Mar 20, 2013 at 2:43 PM, Andreas Röhler
> >> <***@easy-emacs.de> wrote:
> >>>
> >>>
> >>>> I guess it depends on the definition of "works". I don't get python
> >>>> buffers with the name of the :session variable.
> >>>
> >>>
> >>>
> >>> Reads as it works only with named sessions, but fails with unnamed
>
> Oops, sorry I totally misread this before. I guess my last email
> didn't make much sense!
>
> >>
> >>
> >> It fails to name the python process buffers.
> >
> >
> > May you try still an unnamed session as sent by OP?
>
> Unnamed sessions works as expected:
>
>
> #+BEGIN_SRC python :exports results :results output :session
> def foo(x):
> return(x+1)
>
> #+END_SRC
>
> #+RESULTS:
>
>
> #+BEGIN_SRC python :exports results :results output :session
> def bar(x):
> return(x+2)
>
> #+END_SRC
>
> #+RESULTS:
>
> #+BEGIN_SRC python :exports results :results output :session
> print(foo(100))
> print(bar(100))
>
> #+END_SRC
>
> #+RESULTS:
> : 101
> : 102
>
>
> >
> > Andreas
> >
>
>


--
Gary
Ista Zahn
2013-03-20 22:06:27 UTC
Permalink
On Wed, Mar 20, 2013 at 4:25 PM, Gary Oberbrunner <***@oberbrunner.com> wrote:
> Ista, what OS are you on? Maybe this (or part of it anyway) is only a
> Windows problem?

Maybe -- I'm on Arch Linux.

>
>
> On Wed, Mar 20, 2013 at 4:12 PM, Ista Zahn <***@gmail.com> wrote:
>>
>> On Wed, Mar 20, 2013 at 3:53 PM, Andreas Röhler
>> <***@easy-emacs.de> wrote:
>> > Am 20.03.2013 20:42, schrieb Ista Zahn:
>> >
>> >> On Wed, Mar 20, 2013 at 2:43 PM, Andreas Röhler
>> >> <***@easy-emacs.de> wrote:
>> >>>
>> >>>
>> >>>> I guess it depends on the definition of "works". I don't get python
>> >>>> buffers with the name of the :session variable.
>> >>>
>> >>>
>> >>>
>> >>> Reads as it works only with named sessions, but fails with unnamed
>>
>> Oops, sorry I totally misread this before. I guess my last email
>> didn't make much sense!
>>
>> >>
>> >>
>> >> It fails to name the python process buffers.
>> >
>> >
>> > May you try still an unnamed session as sent by OP?
>>
>> Unnamed sessions works as expected:
>>
>>
>> #+BEGIN_SRC python :exports results :results output :session
>> def foo(x):
>> return(x+1)
>>
>> #+END_SRC
>>
>> #+RESULTS:
>>
>>
>> #+BEGIN_SRC python :exports results :results output :session
>> def bar(x):
>> return(x+2)
>>
>> #+END_SRC
>>
>> #+RESULTS:
>>
>> #+BEGIN_SRC python :exports results :results output :session
>> print(foo(100))
>> print(bar(100))
>>
>> #+END_SRC
>>
>> #+RESULTS:
>> : 101
>> : 102
>>
>>
>> >
>> > Andreas
>> >
>>
>
>
>
> --
> Gary
Andreas Röhler
2013-03-20 18:42:12 UTC
Permalink
Am 20.03.2013 19:15, schrieb Nick Dokos:
> John Hendy <***@gmail.com> wrote:
>
>> On Wed, Mar 20, 2013 at 12:25 PM, Nick Dokos <***@hp.com> wrote:
>>> Andreas Röhler <***@easy-emacs.de> wrote:
>>>
>>>> Seems `org-babel-execute':python doesn't get the session flag.
>>>>
>>>> Edebug: org-babel-execute:python
>>>> org-babel-execute:python
>>>> executing Python code block...
>>>> [4 times]
>>>> Result: ((:comments . #1="") (:shebang . #1#) (:cache . "no")
>>>> (:padline . #1#) (:noweb . "no") (:tangle . "no") (:exports
>>>> . "results") (:results . "replace output") (:hlines . "no")
>>>> (:padnewline . "yes") (:session) (:result-type . output)
>>>
>>> Sure it does: ^^^^^^^^^^
>>>
>>> What it does with it is another matter however. Am I missing something?
>>
>> I was thinking the concern was over not having the session named
>> properly, but might be wrong (Andreas could confirm).
>>
>
> I guessed Andreas tried with an unnamed session

yes, tried the example given,
ah, see misinterpreted the spot,
thanks,

Andreas
Andreas Röhler
2013-03-20 19:01:01 UTC
Permalink
Am 20.03.2013 18:25, schrieb Nick Dokos:
> Andreas Röhler <***@easy-emacs.de> wrote:
>
>> Seems `org-babel-execute':python doesn't get the session flag.
>>
>> Edebug: org-babel-execute:python
>> org-babel-execute:python
>> executing Python code block...
>> [4 times]
>> Result: ((:comments . #1="") (:shebang . #1#) (:cache . "no")
>> (:padline . #1#) (:noweb . "no") (:tangle . "no") (:exports
>> . "results") (:results . "replace output") (:hlines . "no")
>> (:padnewline . "yes") (:session) (:result-type . output)
>
> Sure it does: ^^^^^^^^^^
>
> What it does with it is another matter however. Am I missing something?
>
> Nick
>
>> (:result-params "output" "replace") (:rowname-names) (:colname-names))
>>
>> Result: (:session)
>>
>> Result: nil
>>
>

At least for unnamed session it's set to nil here

let* ((session (org-babel-python-initiate-session...

later on it takes the wrong route:

(defun org-babel-python-evaluate
(session body &optional result-type result-params preamble)
"Evaluate BODY as Python code."
(if session
(org-babel-python-evaluate-session
session body result-type result-params)
(org-babel-python-evaluate-external-process
body result-type result-params preamble)))

Best,

Andreas
Gary Oberbrunner
2013-03-21 01:22:20 UTC
Permalink
I've attached a patch which works for me, at least in simple tests. It
should set the buffer name more correctly in session mode. I also added a
new defcustom for the python command to use for session mode specifically;
that is required for Windows, and I don't think it hurts on other OSes.


On Wed, Mar 20, 2013 at 8:20 PM, Gary Oberbrunner <***@oberbrunner.com>wrote:

>
> On Wed, Mar 20, 2013 at 1:00 PM, John Hendy <***@gmail.com> wrote:
>
>> Some other things I noticed when modifying your custom config (just to
>> clarify):
>> - Org-mode git repo is located at "/emacs/site-lisp/org-mode/lisp"?
>> - You shouldn't need (perhaps even as strongly as shouldn't use)
>> =(require 'org)=
>>
>
> Ah, I see -- once I add the proper dir, the proper version of org-mode
> will get autoloaded from there (even with emacs -Q).
>
> But it wouldn't actually hurt, would it?
>
> --
> Gary
>



--
Gary
John Hendy
2013-03-21 01:54:14 UTC
Permalink
On Wed, Mar 20, 2013 at 8:22 PM, Gary Oberbrunner <***@oberbrunner.com> wrote:
> I've attached a patch which works for me, at least in simple tests. It
> should set the buffer name more correctly in session mode. I also added a
> new defcustom for the python command to use for session mode specifically;
> that is required for Windows, and I don't think it hurts on other OSes.
>

Is this fixing *everything* for you, or just the named sessions? Just
wondering if your original issue is fixed, or if you're still having
issues.

If it was fixed... what was it (out of curiosity)? Sorry... still
haven't rebooted into Windows to see if I can replicate on Windows as
well.


John

>
> On Wed, Mar 20, 2013 at 8:20 PM, Gary Oberbrunner <***@oberbrunner.com>
> wrote:
>>
>>
>> On Wed, Mar 20, 2013 at 1:00 PM, John Hendy <***@gmail.com> wrote:
>>>
>>> Some other things I noticed when modifying your custom config (just to
>>> clarify):
>>> - Org-mode git repo is located at "/emacs/site-lisp/org-mode/lisp"?
>>> - You shouldn't need (perhaps even as strongly as shouldn't use)
>>> =(require 'org)=
>>
>>
>> Ah, I see -- once I add the proper dir, the proper version of org-mode
>> will get autoloaded from there (even with emacs -Q).
>>
>> But it wouldn't actually hurt, would it?
>>
>> --
>> Gary
>
>
>
>
> --
> Gary
Gary Oberbrunner
2013-03-21 01:56:23 UTC
Permalink
Both of the issues in my patch were part of it. The buffer naming and
using "python -i" in session mode.

And I'm still not sure default (nameless) sessions are working, and also in
my real testcase it still hangs sometimes. So no, not everything is fine
yet.


On Wed, Mar 20, 2013 at 9:54 PM, John Hendy <***@gmail.com> wrote:

> On Wed, Mar 20, 2013 at 8:22 PM, Gary Oberbrunner <***@oberbrunner.com>
> wrote:
> > I've attached a patch which works for me, at least in simple tests. It
> > should set the buffer name more correctly in session mode. I also added
> a
> > new defcustom for the python command to use for session mode
> specifically;
> > that is required for Windows, and I don't think it hurts on other OSes.
> >
>
> Is this fixing *everything* for you, or just the named sessions? Just
> wondering if your original issue is fixed, or if you're still having
> issues.
>
> If it was fixed... what was it (out of curiosity)? Sorry... still
> haven't rebooted into Windows to see if I can replicate on Windows as
> well.
>
>
> John
>
> >
> > On Wed, Mar 20, 2013 at 8:20 PM, Gary Oberbrunner <***@oberbrunner.com
> >
> > wrote:
> >>
> >>
> >> On Wed, Mar 20, 2013 at 1:00 PM, John Hendy <***@gmail.com> wrote:
> >>>
> >>> Some other things I noticed when modifying your custom config (just to
> >>> clarify):
> >>> - Org-mode git repo is located at "/emacs/site-lisp/org-mode/lisp"?
> >>> - You shouldn't need (perhaps even as strongly as shouldn't use)
> >>> =(require 'org)=
> >>
> >>
> >> Ah, I see -- once I add the proper dir, the proper version of org-mode
> >> will get autoloaded from there (even with emacs -Q).
> >>
> >> But it wouldn't actually hurt, would it?
> >>
> >> --
> >> Gary
> >
> >
> >
> >
> > --
> > Gary
>



--
Gary
Andreas Röhler
2013-03-21 07:42:52 UTC
Permalink
Am 21.03.2013 02:56, schrieb Gary Oberbrunner:

Hi Gary,

great if you can make it work for you.

Nonetheless, still thinking

let-var session in

org-babel-execute:python

needs the fix.

Best,

Andreas
Bastien
2013-03-21 07:43:49 UTC
Permalink
Hi Andreas,

Andreas Röhler <***@easy-emacs.de> writes:

> Nonetheless, still thinking
>
> let-var session in
>
> org-babel-execute:python
>
> needs the fix.

I've not been following this thread, can you send a patch with
the fix and the reason for it? Thanks in advance!

--
Bastien
Andreas Röhler
2013-03-21 08:13:10 UTC
Permalink
Am 21.03.2013 08:43, schrieb Bastien:
> Hi Andreas,
>
> Andreas Röhler <***@easy-emacs.de> writes:
>
>> Nonetheless, still thinking
>>
>> let-var session in
>>
>> org-babel-execute:python
>>
>> needs the fix.
>
> I've not been following this thread, can you send a patch with
> the fix and the reason for it? Thanks in advance!
>

Hi Bastien,

unfortunately my org-environment isn't ready yet for developing.
Might take some time, but I'm on it.
Unless someone else sends that probably trivial patch meanwhile....

Best,

Andreas
Eric Schulte
2013-03-23 22:07:02 UTC
Permalink
Andreas Röhler <***@easy-emacs.de> writes:

> Am 21.03.2013 08:43, schrieb Bastien:
>> Hi Andreas,
>>
>> Andreas Röhler <***@easy-emacs.de> writes:
>>
>>> Nonetheless, still thinking
>>>
>>> let-var session in
>>>
>>> org-babel-execute:python
>>>
>>> needs the fix.
>>
>> I've not been following this thread, can you send a patch with
>> the fix and the reason for it? Thanks in advance!
>>
>
> Hi Bastien,
>
> unfortunately my org-environment isn't ready yet for developing.
> Might take some time, but I'm on it.

I also haven't been following this thread.

Forgetting a patch for the moment, is it possible to conclusively state
that there is or isn't a bug in the current ob-python handling and
naming of sessions? If there is, is there a recipe for reproducing this
bug?

Thanks,

--
Eric Schulte
http://cs.unm.edu/~eschulte
John Hendy
2013-03-24 01:29:04 UTC
Permalink
On Sat, Mar 23, 2013 at 5:07 PM, Eric Schulte <***@gmail.com> wrote:
> Andreas Röhler <***@easy-emacs.de> writes:
>
>> Am 21.03.2013 08:43, schrieb Bastien:
>>> Hi Andreas,
>>>
>>> Andreas Röhler <***@easy-emacs.de> writes:
>>>
>>>> Nonetheless, still thinking
>>>>
>>>> let-var session in
>>>>
>>>> org-babel-execute:python
>>>>
>>>> needs the fix.
>>>
>>> I've not been following this thread, can you send a patch with
>>> the fix and the reason for it? Thanks in advance!
>>>
>>
>> Hi Bastien,
>>
>> unfortunately my org-environment isn't ready yet for developing.
>> Might take some time, but I'm on it.
>
> I also haven't been following this thread.
>
> Forgetting a patch for the moment, is it possible to conclusively state
> that there is or isn't a bug in the current ob-python handling and
> naming of sessions? If there is, is there a recipe for reproducing this
> bug?
>

>
Eric Schulte
2013-03-24 22:59:23 UTC
Permalink
>
>
Nick Dokos
2013-03-25 02:38:34 UTC
Permalink
Eric Schulte <***@gmail.com> wrote:

> >
> >
John Hendy
2013-03-25 02:59:39 UTC
Permalink
On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos <***@hp.com> wrote:
> Eric Schulte <***@gmail.com> wrote:
>
>> >
>> >
Andreas Röhler
2013-03-25 06:34:33 UTC
Permalink
Am 25.03.2013 03:59, schrieb John Hendy:
> On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos <***@hp.com> wrote:
>> Eric Schulte <***@gmail.com> wrote:
>>
>>>>
>>>>
Eric Schulte
2013-03-25 15:40:18 UTC
Permalink
John Hendy <***@gmail.com> writes:

> On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos <***@hp.com> wrote:
>> Eric Schulte <***@gmail.com> wrote:
>>
>>> >
>>> >
John Hendy
2013-03-25 15:55:01 UTC
Permalink
On Mon, Mar 25, 2013 at 10:40 AM, Eric Schulte <***@gmail.com> wrote:
> John Hendy <***@gmail.com> writes:
>
>> On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos <***@hp.com> wrote:
>>> Eric Schulte <***@gmail.com> wrote:
>>>
>>>> >
>>>> >
Eric Schulte
2013-03-25 16:07:37 UTC
Permalink
>>
>> Currently I'd say session support for python is completely broken.
>
> Have *any* changes been made related to python recently? See my
> mailing list post with reproducible example:
> - http://www.mail-archive.com/emacs-***@gnu.org/msg68238.html
>
> This was definitely working for me with a minimal config and starting
> with `emacs -Q`. I cannot reproduce that example anymore. Sessions
> don't work any longer, named or un-named for me, and we had two data
> points (myself and Ista) for whom it worked (at least for named).
>
> I think something was changed that broke it for my working setup.
> Might be nice to figure out what that was.
>

I certainly haven't touched this code. The latest change I see to the
relevant portions of the code is commit 4a0afac6 from Bastien on
Feb. 23rd.

>
> Is there a way to see one's local git history? Not the git log, but
> something like what git versions I've been hopping from/to with each
> successive pull? I could try and see what I was at on 3/20 when I
> posted that and when I last pulled? I see a change related to
> ob-python from Bastien on 3/19... perhaps I could switch to a commit
> prior to that and try again?
>

I don't know of a way to show what versions you have used recently.

There are tools to help find the commits causing a change in behavior.
See http://git-scm.com/book/en/Git-Tools-Debugging-with-Git for a pretty
good summary.

--
Eric Schulte
http://cs.unm.edu/~eschulte
Nick Dokos
2013-03-25 16:41:12 UTC
Permalink
Eric Schulte <***@gmail.com> wrote:

> >>
> >> Currently I'd say session support for python is completely broken.
> >
> > Have *any* changes been made related to python recently? See my
> > mailing list post with reproducible example:
> > - http://www.mail-archive.com/emacs-***@gnu.org/msg68238.html
> >
> > This was definitely working for me with a minimal config and starting
> > with `emacs -Q`. I cannot reproduce that example anymore. Sessions
> > don't work any longer, named or un-named for me, and we had two data
> > points (myself and Ista) for whom it worked (at least for named).
> >
> > I think something was changed that broke it for my working setup.
> > Might be nice to figure out what that was.
> >
>
> I certainly haven't touched this code. The latest change I see to the
> relevant portions of the code is commit 4a0afac6 from Bastien on
> Feb. 23rd.
>

At least, we now all agree that it's broken ;-)

> >
> > Is there a way to see one's local git history? Not the git log, but
> > something like what git versions I've been hopping from/to with each
> > successive pull? I could try and see what I was at on 3/20 when I
> > posted that and when I last pulled? I see a change related to
> > ob-python from Bastien on 3/19... perhaps I could switch to a commit
> > prior to that and try again?
> >
>
> I don't know of a way to show what versions you have used recently.
>

I think `git reflog' can do that, but it's kinda cryptic, so it might
be more trouble than it's worth.

Nick
Ista Zahn
2013-03-25 16:01:58 UTC
Permalink
On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte <***@gmail.com> wrote:
> John Hendy <***@gmail.com> writes:
>
>> On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos <***@hp.com> wrote:
>>> Eric Schulte <***@gmail.com> wrote:
>>>
>>>> >
>>>> >
John Hendy
2013-03-25 16:23:43 UTC
Permalink
On Mon, Mar 25, 2013 at 11:01 AM, Ista Zahn <***@gmail.com> wrote:
> On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte <***@gmail.com> wrote:
>> John Hendy <***@gmail.com> writes:
>>
>>> On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos <***@hp.com> wrote:
>>>> Eric Schulte <***@gmail.com> wrote:
>>>>
>>>>> >
>>>>> >
Eric Schulte
2013-03-25 16:43:09 UTC
Permalink
John Hendy <***@gmail.com> writes:

> On Mon, Mar 25, 2013 at 11:01 AM, Ista Zahn <***@gmail.com> wrote:
>> On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte <***@gmail.com> wrote:
>>> John Hendy <***@gmail.com> writes:
>>>
>>>> On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos <***@hp.com> wrote:
>>>>> Eric Schulte <***@gmail.com> wrote:
>>>>>
>>>>>> >
>>>>>> >
Andreas Röhler
2013-03-25 17:27:29 UTC
Permalink
Am 25.03.2013 17:43, schrieb Eric Schulte:
> John Hendy <***@gmail.com> writes:
>
>> On Mon, Mar 25, 2013 at 11:01 AM, Ista Zahn <***@gmail.com> wrote:
>>> On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte <***@gmail.com> wrote:
>>>> John Hendy <***@gmail.com> writes:
>>>>
>>>>> On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos <***@hp.com> wrote:
>>>>>> Eric Schulte <***@gmail.com> wrote:
>>>>>>
>>>>>>>>
>>>>>>>>
John Hendy
2013-03-25 17:41:48 UTC
Permalink
On Mon, Mar 25, 2013 at 12:27 PM, Andreas Röhler
<***@easy-emacs.de> wrote:
> Am 25.03.2013 17:43, schrieb Eric Schulte:
>
>> John Hendy <***@gmail.com> writes:
>>
>>> On Mon, Mar 25, 2013 at 11:01 AM, Ista Zahn <***@gmail.com> wrote:
>>>>
>>>> On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte <***@gmail.com>
>>>> wrote:
>>>>>
>>>>> John Hendy <***@gmail.com> writes:
>>>>>
>>>>>> On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos <***@hp.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Eric Schulte <***@gmail.com> wrote:
>>>>>>>
>>>>>>>>>
>>>>>>>>>
Ista Zahn
2013-03-25 18:16:07 UTC
Permalink
On Mon, Mar 25, 2013 at 1:41 PM, John Hendy <***@gmail.com> wrote:
> On Mon, Mar 25, 2013 at 12:27 PM, Andreas Röhler
> <***@easy-emacs.de> wrote:
>> Am 25.03.2013 17:43, schrieb Eric Schulte:
>>
>>> John Hendy <***@gmail.com> writes:
>>>
>>>> On Mon, Mar 25, 2013 at 11:01 AM, Ista Zahn <***@gmail.com> wrote:
>>>>>
>>>>> On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte <***@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> John Hendy <***@gmail.com> writes:
>>>>>>
>>>>>>> On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos <***@hp.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Eric Schulte <***@gmail.com> wrote:
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
Ivan Andrus
2013-03-25 19:30:50 UTC
Permalink
On Mar 25, 2013, at 11:27 AM, Andreas Röhler <***@easy-emacs.de> wrote:
> Am 25.03.2013 17:43, schrieb Eric Schulte:
>> John Hendy <***@gmail.com> writes:
>>
>>> On Mon, Mar 25, 2013 at 11:01 AM, Ista Zahn <***@gmail.com> wrote:
>>>> On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte <***@gmail.com> wrote:
>>>>> John Hendy <***@gmail.com> writes:
>>>>>
>>>>>> On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos <***@hp.com> wrote:
>>>>>>> Eric Schulte <***@gmail.com> 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-***@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 "<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.

I think 24.3 is where they changed python.el to fgallina's python.el. So I'd be
willing to bet that it _is_ the problem since it's a complete rewrite and many
things changed.

-Ivan
Andreas Röhler
2013-03-24 07:47:34 UTC
Permalink
Am 23.03.2013 23:07, schrieb Eric Schulte:
> Andreas Röhler <***@easy-emacs.de> writes:
>
>> Am 21.03.2013 08:43, schrieb Bastien:
>>> Hi Andreas,
>>>
>>> Andreas Röhler <***@easy-emacs.de> writes:
>>>
>>>> Nonetheless, still thinking
>>>>
>>>> let-var session in
>>>>
>>>> org-babel-execute:python
>>>>
>>>> needs the fix.
>>>
>>> I've not been following this thread, can you send a patch with
>>> the fix and the reason for it? Thanks in advance!
>>>
>>
>> Hi Bastien,
>>
>> unfortunately my org-environment isn't ready yet for developing.
>> Might take some time, but I'm on it.
>
> I also haven't been following this thread.
>
> Forgetting a patch for the moment, is it possible to conclusively state
> that there is or isn't a bug in the current ob-python handling and
> naming of sessions? If there is, is there a recipe for reproducing this
> bug?
>
> Thanks,
>

Hi,

Ista proved it works for him.

<CA+vqiLHUWvGOgszTO9981NXXbYhnKmcB-rdHbDY8nEhYpzU-***@mail.gmail.com>

Maybe we all other have incomplete resp. not updated installations?

Best regards,

Andreas
John Hendy
2013-03-24 14:47:50 UTC
Permalink
On Sun, Mar 24, 2013 at 2:47 AM, Andreas Röhler
<***@easy-emacs.de> wrote:
> Am 23.03.2013 23:07, schrieb Eric Schulte:
>>
>> Andreas Röhler <***@easy-emacs.de> writes:
>>
>>> Am 21.03.2013 08:43, schrieb Bastien:
>>>>
>>>> Hi Andreas,
>>>>
>>>> Andreas Röhler <***@easy-emacs.de> writes:
>>>>
>>>>> Nonetheless, still thinking
>>>>>
>>>>> let-var session in
>>>>>
>>>>> org-babel-execute:python
>>>>>
>>>>> needs the fix.
>>>>
>>>>
>>>> I've not been following this thread, can you send a patch with
>>>> the fix and the reason for it? Thanks in advance!
>>>>
>>>
>>> Hi Bastien,
>>>
>>> unfortunately my org-environment isn't ready yet for developing.
>>> Might take some time, but I'm on it.
>>
>>
>> I also haven't been following this thread.
>>
>> Forgetting a patch for the moment, is it possible to conclusively state
>> that there is or isn't a bug in the current ob-python handling and
>> naming of sessions? If there is, is there a recipe for reproducing this
>> bug?
>>
>> Thanks,
>>
>
> Hi,
>
> Ista proved it works for him.
>
> <CA+vqiLHUWvGOgszTO9981NXXbYhnKmcB-rdHbDY8nEhYpzU-***@mail.gmail.com>
>

This opens up a compose window in gmail for me. I think this is the
thread you might have wanted to point to:
- http://www.mail-archive.com/emacs-***@gnu.org/msg68267.html

That only speaks to =:session name= argument <=> resultant python buffer names.

As Andreas pointed out, however, there *are* individuals having issues
with the actual code execution, and persistence across blocks with the
same :session names. That's another mystery I don't think we've
solved.

Ista and myself both get proper functionality, but session name
arguments don't create named buffers. Others are not getting proper
functionality.


John

> Maybe we all other have incomplete resp. not updated installations?
>
> Best regards,
>
> Andreas
>
Andreas Röhler
2013-03-24 15:30:10 UTC
Permalink
Am 24.03.2013 15:47, schrieb John Hendy:
> On Sun, Mar 24, 2013 at 2:47 AM, Andreas Röhler
> <***@easy-emacs.de> wrote:
>> Am 23.03.2013 23:07, schrieb Eric Schulte:
>>>
>>> Andreas Röhler <***@easy-emacs.de> writes:
>>>
>>>> Am 21.03.2013 08:43, schrieb Bastien:
>>>>>
>>>>> Hi Andreas,
>>>>>
>>>>> Andreas Röhler <***@easy-emacs.de> writes:
>>>>>
>>>>>> Nonetheless, still thinking
>>>>>>
>>>>>> let-var session in
>>>>>>
>>>>>> org-babel-execute:python
>>>>>>
>>>>>> needs the fix.
>>>>>
>>>>>
>>>>> I've not been following this thread, can you send a patch with
>>>>> the fix and the reason for it? Thanks in advance!
>>>>>
>>>>
>>>> Hi Bastien,
>>>>
>>>> unfortunately my org-environment isn't ready yet for developing.
>>>> Might take some time, but I'm on it.
>>>
>>>
>>> I also haven't been following this thread.
>>>
>>> Forgetting a patch for the moment, is it possible to conclusively state
>>> that there is or isn't a bug in the current ob-python handling and
>>> naming of sessions? If there is, is there a recipe for reproducing this
>>> bug?
>>>
>>> Thanks,
>>>
>>
>> Hi,
>>
>> Ista proved it works for him.
>>
>> <CA+vqiLHUWvGOgszTO9981NXXbYhnKmcB-rdHbDY8nEhYpzU-***@mail.gmail.com>
>>
>
> This opens up a compose window in gmail for me.


mmh, picked the field thought as message-ID
seems not to work that way.


I think this is the
> thread you might have wanted to point to:
> - http://www.mail-archive.com/emacs-***@gnu.org/msg68267.html
>

rather this

http://www.mail-archive.com/emacs-***@gnu.org/msg68273.html

Cheers
Nick Dokos
2013-03-24 16:58:18 UTC
Permalink
John Hendy <***@gmail.com> wrote:

> ...
> - http://www.mail-archive.com/emacs-***@gnu.org/msg68267.html
>
> That only speaks to =:session name= argument <=> resultant python buffer names.
>
> As Andreas pointed out, however, there *are* individuals having issues
> with the actual code execution, and persistence across blocks with the
> same :session names. That's another mystery I don't think we've
> solved.
>
> Ista and myself both get proper functionality, but session name
> arguments don't create named buffers. Others are not getting proper
> functionality.
>

Right - for my part, the python buffers are not even created, let alone
named correctly; i.e. sessions (named or unnamed) don't work at all.

Whether that's my setup or bugs in ob-python.el, I have no idea at this
point: I haven't had time to investigate.

Nick
John Hendy
2013-03-24 16:59:33 UTC
Permalink
On Sun, Mar 24, 2013 at 11:58 AM, Nick Dokos <***@hp.com> wrote:
> John Hendy <***@gmail.com> wrote:
>
>> ...
>> - http://www.mail-archive.com/emacs-***@gnu.org/msg68267.html
>>
>> That only speaks to =:session name= argument <=> resultant python buffer names.
>>
>> As Andreas pointed out, however, there *are* individuals having issues
>> with the actual code execution, and persistence across blocks with the
>> same :session names. That's another mystery I don't think we've
>> solved.
>>
>> Ista and myself both get proper functionality, but session name
>> arguments don't create named buffers. Others are not getting proper
>> functionality.
>>
>
> Right - for my part, the python buffers are not even created, let alone
> named correctly; i.e. sessions (named or unnamed) don't work at all.
>
> Whether that's my setup or bugs in ob-python.el, I have no idea at this
> point: I haven't had time to investigate.

What OS are you using? I have org setup on my dual boot system with
Win7 and just haven't tried on Windows yet.

John

>
> Nick
Nick Dokos
2013-03-24 18:41:44 UTC
Permalink
> >
> > Whether that's my setup or bugs in ob-python.el, I have no idea at this
> > point: I haven't had time to investigate.
>
> What OS are you using? I have org setup on my dual boot system with
> Win7 and just haven't tried on Windows yet.
>

GNU Emacs 24.3.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of 2012-12-29
Org-mode version 8.0-pre (release_8.0-pre-147-gfbb30a @ /home/nick/elisp/org-mode/lisp/)
Linux 2.6.38-16-generic #67-Ubuntu SMP Thu Sep 6 17:58:38 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

I think (but cannot swear) that I've also tried on more recent Ubuntu (12.04)
with the same results.

Nick
Andreas Röhler
2013-03-25 20:46:08 UTC
Permalink
Am 24.03.2013 19:41, schrieb Nick Dokos:
>>>


running into this, func def seems missing:



Debugger entered--Lisp error: (void-function org-babel-result-cond)
(org-babel-result-cond result-params results (org-babel-python-table-or-string results))
(if (string= (substring org-babel-python-eoe-indicator 1 -1) results) nil (org-babel-result-cond result-params results (org-babel-python-table-or-string results)))
(unless (string= (substring org-babel-python-eoe-indicator 1 -1) results) (org-babel-result-cond result-params results (org-babel-python-table-or-string results)))
(lambda (results) (unless (string= (substring org-babel-python-eoe-indicator 1 -1) results) (org-babel-result-cond result-params results
(org-babel-python-table-or-string results))))("Traceback (most recent call last):\n File \"<stdin>\", line 1, in <module>\nNameError: name 'foo' is not defined\nbye")
(let* ((send-wait (lambda nil (comint-send-input nil t) (sleep-for 0 5))) (dump-last-value (lambda (tmp-file pp) (mapc (lambda (statement) (insert statement) (funcall
send-wait)) (if pp (list "import pprint" (format "open('%s', 'w').write(pprint.pformat(_))" ...)) (list (format "open('%s', 'w').write(str(_))" ...)))))) (input-body
(lambda (body) (mapc (lambda (line) (insert line) (funcall send-wait)) (split-string body "[ \n]")) (funcall send-wait)))) ((lambda (results) (unless (string= (substring
org-babel-python-eoe-indicator 1 -1) results) (org-babel-result-cond result-params results (org-babel-python-table-or-string results)))) (case result-type (output
(mapconcat (function org-babel-trim) (butlast (org-babel-comint-with-output (session org-babel-python-eoe-indicator t body) (funcall input-body body) (funcall send-wait)
(funcall send-wait) (insert org-babel-python-eoe-indicator) (funcall send-wait)) 2) "\n")) (value (let ((tmp-file (org-babel-temp-file "python-")))
(org-babel-comint-with-output (session org-babel-python-eoe-indicator nil body) (let (...) (funcall input-body body) (funcall dump-last-value tmp-file ...) (funcall
send-wait) (funcall send-wait) (insert org-babel-python-eoe-indicator) (funcall send-wait))) (org-babel-eval-read-file tmp-file))))))
org-babel-python-evaluate-session(#<buffer *Python*> "print(foo(100)) \nprint \"bye\"" output ("output" "replace"))
(if session (org-babel-python-evaluate-session session body result-type result-params) (org-babel-python-evaluate-external-process body result-type result-params preamble))
org-babel-python-evaluate(#<buffer *Python*> "print(foo(100)) \nprint \"bye\"" output ("output" "replace") nil)
(let* ((session (org-babel-python-initiate-session (cdr (assoc :session params)))) (result-params (cdr (assoc :result-params params))) (result-type (cdr (assoc
:result-type params))) (return-val (when (and (eq result-type (quote value)) (not session)) (cdr (assoc :return params)))) (preamble (cdr (assoc :preamble params)))
(full-body (org-babel-expand-body:generic (concat body (if return-val (format "\nreturn %s" return-val) "")) params (org-babel-variable-assignments:python params))) (result
(org-babel-python-evaluate session full-body result-type result-params preamble))) (org-babel-reassemble-table result (org-babel-pick-name (cdr (assoc :colname-names
params)) (cdr (assoc :colnames params))) (org-babel-pick-name (cdr (assoc :rowname-names params)) (cdr (assoc :rownames params)))))
org-babel-execute:python("print(foo(100)) \nprint \"bye\"" ((:comments . #1="") (:shebang . #1#) (:cache . "no") (:padline . #1#) (:noweb . "no") (:tangle . "no")
(:exports . "results") (:results . "replace output") (:hlines . "no") (:padnewline . "yes") (:session) (:result-type . output) (:result-params "output" "replace")
(:rowname-names) (:colname-names)))
org-babel-execute-src-block(nil ("python" "print(foo(100)) \nprint \"bye\"" ((:comments . #1="") (:shebang . #1#) (:cache . "no") (:padline . #1#) (:noweb . "no")
(:tangle . "no") (:exports . "results") (:results . "replace output") (:hlines . "no") (:padnewline . "yes") (:session) (:result-type . output) (:result-params "output"
"replace") (:rowname-names) (:colname-names)) "" nil 0))
org-babel-execute-src-block-maybe()
org-babel-execute-maybe()
org-babel-execute-safely-maybe()
run-hook-with-args-until-success(org-babel-execute-safely-maybe)
org-ctrl-c-ctrl-c(nil)
call-interactively(org-ctrl-c-ctrl-c nil nil)
Eric Schulte
2013-03-25 21:37:07 UTC
Permalink
> running into this, func def seems missing:
>
> Debugger entered--Lisp error: (void-function org-babel-result-cond)

My guess is that you have a mixed install. You are mostly running the
Org-mode which ships with Emacs (in which `org-babel-result-cond' is not
defined), but you are running the version of ob-python.el from the
master branch (which expects `org-babel-result-cond' to be defined).

This is an increasingly common problem. Maybe the following can help.
http://orgmode.org/worg/org-faq.html#keeping-current-with-Org-mode-development


--
Eric Schulte
http://cs.unm.edu/~eschulte
Andreas Röhler
2013-03-26 06:29:45 UTC
Permalink
Am 25.03.2013 22:37, schrieb Eric Schulte:
>> running into this, func def seems missing:
>>
>> Debugger entered--Lisp error: (void-function org-babel-result-cond)
>
> My guess is that you have a mixed install. You are mostly running the
> Org-mode which ships with Emacs (in which `org-babel-result-cond' is not
> defined), but you are running the version of ob-python.el from the
> master branch (which expects `org-babel-result-cond' to be defined).
>
> This is an increasingly common problem. Maybe the following can help.
> http://orgmode.org/worg/org-faq.html#keeping-current-with-Org-mode-development
>
>

Hmm, don't see there anything to change wrt to the issue.

Have in my init

(defun ar-load-feature-org-mode ()
(interactive)
(add-to-list 'load-path "MY_PATH/feature-org-mode")
(add-to-list 'load-path "MY_PATH/feature-org-mode/lisp")
(find-file "MY_PATH/feature-org-mode/lisp/ob-python.el")
(load "MY_PATH/feature-org-mode/lisp/org-compat.el" nil t)
(load "MY_PATH/feature-org-mode/lisp/ob-comint.el" nil t)
(load "MY_PATH/feature-org-mode/lisp/ob-emacs-lisp.el" nil t)
(load "MY_PATH/feature-org-mode/lisp/org.el" nil t)
(load "MY_PATH/feature-org-mode/lisp/ob-eval.el" nil t)
(load "MY_PATH/feature-org-mode/lisp/ob.el" nil t)
(load "MY_PATH/feature-org-mode/lisp/ob-python.el")
;; (load "MY_PATH/feature-org-mode/testing/org-test-ob-consts.el" nil t)
;; (load "MY_PATH/feature-org-mode/testing/org-test.el" nil t)
(load-this-directory "MY_PATH/feature-org-mode/lisp")
(org-babel-do-load-languages
'org-babel-load-languages
'(
(sh . t)
(python . t))))

Maybe should unload existing org-mode first.
Checking for existing features yields:

org-agenda org-bbdb org-bibtex org-compat
org-docview org-entities org-exp org-exp-blocks
org-faces org-footnote org-gnus org-html
org-info org-infojs org-irc org-jsinfo
org-list org-loaddefs org-macs org-mew
org-mhe org-pcomplete org-rmail org-src
org-version org-vm org-w3m org-wl

;;;;;;;;

Thanks,

Andreas
Eric Schulte
2013-03-26 12:32:36 UTC
Permalink
Andreas Röhler <***@easy-emacs.de> writes:

> Am 25.03.2013 22:37, schrieb Eric Schulte:
>>> running into this, func def seems missing:
>>>
>>> Debugger entered--Lisp error: (void-function org-babel-result-cond)
>>
>> My guess is that you have a mixed install. You are mostly running the
>> Org-mode which ships with Emacs (in which `org-babel-result-cond' is not
>> defined), but you are running the version of ob-python.el from the
>> master branch (which expects `org-babel-result-cond' to be defined).
>>
>> This is an increasingly common problem. Maybe the following can help.
>> http://orgmode.org/worg/org-faq.html#keeping-current-with-Org-mode-development
>>
>
> Hmm, don't see there anything to change wrt to the issue.
>

The key is timing, i.e., the path to the *newest* version of Org-mode
must be at the front of the load-path before the first time Org-mode is
required. I believe this link is the one I should have sent in my
previous email http://orgmode.org/manual/Installation.html.

Especially important is that

(add-to-list 'load-path "~/path/to/orgdir/lisp")

is at the top of your .emacs.

> Have in my init
>

I don't see where you (require 'org) below, but unless it is always done
interactively and always done after calling your load-feature function,
you're probably out of luck.

>
>
> (defun ar-load-feature-org-mode ()
> (interactive)
> (add-to-list 'load-path "MY_PATH/feature-org-mode")
> (add-to-list 'load-path "MY_PATH/feature-org-mode/lisp")
> (find-file "MY_PATH/feature-org-mode/lisp/ob-python.el")
> (load "MY_PATH/feature-org-mode/lisp/org-compat.el" nil t)
> (load "MY_PATH/feature-org-mode/lisp/ob-comint.el" nil t)
> (load "MY_PATH/feature-org-mode/lisp/ob-emacs-lisp.el" nil t)
> (load "MY_PATH/feature-org-mode/lisp/org.el" nil t)
> (load "MY_PATH/feature-org-mode/lisp/ob-eval.el" nil t)
> (load "MY_PATH/feature-org-mode/lisp/ob.el" nil t)
> (load "MY_PATH/feature-org-mode/lisp/ob-python.el")
> ;; (load "MY_PATH/feature-org-mode/testing/org-test-ob-consts.el" nil t)
> ;; (load "MY_PATH/feature-org-mode/testing/org-test.el" nil t)
> (load-this-directory "MY_PATH/feature-org-mode/lisp")
> (org-babel-do-load-languages
> 'org-babel-load-languages
> '(
> (sh . t)
> (python . t))))
>
> Maybe should unload existing org-mode first.

It is not about "unloading", rather the goal is to *only* load the
newest Org-mode.

Best,

>
> Checking for existing features yields:
>
> org-agenda org-bbdb org-bibtex org-compat
> org-docview org-entities org-exp org-exp-blocks
> org-faces org-footnote org-gnus org-html
> org-info org-infojs org-irc org-jsinfo
> org-list org-loaddefs org-macs org-mew
> org-mhe org-pcomplete org-rmail org-src
> org-version org-vm org-w3m org-wl
>
> ;;;;;;;;
>
> Thanks,
>
> Andreas

--
Eric Schulte
http://cs.unm.edu/~eschulte
Gary Oberbrunner
2013-03-26 21:41:31 UTC
Permalink
I did some further testing. With my patch, my real org-mode python file is
now actually working. There were a few gotchas I didn't understand about
session mode and python and matplotlib:

1. In session mode, you are essentially running an interactive python.
(This is made explicit by my patch, which passes -i).
2. In interactive mode, blank lines are special: they indicate the end of
an indented block. So you have to write your org-mode python a little
differently when using session mode.
3. matplotlib uses an "interactive" backend when started from an
interactive python (sensibly). So you have to set the backend explicitly
when using session mode, or it hangs forever with no indication what's
wrong.
4. ob-python does not handle python errors at all in session mode: it
ignores them silently. This makes it really hard to debug the python code.

I'd like to document #s 1-3; where should that go?
I'd like to work on a patch for #4; it seems like the only thing is to
search in the session buffer for likely error strings. Is there any better
method anyone can think of?

--
Gary
John Hendy
2013-03-26 21:47:20 UTC
Permalink
On Tue, Mar 26, 2013 at 4:41 PM, Gary Oberbrunner <***@oberbrunner.com> wrote:
> I did some further testing. With my patch, my real org-mode python file is
> now actually working. There were a few gotchas I didn't understand about
> session mode and python and matplotlib:
>
> 1. In session mode, you are essentially running an interactive python.
> (This is made explicit by my patch, which passes -i).
> 2. In interactive mode, blank lines are special: they indicate the end of an
> indented block. So you have to write your org-mode python a little
> differently when using session mode.
> 3. matplotlib uses an "interactive" backend when started from an interactive
> python (sensibly). So you have to set the backend explicitly when using
> session mode, or it hangs forever with no indication what's wrong.
> 4. ob-python does not handle python errors at all in session mode: it
> ignores them silently. This makes it really hard to debug the python code.
>
> I'd like to document #s 1-3; where should that go?
> I'd like to work on a patch for #4; it seems like the only thing is to
> search in the session buffer for likely error strings. Is there any better
> method anyone can think of?

You should probably create ob-doc-python:
- http://orgmode.org/tmp/worg/org-contrib/babel/languages.html

If you haven't contributed before:
- http://orgmode.org/worg/worg-git.html

Once you clone (after submitting ssh key) with =git clone
***@orgmode.org:worg.git=, you'd create:

~/path/to/worg.git/org-contrib/babel/languages/ob-doc-python.org

There's a template at:

~/path/to/worg.git/org-contrib/babel/languages/ob-doc-template.org

Thanks for doing this! I can't believe there's no existing page for
Python on Worg. Maybe you can document more than just this, too :)


John

>
> --
> Gary
Andreas Röhler
2013-03-27 06:19:02 UTC
Permalink
Am 26.03.2013 22:41, schrieb Gary Oberbrunner:
> I did some further testing. With my patch, my real org-mode python file is
> now actually working. There were a few gotchas I didn't understand about
> session mode and python and matplotlib:
>
> 1. In session mode, you are essentially running an interactive python.
> (This is made explicit by my patch, which passes -i).
> 2. In interactive mode, blank lines are special: they indicate the end of
> an indented block. So you have to write your org-mode python a little
> differently when using session mode.
> 3. matplotlib uses an "interactive" backend when started from an
> interactive python (sensibly). So you have to set the backend explicitly
> when using session mode, or it hangs forever with no indication what's
> wrong.
> 4. ob-python does not handle python errors at all in session mode: it
> ignores them silently. This makes it really hard to debug the python code.
>
> I'd like to document #s 1-3; where should that go?
> I'd like to work on a patch for #4; it seems like the only thing is to
> search in the session buffer for likely error strings. Is there any better
> method anyone can think of?
>

AFAIU the error string is missing, because it's sent the wrong path-to-interpreter,
i.e. using shell-command.
Shell returns 0 or 1, not the Python errors.

Also the interactive spec is related. Usually Python shell as started from py-shell or run-python include this already.
When send from a python-mode, also the empty lines you mentioned and related stuff is treated.

Andreas
Andreas Röhler
2013-03-30 07:19:37 UTC
Permalink
Am 27.03.2013 07:19, schrieb Andreas Röhler:
> Am 26.03.2013 22:41, schrieb Gary Oberbrunner:
>> I did some further testing. With my patch, my real org-mode python file is
>> now actually working. There were a few gotchas I didn't understand about
>> session mode and python and matplotlib:
>>
>> 1. In session mode, you are essentially running an interactive python.
>> (This is made explicit by my patch, which passes -i).
>> 2. In interactive mode, blank lines are special: they indicate the end of
>> an indented block. So you have to write your org-mode python a little
>> differently when using session mode.
>> 3. matplotlib uses an "interactive" backend when started from an
>> interactive python (sensibl

y). So you have to set the backend explicitly
>> when using session mode, or it hangs forever with no indication what's
>> wrong.
>> 4. ob-python does not handle python errors at all in session mode: it
>> ignores them silently. This makes it really hard to debug the python code.
>>
>> I'd like to document #s 1-3; where should that go?
>> I'd like to work on a patch for #4; it seems like the only thing is to
>> search in the session buffer for likely error strings. Is there any better
>> method anyone can think of?
>>
>
> AFAIU the error string is missing, because it's sent the wrong path-to-interpreter,
> i.e. using shell-command.
> Shell returns 0 or 1, not the Python errors.
>
> Also the interactive spec is related. Usually Python shell as started from py-shell or run-python include this already.
> When send from a python-mode, also the empty lines you mentioned and related stuff is treated.
>
> Andreas
>
>
>

That turned out not being the case. I'm quoting:

> This is incorrect. In session mode, there is one long-running python
> interpreter session. Emacs passes it code snippets, and it spits out
> stdout and stderr (all mixed up: output from your program, the lines
> themselves which get echoed, prompts, and error messages if any). There is
> never any "return" value since the python interpreter doesn't exit. The
> only way to handle errors in interactive mode AFAICS is to use approximate
> regexes to look for errors, un-handled exceptions and so on.
>

Cheers
Continue reading on narkive:
Loading...