The hardware and bandwidth for this mirror is donated by dogado GmbH, the Webhosting and Full Service-Cloud Provider. Check out our Wordpress Tutorial.
If you wish to report a bug, or if you are interested in having us mirror your free-software or open-source project, please feel free to contact us at mirror[@]dogado.de.
If a mirai future that was terminated abruptly (e.g. via
tools::pskill() or by the operating system), then it was
not detected as such. Instead it resulted in an unexpected error that
could not be recovered from. Now it is detected and a
FutureInterruptError is signaled, which can then be handled
and the future may be reset().
result() on an interrupted mirai future would only
throw FutureInterruptError the first time. Succeeding calls would result
in other errors.
resolved() on a mirai future already known to be
interrupted would requery the mirai object, instead of returning TRUE
immediately.
Now ‘mirai’ futures can be canceled using cancel(),
which also interrupts them by default, which in turn frees up compute
resources sooner. Map-reduce API such as future.apply,
doFuture, and furrr can take advantage
of this by canceling all non-resolved futures whenever they detect an
error in one of the futures. Also, canceled futures can be
reset() and thereafter relaunched, possibly on another
future backend.
Now ‘mirai_multisession’ futures relay
immediateCondition:s in near real-time,
e.g. progression conditions signals by the
progressr package.
mirai::daemons() argument resilience is
being removed.nbrOfWorkers() and nbrOfFreeWorkers() did
not handle mirai dispatcher errors. Because those are integers, these
functions would return the error integer value instead of giving a
FutureError.These binaries (installable software) and packages are in development.
They may not be fully stable and should be used with caution. We make no claims about them.
Health stats visible at Monitor.