future 1.8.0 is available on CRAN.
This release lays the foundation for being able to capture outputs from futures, perform automated timing and memory benchmarking (profiling) on futures, and more. These features are not yet available out of the box, but thanks to this release we will be able to make some headway on many of the feature requests related to this – hopefully already by the next release.
For shiny users following Joe Cheng’s efforts on extending Shiny with asynchronous processing using futures, future 1.8.0 comes with some important updates/bug fixes that allow for consistent error handling regardless whether Shiny runs with or without futures and regardless of the future backend used. With previous versions of the future package, you would receive errors of different classes depending on which future backend was used.
future_lapply() function was moved to the future.apply package back in January 2018. Please use that one instead, especially since the one in the future package is now formally deprecated (and produces a warning if used). In future.apply there is also a
future_sapply() function and hopefully, in a not too far future, we’ll see additional futurized versions of other base R apply functions, e.g.
Finally, with this release, there was an bug fix related to nested futures (where you call
future() within a
future() – or use
%<-% within another
%<-%). When using non-standard evaluation (NSE) such as dplyr expressions in a nested future, you could get a false error that complained about not being able to identify a global variable when it actually was a column in a data.frame.
I’m giving a presentation on futures at the eRum 2018 conference taking place on May 14-16, 2018 in Budapest. I’m excited about this opportunity and to meet more folks in the European R community.
I’m happy to announce that The Infrastructure Steering Committee of The R Consortium is funding the project Future Minimal API: Specification with Backend Conformance Test Suite. I’m grateful for their support. The aim is to formalize the Future API further and to provide a standardized test suite that packages implementing future backends can validate their implementations against. This will benefit the quality of higher-level parallel frameworks that utilize futures internally, e.g. future.apply and foreach with doFuture. It will also help moving forward on several of the feature requests received from the community.
Help shape the future
If you find futures useful in your R-related work, please consider sharing your stories, e.g. by blogging, on Twitter, or on GitHub. It always exciting to hear about how people are using them or how they’d like to use. I know there are so many great ideas out there!