Extra output in console

Describe the bug I see additional output in the Debug Console.

To Reproduce Steps to reproduce the behavior:

1. Debug any R file.

Your R code Any code.

Your Launch config If applicable, the launch config that causes the bug. E.g.:

            {
                "name": "R: Current File",
                "presentation": {
                    "group": "00 User",
                    "order": 20,
                },
                "type": "R-Debugger",
                "request": "launch",
                "file": "${fileDirname}/${fileBasenameNoExtension}.R",
                "debugMode": "file",
                "allowGlobalDebugging": true,
                "workingDirectory": "${fileWorkspaceFolder}",
            },

Actual behavior

Amounts vary - it can be as little as

})()

and as much as

        else {
            attributes(err) <- list()
            message <- err
        }
        body <- list(message = message)
        sendWriteToStdinEvent("", when = "browserPrompt", count = 0)
        session$clearStackTree <- TRUE
        sendStoppedEvent("exception", description = "Stopped on Exception", 
            text = message)
        browser()
    }
    else {
        logPrint("showing traceback!!!")
        traceback()
        unregisterEntryFrame()
    }

Desktop (please complete the following information):

• OS: Windows 10 21H1, Remote SSH into Linux
• R Version: 4.0.4
• vscDebugger Version: 0.4.6
• vscode-r-debugger Version: 0.4.6

Additional context https://github.com/ManuelHentschel/vscDebugger/blob/0fa6d6177ae9ded53b0c4b60c157b2377d915dfe/R/flow.R#L38-L43

[ManuelHentschel]

I can still repro the issue with "r.debugger.timeouts.prompt": 1, but it’s almost completely gone with "r.debugger.timeouts.prompt": 2, and I have yet to see it with "r.debugger.timeouts.prompt": 3 (or 10 or 100). Great! I’ll keep it at 3 for now to see if it’s stable, and increase as needed.

Good to hear that the fix works for you. Since the delay does not seem to be necessary in most cases, I’ll leave the defaul at 0, but it probably makes sense to add a note about this to the readme.

By the way (different issue?), can you explain the error message

This is an interesting edge case. Most of the time, the result of parse(...) is a subsettable object (i.e. list-like), which the .vsc.debugsource function iterates over to evaluate all entries. But apparently if there is just one R-symbol in the file, the result is a single object, which cannot be iterated over.

I never encountered this, since my “minimal” example was always sth. like print(123). An empty file also throws a weird error, I’ll try to fix these soon, thanks for noticing.

[bersbersbers]

Wow. What a difference 2 milliseconds can make 😃 I uninstalled the extensions everywhere and re-installed the vsix one on the remote system.

I can still repro the issue with "r.debugger.timeouts.prompt": 1, but it’s almost completely gone with "r.debugger.timeouts.prompt": 2, and I have yet to see it with "r.debugger.timeouts.prompt": 3 (or 10 or 100). Great! I’ll keep it at 3 for now to see if it’s stable, and increase as needed.

By the way (different issue?), can you explain the error message

Error in body[[i]][[1]] : object of type 'symbol' is not subsettable

When I do

echo "error" | Rscript -

I get

Error: object 'error' not found
Execution halted

and something like this is what I’d expect in VS Code, too.

In other cases, the error messages are functionally identical:

echo "print(error)" | Rscript -
Error in print(error) : object 'error' not found
Execution halted