vscode-R icon indicating copy to clipboard operation
vscode-R copied to clipboard

Diagnostics seem to have stopped working properly after merge with R-LSP

Open mcrates opened this issue 4 years ago • 10 comments

Describe the bug It could be coincidental, but it seems that after the R-lsp extension was merged into the Regular R Extension that the R.Diagnostics and the Linting are no longer functioning as expected

To Reproduce When I noticed it was no longer giving me diagnostics I thought that it could be due to all my other extensions (none related to R) and so I did a total fresh install of VS Code with no Extensions as well as reinstalling the language server.

I Installed the R Extension, Restarted VS Code And then it was working again. But soon after I noticed it stopped again and now it seems very inconsistent as it has worked again twice at random moments that I can't replicate

Do you want to fix by self? (We hope your help!)

Yes

Expected behavior The system should display when either errors or warnings are occurring See the screenshot below for an example

Screenshots Untitled2

Environment (please complete the following information):

  • OS: Windows
  • VSCode Version: 1.58.2 (System Setup)
  • R Version: 4.0.1
  • vscode-R version: 2.1.0

Additional context Again, this could be an unrelated issue to the merge with the R-LSP Client, but for me it seemed to occur out of nowhere close to when the merge occurred!

Any help to fix this would be highly appreciated!

mcrates avatar Jul 27 '21 02:07 mcrates

I can't say that I have experienced this on WSL. Is there an error in the "R Language Server" output stream?

image

ElianHugh avatar Jul 27 '21 02:07 ElianHugh

Oh I didn't know I could tap into it like that, thanks alot! And yeah there is an error:

`[2021-07-27 12:52:23.422] parse session init error 1 { "code": 501, "message": "R session crashed with exit code 1", "result": null, "stdout": "", "stderr": "Error in FUN(X[[i]], ...) : \r\n no such symbol processx_base64_encode in package C:/Users/USERNAME/AppData/Local/Temp/RtmpslEq5s/callr-client-x64-f88ac42.dll\r\nCalls: callr_startup_hook ... <Anonymous> -> getNativeSymbolInfo -> lapply -> FUN\r\nBacktrace:\r\n1: stop(msg, domain = NA)\r\n2: FUN(X[[i]], ...)\r\n3: lapply(name, function(id) {\r\n4: getNativeSymbolInfo("processx_base64_encode", lib)\r\n5: data$load_client_lib(data$sofile[[paste0("arch-", .Platform$r_arch)]], \r\n6: callr_startup_hook()\r\n", "error": { "message": "R session crashed with exit code 1" } }

[2021-07-27 12:52:23.422] parse session restart 1`

Any idea what that could mean? Thanks alot!

ghost avatar Jul 27 '21 03:07 ghost

Looks like your callr package is not installed properly. You might need to exit all R sessions and reinstall callr via install.packages("callr").

renkun-ken avatar Jul 27 '21 03:07 renkun-ken

Thanks for that, I have given it a try and came to mixed results. It seems that I am getting diagnostics on my file, but only once now, but fixing an error made on purpose does not make it go away.

And the R Language Server Output is still almost the same, (first and last line appear to be different)

[2021-07-28 06:22:44.158] parse session init error 3 {
  "code": 501,
  "message": "R session crashed with exit code 1",
  "result": null,
  "stdout": "",
  "stderr": "Error in FUN(X[[i]], ...) : \r\n  no such symbol processx_base64_encode in package C:/Users/_USERNAME_/AppData/Local/Temp/Rtmp61wHqo/callr-client-x64-f88ac42.dll\r\nCalls: callr_startup_hook ... <Anonymous> -> getNativeSymbolInfo -> lapply -> FUN\r\nBacktrace:\r\n1: stop(msg, domain = NA)\r\n2: FUN(X[[i]], ...)\r\n3: lapply(name, function(id) {\r\n4: getNativeSymbolInfo(\"processx_base64_encode\", lib)\r\n5: data$load_client_lib(data$sofile[[paste0(\"arch-\", .Platform$r_arch)]], \r\n6: callr_startup_hook()\r\n",
  "error": {
    "message": "R session crashed with exit code 1"
  }
}

[2021-07-28 06:22:44.158] parse session restart 3

