I'm trying to build my own package using Windows. I installed everything I need, and running R CMD build mypackage and R CMD INSTALL mypackage seem to run fine. when I run the build command, though, I get a warning from cygwin:
cygwin warning:
MS-DOS style path detected: C:/Documents and Settings/e_sander/My Documents/mypackage_1.0.tar.gz
Preferred POSIX equivalent is: /cygdrive/c/Documents and Settings/e_sander/My Documents/mypackage_1.0.tar.gz
CYGWIN environment variable option "nodosfilewarning"turns off this warning. Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
I did go to the recommended website, but I don't know much about cygwin or linux so I'm not sure there's anything I need to do. I realize that using the MS-DOS style path is deprecated and not recommended in cygwin, but I'm not sure how to change that, since I'm running Windows and that's the path I need. I also haven't noticed any problems with my package, at least when I install it to my computer (and although I haven't used the tarball, I've opened it and everything looks fine). So here's what I'm trying to figure out:
Does leaving the path as is affect my package in any way?
If so, how could it adversely affect my package?
How do I change the path to make cygwin happy?
This is just a warning and it tells you how to disable it. It doesn't affect anything. If you want it to go away, run this from your shell:
export CYGWIN="nodosfilewarning"
Or you could mount C: to /c/ (see man mount).
Does leaving the path as is affect my package in any way?
- No, it is just a warning.
If so, how could it adversely affect my package?
- N/A
How do I change the path to make cygwin happy?
- Set the environment variable as the output states. There are multiple ways to do this; I chose to go with a solution that handles the issue across any invoked environment that parses or inherits from the windows environment by using the "Rapid Environment Editor" program to add a User Variable named CYGWIN with a value nodosfilewarning. But if you wanted you could add it through the control panel using Add environment variables for your account.
Related
After having set the path for the default working directory as well as my first (and only) project within RStudio options I wonder why RStudio keeps creating an empty folder named "R" within my "/home" directory every time it is started.
Is there any file I could delete/edit (eventually create) to stop this annoying behaviour and if so, where is it located ?
System: Linux Mint v. 19.3
Software: RStudio v. 1.3.959 / R version 3.4.4
Thanks in advance for any hints.
Yes, you can prevent the creation of the R directory — R is configurable via a set of environment variables.
However, setting these correctly isn’t trivial. The first issue is that many R packages are sensitive to the R version they’re installed with. If you upgrade R and try to load the existing package, it may break. Therefore, the R package library path should be specific to the R version.
On clusters, an additional issue is that the same library path might be read by various cluster nodes that run on different architectures; this is rare, but it happens. In such cases, compiled R packages might need to be different depending on the architecture.
Consequently, in general the R library path needs to be specific both to the R version and the system architecture.
Next, even if you configure an alternative path R will silently ignore it if it doesn’t exist. So be sure to manually create the directory that you’ve configured.
Lastly, where to put this configuration? One option would be to put it into the user environment file, the path of which can be specified with the environment variable R_ENVIRON_USER — it defaults to $HOME/.Renviron. This isn’t ideal though, because it means the user can’t temporarily override this setting when calling R: variables in this file override the calling environment.
Instead, I recommend setting this in the user profile (e.g. $HOME/.profile). However, when you use a desktop launcher to launch your RStudio, this file won’t be read, so be sure to edit your *.desktop file accordingly.1
So in sum, add the following to your $HOME/.profile:
export R_LIBS_USER=${XDG_DATA_HOME:-$HOME/.local/share}/R/%p-library/%v
And make sure this directory exists: re-source ~/.profile (launching a new shell inside the current one is not enough), and execute
mkdir -p "$(Rscript -e 'cat(Sys.getenv("R_LIBS_USER"))')"
The above is using the XDG base dir specification, which is the de-facto standard on Linux systems.2 The path is using the placeholders %p and %v. R will fill these in with the system platform and the R version (in the form major.minor), respectively.
If you want to use a custom R configuration file (“user profile”) and/or R environment file, I suggest setting their location in the same way, by configuring R_PROFILE_USER and R_ENVIRON_USER (since their default location, once again, is in the user home directory):
export R_PROFILE_USER=${XDG_CONFIG_HOME:-$HOME/.config}/R/rprofile
export R_ENVIRON_USER=${XDG_CONFIG_HOME:-$HOME/.config}/R/renviron
1 I don’t have a Linux desktop system but I believe that editing the Env entry to the following should do it:
Exec=env R_LIBS_USER=${XDG_DATA_HOME:-$HOME/.local/share}/R/%p-library/%v /path/to/rstudio
2 Other systems require different handling. On macOS, the canonical setting for the library location would be $HOME/Library/Application Support/R/library/%v. However, setting environment variables on macOS for GUI applications is frustratingly complicated.
On Windows, the canonical location is %LOCALAPPDATA%/R/library/%v. To set this variable, use [Environment]::SetEnvironmentVariable in PowerShell or, when using cmd.exe, use setx.
I cannot run a R session from the command line by typing 'R', despite having
C:/Program Files/R
and
C:/Program Files/R/R-3.3.2/bin
in both 'Path' (System) and 'PATH' (User) environment variables (the latter directory is where the actual application is located, I was just trying everything by adding the former).
If I manually change the working directory to C:/Program Files/R/R-3.3.2/bin and type R, a session runs.
Any insight as to why this might be the case? Other programs such as Python 3 run fine, provided the the environment variable is set, why not with R?
This question is part of a larger problem where I am trying to get rpy2 working, but though successfully installed, none of it's basic functions are working, and I thought this maybe to do with a version of R being installed at C:/Users/Anaconda2/R (Because this dir was in Path). The R application installed here would not work when opened, but was the directory returned when I typed R RHOME into cmd - despite the fact this installation is not even functioning, and has apparently only existed since I installed rpy2 a couple of hours ago. I reasoned that rpy2 is trying to use the instance of R installed here rather than my normal one, thus causing the error when I call robjects.r. But this still doesn't explain why I can't run R from cmd. When using R.home(component = "home") from inside a an R session (in RStudio or out of it), it returns my normal, working R directory, at C:/PROGRA~1/R/R-33~1.2. By moving the R file tree installed in Anaconda's directory to a somewhere not in Path, I hoped Windows would find the correct installation via Path - but instead I just get Failed to create process.
My last guess was that Windows didn't like the space in "Program Files", but loads of variables in Path go through the same folder. Any ideas?
I am using:
Windows 10,
R 3.3.2,
Python 2.17.13
UPDATE, PERHAPS SOLVED:
On Josh O'Brien's recommendation (thanks!), I typed where R into cmd, returning:
C:\Users\charl\Anaconda2\Scripts\R.exe
C:\Program Files\R\R-3.3.2\bin\R.exe
The first path is marginally different from the C:\Users\charl\Anaconda2\R listed in my first post (both are in Path), and leads to a third R.exe. It's outside the R file tree located in Anaconda, unlike my standard R installation, but seems to be dependent on it nonetheless. If I remove this R.exe to another location (not in Path), Typing R in cmd will run R from the desired directory, thus fixing the problem. R.home() from inside that session confirms this.
My only remaining concern then; is whether this installation of R in Anaconda necessary for rpy2 or can I just delete it, fixing the original problem? It may just be my ignorance, but I was not conscious that installing rpy2 (I used the standard Windows installer rather than compiling manually) would install another instance of R - is it necessary for the package or just a default/option I failed to omit?
I'm trying to run R from iTerm on an OSX computer (OSX 10.11.6). When I enter R, it opens up an older version of R, from the path /Users/***/miniconda2/bin/R. I would like it to run, by default, an R version found at /usr/local/bin/R, without having to enter the full path every time. How would one go about changing the location of the default R?
Thanks for your help
This is likely due to the PATH variable preferring ~/miniconda2/bin before /usr/local/bin. I'm giving you a few options here to help understand why it is happening.
Let's assume your PATH looks like this:
/Users/me/bin:/Users/me/miniconda2/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
Modify PATH
You could modify PATH to move /Users/me/miniconda2/bin after /usr/local/bin or remove it from PATH completely. The downside is that if you rely on other binaries in ~/miniconda2/bin they will no longer be found when executing them by name.
Move R out of the way
Another option would be to move ~/miniconda/bin/R out of the way, for example using
mv ~/miniconda/bin/R ~/miniconda/bin/R-miniconda
Afterwards R will be run from the next location in $PATH, but if you update miniconda2 it may return.
Link to R further up in the PATH (easiest/best)
Finally, you could make sure that there is an R executable in something that is further up the $PATH. This is probably the easiest and most effective option.
First, make sure you have a bin folder in your home directory. If this is not the case, create it using mkdir ~/bin and then restart the terminal. The restart should cause the code in ~/.profile to add that folder to your $PATH. You can verify by doing echo $PATH. If this is not the case, add the following line to your ~/.profile or ~/.bash_profile:
export PATH=$HOME/bin:$PATH
In the example at the top, the PATH already contains /Users/me/bin at the beginning of the line (highest priority).
Next, create a soft link to the R binary in the newly created folder:
ln -s /usr/local/bin/R ~/bin/R
You should now be able to execute R, which will prefer the softlink created, which will execute the one you like. If it does not work right away execute hash -r or restart the terminal.
Just in case you happen to be using RStudio Server (open source) or someone is looking for how to change the RStudio Server default version of R, here is what I found when trying to answer the same question:
Starting in RStudio Server 1.3 (the newest version is 1.4.1106, released February 22, 2021), a user’s preferred version of R can be specified in the rstudio-prefs.json file in the global-level /etc/rstudio folder or in the user-level ~/.config/rstudio folder.
See https://blog.rstudio.com/2020/02/18/rstudio-1-3-preview-configuration/ and https://docs.rstudio.com/ide/server-pro/session-user-settings.html for user setting options in newer versions of RStudio Server.
See https://support.rstudio.com/hc/en-us/articles/200716783-RStudio-Release-History for RStudio release history and https://www.rstudio.com/products/rstudio/download-server/redhat-centos/ for Red Hat downloads of the newest version of RStudio Server.
When compiling with -fsanitize=memory I get WARNING: Trying to symbolize code, but external symbolizer is not initialized! when running the program. How do I initialize the external symbolizer?
I solved my own problem using MSAN_SYMBOLIZER_PATH=$(which llvm-symbolizer-3.4) ./a.out. The problem is that Ubuntu postfixes the version number but the binary doesn't know that. Of course you need to use MSAN instead of ASAN when using the memory sanitizer.
You are supposed to be able to set the ASAN_FILTER environment variable to point at a symbolizer, but I could not get it to work. However, you can redirect stderr into a symbolizer after the fact. You'll still get the warnings about the uninitialized symbolizer, but the filenames and line numbers will be correct.
You can use asan_symbolizer.py as the external symbolizer. After downloading it from that link (to /tmp, for example), invoke your program like so (in bash, for this example):
./myprogram 2>&1 | /tmp/asan_symbolize.py | c++filt
On my Ubuntu system, the issue is that LLVM's tools are installed under /usr/bin with version suffixes (like llvm-symbolizer-4.0), and the sanitizer tools are looking for them without version suffixes.
LLVM also installs its binaries to, e.g., /usr/lib/llvm-4.0/bin; the tools under /usr/bin are actually just symlinks. So an easy solution is to add the appropriate /usr/lib/llvm-*/bin directory to your path when working with sanitizers.
I received such warning when I run program debug version (compiled with -fsanitize=address) on Linux machine that didn't contain clang installation. The problem disappeared after I installed clang from devtoolset.
I am trying to compile Network.HTTP (http://hackage.haskell.org/package/network) on win32/cygwin. However, it does fail with following message:
Setup.hs: Missing dependency on a foreign library:
* Missing (or bad) header file: HsNet.h
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
If the header file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
Unfortuntely it does not give more clues. The HsNet.h includes sys/uio.h which, actually should not be included, and should be configurered correctly.
Don't use cygwin, instead follow Johan Tibells way
Installing MSYS
Install the latest Haskell Platform. Use the default settings.
Download version 1.0.11 of MSYS. You'll need the following files:
MSYS-1.0.11.exe
msysDTK-1.0.1.exe
msysCORE-1.0.11-bin.tar.gz
The files are all hosted on haskell.org as they're quite hard to find in the official MinGW/MSYS repo.
Run MSYS-1.0.11.exe followed by msysDTK-1.0.1.exe. The former asks you if you want to run a normalization step. You can skip that.
Unpack msysCORE-1.0.11-bin.tar.gz into C:\msys\1.0. Note that you can't do that using an MSYS shell, because you can't overwrite the files in use, so make a copy of C:\msys\1.0, unpack it there, and then rename the copy back to C:\msys\1.0.
Add C:\Program Files\Haskell Platform\VERSION\mingw\bin to your PATH. This is neccesary if you ever want to build packages that use a configure script, like network, as configure scripts need access to a C compiler.
These steps are what Tibell uses to compile the Network package for win and I have used this myself successfully several times on most of the haskell platform releases.
It is possible to build network on win32/cygwin. And the above steps, though useful (by Jonke) may not be necessary.
While doing the configuration step, specify
runghc Setup.hs configure --configure-option="--build=mingw32"
So that the library is configured for mingw32, else you will get link or "undefined references" if you try to link or use network library.
This combined with #Yogesh Sajanikar's answer made it work for me (on win64/cygwin):
Make sure the gcc on your path is NOT the Mingw/Cygwin one, but the
C:\ghc\ghc-6.12.1\mingw\bin\gcc.exe
(Run
export PATH="/cygdrive/.../ghc-7.8.2/mingw/bin:$PATH"
before running cabal install network in the Cygwin shell)