Implement Positron functionality in separate modules
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 337
- Forks
- 32
- Avg merge
- 8d 17h
- Merged PRs (30d)
- 11
Description
Currently RMain knows quite a lot about the Positron comms. For instance RMain has a channel to get events from the UI comm and send UI comm requests to the frontend. There are two main tasks to achieve that:
To make progress towards https://github.com/posit-dev/positron/issues/3608, we should remove all of that state and logic in separate modules with a clean boundary. The external components would then register handlers to be called at various points:
- Show message
- Busy
- Top-level refresh (run after each execute-request has completed)
The handlers would be called from the R thread, and so it would be safe for them to call the R API. RMain would allow for a list of handlers, meaning
that multiple external components could register handlers for Busy, for example.
They would also be passed some state:
-
For example refresh handlers would be passed a reference to the prompt info.
-
In the future they could receive a reference to the current structure of the global and debug environments. Ark would be in charge of creating this representation, stopping when it's too deeply nested, etc. All components (variables, LSP, DAP) would consume this representation.
One difficulty wrt the UI comm is RMain::call_frontend_method(). Currently, when an RStudio API method needs some information from the frontend, this sequence happens:
- .Call() into the Rust side
- The Rust side calls
RMain::get()to get the global singleton - Then
RMain::call_frontend_method()is called.
Retrieving a global singleton in this way is necessary because R routines do not know anything about the current state of Ark. But the singleton doesn't need to be RMain. Ideally they would know nothing about RMain. So we could create a similar singleton for UiComm that would be set up when UiComm::start() is called.
One difficulty is that call_frontend_method() needs the currently active request's originator to be able to create an StdIn request. Since the active request live on RMain, we need to fix that first (https://github.com/posit-dev/ark/issues/586).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with RMain, RMain::call_frontend_method(), and the prerequisite in issue #586 to understand the active-request dependency. Then map the UI comm state and logic into separate modules with registered handlers, and define UiComm::start() as the relevant singleton setup point; done means external components can register for the listed events without depending on RMain.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- r, rust
- Domain
- backend-api-design
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 28/100