Traceback errors and unresponsive asynchronous execution

[roblem]

Run this simple codeblock with the obvious syntax error when defining columns in the dataframe:

#+NAME: neptune-seven-five-missouri
#+BEGIN_SRC ipython :session
import numpy as np
import pandas as pd

df = pd.DataFrame(np.random.randn(2,2),columns = ['a','b')
df.head()
#+END_SRC

On first running,

1. A ob-ipython-traceback buffer is created and it points to the line with the problem in the code

   File "<ipython-input-1-2b742a6354e7>", line 4
   df = pd.DataFrame(np.random.randn(2,2),columns = ['a','b')
                                                            ^
   SyntaxError: invalid syntax

2. The traceback instance doesn't pop up. Manually switching to it and pressing q takes the cursor to the top of the offending codeblock at #+NAME: neptune-seven-five-missouri and no line numbers appear
3. This pops up in the messages buffer:

   error in process filter: save-current-buffer: Search failed: "-+> \\([0-9]+\\)"
   error in process filter: Search failed: "-+> \\([0-9]+\\)"

4. The ob-ipython-traceback remains open and I have to manually kill it.

So now I fix the code and rerun it:

#+NAME: neptune-seven-five-missouri
#+BEGIN_SRC ipython :session
import numpy as np
import pandas as pd

df = pd.DataFrame(np.random.randn(2,2),columns = ['a','b'])
df.head()
#+END_SRC

1. I get this below the codeblock which looks ok:

   #+RESULTS: neptune-seven-five-missouri
   :RESULTS:
   [[async-queued: neptune-seven-five-missouri output]]
   :END:

2. However, it remains unresponsive. Clicking [[async-queued: neptune-seven-five-missouri output]] and re-executing the codeblock and it is still unresponsive and this shows up in the messages buffer

   Contacting host: localhost:9988
   Code block evaluation complete.
   Mark set
   Code block evaluation complete.

At this point, I have tried killing all ob-ipython buffers and re-executing which sometimes works. Restarting emacs however is often necessary.

Running on linux (occurred on Fedora 25 and 26 with anaconda python 3.6 virtual environment).

[jkitchin]

That is indeed a bug. I pushed a fix that might address part of the issue.

I use these commands to restart: M-x nuke-ipython, which does a pretty good job I think of killing all the processes, and I have not had to restart emacs in a while with it. Also, M-x debug-ipython will show a lot of info in an org-buffer about what is queued, etc.

[jkitchin]

The problem you were seeing is the queue variables were not getting cleared, so it looked like the block was still in the queue.

[roblem]

Thanks, In my very limited testing, this seems to be a good workaround to my problem, unless I am running a codeblock with a syntax error (e.g. my first codeblock above) in a document where the ipython kernel hasn't been initiated, execution freezes, and I have to click

:RESULTS:
[[async-running: neptune-seven-five-missouri output]]
:END:

and I see this in messages:

Killed kernel-default
error in process sentinel: url-http-parse-response: Trying to parse HTTP response code in odd buffer:  *http localhost:9988*
error in process sentinel: Trying to parse HTTP response code in odd buffer:  *http localhost:9988*

Sometimes resubmitting works (and dumps the traceback in the results output) but most of the time, I have tonuke-ipython. As soon as I execute a valid codeblock with no syntax error, further errors like this one are handled by your workaround.

[jkitchin]

I can't reproduce the freezing behavior. I just pushed a few more additions to handle syntax errors better. It turns out they are different than the other exceptions. Hopefully it works for you. There seems to be a combinatorial growth of ways to use this now with sync vs async, org results vs tracebacks, etc. so testing is getting tricky.

[roblem]

Thanks. Aside from the very small remaining issue outlined above, your two commits fix this. I'll leave it to you if you want to close. Loving Scimax.

[jkitchin]

which issues are still unresolved?

[roblem]

I also can't reproduce the freezing behavior I encountered referenced above, so closing.