Is ESS' R-mode also slower for you than just plain R? Mostly the text gets sent really slowly to the other buffer.
Is this normal or is there something wrong with my setup?
As suggested:
sessionInfo()
R version 2.15.1 (2012-06-22)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_2.15.1 tools_2.15.1
My custom .el file for R: http://pastebin.com/WrUxBAyG
Hopefully someone has a clue what might be off.
EDIT: I actually tried disabling all those R packages, and they don't seem to be the problem.
(setq ess-eval-visibly-p nil)
Solves the issue of slow blocks of code as mentioned here
Depends on what you're doing. If you're doing a long running command with C-c C-c or something it can appear sow.
Sometimes the text wont be written to the R buffer until after the process is done.
For simple commands it shouldn't be noticeably slower though. Googling will show you a bunch of other folks dealing with similar issues. But without more information we can't tell you much else!
-- edited so the accept can be changed.
Related
I have installed RStudio on a new computer, and has developed encoding issues. When I type accented text in console (no file writing or reading involved, just plain console) I lose Czech accents (as in this example - notice the accented N and Č)
> "Ňuf ňuf ňufičky"
[1] "Nuf nuf nuficky"
I know it is a settings issue - I have other R installations that behave correctly - but I am unable to find exact place in my settings to force UTF-8 behavior. Any help would be appreciated.
My session info is:
R version 3.4.2 (2017-09-28)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)
Matrix products: default
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252 LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.4.2 tools_3.4.2 yaml_2.1.14
For the benefit of posterity - I overcame my problem by setting code page to 1250 (while keeping US English as my language).
if (.Platform$OS.type == 'windows') {
Sys.setlocale(category = 'LC_ALL','English_United States.1250')
} else {
Sys.setlocale(category = 'LC_ALL','en_US.UTF-8')
}
in the .Rprofile
Perhaps:
new.locale <- ifelse(.Platform$OS.type=="windows", "Czech_Czech Republic.1250", "en_US.UTF-8")
Sys.setlocale("LC_CTYPE", new.locale)
Also learn to specify your OS.
When I run a complete chunk of code, inline output appears as expected. However if I run the same chunk one line at a time it breaks if I use more than one plot call. So:
set.seed(129485)
x=1:10
y=rnorm(length(x), x, 1)
plot(x,y)
lines(x,y)
works fine in an R script. If I insert it into a code chunk in a brand new R markdown file, like this:
---
title: "wtf"
author: "Drew Tyre"
date: "December 22, 2016"
output: html_document
---
```{r}
set.seed(129485)
x=1:10
y=rnorm(length(x), x, 1)
plot(x,y)
lines(x,y)
```
This chunk runs if I run the entire chunk using control-shift-enter, the play button, or by selecting all the lines and using control-enter. However, if I run the lines one at a time using control-enter, it breaks on the call to lines(x,y):
Error in plot.xy(xy.coords(x, y), type = type, ...) : plot.new has not been called yet
It goes away if I set the options to chunk output in console. I guess it could be the intended behavior, but then maybe control-enter should do the same thing as control-shift-enter when using inline output?
I'm using RStudio 1.0.44 and
R version 3.3.2 (2016-10-31)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets
[6] methods base
loaded via a namespace (and not attached):
[1] rsconnect_0.4.3 tools_3.3.2 yaml_2.1.14
[4] knitr_1.15.1
I can also reproduce this behavior on this machine:
R version 3.2.3 (2015-12-10)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_3.2.3 knitr_1.12.3
Kevin Ushey over at the RStudio community forum had this answer:
This is unfortunately a consequence of the Notebook execution model. The graphics device state is reset after each execution, so code execution that is done line-by-line (e.g. to fill a plot) will not work as expected.
There are some workarounds for this:
Prefer executing a whole chunk at a time, using e.g. Cmd + Shift + Enter,
Wrap your plot generating code in brackets {},
Define a function that generates the entire plot,
Disable inline chunk output for that document. (Do this by clicking the Gear icon in the source toolbar and choosing 'Chunk Output in Console')
I am trying to put a copy of my Rprofile from my work computer onto my home computer, but R does not seem to be able to find it.
I have tried several responses to similar questions including:
In Windows, you set the R_USER profile by opening up a command line and running:
SETX R_PROFILE_USER "C:/.../.Rprofile"
Sys.getenv("R_PROFILE_USER")
[1] "C:/Users/Sally/Rprofile"
but this does not work.
I also tried:
candidates <- c( Sys.getenv("R_PROFILE"),
file.path(Sys.getenv("R_HOME"), "etc", "Rprofile.site"),
Sys.getenv("R_PROFILE_USER"),
file.path(getwd(), ".Rprofile") )
Filter(file.exists, candidates)
[1] "C:/PROGRA~1/R/R-32~1.2/etc/Rprofile.site"
I changed the location of the Rprofile file to match the Filter results with no luck.
sessionInfo()
R version 3.2.2 (2015-08-14)
Platform: i386-w64-mingw32/i386 (32-bit)
Running under: Windows 8 x64 (build 9200)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
If anyone has any suggestions it would be appreciated.
Thanks,
Sally
That is Windows for you -- you need to define $HOME as an evironment variable, or place it in $USER or ... whatever else they decide next.
On operating systems with an x or X in the name, $HOME is well defined and ~/.Rprofile is found.
Possible workaround: just edit $RHOME/etc/Rprofile.site but remember that this file will vanish next time you upgrade R on Windows.
I am having trouble running Rcpp on my PC in RStudio. Whenever I sourceCpp() a cpp file, even the Hello World file that comes with Rcpp::Rcpp.package.skeleton(), I get the warning
In normalizePath(path.expand(path), winslash, mustWork) :
path[1]=".../anRpackage/src/../inst/include": The system cannot find the path specified
I searched Stackoverflow and it looks like some people get this warning if they don't have Depends: Rcpp in the DESCRIPTION of their package, but I am just running sourceCpp() so the DESCRIPTION file shouldn't matter (I also changed my DESCRIPTION file).
It is just a warning so the class and functions I wrote do appear in R, but RStudio frequently crashes after I use the functions in R a few times, which may or may not be related.
My session info:
R version 3.1.3 (2015-03-09)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 8 x64 (build 9200)
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252 LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] Rcpp_0.12.1 RevoUtilsMath_7.4.1 RevoUtils_7.4.1 RevoMods_7.4.1 RevoScaleR_7.4.1 lattice_0.20-30 rpart_4.1-9
loaded via a namespace (and not attached):
[1] codetools_0.2-10 foreach_1.4.2 grid_3.1.3 iterators_1.0.7 tools_3.1.3
I suppose it is possible that Revolution R is the culprit here, but I have no way of knowing. I would appreciate help, because I don't want to ignore this warning, and it's obviously not ideal for RStudio to crash repeatedly.
Kind Regards
This is still relevant today, so here's my discoveries.
Rcpp can generate interfaces to and from C++ and R.
These are generated with the help of attributes specified in source-files.
From these attributes, the call to Rcpp::compileAttributes() produces the headers. Whilst at it, this also create the folder <package directory>/inst/include. If you have specified no attributes, anywhere, then compileAttributes() does not create these directories.
In order to get rid of this warning, create the <package directory>/inst/include.
For more on attributes, see Rcpp attributes vignette.
I'm seeing behavior I don't expect with the cat commands and flush.console() in RGui 2.12.0 (but not Rterm) for Windows. I wanted to see whether it was a problem with my system (or a known behavior) before reporting it as a bug. Specifically I'm seeing strange UNICODE looking characters as it iterates through. Please forgive the use of the huge rnorm() I couldn't figure out how to slow execution in an established way.
for (i in 1:100) {cat(i,"\r");flush.console();rnorm(1000000)}
R version 2.12.0 (2010-10-15)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
It worked as you would expect under R-2.10.0, which is the previous version of R installed in my seldom-used Windows machine. ;-)
I would say report it, but I would just send it to R-devel as "unexpected behavior" as you did here. Make sure to check against the latest daily build before reporting it, since it may have already been fixed.
The problem was in the RGui and the devs claim it will be fixed in the next minor release of 2.12.