posit-dev / posit-dev/ark

Implement Positron functionality in separate modules

Open
#587 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

area: jupyter kernel infra: code-organization
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.