Git Product home page Git Product logo

rmote's Introduction

rmote

gif

Running R on a remote server

R users often find themselves needing to log in to a remote machine to do analysis. Sometimes this is due to data restrictions, computing power on the remote machine, etc. Users can ssh in and run R in a terminal, but it is not possible to look at graphics, etc.

There are currently three approaches that I am aware of to deal with this:

  1. Install RStudio Server on the remote server and use that from a web browser on your local machine. Graphics output is shown in the IDE.
  2. Use X11 forwarding (ssh -X|Y). Graphics output is sent back to your machine.
  3. Use VNC with a linux desktop environment like KDE or GNOME.

Whenever possible, #1 is by far the best way to go and is one of the beautiful things about RStudio Server. #2 is not a good choice - plots are very slow to render, the quality is terrible, and it doesn't support recent advances in plot outputs like htmlwidgets (unless you launch firefox through X11, which will mean you might get to look at one plot per hour). #3 is okay if it is available and you are comfortable working in one of these desktop environments.

There could be other obvious ways to deal with this that I am oblivious to.

A problem

Often we do not have the choice of installing RStudio Server or a desktop environment on the remote machine. Also, some users prefer to work in a terminal sending commands from a favorite text editor on a local machine, but still want to see graphics. We would like to have something better than X11 forwarding to view graphics and other output when running R in a terminal on a remote machine.

A solution

The rmote package is an attempt to make working in R over ssh on a server a bit more pleasant in terms of viewing output. It uses servr on the remote machine to serve R graphics as they are created. These can be viewed on the local machine in a web browser. The user's local browser will automatically refresh each time a new output is available.

Currently there is support for lattice, ggplot2, htmlwidgets, and help output.

Usage

  1. Choose a port to run your remote server on (default is 4321)

  2. ssh into the remote machine, mapping the port on the remote back to your local machine:

    ssh -L 4321:localhost:4321 -L 8100:localhost:8100 user@remote
    

    I also add port 8100 so I can forward shiny apps back to my local machine on a dedicated port.

  3. On the remote machine launch R and install the latest version of servr and rmote (one time only)

    install.packages("rmote", repos = c(CRAN = "http://cran.rstudio.com",
      tessera = "http://packages.tessera.io"))

    or alternatively

    devtools::install_github(c("yihui/servr", "hafen/rmote"))

    Note that this package will probably never be on CRAN since it overwrites some standard R S3 methods.

  4. Run the following in R on the remote:

    rmote::start_rmote()

    To view some of the options for this, see ?start_rmote. One option is the port, which needs to match the one your forwarded in step 2 (4321 is the default.)

  5. On your local machine, open up your web browser to localhost:4321

    Now as you create compatible plots on your remote machine, your browser on your local fmachine will automatically update to show the results. For example, try running each of the following in succession on the server:

    ?plot
    
    qplot(mpg, wt, data=mtcars, colour=cyl)
    
    dotplot(variety ~ yield | year * site, data=barley)
    
    library(rbokeh)
    figure() %>% ly_hexbin(rnorm(10000), rnorm(10000))

This process is slightly more tedious than ssh -X for initial setup, but much faster and more functional.

Other useful utilities

Another interesting package to check out that allows you to control R on a remote machine from your local R session is - remoter.

If you must work on a remote terminal, here are some additional utilities that help make things nice:

Installation

CRAN Build Status codecov.io

This package is not yet on CRAN. To install the latest development version you can install from the cloudyr drat repository:

# latest stable version
install.packages("rmote", repos = c(getOption("repos"), "http://cloudyr.github.io/drat"))

Or, to pull a potentially unstable version directly from GitHub:

if(!require("ghit")){
    install.packages("ghit")
}
ghit::install_github("cloudyr/rmote")

cloudyr project logo

rmote's People

Contributors

hafen avatar leeper avatar snoweye avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rmote's Issues

Allow (or even detect?) image resize in window

