Sublime Forum

Using Sublime Text 2 as an editor for R in Windows

#1

This question has probably been asked before, but it’s a difficult one to search for (at least I’m having trouble with it), since “R” is a pretty broad search term and “R stats/stastistics/etc.” doesn’t seem to bring up anything.

In any case, I’m really digging Sublime Text 2 and would love to see/make/use a system for R similar to the LaTeXTools package, where you can type your code in ST2, hit ctrl+R and have it executed in R, either in the RGUI or the command line, to me it doesn’t matter which.

Surely this has been done already (how can it not be? I mean, there’s even syntax coloring for R in ST2) and I just can’t find the appropriate forum posts. If it hasn’t, I don’t mind working on it myself, but any help (e.g., pointing me to relevant forum posts) would be appreciated.

Thanks

EDIT: I achieved a pretty viable solution through fiddling around with SublimeREPL. Thanks.

0 Likes
#2

Glad to hear it :smile: Don’t hesitate to post bugs or even minor inconveniences here github.com/wuub/SublimeREPL/issues
I’ve got very little feedback regarding R support in SublimeREPL and would really like to know what is missing.

0 Likes
#3

Actually there were some issues I had to sort out. I will post them here for anyone that wants to replicate what I did, because I’m not sure if it’s an issue with my configuration or SublimeREPL in general.

The main problem I had was that SublimeREPL couldn’t find R, even when placing R’s directory into my PATH. Thinking that maybe SUblimeREPL didn’t have access to my User PATH variable, I also tried out adding R to the System PATH, to no avail. I only got things working when I hardcoded the path to R in the Main.sublime-menu file in AppData/Roaming/Sublime Text 2/Packages/SublimeREPL/config/R. Also, I double checked to make sure I could call R from the command line by just typing “R” at the cmd.exe prompt, which worked and verified that R was placed in my path appropriately. So, while it’s a strange issue, at least a workaround exists.

An idea for a feature improvement would be to add a REPL setting for RScript. Currently, I use R to launch the interpreter in Sublime if I want to copy paste code into it from an opened R file. But have a REPL for RScript allows me to select RScript from the SublimeREPL drop downi n the Tools menu and (if the R file I’m interested in is active) it automatically gets passed to and ran by RScript, generating output in a REPL tab in Sublime Text 2. It’s pretty nice. Honestly, this probably isn’t a necessary feature to implement since it is pretty easy to figure out on one’s own, but I thought I’d mention it nonetheless.

As an interesting bonus, all plot functions in R seem to output to .pdf files that get stored in the working directory rather than opening in new windows. This is a benefit to me since, more often than not, if I’m plotting I need to .pdf for a publication or something, but I’m mentioning it here in case anyone is curious as to why their plots aren’t showing up when calling plot from an R REPL.

Thanks for the tool, wuub. SublimeREPL is definitely pretty slick, and a big help to my workflow.

0 Likes
#4

I need to man up and finally finish a real documentation for SublimeREPL :confused:

Problems with PATH are actually the most common ones. Best way to fix them is to place SublimeREPL.sublime-settings file in your Packages/Default directory and fill default_extend_env as required:

{ "default_extend_env": {"PATH": "{PATH};c:\\something\\something\\dark\\side"} }

Sorry for asking such obvious question, but did you restart SublimeText after PATH change?

Will look into it.

Try F2,l (eval lines w/ cursor in them), F2,s (eval selection) and F2,f (eval file)

Hm. Now I’m curious…

0 Likes
#5

Please do. This is a pretty awesome tool. The more I tinker with it the more robust I realize it is.

Indeed I did, to no effect. I will probably incorporate your previous suggestion involving SublimeREPL.sublime-settings, though.

These techniques pretty much obviate the need for the RScript setup I mentioned in the previous post. I didn’t realize they existed or I would’ve used them from the outset. Perhaps I just missed them in the documentation or something. The benefit (or downside) to these approaches versus running RScript is that the REPL persists after the R file is ran, meaning you can continue to query variables and such from the R REPL tab. Dedicating a REPL setup to RScript only gains you the benefit of terminating the RScript process when the script finishes. Good for batch work, perhaps?

If you find some method to allow plots to be viewed in separate windows, please let me know. Like I said, the pdf approach usually works fine for me, but it would be nice to have window support as well. I may look into it myself if I get some free time.

EDIT: A bug(?) I forgot to mention…if R is open in a REPL tab and you make an error (e.g., attemping to print the contents of a variable that doesn’t exist), the appropriate R error message will print, but the REPL will halt execution, meaning you have to bring up a new REPL. It would be greatly preferred if the REPL tab continued to persist after errors, since they can happen pretty frequently in R, and the halt may cause a loss of data/work if a user is working with the REPL directly and not through an R script.

0 Likes
#6

On OSX everything works correctly (referencing unknown variable prints an error and REPL continues to work) also plots are shown in a separate window. I expect on linux it’s the same story.
It’s time to wrestle with Windows… again… :wink:

EDIT5:
disregard those and see next post :smile:

