R CMD BATCH
?
update.packages()
fails.
This FAQ is for the Windows port of R: it describes features specific to that version. The main R FAQ can be found at
http://CRAN.R-project.org/doc/FAQ/R-FAQ.html.
The information here applies only to recent versions of R for Windows, (`2.5.0' or later).
Go to any CRAN site (see http://cran.r-project.org/mirrors.html for a list), navigate to the bin/windows/base directory and collect the file(s) you need. The current release is distributed as an installer `R-2.7.0pat-win32.exe' of about 30Mb. This contains all the components and allows as complete as installation as you choose.
There are also links on that page to the `r-patched' and `r-devel' snapshots. These are frequently updated builds of development versions of R. The `r-patched' build includes bug fixes to the current release, and `r-devel' contains these as well as changes that will eventually make it into the next `x.y.0' release.
Versions of R as from 2.7.0 will only run on Windows 2000 or later. (R 2.6.2 was the last version for Windows 95. 98, ME and NT4.) There is no specific version for x64 Windows, but the standard 32-bit version works well enough. We only test on versions of Windows currently supported by Microsoft, mainly on XP, Vista x64 and Windows Server 2003.
Your file system must allow case-honouring long file names (as is likely except perhaps for some network-mounted systems). A full installation takes up about 60Mb of disk space and a minimal one less than 20Mb.
If you want to be able to build packages from sources, we recommend that
you choose an installation path not containing spaces. (Using a path
with spaces in will probably work, but is little-tested.) Users of
Vista installing for a single user using an account with administrator
rights1 should consider
installing into a non-system area (such as C:\R). If you are
installing to a network drive, you should consider changing the default
form of help during the install not to be Compiled HTML help:
See Help is not shown for some of the packages. Installing to a
network share (a filepath starting with \\machine\...
) is not
supported: such paths will need to mapped to a network drive.
To install use `R-2.7.0pat-win32.exe'. Just double-click on the icon and follow the instructions. If you installed R this way you can uninstall it from the Control Panel or Start Menu (unless you suppressed making a group for R). If you have an account with Administrator privileges you will be able to install R in the Program Files area and to set all the optional registry entries; otherwise you will only be able to install R in your own file area. On Windows Vista you may need to confirm that you want to proceed with installing a program from an `unidentified publisher'.
After installation you should choose a working directory for R. You will have a shortcut to R-2.7.0pat\bin\Rgui.exe on your desktop and/or somewhere on the Start menu file tree, and perhaps also in the Quick Launch part of the taskbar. Right-click each shortcut, select Properties... and change the `Start in' field to your working directory.
You may also want to add command-line arguments at the end of the
Target field (after any final double quote, and separated by a
space), for example --sdi --max-mem-size=1Gb
. You can also set
environment variables at the end of the Target field, for example
R_LIBS=p:/myRlib
, and if you want to ensure that menus and
messages are in (American) English, LANGUAGE=en
.
It is also possible to install from an MSI file, which will be of interest only for system administrators. For how to build an MSI file, see the `R Installation and Administration Manual'.
Run the program bin\md5check.exe. This compares checksums on all the installed files with those put into the installer, and will report any changed or missing files.
(It only works if R was installed from the Inno Setup installer, and not the MSI installer.)
The normal way to customize the installation is by selecting components from the wizards shown. However, sysadmins might like to install R from scripts, and the following command-line flags are available for use with the installer.
It is also possible to save the settings used to a file and later reload those settings using
A successful installation has exit code 0: unsuccessful ones may give 1, 2, 3, 4 or 5. See the help for Inno Setup (http://jrsoftware.org/isinfo.php) for details.
We have some facilities for building a customized installer, in particular to add packages to the installer. See the `R Installation and Administration' manual in the subsection `Building the installers'.
Just double-click on the shortcut you prepared at installation.
If you want to set up another project, make a new shortcut or use the existing one and change the `Start in' field of the Properties.
You may if you prefer run R from the command line of any shell you use, for example a `Command Prompt' or a port of a Unix shell such as tcsh or bash. (The command line can be anything you would put in the Target field of a shortcut, and the starting directory will be the current working directory of the shell.)
Yes, with care. A basic R installation is relocatable, so you can burn an image of the R installation on your hard disc or install directly onto a removable storage device such as a flash-memory USB drive. (If you have installed packages into a private library, their absolute paths will appear in the HTML packages list.)
Running R does need access to a writable temporary directory and to a home directory, and in the last resort these are taken to be the current directory. This should be no problem on a properly configured version of Windows, but otherwise does mean that it may not be possible to run R without creating a shortcut in a writable folder.
Normally you can do this from the R group on the Start Menu or from the `Add/Remove Programs'2 in the Control Panel. If it does not appear there or if you want to remove an old version, run unins000.exe in the top-level installation directory. (There should be a separate uninstall item in the R group for each installed version of R. On Windows Vista, you may well be asked to confirm that you wish to run a program from an `unidentified publisher'.)
Uninstalling R only removes files from the initial installation, not (for example) packages you have installed or updated.
If all else fails, you can just delete the whole directory in which R was installed.
That's a matter of taste. For most people the best thing to do is to
uninstall R (see the previous Q), install the new version, copy any
installed packages to the library folder in the new installation, run
update.packages(checkBuilt=TRUE, ask=FALSE)
in the new R and then
delete anything left of the old installation. Different versions of R
are quite deliberately installed in parallel folders so you can keep old
versions around if you wish.
For those with a personal library (folder R\win-library\x.y
of your home directory), you will need to update that too when the minor
version of R changes (e.g. from 2.6.2 to 2.7.0). A simple way
to do so is to copy (say) R\win-library\2.6 to
R\win-library\2.7 before running
update.packages(checkBuilt=TRUE, ask=FALSE)
.
Indeed there is. It is set by the command-line flag --max-mem-size (see How do I install R for Windows?) and defaults to the smaller of the amount of physical RAM in the machine and 0.5Gb less than the limit of user virtual memory for a process (most often 2GB). It can be set to any amount between 32Mb and 4095Mb.
Use ?Memory
and ?memory.size
for information about memory
usage. The limit can be raised by calling memory.limit
within a
running R session.
The executables Rgui.exe and Rterm.exe support up to 3Gb
per process under suitably enabled versions of 32-bit Windows (see
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
and http://msdn2.microsoft.com/en-us/library/aa366778.aspx: where
this is supported it may need to be specifically enabled). On such
systems, the default for --max-mem-size
is the smaller of the
amount of RAM and 2.5Gb. On some 64-bit versions of Windows (e.g.
Vista) the limit is 4GB, and there the default for --max-mem-size
is the smaller of the amount of RAM and 3.5Gb.
Create a separate shortcut for each project: see Q2.5. All the paths to files used by R are relative to the starting directory, so setting the `Start in' field automatically helps separate projects.
Alternatively, start R by double-clicking on a saved .RData file in the directory for the project you want to use, or drag-and-drop a file with extension .RData onto an R shortcut. In either case, the working directory will be set to that containing the file.
It depends what you want to print.
dev.print
with suitable arguments (see its help page: most likely
dev.print(win.graph)
will work).
help(fn_name, offline=TRUE)
.
R CMD BATCH
?Yes: use R CMD BATCH --help
or ?BATCH
for full details.
You can set also up a batch file using Rterm.exe. A sample batch file might contain (as one line)
path_to_R\bin\Rterm.exe --no-restore --no-save < %1 > %1.out 2>&1
The purpose of 2>&1
is to redirect warnings and errors to the
same file as normal output.
Yes. All recent versions of ESS come with support for this version of
R, and there is support for interrupting the R process from ESS (by
C-c C-c
).
For help with ESS, please send email to ESS-help@stat.ethz.ch, not the R mailing lists.
Several places in the documentation use these terms.
The working directory is the directory from which Rgui
or
Rterm was launched, unless a shortcut was used when it is given
by the `Start in' field of the shortcut's properties. You can find this
from R code by the call getwd()
.
The home directory is set as follows: If environment variable R_USER is set, its value is used. Otherwise if environment variable HOME is set, its value is used. After those two user-controllable settings, R tries to find system-defined home directories. It first tries to use the Windows "personal" directory (typically C:\Documents and Settings\username\My Documents on Windows XP and C:\Users\username\Documents on Vista). If that fails, if both environment variables HOMEDRIVE and HOMEPATH are set (and they normally are), the value is ${HOMEDRIVE}${HOMEPATH}. If all of these fail, the current working directory is used.
You can find this from R code by Sys.getenv("R_USER")
.
Environment variables can be set for Rgui.exe and Rterm.exe in three different ways.
"path_to_R\bin\Rgui.exe" HOME=p:/ R_LIBS=p:/myRlib
R_LIBS=p:/myRlib
If you have permission to do so, you can also create an environment file etc\Renviron.site and set environmental variables in that file in the same way. This is useful for variables which should be set for all users and all usages of this R installation. (Their values can be overridden in a .Renviron file or on the command line.)
See ?Startup
for more details of environment files.
The order of precedence for environmental variables is the order in which these options are listed, that is the command line then .Renviron then the inherited environment.
How did you specify it? Backslashes have to be doubled in R character strings, so for example one needs `"d:\\R-2.7.0pat\\library\\xgobi\\scripts\\xgobi.bat"'. You can make life easier for yourself by using forward slashes as path separators: they do work under Windows. You should include the file extension (e.g. `"xgobi.bat"' rather than just `"xgobi"'); sometimes this isn't shown in Windows, but it is necessary in R.
A simple way to avoid these problems is to use the function
file.choose()
to invoke the standard Windows file selection
dialog. If you select a file there, the name will be passed to R in
the correct format.
Another possible source of grief is spaces in folder names. We have tried to make R work on paths with spaces in, but many people writing packages for Unix do not bother. So it is worth trying the alternative short name (something like `PROGRA~1'; you can get it as the `MS-DOS name' from the Properties of the file on some versions of Windows, and from dir /X in a `Command Prompt' window).
No, not when R itself is running.
When you run the R installer, there are options (under `Select Additional Tasks') to `Save version number in registry' and `Associate R with .RData files'.
If you tick the first option, the following string entries are added to the Windows registry:
HKEY_LOCAL_MACHINE\Software\R-core\R\Current Version
contains the version number, currently 2.7.0.
HKEY_LOCAL_MACHINE\Software\R-core\R\[version]\InstallPath
(where [version]
is currently 2.7.0) contains the path to the R
home directory.
HKEY_CURRENT_USER
.
If you tick the second option (`Associate R with .RData files') and have
administrative privileges, then entries are created under
HKEY_CLASSES_ROOT\.RData
and HKEY_CLASSES_ROOT\RWorkspace
.
After installation you can add the Registry entries in
HKEY_LOCAL_MACHINE
by running RSetReg.exe
in the
bin
folder, and remove them by running this with argument
/U
. Note that this requires administrative privileges and
neither sets up nor removes the file associations.
Directly, no.
There is a (D)COM server written by Thomas Baier available on CRAN (http://cran.r-project.org/other-software.html) which works with Rproxy.dll (in the R distribution) and R.dll to support transfer of data to and from R and remote execution of R commands, as well as embedding of an R graphics window. An R-Excel interface making use of the (D)COM server is included in the distribution.
Thomas Baier also has a package rcom
available on CRAN (in the
usual way for a package) to provide COM client and server functionality
from within R.
Another (D)COM server is available from http://www.omegahat.org/,
which allows R objects to be exported as COM values. That site also
has packages RDCOMClient
and SWinTypeLibs
which allow R
to act as a (D)COM client.
for example update.packages()
and the menu items on the Packages menu.
We have had several reports of this, although they do work for us on all of our machines. There are two known possible fixes.
(a) Use the alternative internet2.dll by starting R with the flag --internet2 (see How do I install R for Windows?) which uses the Internet Explorer internals (and so needs Internet Explorer 4 or later installed). Note that this does not work with proxies that need authentication.
(b) A proxy needs to be set up: see ?download.file
. Here are two
versions of an example (a real one, but from a machine that is only
available locally) of a command-line in a short cut:
"path_to_R\bin\Rgui.exe" http_proxy=http://user:pass@gannet:80/ "path_to_R\bin\Rgui.exe" http_proxy=http://gannet/ http_proxy_user=ask
The second version will prompt the user for the proxy username and password when HTTP downloads are first used.
Another possibility is that firewall settings are blocking the R executables from contacting the Internet, but this should result in informative error messages from the firewall program.
This has not been reported for a few years, but used to happen regularly. All the occurrences we have solved have been traced to faulty versions of `msvcrt.dll': we have installed a workaround that seems to avoid this. A few other people have discovered this was caused by desktop switcher and keyboard macro programs, for example `Macro Magic' and `JS Pager'.
This is a warning which indicates that R has taken action to correct the action of some (non-R) DLL which has just been loaded and has changed the floating point control word (in its initialization code) to a setting incompatible with that needed for R. This is not good practice on the part of the DLL, and often indicates that it needs to be updated. (It was common with DLLs compiled in early versions of Visual C++.)
Unfortunately, because DLLs may load other DLLs it is not possible for R to track which DLL caused the problem.
See also ?dyn.load
.
Some users have found that Rgui.exe
fails to start, exiting with
a “Floating-point invalid operation” or other low level error. This
error may also happen in the middle of a session. In some cases where
we have tracked this down, it was due to bugs in the video driver on the
system in question: it makes changes to the floating point control word
which are incompatible with R. (Good practice would restore the control
word to the state it was in when the driver code was called, and R
tries hard to correct this before running its own code.) For example,
one user reported that the virtual screen manager JSP2 caused this
crash.
These errors are essentially impossible for us to fix or work around beyond the measures already taken (which were increased in R 2.3.0). The only solution we know of is for the user to replace the buggy system component that is causing the error.
This is a misreading of Windows' confusing Task Manager. R's computation is single-threaded, and so it cannot use more than one CPU. What the task manager shows is not the usage in CPUs (as better written utilities do) but the usage as a percentage of the apparent total number of CPUs. We say `apparent' as it treats so-called `hyperthreaded' CPUs as two CPUs even though there is only one physical CPU: dual-core CPUs will also show as two CPUs (which they genuinely are).
Many benchmarks show hyperthreading reduces the overall workload, so you may want to experiment with disabling it.
It does. A few issues have been reported that related to the way accounts and file permissions work. (These are not specifically R issues, but changes in user experiences.)
Earlier versions of Windows had user and Administrator accounts, and user accounts could be give administrative privileges (by being added to the local Administrators group) and so write permission over system areas such as c:\Program Files. R would be installed either by a user in his own file space or by an account with administrator privileges into a system area. Sysadmins could set policies for user accounts, and you might for example have needed to be a `Power User' to install software at all.
Vista normally disables the Administrator account and expects software installation to done by an account which is in the local Administrator group with `admin approval mode' turned on. (The Administrator account by default has it turned off.) Unlike (say) Windows XP, such accounts do not run programs with full administrator privileges, and this is where the issues arise. (For background information consult http://technet.microsoft.com/en-us/windowsvista/aa906021.aspx and http://windowsvistablog.com/blogs/windowsvista/archive/2007/01/23/security-features-vs-convenience.aspx.) Vista has the concept of `over-the-shoulder' credentials: if you are running without full administrator privileges and do something which needs them you may be prompted with one or more security-check dialog boxes, and may be required to provide administrator credentials or confirm that you really want to take that action.
Vista will report that the R installer has an `unidentified publisher' and ask if it should be run. System administrators can disable installing applications from non-trusted sources, in which case you will have to persuade them that R is trustworthy, or digitally sign the R installer yourself, or (unless this is also disabled) run the installer from a standard account and install into your own file area. (The same issues apply to the .msi version of the installer.)
If you install R as a standard user into your own file space and use it under the same account, there are no known permission issues.
If you use the default Administrator account (without `admin approval mode' being turned on) and install/update packages (in the system area or elsewhere), no issues are known.
If you use an account in the local Administrators group in `admin
approval mode' (which is the intended norm under Vista), installation
will make use of `over-the-shoulder' credentials. You will run into
problems if you try installing (including updating) packages in the
main R library. (It would be nice if at that point R used
over-the-shoulder credentials, but they apply to processes as a
whole. Vista disallows creating .chm
and .dll
files in
the system area without credentials.) There are several ways around
this.
For an installation to be used by a single user, the simplest way is to make use of the `personal library' introduced in R 2.5.0: See I don't have permission to write to the R-2.7.0pat\library directory.
For a site installation, you can create a site-wide library directory anywhere convenient, and add it to the default package search path for all users via R_LIBS_SITE in etc\Renviron.site. See What are HOME and working directories?. There is a standard location for a site library, the site-library directory in the top-level R folder (which you would need to create with full control for the R installation account). This will be used for installation in preference to the main library folder if it exists.
This approach will not allow you to update the recommended packages unless you `Run as administrator': we suggest you use an R session running under Administrator privileges when updating those.
Another issue with Vista is that the standard POSIX ways that R uses
(e.g. in file.info
and file.access
) to look at file
permissions no longer work reliably. file.access
was re-written
for R 2.5.1 to work with Windows NT-based security and the new version
seems much more reliable with Vista.
On suitably recent hardware Vista can prevent the execution of code from data areas via `Data Execution Prevention' (from a tab in System Properties -> Advanced -> Performance), and sysadmins can turn this on for all programs. R runs correctly with DEP enabled.
R version 2.6.0 and later will make use of directional quotes that are not always rendered correctly by Windows.
Whether these are used in R output (from functions sQuote
and
dQuote
) is controlled by getOption("useFancyQuotes")
whose
default is FALSE
except for the Rgui
console. There are
two potential problems with rendering directional quotes. The first is
that in European locales the `Windows Command Prompt' is by default set
up to use MS-DOS and not Windows default encodings: this can be changed
via chcp, with chcp 1252 being appropriate for
Western European (including English) locales. The other is that the
default raster fonts only include directional single quotes and not
directional double quotes (which will probably be rendered as a filled
rectangle).
Directional quotes will also be used in text help which is normally displayed in R's internal pager: these may not be rendered correctly in an external pager. They are also used in CHM and HTML help, where most browsers use fonts which render them correctly.
The font used can affect whether quotes are rendered correctly. The
default font in the Rgui
console and internal pager is
Courier New
, which has directional quotes on all the systems we
tried. Lucida Console
has elegant glyphs for directional quotes,
but seems rather light on Windows XP (it looks better than Courier
New
on Vista). Non-TrueType fonts such as Courier
and
FixedSys
lack directional double quotes on all the systems we
tried.
Two things may be happening. First, only languages which can be displayed using the current codepage are offered so you cannot install in Japanese unless running Windows in Japanese.
Second, only a limited range of languages is supported (but still wider than those for which R has translations), currently Brazilian Portuguese, Catalan, both Simplified and Traditional Chinese, Czech, Danish, Dutch, Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Russian, Slovenian and Spanish (Spain).
The default behaviour of R is to try to run in the language you run
Windows in. Apparently some users want Windows in their native language,
but not R. To do so, set LANGUAGE=en
as discussed in Q2.2 and
Q2.15, or in the Rconsole file.
All recent Windows versions of R support `East Asian' languages (with a suitable version of Windows – e.g. Western installations of Windows XP do not by default have such support).
Both Rterm.exe and RGui.exe support single- and
double-width characters. It will be necessary to select suitable fonts
in files Rconsole and Rdevga (see ?Rconsole
or the
comments in the files: the system versions are in the etc
folder); in the latter you can replace Arial
by Arial
Unicode MS
, and we tried FixedSys
and MS Mincho
in
Rconsole. (Note that Rdevga only applies to Windows
graphics devices and not, say, to pdf
.)
Note that it is important that the console font uses double-width characters for all CJK characters (as that is what the width table used assumes): this is true for the fonts intended for CJK locales but not for example for Lucida Console.
You do need to ensure that R is running in a suitable locale: use
Sys.getlocale()
to find out. (CJK users may be used to their
language characters always being available, which is the case for
so-called `Unicode' Windows applications. However, R used to run on
Windows 9x and is not therefore `Unicode'.) You can find suitable
locale names from
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_crt_language_and_country_strings.asp:
beware that "Chinese"
is Traditional Chinese (code page 950,
Big5) and "chs"
is needed for Simplified Chinese (code page 936,
GB2312). Note that this can be rather tricky: on Windows XP there are
several places to select the language under the `Regional and Language
Options' part of the control panel, and the appropriate language has to
be set under both the `Regional Options' and `Advanced' tabs.
When using Rterm the window in which it is run has to be set up to use a suitable font (e.g. Lucida Console, not the OEM raster fonts) and a suitable codepage (which for the Windows Cmd shell can be done by chcp).
Precisely, you selected English for installation! The language of the installer has nothing to do with the language used to run R: this is completely standard Windows practice (and necessary as different users of the computer may use different languages).
The language R uses for menus and messages is determined by the
locale: please read the appropriate manual (the R
Installation and Administration Manual) for the details. You can
ensure that R uses English messages by appending LANGUAGE=en
to
the shortcut you use to start R, or setting it in the Rconsole file.
for example, in the console and to annotate graphs. Similar comments apply to any non-Western European language.
With suitable fonts, this should just work. You will need to set MS
Mincho or MS Gothic as the console font to ensure that single- and
double-width characters are handled correctly. The default graphics
fonts for the windows()
graphics device can handle most common
Japanese characters, but more specialized fonts may need to be set.
(See Q3.5 for how to set fonts: the console font can also be set from
the `GUI preferences' meny item.) The help for windowsFonts
has
examples of selecting Japanese fonts for the windows()
family of
devices.
In addition, the Hershey vector fonts (see ?Hershey
,
?Japanese
and demo(Japanese)
) can be used on any graphics
device to display Japanese characters.
To use non-Latin-1 characters in the postscript
graphics device,
see its help page (which also applies to pdf
).
You need to specify a font in Rconsole (see Q3.5) that supports the encoding in use, in Western European languages Latin-1. This used to be a problem in earlier versions of Windows, but now it is hard to find a font which does not.
Support for these characters within Rterm depends on the environment (the terminal window and shell, including locale and codepage settings) within which it is run as well as the font used by the terminal window. Those are usually on legacy DOS settings and need to altered.
In most cases they actually are, but by Windows. Setting the locale
or the LANGUAGE
environment variable does not change the
Windows setting of its `UI language'. Under (international) Windows
XP there are three tabs on the Regional and Language Options
applet in the Control Panel. The first tab controls the locale, the
second the UI and the third the fonts used for `non-Unicode' programs
(but apparently also for Unicode ones in many cases): see Q3.3. Vista
talks about the 'UI language' and the 'system locale' for setting
the language used for `non-Unicode' programs.
If you have Windows running completely in say French or Chinese these settings are likely to be consistent. However, if you try to run Windows in one language and R in another, you may find the way Windows handles internationalization slightly odd. For further details see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_0ddl.asp.
Yes, but you will need a lot of tools to do so, unless the author or the
maintainers of the bin/windows/contrib section on CRAN have been
kind enough to provide a pre-compiled version for Windows as a
.zip
file.
You can install pre-compiled packages either from CRAN or from a local
.zip
file by using install.packages
: see its help page.
There are menu items on the Packages
menu to provide a
point-and-click interface to package installation. The packages for
each minor (2.x) version will be stored in a separate area, so for R
2.7.? the files are in bin/windows/contrib/2.7. You can try
those compiled for earlier versions (but not before 2.0.0), at your own
risk.
Note that the pre-compiled versions on CRAN are unsupported: see http://cran.r-project.org/bin/windows/contrib/ReadMe, which also gives the locations of a few other pre-compiled packages.
If there is not a pre-compiled version or that is not up-to-date or you prefer compiling from source, read the `R Installation and Administration' manual section on `Add-on Packages'. You need to make sure you installed the necessary files, and you will need to collect and install several tools: you can download them via the portal at http://www.murdoch-sutherland.com/Rtools/. Once you have done so, just run R CMD INSTALL pkgname. To check the package (including running all the examples on its help pages and in its test suite, if any) use R CMD check pkgname: see the `Writing R Extensions' manual.
Note that this is rather tricky; please do ensure that you have followed the instructions exactly. At least 90% of the questions asked are because people have not done so.
You can install packages anywhere and use the environment variable R_LIBS (see How do I set environment variables?) to point to the library location(s).
Suppose your packages are installed in p:\myRlib. Then you can EITHER
set the environment variable R_LIBS to p:\myRlib before starting R
OR use a package by, e.g.
library(mypkg, lib.loc="p:/myRlib")
You can also have a personal library, which defaults to the directory
R\win-library\x.y of your home directory for versions
x.y.z of R. This location can be changed by setting the
environment variable R_LIBS_USER, and can be found from inside R
by running Sys.getenv("R_LIBS_USER")
. This will only be used if
it exists so you may need to create it: you can use
dir.create(Sys.getenv("R_LIBS_USER"), recursive = TRUE)
to do so. If you use install.packages
and do not have permission
to write to the main or site library, it should offer to create a personal
library for you and install the packages there. This will also happen
if update.packages
offers to update packages for you in a library
where you do not have write permission.
There can be additional security issues under Windows Vista: See Does R run under Windows Vista?. In particular, the detection that a standard user has suitable permissions appears to be unreliable under Vista, so we recommend that you do create a personal directory yourself.
To update the HTML indices after you have installed a pre-compiled package, run at the R prompt.
> link.html.help()
This is done automatically when installing from the Packages menu or by
install.packages()
, and when help.start
is run,
provided you have write permission on R-2.7.0pat/library. If
you do not have sufficient permission, you will get warnings and the
packages you install will not appear in the list of packages or the
search system.
The following conditions need to hold for functions in a package you installed.
If those hold, this works for us. Note that if you were unable to update the indices (for which you need write permission in the R-2.7.0pat directory), only the functions in packages installed in the main library will be found.
If the help search system does not work at all, this probably indicates that Java support is either not installed or Java or JavaScript is not enabled in your browser. The search page contains a link to the appropriate section in the R Installation and Administration manual.
Is the package compiled for this version of R? Many of the packages need to be compiled for a fairly recent version.
You can tell the version the package was compiled for by looking at the
`Built:' line in its DESCRIPTION file or at the
`Version' tab of its DLL in the libs directory.
(Right-click on the DLL in Windows Explorer and select `Version'
tab of the `Properties', or use the DLL.version
function
inside R.)
For package tcltk
to work (try demo(tkdensity)
or
demo(tkttest)
after library(tcltk)
) you need to have Tcl
installed. This is an optional part of the installation although it is
selected by default. If the message is
Tcl/Tk support files were not installed
the optional files were not installed, and you need to go back to the installer and install them.
Alternatively, if you have the environment variable MY_TCLTK set to a non-empty value, it is assumed that you want to use a different Tcl/Tk 8.5.x installation with the path to its bin directory given by value of MY_TCLTK, and that this is set up correctly (with TCL_LIBRARY set if needed). In that case you do not need the Tcl/Tk support files installed (but they can be). Note that you do need 8.5.x and not 8.4.x. (If you build R from the sources yourself you can configure it to use 8.4.x.)
Several package authors have suggested using ActiveTcl (http://www.activestate.com/Products/activetcl/) as a way to get Tcl/Tk extensions. This could be used by setting (for a default install)
MT_TCLTK=c:/Tcl/bin
but current versions (e.g. 8.5.1.0) do not contain any extra
extensions. Some extensions can be copied over from an ActiveTcl
install of Tcl/Tk 8.4 or downloaded via the Teacup
facility.
They may well not work between packages installed in different libraries. This is solved under Unix using symbolic links which Windows does not implement (except on NTFS file systems under Vista/Server 2008 – where they may need Administrator privileges).
With HTML, help.start()
fixes up links to the most of the
standard packages if it has write permission in the main library tree.
Not even these work for Compiled HTML help.
Currently links to the base
, datasets
, utils
,
grDevices
, graphics
, methods
and stats
packages are fixed.
update.packages()
fails.You may not be able to update a package which is in use: Windows `locks'
the package's DLL when it is loaded. So use update.packages()
(or the menu equivalent) in a new session.
If you put library(foo)
in your .Rprofile you will need to
start R with --vanilla to be able to update package foo
.
If you set R_DEFAULT_PACKAGES to include foo
, you will
need to unset it temporarily.
It has been reported that some other software has interfered with the installation process by preventing the renaming of temporary files, Google Desktop being a known example.
as shown in the Select repositories...
item on the
Packages
menu?
This reads from the tab-delimited file R_HOME\etc\repositories, which you can edit, or put a modified copy at .R\repositories in your HOME directory (see What are HOME and working directories?).
Is this for Compiled HTML help (the default)? If a help viewer appears but says the page cannot be displayed, this may be due to a Windows security patch (http://support.microsoft.com/kb/896358). Either apply the workarounds given at that URL or choose another form of help as the default (on installation or by editing R_HOME\etc\Rprofile.site).
help.start()
does not automatically send help
requests to the browser: use options(htmlhelp=TRUE)
to turn this on.
source()
) can be specified with
either "/" or "\\".
system()
is slightly different: see its help page and that
of shell()
.
You have read the file README.R-2.7.0pat? There are file menus on
the R console, pager and graphics windows. You can source and save from
those menus, and copy the graphics to png
, jpeg
,
bmp
, postscript
, PDF
or metafile
. There are
right-click menus giving shortcuts to menu items, and optionally
toolbars with buttons giving shortcuts to frequent operations.
If you resize the R console the options(width=)
is automatically
set to the console width (unless disabled in the configuration file).
The graphics has a history mechanism. As README.R-2.7.0pat says:
`The History menu allows the recording of plots. When plots have been recorded they can be reviewed by <PgUp> and <PgDn>, saved and replaced. Recording can be turned on automatically (the Recording item on the list) or individual plots can be added (Add or the <INS> key). The whole plot history can be saved to or retrieved from an R variable in the global environment. The format of recorded plots may change between R versions. Recorded plots should not be used as a permanent storage format for R plots.There is only one graphics history shared by all the windows devices.'
The R console and graphics windows have configuration files stored in
the RHOME\etc directory called Rconsole and Rdevga;
you can keep personal copies in your HOME directory. They contain
comments which should suffice for you to edit them to your
preferences. For more details see ?Rconsole
.
There is a GUI preferences editor invoked from the Edit
menu which
can be used to edit the file Rconsole.
The graphics system asks Windows for the number of pixels per inch in
the X and Y directions, and uses that to size graphics (which in R are
in units of inches). Sometimes the answer is a complete invention, and
in any case Windows will not know exactly how the horizontal and
vertical size have been set on a CRT. You can specify correct values
either in the call to windows
or as options: see ?windows
.
(Typically these are of the order of 100.)
On one of our systems, the screen height was reported as 240mm, and the width as 300mm in 1280 x 1024 mode and 320mm in 1280 x 960 and 1600 x 1200 modes. In fact it was a 21" monitor and 400mm x 300mm!
You may want to do this from within a function, for example when calling `identify' or `readline'. Use the function `bringToTop()'. With its default argument it brings the active graphics window to the top and gives it focus. With argument `-1' it brings the console to the top and gives it focus.
This works for Rgui.exe in MDI and SDI modes, and can be used for graphics windows from Rterm.exe (although Windows may not always act on it).
R 2.5.0 introduced TAB completion in both Rgui and Rterm. Hitting TAB whilst entering a command line completes the current `word' as far as is unambiguously possible. Hitting TAB a second time then shows a list of possible completions (or the first few if there are many): the user can then enter one or more characters and hit TAB again.
What is it `completing'? There are two modes: within an unterminated
(single- or double-) quoted expression it completes file paths.
Otherwise, it is completing R expressions: most obviously it will match
visible R object names and keywords, so apr folloed by TAB
will (in a vanilla session) complete to apropos
. After a
function name and parenthesis (e.g. apropos() it will complete
argument names (and =), and after $ or @ it will
complete list components or slot names respectively.
This feature can be turned off: Rgui has two menu items to do
so, and setting the environment variable R_COMPLETION to
FALSE
turns it off completely for both Rgui and
Rterm. Further, the behaviour can be fine-tuned: to see the
settings available use
?rc.settings
which also explains how the various types of completion work.
This feature is very similar to the completion available in the
readline
-based command line interface on Unix-alikes: the Mac OS
X Gui has a different completion scheme.
Have you changed the working directory?: see Q6.2.
Use the `File | Change Dir...' menu item to select a new working directory: this defaults to the last directory you loaded a file from. The workspace is saved in the working directory. You can also save a snapshot of the workspace from the `Save Workspace...' menu item.
From the command line you can change the working directory by the
function setwd
: see its help page.
Yes. All ports of R use the same format for workspaces, so they are interchangeable (for the same 2.x.? version of R, at least).
Note though that character data in a workspace will be in a particular encoding that is not recorded in the workspace, so workspaces containing non-ASCII character data may not be interchangeable even on the same OS. Since R marks character data when it knows it to be in UTF-8 or Latin-1 (including its Windows superset, CP1252), strings in those encodings are likely to be transferred correctly: fortunately this covers most of the common cases (Mac OS X normally uses UTF-8, and Linux users are likely to use Latin-1 (its interpretation of the C locale) or UTF-8.)
This is deliberate: the console output is buffered and re-written in chunks to be faster and less distracting. You can turn buffering off or on from the `Misc' menu or the right-click menu: <Ctrl-W> toggles the setting.
If you are sourcing R code or writing from a function, there is another
option. A call to the R function flush.console()
will write out
the buffer and so update the console.
They only seem to be truncated: that $ at the end indicates you can scroll the window to see the rest of the line. Use the horizontal scrollbar or the <CTRL + left/right arrow> keys to scroll horizontally. (The <left/right arrow> keys work in the pager too.)
To build R on 32-bit Windows you will need the tools from http://www.murdoch-sutherland.com/Rtools/ as well as some others. See the `R Installation and Administration' manual.
It has been possible to cross-build R for Windows x64 using
binutils
and gcc
with the `x86_64-pc-mingw32' target,
using suitable settings in src/gnuwin32/MkRules (see the comments
there). However, that toolchain is experimental and the support for
Unicode file functions needed for R 2.7.x is at present incomplete.
You are of course welcome to try a commercial compiler, but we will not be distributing a port to which users cannot easily add packages.
Fast BLAS (Basic Linear Algebra Subprograms,
http://www.netlib.org/blas/faq.html) routines are used to speed
up numerical linear algebra. There is support in the R sources for the
`tuned' BLAS called ATLAS (http://math-atlas.sourceforge.net).
The savings can be appreciable: on a 2.6GHz P4 and a 1000 x 1000 matrix
svd
took 16.2 sec with the standard BLAS and 7.8 sec with ATLAS.
Because ATLAS is tuned to a particular chip we can't use it generally:
the optimal routines for a P4 or an Athlon XP are quite different and
neither will run at all on a PII.
BLAS support is supplied by the single DLL R_HOME\bin\Rblas.dll, and you can add a fast BLAS just by replacing that. Replacements for some of the more common chips are available on CRAN in directory bin/windows/contrib/ATLAS. See the R Installation and Administration Manual for how to build an ATLAS Rblas.dll tuned to your system using the R sources.
We strongly encourage you to do this via building an R package: see the `Writing R Extensions' manual. In any event you should install the parts of the R system for building R packages (installed by default), and get and install the tools (including Perl) and compilers mentioned in the `R Installation and Administration' manual. Then you can use
...\bin\R CMD SHLIB foo.c bar.f
to make foo.dll. Use ...\bin\R CMD SHLIB --help for
further options, or see ?SHLIB
.
If you want to use Visual C++, Borland C++ or other compilers, see the appropriate section in README.packages.
You will need a suitable version of gdb: we normally use that
from the Cygwin distribution. Debugging under Windows is often a
fraught process, and sometimes does not work at all. If all you need is
a just-in-time debugger to catch crashes, consider
Dr. Mingw
from the mingw-utils
bundle on
http://www.mingw.org (see also
http://jrfonseca.dyndns.org/projects/gnu-win32/software/drmingw/).
That will be able to pinpoint the error, most effectively if you build a
version of R with debugging information as described below.
First, build a version of the R system with debugging information by
make clean make DEBUG=T
and make a debug version of your package by either
make pkgclean-mypkg make DEBUG=T pkg-mypkg
or
Rcmd install -c mypkg set DEBUG=T Rcmd install mypkg
Then you can debug by
gdb /path/to/R-2.7.0pat/bin/Rgui.exe
However, note
tukeyline
in
package stats
might be
gdb ../../../../bin/Rgui.exe (gdb) break WinMain (gdb) run [ stops with R.dll loaded ] (gdb) break R_ReadConsole (gdb) continue [ stops with console running ] (gdb) continue Rconsole> library(stats) (gdb) break tukeyline (gdb) clear R_ReadConsole (gdb) continue Rconsole> example(line) ...
Alternatively, in Rgui you can use the `Misc|Break to debugger' menu item
after your DLL is loaded. The C function call breaktodebugger()
will do the same thing.
mingw
version of gdb. It does often work with the cygwin
version.
mingw
port
on their site), and Borland's debugger with a DLL compiled in a Borland
compiler.
See http://www.stats.uwo.ca/faculty/murdoch/software/debuggingR/gdb.shtml for some further details.
You need to do two things:
(a) Write a wrapper to export the symbols you want to call from R as
extern "C"
.
(b) Include the C++ libraries in the link to make the DLL. Suppose X.cc contains your C++ code, and X_main.cc is the wrapper, as in the example in `Writing R Extensions'. Then build the DLL by (gcc)
...\bin\R CMD SHLIB X.cc X_main.cc
or (VC++, which requires extension .cpp
)
cl /MT /c X.cpp X_main.cpp link /dll /out:X.dll /export:X_main X.obj X_main.obj
or (Borland C++, which also requires extension .cpp
)
bcc32 -u- -WDE X.cpp X_main.cpp
and call the entry point(s) in X_R
, such as X_main
.
Construction of static variables will occur when the DLL is loaded, and
destruction when the DLL is unloaded, usually when R terminates.
Note that you will not see the messages from this example in the GUI console: see the next section.
This example used to be in package cxx_0.0-x.tar.gz in the src/contrib/Devel section on CRAN, and could be compiled as a package in the usual way on Windows.
The Rgui.exe console is a Windows application: writing to
stdout
or stderr
will not produce output in the
console. (This will work with Rterm.exe.) Use Rprintf
or
REprintf
instead. These are declared in header file
R_ext/PrtUtil.h.
Note that output from the console is delayed (see The output to the console seems to be delayed), so that you will not normally see any output before returning to the R prompt.
Writing to Fortran output writes to a file, not the Rgui console.
Use one of the subroutines dblepr
, intpr
or realpr
documented in the `Writing R Extensions' manual.
Note that output from the console is delayed (see The output to the console seems to be delayed), so that you will not normally see any
output before returning to the R prompt even when using the xxxpr
subroutines.
The console, pagers and graphics window all run in the same thread
as the R engine. To allow the console etc to respond to Windows events,
call R_ProcessEvents()
periodically from your compiled code.
If you want output to be updated on the console, call
R_FlushConsole()
and then R_ProcessEvents()
.
R-windows@r-project.org