I am trying to build an Electron app to open a terminal emulator (using xterm.js) and inside that to run R.
Already found this very useful example, and able to automatically run R. But since the Electron user interface will have menus and dialogs (including a data viewer), it is mandatory to:
detect when new objects have been created in the R environment
return (for instance a new data frame) to the Electron app in order to display it
I am thinking to have a set of background R functions to report all of that, however I don't know if:
it is possible to send an invisible command to xterm (which will have an active R session)
the Electron app can receive (invisible) messages from xterm (more specifically, from the R process that is opened within xterm)
All this communication between the Electron app and the R session within xterm should not be echoed in the terminal, of course. It should be somewhat similar to RStudio, where the new R objects are automatically reported from the console to the user interface.
Any suggestion would be highly appreciated.
Related
I've created a single R file 'myfile.R' which is composed of several functions, reading from an odbc connection, and of course the ui and server components for the shiny application. The goal is for the user to treat this as an executable, that is, I'd like them to be able to run this app without having to run Rstudio. Currently on this environment, Rstudio is installed (as are the relevant packages), what I'm currently writing in command line is:
Rscript myfile.R
The file looks to be successfully loaded, but the application itself does not 'pop up' towards me, infact nothing does, it just says that it is listening on http....
I was thinking of creating a bash script that could do this, and this seemed to be the most simple approach but this is not working.
I'm working a little side project on R Studio and I'm trying to import data from an Oracle database. The problem is, whenever I try to establish the connection using the DBI::dbConnect command, it just 'hangs'. It won't continue to the next command on my R Studio script. I've added a timeout to the dbConnect command, but it doesn't help anything. In order to exit, I have to shut down R Studio completely.
I've tested the connection, check the screenshot below, using the 'Connections' tab on R Studio. As you can see, it is able to establish the connection. So that should mean the parameters are set correctly, right? But when I run it on the script, it just keeps 'hanging' on the dbConnect command.
What can I do?
When it connects successfully to the database RStudio loads in connection pane a tree which present all schemas and all tables. It's useful by it can be slow.
Depending on Oracle database I use, it often takes a long time to load this and it's longer when user have low privileges on database (user with only one schema for instance).
I see two ways trying to go further:
connect with your statement on RGui to see if it works correctly then it's really linked to RStudio's connection pane
connect with system / admin or a higher level user to check if it's work better with
I have made a Desktop shiny app for windows using the amazing package RInno but I have been experiencing some inconsistencies with launching the application. Occasionally the application will not quit its session properly, leaving R running in the background. Their github suggests using this chunk of code in the server function to insure R is properly terminated when the session ends. I can tell when the application quits properly because I include a custom function that copies the log files to a new indexed name for records and debugging.
if (!interactive()) {
session$onSessionEnded(function() {
write_logs_out() #My custom function. renames logs and stores backups of session data in .rds files
stopApp()
q("no")
})
}
In these cases a new log file is not made so I assume stopApp() and q("no") are never executed as well, leaving R running in the background. One major issue is I do not know how to reproduce this error. My current guess is that this occurs when the R session locally becomes unresponsive. While R is still running in the background, the shiny app never fully opens to a web browser. I will first need to open task manager and quit any R sessions (usually with the name "R front-end") in order to get the app working again.
Since I dont know how to expect this random error, I was wondering if any windows experts could help me write a script that will check if an R process is running, and then kill it. This would at least
I know that
tasklist | findstr Rscript.exe
will list all the current Rscripts running (which I believe is the "R front-end" i see in task manager), but I don't know if it is bad practice to simply include taskkill /IM "Rscript.exe" /F before the line that calls the .wsf file that starts the app.
The main problem I see with this is that if the session is running fine and the user for some reason clicks the app again, it will force a complete restart.
Any suggestions?
I am used to using R in RStudio. For a new project, I have to use R on the command line, because the data storage and analysis are only allowed to be on a specific server that I connect to using ssh. This server doesn't have rstudio-server to support remote RStudio sessions.
The project involves an extremely large dataset, and some pre-written code to load/format the data that I have been told to run using "source()" before I do anything else. This takes several minutes to run and load the data each time.
What would a good workflow be for something like this? Editing my code in a .r file, saving, then running it would require taking several minutes to load the data each time. But just running R in an interactive session would make it hard to keep track of what I am doing and repeat things if necessary.
Is there some command-line equivalent to RStudio where you can have an interactive session but be editing/saving a file of your code as you go?
Sounds like JuPyteR might be your friend here.
The R kernel works great.
You can use it on a remote server either with exposing an open port (and setting up JuPyteR login credentials)
Or via port forwarding over SSH.
It is a lot like an interactive reply, except it holds state.
And you can go back and rerun cells.
(Of course state can be dangerous for reproduceability)
For RStudio you can launch console and ssh to your remote servers even if your servers don't use expensive RStudio for servers platform. You can then execute all commands from R Studio directly into the ssh with the default shortcut key. This might allow to continue using R studio, track what you're doing in the R script, execute interactively.
RStudio server uses a headless R session and seems to pass all of the I/O operations encoded to save bandwidth. This works for everything except for packages like Rattle or Latticist, which work through their own GUI. Is there a way to use these packages through RStudio server or otherwise access the RStudio server R session to run these packages remotely?
Bonus if there's an efficient way to run these packages remotely without forwarding an X session over SSH.
I'm not sure this is possible over the RStudio interface because of the way these graphical programs work. It's easy enough for RStudio to capture textual input and output for R. Capturing normal graphical output is pretty impressive, but that's done "natively" in R. Even packages like ggplot2 and lattice use the builtin R plotting capabilities -- they do some rendering and data processing on their own, pass that onto grid and then grid renders the plots via R builtins when plot() or print is called (including implicitly in the REPL for interactive sessions). RCommander, RGL and the like use external libraries (Tcl/Tk, OpenGL), which render their interfaces directly over operating system services and not via R. R doesn't even see the output from these programs -- it only knows that the R wrapper function for these services hasn't returned yet. For local RStudio, this isn't a problem because the services are forwarded directly to the local display, but for RStudio server, there is no display!
Another consideration: assuming R could capture and forward X, that would imply having an X Server (in X, Server is the display/keyboard/etc, Client is the program that needs I/O) running in your browser. Modern JavaScript is pretty amazing at times, but X is a very complicated codebase and very sensitive to latency. Running X over the Internet is much slower than over the local network -- the protocol just wasn't designed for such things and most operations involve far too many roundtrips.
On a more practical side, you can still do most of your work via RStudio and only do the graphical commands via X forwarding:
Do everything that doesn't involve an external graphics interface.
Save your R Session (in the Environment tab or via the command line) as .RData in your project directory. (You can actually do this elsewhere, but it's generally more convenient if your workspace is saved in the working directory.)
Login in via SSH and X Forwarding and cd to the project directory.
Start R -- R will automatically load any existing workspaces saved as .RData. (You can disable this behavior with --vanilla. Depending on the size of your workspace, R may take a few seconds to a few minutes to load.
Have fun with Rattle, Latticist, RCommander, RGL, etc! Be ready for massive lag if you're doing this over the Internet and not the local network (see above).