High-Performance Open-Source Archive
All deprecated future_invoke_map_*() variants have
been removed.
All *_raw() variants from purrr have been removed,
such as future_map_raw(). purrr 1.0.0 has deprecated these,
they have limited use, and as far as we can tell no packages were using
them (#298).
future_options() has been removed. It has been
defunct since furrr 0.3.0 (May 2022).
New future_map_vec(),
future_map2_vec(), future_pmap_vec(), and
future_imap_vec() to align with purrr (#261).
When a furrr function errors, purrr’s error index is no longer confusingly reported (#250).
furrr_options() no longer drops the
"ordering" attribute when casting non-integer
chunk_size or scheduling to integer (#289,
#290).
furrr now looks up the purrr mapping function on the worker itself, rather than sending over its own copy of the function. This avoids possible issues when you have, say, purrr 1.0.0 locally but purrr 0.3.5 on the worker, where the internals of the purrr function may have changed between the two versions (#253).
Fixed a rare issue where the deprecated .progress
bar may cause an integer overflow with extremely long inputs
(#288).
Detangled furrr’s documentation from purrr’s to avoid some documentation inheritance issues (#286).
Fixed an issue where generating random seeds could sporadically fail (#271, @HenrikBengtsson).
Updated documentation examples and vignettes to use the base R pipe (#285, @HenrikBengtsson).
furrr now requires R >=4.1.0, which is in line with the tidyverse (#285).
lifecycle >=1.0.5, rlang >=1.1.7, purrr >=1.2.1, vctrs >=0.7.0, globals >=0.19.1, and future >=1.70.0 are now required.
future_options() is now defunct and will be removed
in the next minor release of furrr. Please use
furrr_options() instead (#137).
The lazy argument of furrr_options()
has been completely removed. This argument had no effect, as futures are
always resolved before the corresponding furrr function returns
(#222).
future_walk() and the other walk functions now avoid
sending the results of calling .f back to the main process
(#205).
The conditions argument of
furrr_options() now supports selectively ignoring
conditions through an exclude attribute. See
?furrr_options for more information (#181).
Standard output is now dropped from future results before they are returned to the main process (#216).
Condition objects are now dropped from future results before they are returned to the main process (#216).
Unskipped a test now that the upstream bug in future is fixed (#218, HenrikBengtsson/future.apply#10).
Removed ellipsis in favor of the equivalent functions in rlang (#219).
Removed a multisession test related to whether or not an attempt was made to load furrr on the workers (#217).
Updated snapshot tests related to how testthat prints condition details (#213).
furrr now requires R >=3.4.0, which is in line with the tidyverse.
lifecycle >=1.0.1, rlang >=1.0.2, purrr >=0.3.4, vctrs >=0.4.1, globals >=0.14.0, and future >=1.25.0 are now required (#214).
Preemptively updated tests related to upcoming changes in testthat (#196).
Updated snapshot tests failing on CI related to changes in lifecycle 1.0.0 (#193).
Updated documentation examples to explicitly set the seed on the workers when random numbers are generated (#175).
Removed an internal call to
future:::supportsMulticore() since it is no longer internal
(#174).
All furrr functions now enforce tidyverse recycling rules (for
example, between .x and .y in
future_map2()). Previously this was mostly the case, except
with size zero input. Recycling between input of size 0 and input of
size >1 no longer recycles to size 0, and is instead an error. purrr
will begin to do this as well in the next major release (#134).
future_options() has been deprecated in favor of
furrr_options(). Calling future_options() will
still work, but will trigger a once per session warning and will
eventually be removed. This change was made to free up this function
name in case the future package ever wants to use it.
In a future version of furrr, the .progress argument
will be deprecated and removed in favor of the progressr
package. The progress bar has not yet been removed in furrr 0.2.0,
however I would encourage you to please start using progressr if
possible. It uses a much more robust idea, and has been integrated with
future in such a way that it can relay near real-time progress updates
from sequential, multisession, and even cluster futures (meaning that
remote connections can return live updates). Multicore support will come
at some point as well. That said, be aware that it is a relatively new
package and the API is still stabilizing. As more people use it, its
place in the future ecosystem will become clearer, and tighter
integration with furrr will likely be possible.
New pkgdown article on using furrr with progressr for generating progress updates.
New pkgdown article discussing an alternative strategy to automatic globals detection using the carrier package.
New pkgdown article discussing how furrr “chunks” input to send if off to workers.
New pkgdown article on common gotchas when using furrr.
New pkgdown article detailing how to use furrr with remote AWS EC2 connections.
future_walk() and friends have been added to mirror
purrr::walk().
furrr_options() now has a variety of new arguments
for fine tuning furrr. These are based on advancements made in both
future and future.apply. The most important is chunk_size,
which can be used as an alternative to scheduling to
determine how to break up .x into chunks to send off to the
workers. See ?furrr_options for full details.
future_pmap() and its variants now propagate the
names of the first element of .l onto the output
(#116).
future_pmap() and its variants now work with empty
list() input (#135).
future_modify(), future_modify_if() and
future_modify_at() have been brought up to date with the
changes in purrr 0.3.0 to their non-parallel equivalents. Specifically,
they now wrap [[<- and return the same type as the input
when the input is an atomic vector (#119).
future_map_if() and future_modify_if()
gained the .else argument that was added to purrr’s
map_if() and modify_if() in purrr 0.3.0
(#132).
All *_raw() variants from purrr have been added,
such as future_map_raw() (#122).
All furrr functions gained a new argument,
.env_globals, which determines the environment in which
globals for .x and ... are looked up. It
defaults to the caller environment, which is different than what was
previously used, but should be more correct in some edge cases. Most of
the time, you should not have to touch this argument. Additionally,
globals for .f are now looked up in the function
environment of .f (HenrikBengtsson/future.apply#62,
#153).
The future specific global option
future.globals.maxSize now scales with the number of
elements of .x that get exported to each worker. This helps
prevent some false positives about exporting objects that are too large,
and is the same approach taken in future.apply (#113).
.x is now searched for globals. Only globals found
in the slice of .x that corresponds to worker X are
exported to worker X. This is relevant if .x is, say, a
list of functions where each has their own set of globals
(#16).
The progress bar furrr creates now outputs to stderr rather than stdout.
The progress bar is now only enabled for multisession, multicore,
and multiprocess strategies. It has never worked for sequential futures
or cluster futures using remote connections, but .progress
is now forced to false in those cases.
future_invoke_map() and its variants have been
marked as retired to match purrr::invoke_map().
The internals of furrr have been overhauled to unify the
implementations of future_map(),
future_map2(), future_pmap() and all of their
variants. This should make furrr much easier to maintain going forward
(#44).
A MIT license is now used.
rlang >= 0.3.0 is now required to ensure that the rlang
~ is serializable. The hacks in furrr that tried to work
around this have been removed (#123).
future >= 1.19.1 is now required to be able to use
future::value() instead of the soon to be deprecated
future::values() and to access a few bug fixes
(#108).
purrr >= 0.3.0 is now required to gain access to various new
features and breaking changes. For example, map_if() gained
an .else argument, which has been added to
future_map_if().
globals >= 0.13.1 is now required because of substantial new speed boosts there related to searching for global variables, and to gain access to a few bug fixes.
Features:
future_pmap_*() functions have been added to mirror
pmap().
The future.* arguments to each function have been
replaced with an overarching .options argument. Use
future_options() to create a set of options suitable to be
passed to .options. This change streamlines the interface
greatly, and simplifies documentation (#8, @hadley).
future_invoke_map_*() functions have been added to
mirror invoke_map().
More documentation and examples have been added.
Added the ability to use a progress bar with
.progress = TRUE for multicore, multiprocess, and
multisession plan()s.
Bug Fixes:
Fixed a bug with using ~ inside a
mutate() + map() combination.
Added a missed future_imap_int().
furrr on 2018-04-13.
Need mirroring services?
Contact our team at info@vpspulse.com.
Mirror powered by VPSpulse
Infrastructure sponsored by VPSPulse & Secure Payments by ArionPay.