Changelog
Source:NEWS.md
parabar 1.4.0
Added
- Add vignette
foreach.Rmd
to illustrate howparabar
can be used in conjunction with theforeach
package. The implementation for the%dopar%
operator is provided by thedoParabar
package. Theforeach.Rmd
vignette is locally build from theforeach.Rmd.orig
file.
parabar 1.3.0
CRAN release: 2024-12-10
Added
- Update
AsyncBackend
to allow forceful stopping of the cluster. This is controlled by the package optionstop_forceful
, which, when set toTRUE
, permits the backend to stop the cluster even if tasks are running or if tasks have finished but their results have not yet been read into the main session. The stopping logic is now based on the newly added classSessionState
. Closes #59. - Add
SessionState
class to easily check if an asynchronous backend is ready for certain operations. - Add tests for the
SessionState
andTaskState
classes, and other improvements to the existing tests. - Introduce “pseudo-tests” for
SyncBackend
andAsyncBackend
finalizers. These tests don’t perform real assertions but instead verify that finalizers are invoked when backend instances are garbage collected. As of now, there appears to be no reliable way to programmatically capture conditions handled within a finalizer triggered by manualgc()
invocation.
Changed
- Remove
SyncBackend
andAsyncBackend
destructors in favour ofR
finalizers registered viabase::reg.finalizer
. - Rename
Service
toBackendService
for clarity and consistency. While the nameService
makes sense in the context of theparabar
package, it can be confusing when usingparabar
in conjunction with other packages (e.g., in the context of thepowerly
package). The new nameBackendService
is hopefully more descriptive and less likely to clash with other packages. - Update
comparison.Rmd
vignette to refresh the comparison betweenparabar
andpbapply
packages. - Update design diagram and improved its readability and the client code examples.
- Refactor
task_is_running
test helper to accept more context types. - Update
Specification
to allow backends with a single core. Closes #71.
Fixed
- Fix error triggered by the invocation of the backend destructors (i.e., see issue #61). Clean-up of resources is now handled via the
base::reg.finalizer
mechanism, with finalizers being automatically registered when a backend is created. This ensures that the cluster is stopped and resources are released even if the user forgets to callstop_backend
explicitly. Closes #61. - Fix the
sink
redirect to use the correct destination onWindows
(i.e.,nul
instead of/dev/null
). Closes #74.
parabar 1.1.1
CRAN release: 2024-02-05
Added
- Add tests for progress tracking context when executed tasks throw an error. In relation to #44.
parabar 1.1.0
CRAN release: 2023-05-07
Added
- Update implementations of
Service$apply
operation forBackend
classes to validate the providedmargin
argument before running the parallel operation. - Add helper
Helper$check_array_margins
to validate the margins provided to theService$apply
operation. - Add exception
Exception$array_margins_not_compatible
for using improper margins in theService$apply
operation. - Add exception
Exception$primitive_as_task_not_allowed
for trying to decorate primitive functions with progress tracking in theProgressTrackingContext
class. - Add helper
Helper$is_of_class
to check if an object is of a given class. - Add optional arguments to the
get_output
operation ofSyncBackend
for consistency. - Add more tests to improve coverage.
- Add implementation for
Service$lapply
andService$apply
operations for all classes that implement theService
interface. - Add
par_lapply
andpar_apply
functions to the userAPI
. These functions can be used to run tasks in parallel akin toparallel::parLapply
andparallel::parApply
, respectively. - Add
UserApiConsumer
R6
class that provides an opinionated wrapper around the developerAPI
of theparabar
package. All parallel operations (e.g.,par_sapply
andpar_lapply
) follow more or less the same pattern. TheUserApiConsumer
encapsulates this pattern and makes it easier to extendparabar
with new parallel functions (e.g.,par_apply
) while avoiding code duplication. TheUserApiConsumer
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 userAPI
.
Changed
- Force early evaluation for the
x
argument of task execution functions inProgressTrackingContext
class. - Update the log file for progress tracking to include
parabar
in file name. - Disable warnings for
file.create
inProgressTrackingContext
class. This warning is superfluous since the code handles creation failures. - Refactor test helpers to avoid code duplication.
- Update
par_sapply
to use theUserApiConsumer
class. - Update the developer
API
R6
classes to implement thelapply
parallel operation.
Fixed
- Ensure task execution errors are propagated to the main session in
AsyncBackend
. Closes #35. - Fixed the rendering of
CC BY 4.0
license icons inREADME.md
for the package website. - Update
.decorate
method ofProgressTrackingContext
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. - Fix the
export
operation in theSyncBackend
andContext
classes to fallback to the parent environment if the argumentenvironment
is not provided.
parabar 1.0.0
Added
- Add
CC BY 4.0
license for package documentation, vignettes, and website content. - Add code coverage
GitHub
workflow viacodecov
and badge inREADME
. - Add tests for end-user API and developer API.
- Add vignette
comparison.Rmd
to compareparabar
to thepbapply
package, and provide rough benchmarks. Thecomparison.Rmd
vignette is locally build from thecomparison.Rmd.orig
file (i.e., see this resource for more information). - Add active biding
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.
Changed
- Refactor
Specification
for testing purposes. - Replace
\dontrun{}
statements in examples withtry()
calls. - Update example for
Options
class to feature theprogress_log_path
active binding. - Update progress logging injection approach in
.decorate
method ofProgressTrackingContext
to usebquote
instead ofsubstitute
. -
Breaking. Rename class
ProgressDecorator
toProgressTrackingContext
to be more consistent with the idea of backends that run in contexts. - Add
...
optional arguments to signature ofget_output
method inService
interface. - Update private method
.make_log
ofProgressDecorator
to use theprogress_log_path
option. - Update
UML
diagram to include missing classes and changed methods. Also updated the corresponding diagram figure in the package documentation.
parabar 0.10.1
CRAN release: 2023-02-28
parabar 0.10.0
Added
- Add new exported wrappers to the
pkgdown
reference section. - Add several exported wrappers to the user API:
-
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.
-
- Add type checks for the exported functions (i.e., the user API).
- Add helper method for checking and validating the type of an object. The
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
).
Changed
- Add
.scss
styles to override the table column width for the exported wrappers table in thepkgdown
website. - Update
README
and package documentation to mention new exported wrappers. - Update order of topics for website reference section generated via
pkgdown
. - Update
roxygen2
@examples
for exported wrappers. The code for the examples is located in the documentation for thestart_backend
function. All other exported wrappers (i.e.,clear
,export
,peek
,evaluate
, andpar_sapply
) inherit the@examples
section fromstart_backend
. - Update references in
@seealso
documentation sections. - Change
backend
argument ofpar_sapply
tobackend = NULL
. This implies, thatpar_sapply
without a backend behaves identically tobase::sapply
.
parabar 0.9.4
Added
- Add custom styles to
extra.scss
to improve documentation website. - Add
S3
print method for theLOGO
object.
Changed
- Improve documentation for exported objects.
- Merge documentations of
get_option
,set_option
, andset_default_options
. - Improved
README
. More specifically, added description forService
interface methods and enabled documentation linking (i.e., via?
) forpkgdown
website.
Fixed
- Add missing export for
Options
class. - Ensure the examples in
ProgressBar
usewait = TRUE
when fetching the output. - Fix bug in the
evaluate
backend operation. The expression passed toevaluate
was not correctly passed down the function chain toparallel::clusterCall
. See this question onStackOverflow
for clarifications. Closes #9.
parabar 0.9.3
Changed
- Change type of private field
.bar_config
inProgressDecorator
class tolist
. This way, theconfigure_bar()
method ofProgressBar
class becomes an optional step.
Fixed
- Implement file locking when logging progress from child processes to avoid race conditions. The implementation is based on the
filelock
package. Closes #8. - Fix typo in
DESCRIPTION
.
parabar 0.9.2
Fixed
- Update
man-roxygen/parabar.R
\html{...}
to fixHTML
validation errors. Closes #6. - Fix package description in
DESCRIPTION
file to comply withCRAN
requirements.
parabar 0.9.0
Added
- Add package website via
pkgdown
andGitHub
pages. - Add
GitHub
workflow to automatically check the package on several platforms andR
versions. - Export all
R6
classes as developer API and regenerate the namespace. - Add preliminary package documentation to
README
file. - Add exported wrapper
par_sapply
to run tasks in parallel and display a progress bar if appropriate. - Add exported wrapper
stop_backend
to stop a backend instance. - Add exported wrapper
start_backend
to create a backend instance based on the specified specification. - Add exported wrapper
configure_bar
for configuring the type and behavior of the progress bar. - Add exported wrapper
set_option
forHelper$set_option
. This function is available to end-users and can be used to set the value of a specific option. - Add helper method for setting package options. The static method
Helper$set_option
is a wrapper aroundbase::getOption
that sets the value of a specific option if it exists, or throws an error otherwise. - Add package object documentation and relevant information in
DESCRIPTION
file. - Add
parabar
logo startup message for interactiveR
sessions. - Add function to generate package logo based on the
ASCII
template ininst/assets/logo/parabar-logo.txt
. - Add exported wrapper
get_option
forHelper$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. - Add helper method for getting package options or their defaults. The static method
Helper$get_option
is a wrapper aroundbase::getOption
that returns the value of a specific option if it exists, or the default value set by theOptions
class otherwise. - Add
Options
R6
class andset_default_options
function to manage package options forparabar
. The documented fields of theOptions
class represent the options that can be configured by the user. Theset_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 ofOptions
in thebase::.Options
list under the keyparabar
. - Implement initial software design. For a helicopter view, the design consists of
backend
andcontext
objects. Abackend
represents a set of operations that can be deployed on a cluster produced byparallel::makeCluster
. The backend, therefore, interacts with the cluster via specific operations defined by theService
interface. Thecontext
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 theProgressDecorator
class. This class extends the regularContext
class and decorates the backendsapply
operation to provide progress tracking and display a progress bar. - Add context classes to consume and decorate backend APIs. Since the context classes implement the
Service
interface, the client can interact with context objects as if they represents instances ofBackend
type. This release introduces the following contexts:-
Context
: represents a regular context that wraps backend objects. In other words, allService
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 thesapply
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.
-
- Add classes to work with synchronous and asynchronous backends:
-
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 ofparabar
. -
Backend
: represents an abstract class that implements theService
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 thesapply
method, the caller process (i.e., usually the interactiveR
session) is blocked until the task finishes executing. -
AsyncBackend
: represents a concrete implementation for an asynchronous backend. After lunching a task in parallel via thesapply
method, the method returns immediately leaving the caller process (e.g., the interactiveR
session) free. The computation of the task is offloaded to a permanent backgroundR
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 theget_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., viaparallel::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.
-
- Add
Helper
,Warning
, andException
R6
classes. These classes contain static member methods that provide useful utilities, handle warning messages, and throw informative errors, respectively. - Add
UML
diagram for package classes. The classes provided byparabar
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.
parabar 0.1.0
Added
- Add
Bar
abstraction for working with progress bars inR
. Currently, two types of of progress bars are supported (i.e.,BasicBar
andModernBar
).BasicBar
uses as engine theutils::txtProgressBar
, andModernBar
relies on theR6
class obtained fromprogress::progress_bar
. Specific concrete instances of these bar types can be requested from theBarFactory
.