| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks!
Sorry, something went wrong.
|
We will need a new release of ipympl with this before ipykernel 7.0.0 is released. I think it could be 0.9.8 as this isn't really new functionality, or 0.10.0 is that is preferred. |
Sorry, something went wrong.
|
Sounds good! We can make it 0.9.8 |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
The upcoming ipykernel 7.0.0 release will support subshells which are separate threads of execution within a kernel process. JupyterLab has already been updated to deal with subshells on kernels that support them and this includes options for running comms over subshells (jupyterlab/jupyterlab#17363). This PR contains changes that are needed in ipympl to support subshells, specifically use of a threading.Lock in the python code that accesses global state such at Matplotlib's Gcf and ipython.display. Without this we see problems such as plots not being displayed as one thread can be, for example, modifying a collection in Gcf whilst another is reading it. Strictly speaking we only need to lock when one thread is writing to a global as we can tolerate multiple non-modifying reads at the same time, but I have preferred to keep the changes as simple and understandable as possible but putting the locks at a high level in each of the functions that needs it.
Above is a screenshot reproducing the problem using latest commit 5e068ed, showing that the third plot is not displayed. To reproduce this use the latest jupyterlab and precisely ipykernel==7.0.0a2, and in Lab's Settings Editor select "Kernel comms over subshells" to be "One subshell per comm-target". It does not occur every time, but this is the setting that I have found most likely to produce the problem. After this PR, all plots display correctly.