Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ark: Decouple LSP and kernel? #3180

Open
lionel- opened this issue May 17, 2024 · 0 comments
Open

Ark: Decouple LSP and kernel? #3180

lionel- opened this issue May 17, 2024 · 0 comments
Labels
area: kernels Issues related to Jupyter kernels and LSP servers lang: r

Comments

@lionel-
Copy link
Contributor

lionel- commented May 17, 2024

Currently the LSP and the Jupyter kernel are quite tangled with each other through the use of r_task().

  • This has performance and safety implications, see Ark: Infrastructure: Reduce concurrent R evaluations to a minimum #2322

  • This prevents LSP features from working while the R session is disconnected or shut down. A shutdown R can happen early at startup during runtime discovery, or if the user disabled automatic startup, or if they closed the session. I've noticed that it's puzzling to have different indentation behaviour depending on the availability of the LSP for instance. This sort of issue will become more visible as we ramp up our formatting capabilities through the LSP.

If we make sufficient progress with #2322 (avoid concurrent R calls) and #2321 (use static analysis where possible), we should be able to pull out the LSP from the kernel and maintain a permanent session in the frontend. The LSP would then communicate with the kernel through a Jupyter comm, e.g. to receive updates about global console scopes (global env, search path, etc) between top-level R evaluations.

One problematic aspect is the generation of help pages which does require calling R. We'd need a side session to populate these. It's unclear what we could do regarding help from devtools during development though.

A middle ground would be to decouple only parts of the LSP and run two instances, one in the frontend and the other in the backend. This would likely require implementing our own VS Code providers to select the correct instance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: kernels Issues related to Jupyter kernels and LSP servers lang: r
Projects
None yet
Development

No branches or pull requests

2 participants