Strange interaction with matplotlib magic
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 38/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- python
調査の方向性
%matplotlib qt を使用し、jupyter_client と ipykernel で実行ループを再現して、例外発生後の iopub execution_state: idle メッセージと wait_for_ready を比較する。カーネルの中断動作を追跡し、次の実行リクエストを確実に許可するシグナルを特定する。完了の条件は、順序が理解され、報告された動作に検証済みの解決策があることである。
索引モデルが issue の本文から書いたものです。
説明
I have an app that uses jupyter_client to interact with an ipykernel. In that app I have an execution loop that sends an execute request and then waits for a reply on the iopub channel that has "execution_state": "idle". I assume that when this message is received it is done executing and ready to execute something else. I never send a second execute request until I get the idle-state reply.
This works until I use the %matplotlib magic to load a gui backend (e.g., %matplotlib qt). After that, things begin to behave strangely. If I send code to execute, and that code raises an exception, I get the error reply normally. But then whatever code I send next is aborted without ever being executed. I can only assume this is due to some interaction with the gui event loop that that matplotlib magic is creating, but I can't figure out exactly where the problem lies. It seems that the "stop aborting" event somehow is not processed until after the next execution request I send (even if the app just sits idle in between the exception-raising code and my next execution request). In other words things seem to happen out of order: I send a request, it raises an exception, the kernel "aborts the queue" (even though there are no other requests in the queue), I then send a new request, and the kernel then aborts that (even though it wasn't in the queue when the kernel decided to abort).
I'm not sure if this is a problem with ipykernel or with jupyter_client, but I'm posting here to see if there's something else I should be doing on the jupyter_client end. In particular, I want to know what message I need to wait for after submitting an execution request that tells me "the kernel is done processing, the next execution request you send will be processed and will not be aborted because of some lingering earlier error". I thought that was the idle-state message, but apparently not, because when I receive that message it seems the kernel might still be in a state where it is going to abort whatever I send it (because it thinks they were all part of one execution queue). Right now I fixed it by inserting a wait_for_ready call after each execution, but I'm not sure if that is overkill or could have any other unexpected effects.
Originally opened as jupyter/jupyter_client#904 by @BrenBarn, migration requested by @blink1073
- 主要言語
- Python
- スター
- 734
- フォーク
- 411
- 平均マージ
- 1日 2時間
- マージ済み PR(30日)
- 9
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
ipython/ipykernel のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 68/100
ipython/ipykernel の issue をすべて見る
似ている issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 90/100
learningequality/ricecooker#747 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
BSData/horus-heresy-3rd-edition#3171 ·
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
run-llama/llama_index#23199 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
KhronosGroup/glTF-Blender-IO#2769 ·