Closed roblem closed 7 years ago
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.
The problem you were seeing is the queue variables were not getting cleared, so it looked like the block was still in the queue.
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.
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.
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.
which issues are still unresolved?
I also can't reproduce the freezing behavior I encountered referenced above, so closing.
Run this simple codeblock with the obvious syntax error when defining columns in the dataframe:
On first running,
ob-ipython-traceback
buffer is created and it points to the line with the problem in the codeq
takes the cursor to the top of the offending codeblock at#+NAME: neptune-seven-five-missouri
and no line numbers appearob-ipython-traceback
remains open and I have to manually kill it.So now I fix the code and rerun it:
[[async-queued: neptune-seven-five-missouri output]]
and re-executing the codeblock and it is still unresponsive and this shows up in the messages bufferAt 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).