Strange interaction with matplotlib magic
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 38/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- python
- Lĩnh vực
- backend-api-design
Hướng nghiên cứu
Tái hiện vòng lặp thực thi bằng jupyter_client và ipykernel với %matplotlib qt, so sánh thông báo iopub execution_state: idle với wait_for_ready sau một exception. Theo dõi hành vi abort của kernel và xác định tín hiệu nào cho phép một cách đáng tin cậy yêu cầu thực thi tiếp theo; hoàn thành có nghĩa là đã hiểu thứ tự và hành vi được báo cáo có một cách giải quyết đã được xác minh.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Ngôn ngữ chính
- Python
- Star
- 734
- Fork
- 411
- Merge trung bình
- 1 ngày 2 giờ
- Pull request đã merge (30 ngày)
- 9
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của ipython/ipykernel
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 72/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 68/100
-
ipython/ipykernel#1550 · 1 bình luận · 1 reaction · 1 người được giao ·
Tất cả issue của ipython/ipykernel
Issue tương tự
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
canonical/paas-charm#368 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
tech debt
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
addition to tracking list Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
StevenBlack/hosts#3256 ·
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
qualcomm/qai-appbuilder#275 ·