I often use C level debuggers such as lldb and gdb when debugging R
packages with compiled code. If you are unfamiliar with doing this Kevin Ushey
has an excellent
post on the topic.
Usually bugs are reproducible both from the R terminal and RStudio. If this is
the case then running R under the debugger is easy; just start R from the
terminal with R -d lldb.
Read More →I would first like to thank Dean Attali for writing the original post that inspired this one. Creating vectorized functions is definitely a common problem when dealing with vectors and creating functions in R and having public discourse on the best ways to do this is great for the whole community, thanks Dean!
An issue was opened https://github.com/r-lib/fs/issues/95 in the fs
package describing an unexpected error code (ENOENT rather than EEXIST)
when copying the same file to the same destination twice. Tracking down the
cause of this turned out to be one of the weirdest bugs I have seen.
Error messages in many programming languages (including R) often have the full paths to files included in the error message. (e.g. “/Users/jhester/projects/pkgname/R/pkg.R”). This feature is very helpful when working with a package locally as it makes it easy to find exactly what file has an issue. However if these errors are included in documentation examples or in check output the local directory information is extraneous and possibly sensitive.
Read More →Docker and the rocker projects have been widely touted in the R community as a way to provide reproducibility in analysis by explicitly describing system dependencies for a given project. See An Introduction to Rocker: Docker Containers for R for details of the project goals and use-cases. However a different use case than those described in the paper where docker is also useful is for testing R packages during package development.
Read More →