When using rmote under Firefox, displayed plot images don't seem to be scaled down to fit the browser window.

It would be very convenient if I could set my plot output via rmote_device to a given pixel size, but then have that image downsized to the size of the browser window if it's too large. (This would save a lot of trouble when moving/resizing the window.) If I right-click and "View Image" then Firefox does this very nicely, but I then obviously lose the auto-refresh capability.

In fact, and this seems a far more complex problem, it would be amazing if rmote could detect the size of the browser window and set the rmote_device to the appropriate size. I have no idea if that would be possible, but would be a massive improvement.

As it is, I'm finding rmote incredibly useful for working on my compute server, so thank you!

Less hacky way to intercept plot output

Currently we overwrite R print methods to capture plot output and send it to servr. It would be nice to do this more cleanly with something like addTaskCallback(). I want to keep usage extremely simple, such that nothing is done differently than what you would do if you were operating locally. A potential issue with addTaskCallback() is that I don't think you can know that you need to intercept a plot output until after it has already been written to the default graphics device. Some deeper knowledge of R internals would be useful here...

Does it work with Sun Grid Engine?

This repository looks fantastic. Would be great to use it at work, but unfortunately after SSHing onto the remote cluster I have to log onto one of our nodes to do the work. I followed your tutorial and suspect that this additional step could be the reason why I can't get it to work at the moment. Instead, in R I get this kind of output after reloading the localhost:4321 website (which doesn't refresh on its own for me):

> channel 5: open failed: connect failed: Connection refused
channel 5: open failed: connect failed: Connection refused
channel 5: open failed: connect failed: Connection refused

Just asking in case you have some experience with this kind of environment. I apologise if this is not enough information to understand what the problem is. If so, let me know and I'll explain in a bit more detail later.

Thanks!

pheatmap in rmote

Hello Ryan,
I generate heatmap many times and my choice of R package is "pheatmap" in CRAN since it is sometimes hard to draw heatmap with ggplot. However, it seems that Rmote does not work well with this package, generating no plot at localhost page. Could you let me know any suggestion?

start_rmote(server_dir) doesn't seem to work with `~/some_path`

Hi,

While trying to get rmote working in an SGE cluster, I tried setting the server_dir argument to a value that would change by day and use a directory that could be accessed through multiple terminal sessions to SGE. So I tried setting server_dir to something like server_dir = paste0('~/rmote/rmote_server_', Sys.Date()) and it initially seemed to work (rmote printed the message with the url) but eventually it wasn't working. That's why I changed my .Rprofile to use /users/my_username/ instead of ~/ and it all worked after that point and now it also prints the To stop the server message. To make the difference in messages clear, I'm posting them here:

Failing with ~/

Serving the directory /users/my_username/rmote/rmote_server_2018_02_16 at http://127.0.0.1:4321

When it works:

Serving the directory /users/my_username/rmote/rmote_server_2018_02_16 at http://127.0.0.1:4321
To stop the server, run servr::daemon_stop("some_number") or restart your R session

I ignore if that's something you would expect or if you meant to have it work with paths that include ~/.

Best,
Leo

serve knitr results

Hello!
Thanks a lot for the awsome package. Is it possible to directly serve resulting html when calling rmarkdown::render("test.Rmd")
Right at the moment I found a hacky way around this, by manually copying the resulting file into the served directory of rmote_start().
Is there a better way?

Cheers,
Adrian

No support for base graphics

It would be nice if base graphics could be viewed remotely too. Until that time could you highlight that base graphics doesn't work in the README? It only lists the things that do work (lattice, ggplot2 etc).

It might be worth looking to see how knitr handles the detection and capture of base graphics plots...

"Minimal" view for `rmote` output

While the history of plots is useful, it would be really nice to recreate (almost) the experience of working just with a plot window on a local machine. Would it be possible to have a 'minimal' interface option that removed the bar at the top of the rmote plot html, and the (collapsed) history sidebar?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.