anvl_condition ¶This module contains functions responsible for ANVL’s core functionality.
At the heart of anvl lies a very simple memoization library.
Build system = memoization. More specifically,
build_target(Target) ->
memoize(
changed(Target) andalso
begin
rebuild(Target),
true
end).
-spec format_condition(t()) -> iolist().
Pretty-print a condition.
-spec n_complete() -> non_neg_integer() | undefined.
Get the number of conditions that completed with any result.
-spec n_waiting() -> non_neg_integer().
Get the number of conditions waiting for preconditions.
-spec n_running() -> non_neg_integer().
Get the number of conditions that are currently running.
-spec set_result(_Key, Value) -> Value.
-spec has_result(_Key) -> boolean().
-spec maybe_get_result(_Key) -> {value, _Value} | false.
Non-throwing version of anvl_condition:get_result/1.
-spec get_result(_Key) -> _Value.
ANVL condition’s return value is a boolean that specifies presense of side-effects.
If it needs to return any other data,
get_result/1 and (set_result/2) functions can be used.
These functions, essentially, allow to set and access global variables.
Note on the code style:
this function must be called only by the same plugin that sets the result.
Plugins must wrap get_result function in a proper API complete with return type.
Raw global variables should be never exposed to the outside,
because it leads to unmaintainable code.
See anvl_condition:maybe_get_result/1
See anvl_condition:has_result/1.
-spec satisfies(speculative()) -> ok.
This function declares that the current condition resolves a speculative condition.
It’s a counterpart to speculative/1.
Once a condition that called satisfies(X) is resolved
(with any result, including failure),
speculative condition X is resolved with the same result.
It’s recommended to call this function at the very beginning of the condition: in case of failure, this will automatically mark speculative condition as failed and notify condition dependent on it.
-spec speculative(speculative()) -> t().
Sometimes a condition doesn’t know the recipe to resolve a precondition, but it assumes that it will be resolved eventually somehow. For example, a module in appliction X can use a parse transform declared in another application, but it don’t know which one. We call this situation speculative precondition.
This function is a built-in condition that serves as a placeholder in such situations. While ANVL can detect unresolved speculative preconditions, it’s better to make all dependencies explicit. Therefore, this functionality should be used as the last resort.
Cond token that represents the result.
-spec is_changed(t()) -> boolean() | undefined.
For a satisfied condition, this function returns whether the condition has
made changes to the system. Otherwise it returns undefined.
-spec precondition([t()],
pos_integer() | infinity) -> boolean().
Equivalent to precondition(L),
but takes an additional parameter ChunkSize that sets the maximum number of parallel tasks
spawned to satisfy the conditions in L.
Note: any sub-tasks spawned by the preconditions themselves are not accounted for.
-spec precondition(L :: [t()] | t()) -> boolean().
Block execution of the function until all preconditions in L are satisfied. Throws an exception if any precondition could not be satisified.
Returns whether any changes were made to the system to satify the preconditions.
-spec stats() -> map().
Get various statistics about the run.