EDIT: also, default_extend_env seems to have little effect on Windows, it’s correctly applied (i,e. PATH is modified) but makes no difference wrt to subprocess being able to run R.exe.Stay with your hardcoded solution for now.

EDIT2:
Closing R.exe after an error can be changed with:

options(error=utils::recover)

Put it at the end of ./R/R-2.14.2/etc/Rprofile.site it should be work.

EDIT3:
And our PATH problems on Windows are explained: bugs.python.org/issue8557
It’s possible to easily “fix” that with a simple shell=(os.name == ‘nt’), in subporcess.Popen() but I need to think it through, unfortunately running a process under shell=True makes it very difficult to kill the child on tab close.

EDIT4:
R thinks it is not running interactively on Windows, That’s why plots are saved and EDIT2 was required. I’m investigating what can be done about it.

> interactive() [1] FALSE

0 Likes
#7

Ok. For now update config/R/Main.sublime-menu to this. I’ll review this and shell=true tomorrow and if no regression is found it will make to SublimeREPL v1.0.20

     {
        "id": "tools",
        "children":
        {
            "caption": "SublimeREPL",
            "mnemonic": "r",
            "id": "SublimeREPL",
            "children":
            
                {"command": "repl_open",
                 "caption": "R",
                 "id": "repl_r",
                 "mnemonic": "r",
                 "args": {
                    "type": "subprocess",
                    "external_id": "r",
                    "encoding": "utf8",
                    "cmd": {"linux": "R", "--interactive", "--no-readline"],
                            "osx": "R", "--interactive", "--no-readline"],
                            "windows": "C:\\Program Files\\R\\R-2.14.2\\bin\\i386\\Rterm.exe", "--ess"]},
                    "cwd": "$file_path",
                    "extend_env": {"osx": {"PATH": "{PATH}:/usr/local/bin"},
                                   "linux": {"PATH": "{PATH}:/usr/local/bin"},
                                   "windows": {}},
                    "cmd_postfix": "\n", // postfix that will be automatically added after a line in repl
                    "suppress_echo": {"osx": true,
                                      "linux": true,
                                      "windows": false},
                    "syntax": "Packages/R/R.tmLanguage"
                    }
                }
            ]
        }]
    }
]
0 Likes
#8

EDIT 2 appears to fix the R.exe terminating after an error. Great!

Your updated Main.sublime-menu fixes the plot issue as well. I’m now plotting in windows. Thanks!

Awesome turnaroud on this, wuub. Good work!

0 Likes
#9

I thought I would post an update concerning using ST2 with R in Windows since I have been using the setup exclusively for a couple of weeks now. There are some pros, some cons, and a bug I thought I’d point out. wuub, if you want the bug(s) posted to the Github repo, let me know and I can do that.

Pros:

  • Syntax highlighting (both in .R files and in the REPL window for R). I never realized how awesomely helpful a syntax highlighted R-terminal window would be. It’s great.
  • Text-file like navigation of the R REPL window. It’s helpful (sometimes) to be able to use the arrow keys to navigate through the terminal and terminal output history like it’s one big text file. However, this does have some drawbacks
  • Numerous other ST2-related benefits. auto-complete, multiple cursors, etc.
  • Plotting to multiple windows (vs overwriting the content of a single window) by default
  • Launching the R REPL using the current directory as the working directory

Cons (vs. the classic R GUI):

  • No tab-complete in the REPL. Coming from the RGUI, a handy feature for member access is to do something like the following: object$, followed by the tab key which allows for tabbing through the members of the object. This is not unlike tab-complete in any other shell. In an R REPL, however, since the terminal is manipulated like a text file, the tab key works as tab would in a text editor. The same is true for the enter key. So, to run a line, for example, I have to have ensure that the cursor is at the end of the line and then hit Enter. This con is by no means a deal-breaker for me, and in many cases the REPL behaving like a text document is beneficial. It’s just something I thought I’d point out if anyone else considers going with the R REPL setup. In short, the REPL acts like a text file, and is therefore not manipulated in the way you intuitively expect command line interpreters to work. Not a bad thing, just takes some getting used to, and some may consider it a con.

Bugs:

  • Closing an R REPL tab in ST2 sometimes does not close the RTerm.exe process, leading to running processes that must be killed via Ctrl+alt+del. This isn’t a huge hindrance in most cases; however, sometimes the orphaned Rterm.exe process will begin to consume massive amounts of CPU. On my Core2Duo machine for example, the process will consume 50% CPU, dominating a single core. This leads to massive slowdown and, to someone unfamiliar with the issue, can cause quite a bit of frustration since the computer essentially bogs down with no obvious reason. I have verified that this bug exists on multiple machines (all Win 7). Other members of my lab (who have seen firsthand how much better the SublimeREPL approach to R is over the traditional R GUI), have also noticed the issue on their setups, again all Windows 7 machines. I have yet to test if a similar problem arises on OS X, but I can if necessary. Also note that the Rterm.exe process can always be killed effectively (in Windows) using Ctrl+Alt+Del. In Unix-y terms, the process isn’t a zombie, just an orphan.

This may just be a general SublimeREPL bug that I’m not familiar with, but I thought I’d point it out in any case.

TL;DR: R + SublimeREPL = happiness, Cons exist but they’re minimal when compared to the pros, an orphan process bug within SublimeREPL (when using R) seems to exist.

Thanks!

0 Likes
#10

since I have been using the setup exclusively for a couple of weeks now.

Thank you very much. It’s nice to know that someone actually finds this useful.

wuub, if you want the bug(s) posted to the Github repo, let me know and I can do that.

Nah. I sometimes report bugs myself to close them with a commit message for future reference. But this orphaned process problem is already known (github.com/wuub/SublimeREPL/issues/17)

No tab-complete in the REPL (…) REPL acts like a text file, and is therefore not manipulated in the way you intuitively expect [size=70](emphasis mine)[/size]

There are two extreme approaches to embedding a **generic** interpreter inside a text editor. One is through standard text editing mode somehow piped to/from the interpreter (SublimeREPL) other is terminal emulation (SublimePTY). Problem is, I'm not happy with either of those. SublimeREPL looses all the terminal/console functions, while PTY looses all the nice editing properties of the editor. There is a much better (in terms of usability) middle ground, something I like to call "cooperative interpreter". Basically a standard REPL, but one that knows it's being run inside ST2 and provides a side channel communication for autocomplete, thread management (think runaway loop) and maybe some better text-transfer/debugging facilities (+- what most interpreter GUIs do but with better front-end/back-end separation) . Sounds tempting, but there is a catch. There is no generic way to do it, you need a separate cooperative interpreter for each language you wish to support this way. I would probably manage to code something for python in my spare time, but that's it, with my recent workload everything is progressing superslow either way.

To cut the long story short: I know this is an issue, I bump into it every day, I think I know how to fix this, the only problem is lack of resources :neutral_face:

Closing an R REPL tab in ST2 sometimes does not close the RTerm.exe process,

There is an ongoing issue with killing some types of subprocess REPLs (mostly on Windows). For some (e.g. Clojure, Scala) I used an easy to implement “soft_quit” solution that sends a “graceful exit” string before trying to kill the process. I’ve got reports that it helps (a bit).
Next version of SublimeREPL will include a soft_quit config for R:

"soft_quit": "\nquit(save=\"no\")\n",

It may help if RTerm is still responding but decided to ignore SIGTERM for some reason.

This may just be a general SublimeREPL bug that I’m not familiar with, but I thought I’d point it out in any case.

a) this is a known problem, b) I was unable to recreate it with RTerm. Can you think of a use case leading to an orphaned RTerm?

0 Likes
#11

Ah, so it was known problem, sorry to retread old ground, then. In terms of (b), I cannot think offhand of an issue that causes the problem because I usually don’t notice the orphans until they are sucking away at my available resources. In the upcoming days I will keep an eye on my process monitor and try to determine when the issue occurs. I have added the soft_quit option to my R config and I haven’t noticed the orphan problem since. However, I’ve only used R a handful of times since making the change. In short, I’ll keep an eye out and see if I can’t give you a more thorough description of the problem.

Thanks for the help, and for your fast-as-usual response. I would’ve gotten a reply up sooner, but the ST2 forums have been down for me pretty much all day.

0 Likes
#12

To be precise, orphaned processes are a known problem. With Clojure and Scala the reason why this happens is known, not so with RTerm. You made a good choice rising this issue. Having a reliable recreation steps would be even better, but I know how it is with Heisenbugs.

Thanks, I appreciate your help!

No problem. Most of the time REPL/PTY issues have to wait until weekend either way.

0 Likes
#13

Sorry it took so long to get back to you on this, I’ve been away on travel.

Initially I was unable to provide a use case to create the orphaned R term process, but insight form a colleague made it fairly obvious what the problem is. My ST2 setup is configured to ‘‘remember’’ the open tabs so that, upon reopening ST2 after a close, the previously opened tabs are available. When an R REPL is running and you close ST2 (but don’t close the REPL tab first) the Rterm process is not killed. However, when you reopen ST2 and close the R REPL, it is (I’m assuming) no longer associated with the RTerm process, therefore closing the R REPL tab has no effect on the RTerm process. Does this make sense? Basically if you set up ST2 to reopen previously opened tabs at launch and you don’t close the R REPL tab before quitting ST2, the Rterm process is essentially orphaned.

I’m still not sure why CPU usage on the orphaned process blows up to 50%, but I was able to replicate the orphaning issue using the above approach.

Hope this helps.

0 Likes
#14

I also have been using SublimeREPL with R in Windows and greatly appreciate the package. Last year I was using the plugin without problems (aside from the rterm process that did not close when sublime exited).

However, now I cannot get code to run from another file. I used to select code an hit F2, s. Now not is not longer working for me. I have also tried the various new menu options under “Eval in REPL” and “Transfer to REPL”. None seem to work.

0 Likes
#15

The best environment for R is eclipse with StatET, and that’s because of one feature: a workspace explorer. All objects, with their dimensions, are there. You can preview them. I have no idea how the feature could be replicated, but it’d be kiler.

0 Likes