This document contains a user guide to the R.app version of R, and information on using R on OS X which supplements the main R manuals. As from R 3.0.0 most of the information has been moved to those manuals, the latest versions of which can be found at http://cran.r-project.org/manuals.html.
In this document R refers to the core, command-line-based R system while R.app refers to the GUI-based Mac OS application that controls the underlying R.
This `R for Mac OS X FAQ' is rather incomplete at the moment and requires contributions from users. Anything specific to the R language can be found in the main R-FAQ (see http://cran.r-project.org/doc/FAQ/R-FAQ.html). Please send any requests/questions you would like answers to the R-SIG-Mac mailing list (after subscribing) as well as comments on this FAQ.
The last section of this document contains the most frequently asked questions that don't fit strictly into any of the categories above – it is usually a good idea to always look into that section if your issue doesn't fit any of the above or was not answered in one of the specific sections. Always read this FAQ before asking for help on R-SIG-Mac!
There is only one version of R for Mac OS X. However, R on Mac OS X can be used either on the command-line as on other Unix systems, or via the R.app GUI (see R.app). The second approach is mostly preferred by Macintosh users.
Prior to R 3.0.0 there were separate 32- and 64-bit version of R.app: nowadays only 64-bit builds are supported in binary form.
64-bit Intel-based Macs, that is any machine made since mid 2008.
R is available on CRAN in the form of an Installer package containing the R framework and the R.app GUI. The package is usually named R.pkg with an optional version number.
The installation is done by double-clicking on the Installer package. The Installer will guide you through the necessary steps. Note that it will require password or login of an account with administrator privileges. The installation can be customized, but the default is suitable for most users.
Snapshots of the R-patched and R-devel flavours are available at http://r.research.att.com/, packaged in the same way.
Further details, including uninstallation and building R from the sources, are in the `R Installation and Administration Manual'.
R.app is the name of the GUI for Mac OS X that was introduced in R 2.0.0. It appears as an icon labeled R, but to avoid confusion with general R, we prefer to use the name as it appears when using Get Info on the GUI: R.app This stands for R application.
Internally R.app is a Cocoa program (hence written in Objective C) which links to embedded R installed as a framework.
R.app is part of the binary distribution of R for Mac OS X available from CRAN. That distribution consists of one package containing the R framework and R.app.
Development versions of R.app are made available on daily basis in the form of a disk image containing the R.app itself. See the Mac OS X pages on CRAN for detail how to obtain such snapshots (currently at http://R.research.att.com/).
R.app is installed the same way as the R framework, namely using binary package provided on CRAN. The bin/macosx directory of a CRAN site contains a standard Apple installer package named R.pkg (optionally containing the version number). Download and double-click the package icon.
Please, carefully read the note on the usage of tcltk and Fortran on the bin/macosx directory of a CRAN site.
In this section you'll find general information on the R.app. For specific R tasks that can be done via the R.app using menus you should read below (see The Menus).
The current design of the R Console is to have a single frame for input (user) and output (R).
Copy and paste works in R as in any other Macintosh application.
If you want high resolution graphic exports, you can save the PDF format using the File/Save as menu item (see Quartz device). Or you can use supported formats in R through pdf(), jpeg() etc. (type ?capabilities to get more details).
If not otherwise specified in the Preferences (see Preferences), or if the specified path is no longer available, then the default working directory at startup is the user home.
The working directory can be changed using the setwd R command or using the Misc menu item Change working directory. Finally it is possible to use a specific directory for a single R session by dragging a folder onto the R.app icon. If R.app is not running, this will cause R.app to be started in the directory corresponding to the folder dragged. The same can be achieved on the command line – for example open -a R . causes R.app to be started using the current directory as the startup working directory.
This feature is useful if you want different startup procedures defined by the .Rprofile; you can edit a .Rprofile (containing you personal initialization R commands) in a particular directory and use the Preferences (or any other method mentioned above) to change the startup directory. Next time you launch R.app the .Rprofile is read and executed by R at startup. This is the equivalent on Unix (or the command line) to launch R from different directories.
When the R Console Window is resized, the R option width is set appropriately so that any future output will fit the window size.
Use the Preferences window to set the R Console text colors (see Preferences).
R.app provides an integrated editor for editing of R code. It sports a number of features designed to help developing code inside R. The probably most often used function is the ability to execute code directly from the editor by pressing <Command>-<Return>. Other features include syntax highlighting, brace-matching, code completion and function indexing.
The editor supports undo/redo operations on an appropriate level of granularity (used to be all or nothing). The editor has an optional facility to show line numbers. These help with locating error messages. The editor also responds to the 'Go to Line' Edit menu function. The associated Preference Pane allows enabling/disabling of the line numbers, as well as setting line number gutter width (to fit larger line numbers) and text margin width.
Completion of typed input (both file names and R code) in the editor is available through the Edit menu 'Complete' or by typing <Control>-<.> (same as is Xcode). It uses the same facilities as the console window (for compatibility the console responds to both <Tab> and <Control>-<.>).
The editor maintains a popup list of functions defined in the edited document. The list is available in the toolbar and is updated as you type. Selecting a function from that list causes the cursor to jump to the beginning of the function.
The editor supports syntax-highlighting for R code. It is possible to change the syntax highlighting colors using the Syntax Color Preference Pane (see below). Starting with R.app version 1.17 lazy syntax highlighting is used, which means that changes influencing the entire file (such as typing a single or double quote) no longer apply to the entire file, but only a few lines. This temporary state is usually recovered by closing the quote, but in some rare instances it may persist until a change is made to the first line of the offending quote. However, lazy highlighting brings huge speedup when editing large files.
By default, the editor used is incorporated into R.app, the Mac OS X GUI for R. It is a
relatively simple multi-document editor that supports the features listed above. Additionally,
two powerful commands are available to source the file being edited in its entirety (Command-E)
or to source the current selection to R (Command-Return). Using R's edit() function, allows
editing of R objects or files while R is kept waiting for the edit session to finish.
It is possible to 'redirect' all R requests to an external editor, which runs
outside R.app. In that case, it is not possible to keep R waiting if edit() is used. Using
AppleScript it is easy to implement Command-E and Command-Return like functionality.
The editor contains a light-weight help system in form of a search filed placed inside the toolbar. It is possible to use either an exact or approximate search.
Drag and drop of a directory on the R.app icon while R.app is not running will start R.app and set the working directory. By default .RData and the history file (default name .Rapp.history) are fetched from this working directory. If a file is dropped on the R.app icon while R.app is not running, R.app is started, the file is either restored (if it is a saved workspace), sourced into R.app or opened in the selected editor. Whether the file is opened or sourced is specified by a Preference setting in the StartUp Preference Pane.
Note: At this point opening a file in the editor before R.app is finished loading will crash R.app.
While R.app is running, drag & drop of a directory updates the working directory. Drag & drop of a file sources or opens the file in the selected editor. Double clicking on files bound to ("Open With ...") R, if R.app is not running, R.app is started and the file is sourced or opened in editor. If R.app is running, the file is opened in the editor.
The Help screen allows a user to go back or forward to previous help pages. It is possible to print help pages. If a help topic is not found, a pop-up window allows to exit the help search or expand the search to a fuzzy/approximate search.
R.app uses history files that are (superset) compatible with history files created by R. Multiline support remains available from inside R.app. Multiline is particularly useful when using the <Command>-<Return> feature while editing an R script. Import and export allows storing and importing history from files visible in the Mac OS Finder. Multiline is preserved. This can be set through the StartUp Preference Panel. Default number of kept history entries is 250. A variety of history entry cleanup modes is possible. At a minimum it is suggested to select "Cleanup history entries". It's optional to select removal of duplicate entries and strip comments.
Note: Command-line R stores history in a file usually called .Rhistory. It is suggested to use a different name for the R.app history file, and the default is .Rapp.history.
Note that the functions loadhistory(), savehistory() and
hence history() are not currently supported in R.app.
The official CRAN binaries come pre-packaged in such a way that administrator have sufficient privileges to update R and install packages system-wide. However, the default Unix build requires root-authentication for package installation and other administrative tasks. As it is not feasible to run the GUI as root, we provide the possibility to authenticate system commands issued from the GUI. The authentication requires an administrator login and causes all subsequent system commands to be executed as root. Use with care!
In order to allow non-administrators to maintain their own set of
packages, R.app optionally adds ~/Library/R/x.y/library to the
.libPaths (see start-up preferences, x.y denotes the R
version without patch level). It is possible to use the Package
Installer to install packages either globally (admin users only) or for
the current user only. (This is the same mechanism for personal library
directories described in the main R documentation, but with a location
specific to CRAN-like builds of R on OS X.)
Note that user-local packages are only used when the corresponding preference option is enabled. The default for admin users is to use system-wide directories, for non-admin users the personal library directory will be used.
The Application menu is the first one after the main Apple Menu: it is
labelled R.
With this menu you can access three items: 1. the About box, which tells you which version of R is currently in use, 2. Check for updates, which search on CRAN if a new version of the binary distribution of R for Mac OS X is available (you need an Internet connection), 3. you can access the Preferences (see Preferences).
This menu provides standard functionalities. The open command is associated to the action Source R code, which means that you can select a file, which is a script, and it will be executed in R. This is a interface to the R source command source.
Apart for standard functionalities, the only relevant item in this menu is Edit Object which is an interface to the R edit function.
With this menu you can load and save the history of commands typed in the R Console or view what's currently inside. You can also change the current working directory, let R show you the current working directory or set it back to the startup directory. From release 1.9.0 of R the current working directory is also shown on the main window bar.
Here you find self explanatory menu items for manage your workspace in
R. You can either load and save the workspace also by specifying file
name. All of these are interfaces to the load and
save R commands. The only relevant item, which is specific
to this GUI, is Browse workspace which invokes the
browseEnv() function in R. This will open a window with a
summary description of the objects in your workspace. Recursive objects
(like lists, data.frame etc) can be expanded (one level only though).
Using this menu you can have access to the list of packages and data-sets installed on your system and to the ones on CRAN or on the Bioconductor site.
With the first two menus you can load and detach packages and data-set from the workspace. Let's start with the Package Manager. This opens a window with several columns displayed. For each package on your system you can see a check box, the current status of the package (loaded/not loaded), its name and the package description text. You use the check box to select/de-select the packages you want. On window closure, the checked packaged will be loaded and the unchecked ones (if loaded) will the detached (not completely as on Mac OS X you cannot unload completely dynamic libraries).
The same applies to the Dataset Manager menu but for data-sets.
You can than get or update packages CRAN either in binary or source format. Daily build of CRAN packages are available for Mac OS X. If you don't know how to build R itself from source, you'll probably be unable to build packages from source on your own. In this case, you should always choose for the binary option. These binary packages work (for sure!) for the release version of R for Mac OS X you find on CRAN even though it is not excluded that they will work for other prebuilt versions of R.
When you attempt to install packages from CRAN, R first tries to get a connection to the Internet to download the list of available packages. Than a window will open similar to the one in the package manager with the only difference that for each package there is also the information concerning the version of the package installed on your system (if any) and the version of the prebuilt package available on CRAN. When you close the window, the select packages will be downloaded.
The same strategy applies to the Bioconductor menu item, with some more options typical of the Bioconductor way of managing packages.
For some reason it could happen that you have the package you want to install (either in binary or source form) on one of your local disks, or even a directory containing a package source. You can use the last menu to do the task of installing the package. Having a package in a directory form usually applies to people that are developing packages themselves.
Note that packages which do not contain C, C++, Fortran ... code which needs to be compiled can be compiled from their sources with no additional tools.
For more information on this topic see also How to install packages.
Using this menu you can open the on-line manuals (R Help), read this FAQ and review the latest changes, bug fixes and new features of R for Mac OS X (What's new in this version). There are also interfaces to the R help and help.search functions as well as the example function.
You can set several aspects of the R GUI via preferences. You can access the Preferences window via the Application menu when the R Console is open.
The Drag & drop section defines drag & drop behaviour during R start-up. Options are to open file in an editor or to source file. Default is to source the file. The Default Library Paths section enables, on next start-up of R, to add a directory, e.g. ~/R/Library, to the library search/install path. The initial working directory section can be used to enforce the initial working directory. If no directory is specified, this directory is used as the default. The Change button allows to select a new directory. The Always apply selection will enforce the specified intial start-up directory. The history section controls reading of the history file on startup. If selected, R will read history file on start-up. The R history file field is used to read and store history from/to. This field can be edited to allow selecting files starting with a period (e.g. .Rapp.history). If you want the same history file regardless of your selected working directory, specify a fixed path (e.g. ~/.Rapp.history). The Default button will reset the history file name to its default value. The History handling area allows setting of the max number of entries to be kept in history, to remove duplicate entries, to cleanup history entries (this is very useful to remove blank lines when submitting multiple lines using Command-Return) and the strip comments before the entry is added to the history.
If Built-in editor is selected, allows enable/disable of syntax
coloring, brace highlighting and the showing of line numbers. If
External editor is selected, allows specifying which external
editor. That editor will be used for all editing functions. It runs as a
separate application. Using an external editor means that R will never
wait while editing (e.g. edit(A) will return immediately and
open A in the external editor. Command-E and Command-Return like
functionality would need to be implemented by other means,
i.e. AppleScript. The external editor can be any application
(e.g. SubEthaEdit, TextWrangler, BBEdit, Smultron, etc) or can be
activated through a shell script (e.g. see or smultron, both give better
control on how to start the editor).
Enables to select the syntax colors.
Enables to select the input/output colors in R Console.
Currently the the Quartz preference pane is not being used.
On Unix systems a bug report can be generated using the function
bug.report(). Alternatively the bug report can be submitted to
the Web page at http://bugs.R-project.org/.
Before you file a bug report, please try to reproduce it using both
R.app and the console version of R (if applicable). If the bug if
R.app-specific, please report the bug to the mailing list
R-SIG-Mac@R-project.org instead. Please do NOT forget to
mention the exact R.app version and include the output of
sessionInfo().
In any circumstances, in case of a crash, please report the crash.log for the R.bin and/or R.app application. You can get this crash.log using the Console.app located inside /Applications/Utilities (select `1' in the crash menu in the R console at the time of the crash (if you see that menu) to generate a crash report).
You have several options for installing new packages on your system. We discuss here only the GUI interface to the standard R functions like install.packages(). For the R functions see the standard R documentation.
GUI provides direct access/download/installation of packages located on
CRAN, the Bioconductor repositories or a custom repository. You can
also install packages from local files, either binary of source
packages, as explained below. Otherwise you can use the appropriate R
commands (see install.packages) to install packages from a
specific location other than the above mentioned ones.
R for Mac OS X recognizes packages in two forms: binary packages and source packages.
Binary packages are R packages in ready-to-use form, such that no
additional tools are necessary for their use. Binary packages are
specific for a given R version and OS. CRAN and Bioconductor
repositories offer R packages in binary form for the last released
R version. Unlike on other Unix systems, R for Mac OS X installs
binary packages by default, i.e. install.packages will look for
binary repositories unless instructed otherwise.
Source packages are general in that they can be used on any platform and OS supported by R, but they need to be processed and/or compiled before they can be used. Additional tools may be necessary for that, see see Installation of source packages for details. For most users binary packages are sufficient (if available and current).
On Mac OS X packages can be installed in three ways:
install.packages command in R
R CMD INSTALL command in the shell (aka Terminal)
The latter two methods are common to all Unix systems and as such described in the general R documentation. In the following we will concentrate on using the Package Installer.
If you decide to install packages you should use the Packages & Data menu of the GUI, in particular the sub-item Package Installer. Select the repository, package type (binary or source) and press Get List. This will connect to the repository through the Internet and a list all packages available for installation. The list tells you if a package is already installed on your system, the version of the package available on CRAN and the version of the same package if already installed.
You can use the search field to narrow the list of package to those matching your search criteria. Additionally you can use the search list menu to list only packages that are already installed on your system which is useful for comparing versions of available and installed packages. Finally, you can filter down to packages that have been installed by a previous R version as to allow a simple upgrade.
Select any package you want to install and press the Install button. You can follow the progress of the installation in the R Console. Once the required packages are installed, the list is re-loaded to reflect the versions of newly installed packages.
If you want to update all packages to the latest version, select the repository to use for the packages and press Update All. R will automatically determine the list of packages that can be updated and present you with a selection of packages to update.
You can also download any other package from the Internet yourself and decide to install it from source. In such case select one of the local entries in the top left list and press the Install button (which is now enabled).
Packages can also be installed from other repositories by selecting Other Repository source. Enter the repository URL in the adjacent field. Note that currently the Package Installer assumes that custom repositories maintain proper hierarchy for both source and binary packages the same way CRAN does when using Other Repository. If your custom repository is flat, select Other Directory URL in the installation type list.
Source packages which do not contain compiled code can (with rare exceptions) be installed with no additional tools.
Packages with compiled code (or some with Unix scripts) need the tools used to build R itself discussed in the `R Installation and Administation Manual', and these will need to be in the `PATH' as seen from R.app or command-line R. For R.app you may need to add e.g. /usr/local/bin and it is usually most convenient to use command-line R.
If using a CRAN binary install of R the compilers may not be in the same place or have the same names as on the CRAN build machine. Look at file /Library/Frameworks/R.framework/Resources/etc/Makeconf, which will contain lines like
CC = gcc -arch x86_64 -std=gnu99
CXX = g++ -arch x86_64
CXXCPP = g++ -arch x86_64 -E
FC = gfortran -arch x86_64
F77 = gfortran -arch x86_64
OBJC = clang -arch x86_64
OBJCXX = clang++ -arch x86_64
You can either edit that file, or override settings in file ~/.R/Makevars: see the section `Customizing package compilation' of the `R Installation and Administration Manual'.
The main library of packages is the one located inside the R.framework
(in /Library/Frameworks/R.framework/Resources/library). This
library contains the packages (base and recommended ones) distributed
along with R. Only administrators are allowed to install packages in
this system-wide directory. Note that this directory is
R-version-specific. Optionally users can install personal packages in
their ~/Library/R/x.y/library directory where x.y denotes
the R version without the patch level (such as 3.0) – see the startup
preferences in R.app.
The Package Installer performs installation to either place depending on the installation target setting. The default for an admin users is to install packages system-wide, whereas the default for regular users is their personal library tree.
If you use install.packages R function instead of
the Package Installer, the regular Unix behavior applies (see help pages
for details). For default setup this means that the packages are
installed according to the startup preference setting. You can check the
current defaults by issuing
.libPaths()
R has partial support for Apple-Scripts. At the moment R can be invoked and asked to run commands from an AppleScript script. What follows is an example of script that interacts with R. It first invokes R and then sends commands to R with the cmd applescript command.
set CommandLine to "R.Version()"
try
tell application "R"
activate
with timeout of 90000 seconds
cmd CommandLine
cmd "Sys.getenv()"
cmd "print(\"HelloWorld!\")"
end timeout
end tell
end try
In the above, cmd is the (only) applescript command in the R dictionary that is used to tell R to execute an R command in the R Console. The syntax is
cmd <command string>
where command string have to be in quotes. Actually, the output of the command is not sent back to the application that is calling R but to the R Console directly.
There are some issues. The first is that if R is still not running, it will take a while (depending on how fast your machine is) to startup. In the meanwhile the script sends commands without waiting and it could happen that some commands are missed by R, i.e. they arrive before R is ready to receive applescript commands. The second issue, is that it could be that the applescript calls a bad version of R. This could happen if you have an old version of R (for example the old Carbon R) installed on your System.
As an example, we report here a small script that asks R to source a file using a file dialog.
set file_to_source to (choose file with prompt "Choose file to source") as alias
try
tell application "R"
activate
with timeout of 90000 seconds
cmd "source(\"" & file_to_source & "\")"
end timeout
end tell
end try
R accepts the Apple Event command open. This means than an external editor can communicate with R sending portions of R code to execute via files. This is the approach used by the R-Tcl Mode in Alpha X (see http://www.kelehers.org/alpha/).
Dragging a file on the R icon, causes R to source this file via the source R command or, if the file is an R image data file RDX1 or RDX2 (normally files with extension .rda or .RData), the data is loaded in the workspace and every object with the same name in the workspace is overwritten without notice. Loading a data file is equivalent to the R command load. At the moment there is no control over the file types, i.e. dragging wrong files (i.e. files that are not R scripts or image data) simply gives an error. It is up to the user to do the right thing.
If R is not yet running this action causes R to startup.
The quartz() device is the native graphic device in R for Mac OS
X. Its name derives from Apple's Quartz Technology which is essentially
similar to PDF rendering.
The quartz() device can be used from R.app or a suitable build of R
running at the Mac console. Where supported it is the default graphics
device.
The quartz device allows for interaction. You can use both identify and locator functions. To break the sequence you should right/control-click or hit the <ESC> key.
You can save the content of the quartz device window into a PDF file, via the R menu when the device window has focus. This is a simple way to export high quality graphics from R into other applications on Mac OS X as graphics is PDF-based (so are almost all applications available). For other solutions, see (see Copying the image into the clipboard) and the quartz.save function.
You can copy the content of the quartz device window in the clipboard to make the resulting image available for pasting into other applications. The clipboard will contain both a PDF version and a bitmap version of the quartz device window. Which version will be used depends on the pasting applications, most modern application will prefer the PDF version which is of higher quality as it supports vector graphics.
Each binary distribution of R available through CRAN is built to use the X11 implementation of Tcl/Tk. Of course a X windows server has to be started first: this should happen automatically on OS X, provided it has been installed (it needs a separate install on Mountain Lion and later). The first time things are done in the X server there can be a long delay whilst a font cache is constructed; starting the server can take several seconds.
Mac OS X 10.9 and higher no longer include X11 by default and it has to be obtained separately from http://xquartz.macosforge.org.
If you don't like the X11 style of widgets and use command-line R you would probably want to build R using the Aqua version of Tcl/Tk (see the `R Installation and Administration Manual'). Note, however, that such builds do not work when used in the R.app GUI.
R and the R.app GUI introduced support for internationalization in R 2.1.0. Among other things this means that both messages and GUI elements can be translated into various languages. R.app automatically detects user's settings in the International section of the System Preferences and uses that information to offer translated messages and GUI if available. Please note that both Language and Formats information is used so they should be set up consistently.
If you use a non-standard setup (e.g. different language than formats), you can override the auto-detection performed by setting `force.LANG' defaults setting, such as for example
defaults write org.R-project.R force.LANG en_US.UTF-8
when run in Terminal it will enforce US-english setting regardless of the system setting. If you don't know what Terminal is you can use this R command instead:
system("defaults write org.R-project.R force.LANG en_US.UTF-8")
but do not forget to quit R and start R.app again afterwards. Please note that you must always use `.UTF-8' version of the locale, otherwise R.app will not work properly.
By default R.app uses UTF-8 for newly created documents and for the console. When opening new documents R.app assumes UTF-8 and only if the document violates UTF-8 rules, it will try to fallback to legacy encoding, usually Mac Roman.
If you are interested in translating R.app GUI into other languages, please read the developer documentation at http://developer.r-project.org/Translations30.html.
Here are few references that can be of interest for Mac OS X and/or developers.
The Apple Developer Connection (can be reached at http://developer.apple.com) is the main source of information for Apple products (OS, hardware, software) for developers. You can subscribe for free to ADC and get the latest up-to-date tools from Apple (compilers for example): however more recently these have been distributed through the App Store.
There is a page dedicated to development versions for R for Mac OS X. This page is located at http://R.research.att.com/ and is maintained by Simon Urbanek. It contains latest nightly builds of R and R.app as well as information on tools necessary to build R.
Special thanks go to Jan de Leeuw, Byron Ellis and Thomas Lumley in random order. Last but not least Apple for amazing OS and GUI.
You can by writing a .Rprofile file in your favorite session directory and change accordingly the startup working directory using the Preferences (see The current and startup working directories).
In this case R will try to source this file or load the image data file (see Finder actions). If R is not yet running it will be launched.
In R.app you can use the the Stop toolbar button or the <ESC> (escape) key in the console window to interrupt a running calculation or output.
For the command line version the same is achieved by pressing <Ctrl>-c. Both applications honor the INT signal, i.e. you can type the following in a separate Terminal window to cancel all R computations:
killall -INT R
However, if the executed code does not check for interrupts (using `R_CheckUserInterrupt') there may be no way of stopping R. In that case it may be worth alerting the maintainer of the package to allow interruption (if appropriate).
If you see error messages upon start of the R GUI which contain
Library/InputManagers anywhere in the text, then you have some
broken haxxies installed in your system. Those messages do NOT come from
R, so don't blame us. Bundles located in Library/InputManagers
of your home (or system) are hacks that get loaded into every Mac
application that you start. In most cases you don't see them crashing,
because most applications don't show the console output, but R does,
so all the errors those hacks are causing become visible. The easiest
remedy is to delete all offending bundles (possibly the whole
Library/InputManagers folder) and get a fixed version of the hack
(if you need it). The most common cause for broken hacks is system
updgrade (e.g. you get a new Mac and you transfer you settings which
include those hacks that are incompatible with your new Mac).
If you want to disable all external error output in the GUI, use
defaults write org.R-project.R 'Ignore stderr' YES
in the Terminal. Note, however, that this will disable all error output from external programs including package installation or the system command.
The BLAS library used by R depends on the way R was compiled (see `R Installation and Administration' manual for details). Current R binaries supplied from CRAN provide both vecLib-based BLAS and reference BLAS shipped with R. vecLib is a part of Apple's Accelerate framework which provides an optimized BLAS implementation for Mac hardware. Although fast, it is not under our control and may possibly deliver inaccurate results.
The CRAN binary uses --enable-BLAS-shlib option and two Rblas
shared libraries are supplied: libRblas.vecLib.dylib which uses
vecLib BLAS and libRblas.0.dylib which uses reference BLAS from
R. A symbolic link libRblas.dylib determines which one is
used. Currently the default is to use the R BLAS: this is recommended
for precision.
In order to change which BLAS is used, change the libRblas.dylib symlink correspondingly – for example in Terminal:
cd /Library/Frameworks/R.framework/Resources/lib
# for vecLib use
ln -sf libRblas.vecLib.dylib libRblas.dylib
# for R reference BLAS use
ln -sf libRblas.0.dylib libRblas.dylib
This feature is only present in the R CRAN binary. Ordinarily compiled R from sources will only have one of the above BLAS libraries, corresponding to the configuration options used.
The output is not produced continuously during the package installation. R.app does its best to display the output as soon as possible, but for example the documentation script does not print anything until done.
Also note that the development build of R.app sends output to the error console instead of the screen. You may want to check the Console application in that case.
When plots based on the image() function are exported to PDF,
Preview shows very faint grid lines at the edges of the rectangles that
create the image. Those lines are a rendering artifact in Preview coming
from the combination of anti-aliasing and sub-pixel rendering. They are
not really a part of the PDF (zooming in will reveal that they are not a
real object which would get larger with zoom) since the rectangles are
defined as a gapless coverage of the area. The effect can be
circumvented by disabling anti-aliasing in Preview.
We correct for this effect in Quartz when rendering on-screen by snapping all rectangles to pixel boundaries of the screen, but Preview does not.
The same effect occurs in any plot with adjacent, filled polygons without border.
The R.app GUI uses Apple frameworks for text editing and thus the
behavior of text views (console, editor, etc.) is consistent with other
applications and allows a very flexible customization. For example if
you are not satisfied with the default Emacs-like key bindings that Mac
OS X provides, Apple allows you to extend them arbitrarily. For more
details see Apple's documentation on
Key Bindings. There are also many 3rd-party pages on key bindings
customization, search for StandardKeyBinding.dict.
The CRAN build of R is slightly different from a vanilla build of R,
i.e., a simple ./configure && make && make install. The default
package type for all builds compiled from sources is "source"
wheres CRAN uses binary packages. Only the CRAN build is
guaranteed to be compatible with the package binaries on CRAN (or
Bioconductor).
In the command line version of R, R.home() always points to the
Resources directory symbolic link inside the R framework which
points to Versions/Current/Resource which is turn points to the
actual home – a versioned directory such as for example
Versions/3.0/Resources. This is how framework versioning works
in Mac OS X and is defined by Apple (see
Framework Anatomy).
The advantage of this setup is that it is possible to install multiple R
versions in parallel and they all will be fully functional as long as
the Current symbolic link points to the currently used
version. There is even a small GUI utility RSwitch available from
the R for Mac devel page that allows
you to select the desired version. In addition, any application
embedding R can choose to use a specific R version (in most cases) or
any version. Note that R.app is compiled against a particular version
of R and it may crash if RSwitch is used to change the version
of R in use.
Although it is possible to set R_HOME directly to the versioned
path in the R shell scripts (and thus be able to run different version
in parallel without changing the symbolic link), there are several
dangers lurking there so we don't recommend it. One problem is that
building packages from source won't work. The linker is always linking
against the current version of the framework and therefore only the
currently active version of R can compile packages. Further, packages
may have used the value of R.home() at install time and thus may
not work with incorrect setting. Finally, if such an R start script
happens to get copied and the R version changes, it will stop working.
If your R.app GUI crashes on startup, there are two common causes for this: a saved workspace or a corrupted history file. (Another is a mismatch between R.app and R if either has been updated or RSwitch has been used.)
Saved workspaces can contain commands that implicitly load packages
which in turn can trigger bugs in packages or feed R with incorrect
starting values (especially if it was saved using another R). Try
removing or renaming your workspace – it's called .RData. If you
did not change your startup settings, you can e.g. use
mv ~/.RData ~/workspace.RData
to move it aside and load later manually for inspection using load("~/workspace.RData").
Second most common cause of crashes on startup is a history file that was not created using the R.app GUI. Again, move it aside to see if that's the issue: for the default file this could be done by
mv ~/.Rapp.history ~/history.txt
Although we are trying to recover from invalid history files, they can still crash R.app due to issues in the internal handling of strings in Mac OS X. We are currently working on preventing this issue.
If you did both of the above and R.app still crashes, please select `1' in the menu after the crash (if you get the crash menu in the console) and send us the resulting crash report (see see R.app Bugs above).
R.app will by default save the history in a .Rapp.history file
whereas command line R will use .Rhistory. So the saved
history is only used in subsequent R.app sessions and not command-line
R, and conversely.
Note that calling savehistory() in R.app does not currently
save the history of the R.app session: this means that
history() will show an empty window.
When executing system commands (for example directly via system or indirectly via functions that call other programs such as install.packages) the locations in which the shell is looking for programs is governed by the PATH environment variable. That variable may be set differently for R started from an interactive shell and for R started in the GUI. You can use Sys.getenv("PATH") to verify the current setting.
When R is started from a shell (e.g., on the command line of the Terminal), it will inherit settings from that shell. Those are typically modified by shell-specific configuration files, such as .profile or .bashrc. Those apply only to the shell, not to the system as a whole. In addition, some installers (such as MacTeX) will modify global shell settings to make user's life more comfortable on the command line, but, again, those do not apply to programs not started from the shell – such as GUIs. See Apple Technical Q&A QA1067 for what Apple says about the topic.
In order to standardize your PATH setting in R, you can set it in
your .Renviron file (in your home directory – see ?Startup
in R for details on how R uses configuration files on startup). This
setting will apply to R regardless of how it is started. You can also
add more elaborate constructs to .Rprofile instead if you wish to
selectively modify the existing PATH variable via
Sys.getenv and Sys.setenv.
Typically this means that you have corrupted fonts in your system. Open
the Font Book application (in Applications) and check the
fonts that you are using (for example the default font in Quartz is
currently “Arial”). Corrupted fonts will have no glyphs (text will not
appear as it should), remove such fonts.