Nothing
ProgressTrackingContext.R
class.
Closes #44.UserApiConsumer
class. Closes #41.UML
design diagram. Closes #45.apply
operation to README
documentation.Service$apply
operation for Backend
classes to
validate the provided margin
argument before running the parallel operation.Helper$check_array_margins
to validate the margins provided to
the Service$apply
operation.Exception$array_margins_not_compatible
for using improper
margins in the Service$apply
operation.Exception$primitive_as_task_not_allowed
for trying to decorate
primitive functions with progress tracking in the ProgressTrackingContext
class.Helper$is_of_class
to check if an object is of a given class.get_output
operation of SyncBackend
for
consistency.Service$lapply
and Service$apply
operations for all
classes that implement the Service
interface.par_lapply
and par_apply
functions to the user API
. These functions
can be used to run tasks in parallel akin to parallel::parLapply
and
parallel::parApply
, respectively.UserApiConsumer
R6
class that provides an opinionated wrapper around
the developer API
of the parabar
package. All parallel operations (e.g.,
par_sapply
and par_lapply
) follow more or less the same pattern. The
UserApiConsumer
encapsulates this pattern and makes it easier to extend
parabar
with new parallel functions (e.g., par_apply
) while avoiding code
duplication. The UserApiConsumer
class can also be used as a standalone
class for parallel operations, however, its primary purpose is to be used by
the parallel task execution functions in the user API
.x
argument of task execution functions in
ProgressTrackingContext
class.parabar
in file name.file.create
in ProgressTrackingContext
class. This
warning is superfluous since the code handles creation failures.par_sapply
to use the UserApiConsumer
class.API
R6
classes to implement the lapply
parallel
operation.AsyncBackend
. Closes
#35.CC BY 4.0
license icons in README.md
for the
package website..decorate
method of ProgressTrackingContext
to be more flexible.
More specifically, the method will now throw when primitive functions are
provided for decoration. The method can now handle both inline functions
(i.e., function(x) x
) and functions that have a body defined in terms of
compound expressions (i.e., function(x) { x }
). Closes
#32.export
operation in the SyncBackend
and Context
classes to
fallback to the parent environment if the argument environment
is not
provided.URL
in package NEWS.md
per CRAN
request.URLs
in package documentation per CRAN
request.v0.x.x
to v1.x.x
.CC BY 4.0
license for package documentation, vignettes, and website
content.GitHub
workflow via
codecov
and badge in
README
.comparison.Rmd
to compare parabar
to the pbapply
package,
and provide rough benchmarks. The comparison.Rmd
vignette is locally build
from the comparison.Rmd.orig
file (i.e., see this
resource for more
information).Options$progress_log_path
to handle generation of
temporary files for tracking the execution progress of tasks ran in parallel.
Using a custom path (e.g., for debugging) is also possible by setting this
active binding to a desired path.Specification
for testing purposes.\dontrun{}
statements in examples with try()
calls.Options
class to feature the progress_log_path
active
binding..decorate
method of
ProgressTrackingContext
to use bquote
instead of substitute
.ProgressDecorator
to ProgressTrackingContext
to
be more consistent with the idea of backends that run in contexts....
optional arguments to signature of get_output
method in Service
interface..make_log
of ProgressDecorator
to use the
progress_log_path
option.UML
diagram to include missing classes and changed methods. Also
updated the corresponding diagram figure in the package documentation.Specification
to prevent incompatible cluster types (e.g., FORK
) on
Windows
platforms. For such cases, a warning is issues and the cluster type
defaults to PSOCK
.make_logo
can be ran on all platforms.README
to add CRAN
installation instructions and new badges.\dontrun{}
from make_logo
function examples as per
CRAN
request in commit 87678fe
. However, this results in the examples
failing the R-CMD-check
workflow. Reverted the change in commit a9d11ac
.LOGO
from v1.x.x
to v0.x.x
.SyncBackend
class.pkgdown
reference section.clear
: to clean a provided backend instance.export
: to export variables from a given environment to the .GlobalEnv
of the backend instance.peek
: to list the variables names available on the backend instance.evaluate
: to evaluate arbitrary expressions on the backend instance.Helper$check_object_type
method checks if the type of an object matches an
expected type. If that is not the case, the helper throws an error (i.e.,
Exception$type_not_assignable
)..scss
styles to override the table column width for the exported
wrappers table in the pkgdown
website.README
and package documentation to mention new exported wrappers.pkgdown
.roxygen2
@examples
for exported wrappers. The code for the examples
is located in the documentation for the start_backend
function. All other
exported wrappers (i.e., clear
, export
, peek
, evaluate
, and
par_sapply
) inherit the @examples
section from start_backend
.@seealso
documentation sections.backend
argument of par_sapply
to backend = NULL
. This implies,
that par_sapply
without a backend behaves identically to base::sapply
.export
method to use the .GlobalEnv
as fallback when exporting
variables.extra.scss
to improve documentation website.S3
print method for the LOGO
object.get_option
, set_option
, and set_default_options
.README
. More specifically, added description for Service
interface methods and enabled documentation linking (i.e., via ?
) for
pkgdown
website.Options
class.ProgressBar
use wait = TRUE
when fetching the
output.evaluate
backend operation. The expression passed to
evaluate
was not correctly passed down the function chain to
parallel::clusterCall
. See this
question on StackOverflow
for
clarifications. Closes
#9..bar_config
in ProgressDecorator
class to
list
. This way, the configure_bar()
method of ProgressBar
class becomes
an optional step.filelock
package. Closes
#8.DESCRIPTION
.man-roxygen/parabar.R
\html{...}
to fix HTML
validation errors.
Closes #6.DESCRIPTION
file to comply with CRAN
requirements.README
file.par_sapply
exported function due to exceeding the
CRAN
time limit for running examples.pkgdown
and GitHub
pages.GitHub
workflow to automatically check the package on several platforms
and R
versions.R6
classes as developer API and regenerate the namespace.README
file.par_sapply
to run tasks in parallel and display a
progress bar if appropriate.stop_backend
to stop a backend instance.start_backend
to create a backend instance based on the
specified specification.configure_bar
for configuring the type and behavior of
the progress bar.set_option
for Helper$set_option
. This function is
available to end-users and can be used to set the value of a specific option.Helper$set_option
is a wrapper around base::getOption
that sets the value
of a specific option if it exists, or throws an error otherwise.DESCRIPTION
file.parabar
logo startup message for interactive R
sessions.ASCII
template in
inst/assets/logo/parabar-logo.txt
.get_option
for Helper$get_option
. This function is
available to end-users and can be used to get the value of a specific option
or its default value.Helper$get_option
is a wrapper around base::getOption
that returns
the value of a specific option if it exists, or the default value set by the
Options
class otherwise.Options
R6
class and set_default_options
function to manage package
options for parabar
. The documented fields of the Options
class represent
the options that can be configured by the user. The set_default_options
function can be used to set the default package options and is automatically
run at package load time. In a nutshell, set_default_options
stores an
instance of Options
in the base::.Options
list under the key parabar
.backend
and context
objects. A backend
represents a set of operations
that can be deployed on a cluster produced by parallel::makeCluster
. The
backend, therefore, interacts with the cluster via specific operations defined
by the Service
interface. The context
represents the specific conditions
in which the backend operations are invoked. A regular context object simply
forwards the call to the corresponding backend method. However, a more complex
context can augment the operation before invoking the backend operation. One
example of a complex context is the ProgressDecorator
class. This class
extends the regular Context
class and decorates the backend sapply
operation to provide progress tracking and display a progress bar.Service
interface, the client can interact with
context objects as if they represents instances of Backend
type. This
release introduces the following contexts:Context
: represents a regular context that wraps backend objects. In other
words, all Service
methods calls implemented by this context are forwarded
to the corresponding methods implemented by the backend object.ProgressDecorator
: represents a progress tracking context. This context
decorates the sapply
method available on the backend instance to log the
progress after each task execution and display a progress bar.ContextFactory
: represents a blueprint for obtaining specific context
instances.Service
: represents an interface that all concrete backends must
implement. It contains the methods (i.e., operations) that can be requested
from a given backend instance. These methods form the main API of parabar
.Backend
: represents an abstract class that implements the Service
interface. It contains fields and methods relevant to all concrete backend
implementations that extend the class.SyncBackend
: represents a concrete implementation for a synchronous
backend. When executing a task in parallel via the sapply
method, the
caller process (i.e., usually the interactive R
session) is blocked until
the task finishes executing.AsyncBackend
: represents a concrete implementation for an asynchronous
backend. After lunching a task in parallel via the sapply
method, the
method returns immediately leaving the caller process (e.g., the interactive
R
session) free. The computation of the task is offloaded to a permanent
background R
session. One can read the state of the task using the public
field (i.e., active binding) task_state
. Furthermore, the results can be
fetched from the background session using the get_output
method, which can
either block the main process to wait for the results, or attempt to fetch
them immediately and throw an error if not successful.Specification
: represents an auxiliary class that encapsulates the logic
for determining the type of cluster to create (i.e., via
parallel::makeCluster
), and the number of nodes (i.e., R
processes) for
the cluster.TaskState
: represents an auxiliary class that encapsulates the logic for
determining the state of a task.BackendFactory
: represents a blueprint for obtaining concrete backend
implementations.Helper
, Warning
, and Exception
R6
classes. These classes contain
static member methods that provide useful utilities, handle warning messages,
and throw informative errors, respectively.UML
diagram for package classes. The classes provided by parabar
can
be split in three categories, namely (1) backend classes responsible for
managing clusters, (2) context classes that decorate backend objects with
additional functionality (e.g., progress tracking), and (3) progress bar
classes providing a common interface for creating and interacting with various
progress bars.Bar
abstraction for working with progress bars in R
. Currently, two
types of of progress bars are supported (i.e., BasicBar
and ModernBar
).
BasicBar
uses as engine the utils::txtProgressBar
, and ModernBar
relies
on the R6
class obtained from progress::progress_bar
. Specific concrete
instances of these bar types can be requested from the BarFactory
.Any scripts or data that you put into this service are public.
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.