ghost avatar Jul 27 '21 20:07 ghost

Does the error above occurs to all files or just spcific files? Does it always occur or randomly occur?

Would you like to try the following code:

callr::r(function(file) {
    uri <- languageserver:::path_to_uri(file)
    content <- readLines(file)
    languageserver:::diagnose_file(uri, content)
}, list(file = "/path/to/your/file.R"), system_profile = TRUE, user_profile = TRUE)

where file= argument should be replaced with your R file.

renkun-ken avatar Jul 29 '21 06:07 renkun-ken

If it works before the integration of vscode-r-lsp, then you might want to try setting "r.lsp.enabled": false (which disabled vscode-R language service), and install vscode-r-lsp from marketplace. If this works for you, then it implies that there is something wrong with the integration.

renkun-ken avatar Jul 29 '21 08:07 renkun-ken

Thanks a lot renkun for all your assistance! So, I did some testing to try and confirm a few things;

  • It looks like my issues are unrelated to the integration, I get the same issues using the R-LSP Extension as I do when using the new integrated one, (so it must have been coincidental when I noticed my issue!)

  • It always occurs with the error appearing about twice every second

  • It happens on any r file I have, even a newly created one

  • Eventually (it seems to depend on the length of the file/number of errors/warning) it will work and it gives the following message:

[2021-07-30 08:21:59.647] diagnostics session ready 2 2021-07-30 08:21:59
[2021-07-30 08:22:00.257] diagnostics session released session_id = 2 remain pool size = 3
[2021-07-30 08:22:00.257] diagnostics_callback called:...
...
[2021-07-30 08:22:00.257] deliver:  ["Notification", "Message", "R6"]
[2021-07-30 08:22:00.257] method:  textDocument/publishDiagnostics
[2021-07-30 08:22:00.257] diagnostics task timing: 9.40971231857936   file:.....
[2021-07-30 08:22:00.897] received:  Content-Length: 286

[2021-07-30 08:22:00.913] received payload.
[2021-07-30 08:22:00.913] handling request:  textDocument/codeAction
[2021-07-30 08:22:00.913] text_document_code_action:  {...
 
[2021-07-30 08:22:00.913] deliver:  ["Response", "Message", "R6"]
  • The code you gave me to manually run it seems to always work, giving results like this
 [1]]
[[1]]$range
$start
$line
[1] 7
$character
[1] 59
attr(,"class")
[1] "position"
$end
$line
[1] 7
$character
[1] 60
attr(,"class")
.........

So it will work on very tiny files with no error pretty quickly, but on any normal or large sized file the diagnostics are taking up to 20minutes to appear, and then will not update for another set time up to 20 minutes (Which I assume is caused by those non-stop errors).

Thanks again for the help!

ghost avatar Jul 29 '21 22:07 ghost

Looks like your diagnostics runs quite slowly there. It could be either caused by slow callr session communication or lintr::lint. Would you like to try the following with file replaces with the file path that is slowest to lint:

system.time({
    file <- "/path/to/your/file.R"
    uri <- languageserver:::path_to_uri(file)
    content <- readLines(file)
    languageserver:::diagnose_file(uri, content)
})
system.time({
callr::r(function(file) {
    uri <- languageserver:::path_to_uri(file)
    content <- readLines(file)
    languageserver:::diagnose_file(uri, content)
}, list(file = "/path/to/your/file.R"), system_profile = TRUE, user_profile = TRUE)
})

renkun-ken avatar Jul 31 '21 15:07 renkun-ken

Ok I ran both those functions in R and got the following results. First one:

user  system elapsed
   2.31    0.11    2.67

Then I ran the second one And it did nothing...

It seems that for whatever reason that second one you gave just ran forever. I left it for a couple hours and it still had done nothing, so I canceled it.

I also tried running the second one on a much smaller file and I got the same result.

Am I just not running it correctly or does that mean I have some other issue?

Thank you

ghost avatar Aug 02 '21 00:08 ghost

This issue is stale because it has been open for 365 days with no activity.

github-actions[bot] avatar Aug 02 '22 02:08 github-actions[bot]

This issue was closed because it has been inactive for 14 days since being marked as stale.

github-actions[bot] avatar Aug 17 '22 02:08 github-actions[bot]