Support remote R session (located in a different machine)

[Tal500]

The user can run remote R session on a different machine by controlling R_app, R_cmd and R_args global vars.
However, I suppose because the nvim-R communication uses also the filesystem (on temporary dir), it fails to connect to a remote machine hosting the R session.

Since Nvim-R uses already TCP to connect between process, why do we need also a file for that?

Do you think it's possible to have cross-machine communication?
For reference, this is my PR doing much more work than probably needed here on the VSCode-R extension: REditorSupport/vscode-R#1394

[jalvesaq]

Nvim-R relies on the existence of many files created by R. Some of them might be big and it would slow down R usage if Nvim-R had to wait for them to be transferred by a TCP connection. Please, look at ~/.cache/Nvim-R and /dev/shm/Nvim-R-yourlogin. If you can't find these directories, type :echo $NVIMR_TMPDIR and :echo $NVIMR_COMPLDIR to know where they are.

Please, see https://github.com/jalvesaq/Nvim-R/wiki/Remote-access

[jalvesaq]

I added support for R into vimcmdline. If accessing the remote machine through ssh this configuration for init.lua might be enough:

vim.g.cmdline_app = {
    r = 'ssh -t [email protected] R --no-save',
}

[Tal500]

I added support for R into vimcmdline. If accessing the remote machine through ssh this configuration for init.lua (not tested) might be enough:

vim.g.cmdline_app = {
    r = 'ssh [email protected] R',
}

Thanks!
Will hopefully test it and report when I could

[jalvesaq]

I have just tried the instructions that were on https://github.com/jalvesaq/Nvim-R/wiki/Remote-access and they no longer work. Nvim-R has become more complex since 2017, and many files created by nvimcom from the remote machine are now made by an R instance called by the nclientserver running locally.

I will delete the code that was an attempt to enable remote access of R. You have to use vimcmdline or another plugin to send code to R running remotely.

[Tal500]

Can you make the following hard-coded R command more configurable?

Nvim-R/R/nvimcom/src/apps/nclientserver.c

Lines 1037 to 1046 in 97601b0

	res = CreateProcess(NULL,
	"R.exe --quiet --no-restore --no-save --no-echo --slave -f bo_code.R", // Command line
	NULL, // process security attributes
	NULL, // primary thread security attributes
	TRUE, // handles are inherited
	CREATE_NO_WINDOW, // creation flags
	NULL, // use parent's environment
	tdir, // use tmpdir directory
	&si, // STARTUPINFO pointer
	&pi); // receives PROCESS_INFORMATION

And this line worry me a little bit:

Of course, none of NvimR's features that depend on information on R's workspace will be available.

Is there no other way to get (n)VIM<->remote-R great interoperability?

[jalvesaq]

Nvim-R has many redundant features.

• You will not get syntax highlighting and completion of functions as their libraries are loaded, but you will get the same for all libraries that have either library() or require() calls in the script. as long as you have R and the libraries installed in your local machine.
• You will not have the Object Browser to inspect objects, and completion from cmp-nvim-r will not complete objects from the R workspace, but you still can easily send commands such as ls(), summary(obj), str(obj), and print(obj) to R Console.

[jalvesaq]

Can you make the following hard-coded R command more configurable?

This is a code that runs in the background. It should work without any need for user configuration. Ideally, users should only choose an option meaning "I want to access R remotely", and all necessary internal changes should be automatic. In general, users should choose options that represent what they want and we would have to program Nvim-R to do what is required to make the option work.

[jalvesaq]

I made another attempt at running R remotely: https://github.com/jalvesaq/Nvim-R/tree/remote
If you want to try it, the instructions are at: https://github.com/jalvesaq/Nvim-R/blob/remote/doc/remote_acess.md

You may have to manually install nvimcom on the remote machine. Anyway, nvimcom messages sent from the remote machine still are not reaching the nclientserver in the local machine.

Debugging code is enabled in the remote branch and messages are logged in two files: /dev/shm/nclientserver_log and /dev/shm/nclientserver_stdout.

[jalvesaq]

The remote branch is working on Linux, but I had to replace the UDP server with a TCP one and I can't write the Windows version because I don't have access to a Windows system.

[Tal500]

I made another attempt at running R remotely: https://github.com/jalvesaq/Nvim-R/tree/remote If you want to try it, the instructions are at: https://github.com/jalvesaq/Nvim-R/blob/remote/doc/remote_acess.md

You may have to manually install nvimcom on the remote machine. Anyway, nvimcom messages sent from the remote machine still are not reaching the nclientserver in the local machine.

Debugging code is enabled in the remote branch and messages are logged in two files: /dev/shm/nclientserver_log and /dev/shm/nclientserver_stdout.

Will try this out probably next week! (In a linux environment)
About our work environment: We specifically don't need sshfs here because our home directories are globally shared on NFS.

[jalvesaq]

I could compile the code with mingw now, but I can't run it to know if it actually works.

[jalvesaq]

We specifically don't need sshfs here because our home directories are globally shared on NFS.

I wrote instructions for ssh and sshfs because I know how to use them. The hope is that the instructions will make it easier for people to configure their own environment.

[Tal500]

I made another attempt at running R remotely: https://github.com/jalvesaq/Nvim-R/tree/remote If you want to try it, the instructions are at: https://github.com/jalvesaq/Nvim-R/blob/remote/doc/remote_acess.md

You may have to manually install nvimcom on the remote machine. Anyway, nvimcom messages sent from the remote machine still are not reaching the nclientserver in the local machine.

Debugging code is enabled in the remote branch and messages are logged in two files: /dev/shm/nclientserver_log and /dev/shm/nclientserver_stdout.

Tried it on Linux, and working almost perfectly!
The only issue is when the user is pressing ,rf on an R buffer just before R server initialization(takes few seconds).
Can we have some "lock" for the initialization completion (or until failure) for the R terminal invocation by ,rf?

[Tal500]

Update:
While the library lists work, the .GlobalEnv is empty (while it's not!)

[jalvesaq]

R starts faster now.

But I couldn't fix the Object Browser. I guess the problem is caused by a delay in file transfer from the remote machine to the local one. When R finishes writing a file, nvimcom sends a message to nclientserver through the established TCP connection. Then, the nclientserver immediately reads the file. I added the options -o sync_readdir and -o sshfs_sync to sshfs, but didn't see any difference.

If my guess is correct, the solution could be to transfer data from R's workspace through the TCP connection, using the remotely mounted directories only to get data on installed packages, which only change when new versions are installed.

[Tal500]

If my guess is correct, the solution could be to transfer data from R's workspace through the TCP connection, using the remotely mounted directories only to get data on installed packages, which only change when new versions are installed.

As I did in REditorSupport/vscode-R#1394 , passing data in a TCP-only way was proved to be very useful. For binary data, if you have, using Base64 encoding is the easiest solution(see my implementation).

In addition, it was very comfortable (and increased robustness and debugging abilities) the ability to take an existing R session and connect&disconnect it from the IDE on-the-fly, by simple R file loading and calling connect()&disconnect() functions in R.

[jalvesaq]

I will try your suggestion, but maybe only next week, depending on my spare time.

[jalvesaq]

The list of objects in .GlobalEnv and the names of libraries are now sent through the TCP connection.

[Tal500]

The list of objects in .GlobalEnv and the names of libraries are now sent through the TCP connection.

Thanks! Works(verified)!