Use new Jupyter supervisor by default in desktop mode #5262
Labels
area: core
Issues related to Core category.
area: kernels
Issues related to Jupyter kernels and LSP servers
Milestone
Comments
jmcphers
added
area: kernels
This was referenced Nov 7, 2024
jmcphers
added a commit
that referenced
this issue
Nov 8, 2024
…5299) This change brings Kallichore out of experimental mode and makes it the default for all environments (server and desktop). <img width="430" alt="image" src="https://github.com/user-attachments/assets/4809ca1b-2e87-473d-963e-a7d49a8bd416"> It also rebrands the supervisor, removing its codename and referring to it instead as the "Positron Kernel Supervisor". The extension has also been renamed, from `kallichore-adapter` to `positron-supervisor` to group it with our other extensions and make the name more meaningful. It contains some improvements to logging; formerly you had to let Kallichore run in a visible terminal to see its logs. Now its logs are also streamed to the "Positron Kernel Supervisor" output channel. (This doesn't increase the number of output channels, as this channel replaces the "Kallichore Adapter" channel.) Finally, it includes a fix for a bug that could cause cell execution hangs when switching notebook kernels rapidly under the new supervisor. This issue was found via an automated test; the fix is to clean up some references to the notebook's interpreter session as soon as we know the kernel has exited (whether via an exit state change or exit event). The change does _not_ remove the Jupyter Adapter. The Jupyter Adapter remains, for now, as a troubleshooting tool (i.e. if we're seeing any unexpected behavior and suspect it is caused by the supervisor, we can switch back to the adapter to compare notes). My hope is to have the supervisor as the default in the 2024.12 release, and to be able to remove the Jupyter Adapter entirely in 2025.01 or 2025.02. Addresses #5262. ### QA Notes - If you find any issues, please include lines from the new Positron Kernel Supervisor output channel that seem relevant. - This change passes the full suite of Electron tests. https://github.com/posit-dev/positron/actions/runs/11714219722/attempts/1 - This change should not break Reticulate, because Reticulate always uses the Jupyter Adapter. Positron can mix and match supervisors, so it's fine for R/Python to use Kallichore even when Reticulate is using the Adapter. - I'm hopeful this will address some of the "socket disposed" / "address in use" errors we sometimes see in tests, since Kallichore has some code that tries to reduce the odds of these things happening. However, it is difficult to completely eliminate this problem since it's due to a race condition that is built into the protocol. See posit-dev/kallichore#2 for more notes and planned work. --------- Signed-off-by: Jonathan <jonathan@posit.co> Co-authored-by: sharon <sharon-wang@users.noreply.github.com>
Verified FixedTest scenario(s)Looking good locally and in automation runs Link(s) to TestRail test cases run or created: |
jmcphers
added a commit
that referenced
this issue
Nov 19, 2024
…5299) This change brings Kallichore out of experimental mode and makes it the default for all environments (server and desktop). <img width="430" alt="image" src="https://github.com/user-attachments/assets/4809ca1b-2e87-473d-963e-a7d49a8bd416"> It also rebrands the supervisor, removing its codename and referring to it instead as the "Positron Kernel Supervisor". The extension has also been renamed, from `kallichore-adapter` to `positron-supervisor` to group it with our other extensions and make the name more meaningful. It contains some improvements to logging; formerly you had to let Kallichore run in a visible terminal to see its logs. Now its logs are also streamed to the "Positron Kernel Supervisor" output channel. (This doesn't increase the number of output channels, as this channel replaces the "Kallichore Adapter" channel.) Finally, it includes a fix for a bug that could cause cell execution hangs when switching notebook kernels rapidly under the new supervisor. This issue was found via an automated test; the fix is to clean up some references to the notebook's interpreter session as soon as we know the kernel has exited (whether via an exit state change or exit event). The change does _not_ remove the Jupyter Adapter. The Jupyter Adapter remains, for now, as a troubleshooting tool (i.e. if we're seeing any unexpected behavior and suspect it is caused by the supervisor, we can switch back to the adapter to compare notes). My hope is to have the supervisor as the default in the 2024.12 release, and to be able to remove the Jupyter Adapter entirely in 2025.01 or 2025.02. Addresses #5262. - If you find any issues, please include lines from the new Positron Kernel Supervisor output channel that seem relevant. - This change passes the full suite of Electron tests. https://github.com/posit-dev/positron/actions/runs/11714219722/attempts/1 - This change should not break Reticulate, because Reticulate always uses the Jupyter Adapter. Positron can mix and match supervisors, so it's fine for R/Python to use Kallichore even when Reticulate is using the Adapter. - I'm hopeful this will address some of the "socket disposed" / "address in use" errors we sometimes see in tests, since Kallichore has some code that tries to reduce the odds of these things happening. However, it is difficult to completely eliminate this problem since it's due to a race condition that is built into the protocol. See posit-dev/kallichore#2 for more notes and planned work. --------- Signed-off-by: Jonathan <jonathan@posit.co> Co-authored-by: sharon <sharon-wang@users.noreply.github.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Currently, the experimental Jupyter kernel supervisor ("Kallichore") is used as the default in Positron Workbench, but we use a totally different supervisor (the "Jupyter Adapter") by default in Positron Desktop. We should make the new supervisor the default in Positron Desktop, too; it is expensive to maintain two different supervisors, and the old supervisor has some known issues we don't plan to fix.
Details:
The text was updated successfully, but these errors were encountered: