Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Future R Language change requests / contributions

Open
  • Is something wrong?
#4 8 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
22/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
r
Domain
devtools

Research direction

Start by reviewing the requested R-language and browser-hook changes, especially the linked src/main/eval.c lines 1313-1315 and the referenced vscDebugger discussion. Determine which limitation remains actionable in debugadapter and whether it belongs upstream in R. Done would require narrowing this catalog to one decided, implementable request with an agreed validation path.

Written by the indexing model from the issue text.

Description

While developing this, I found that there are a few features that are unfortunately quite difficult to implement. Some of which can be made significantly simpler with a few changes to the R language. This issue catalogs those changes.

Change Requests

❓ Top level pre-execution hook

Currently we have addTaskCallback to register callbacks for code to run after a top level expression, but unfortunately have no mechanism of registering code to run before each top level expression.

Without this feature, debug statements are processed only upon each top level expression's completion in the REPL, meaning that the state of the debugger in the REPL lags behind the state of the debugger in the IDE and is only synchronized after a top level callback.

With this feature, any new breakpoint traces can be set before user input is evaluated, minimizing debugger state desync.

✅ Browser callback hooks

Currently a "shadow" browser is used, which introduces an enormous amount of complexity to the project. The browser prompt is a fixed part of the R language with almost no opportunities to inject code in its REPL. To handle this, a process is forked and its output is split between the REPL presented to the user while commands and output required for the debugger are hidden and communicate directly with the DAP server.

Instead, if hooks could be added to the browser REPL akin to the standard REPL task callbacks, then this code could be executed in the foreground process directly without cluttering the REPL output with messy server messaging calls.

Step Information in Browser Hook

  • Getting access to the expression that is being debugged, not just the sys.call(). Ideally with position information within the evaluating function. This seems to be accessible in-between browser steps at the C level (SrcrefPrompt, but I can't figure out how to grab this information on the R side. Update: this is available in debug() prompts, but not browser() prompts
  • Would be nice to have some information about what stepping commands are issued in the browser hook (n, s, c, etc)
  • condition argument of debug() appears to be broken? 
    f <- function(x) { x }
debug(f, condition = list(test = 123))
f()
#> Browse[1]> browserCondition()
#> NULL
  • Would love a way to disable the debug at <file>#<line>: ... text that gets spit out during each debug step now that browser hooks allow for custom-built prompts.
Other mentions of this limitation

The core challenge imposed by having a rather fixed debug browser was also felt in the vscDebugger project, which got around this challenge by running a separate R process governed by javascript. This method relies on parsing of stdout.

from https://github.com/ManuelHentschel/VSCode-R-Debugger/issues/156#issuecomment-990167766

The main problem with the vscDebugger package is that there seems to be no way to control the program flow (stepping through code while debugging) from within R itself. Therefore, I am using a node-based wrapper, which controls the input to/output from an R process underneath.

Dominant language
R
Stars
20
Forks
2
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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.

More from dgkf/debugadapter

All issues in dgkf/debugadapter

Similar issues

More R issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.