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!
The Vectorize function is sometimes suggested as a solution to the problem of iterating over elements of a vector, such as How to use dplyr’s mutate in R without a vectorized function by Dean Attali.
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.
The fs package provides filesystem operations for the R language, it is built on top of filesystem functions in libuv. Libuv in turn relies on the native system calls for each operating system it supports.
Creating an R package can be a daunting task if you have only used R interactively, in notebooks or scripts. This talk will demystify the process creation process by going from a simple R script and turning it into a fully fledged package complete …
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.
These output files could be modified by hand before committing them, e.
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.
Talk on R package development best practices. Focuses on using the devtools package and associated workflows to improve your rate of package development.