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).
format_condition/1 ¶-spec format_condition(t()) -> iolist().
Pretty-print the condition.
percent_complete() ¶-spec percent_complete() -> number().
set_result(_Key, Value) ¶-spec set_result(_Key, Value) -> Value.
has_result(_Key) ¶-spec has_result(_Key) -> boolean().
get_result(_Key) ¶-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.
This function MUST ONLY be called by the plugin that SETS the result. Plugins must wrap return values in a proper API function complete with return type. Raw global variables should be never exposed to the outside, because it would lead to unmaintainable code.
satisfies(Cond) ¶-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.
speculative(Cond) ¶-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. Needless to say, this functionality is an unsound hack meant as a last-resort measure.
Cond token that represents the result.
is_changed(Cond) ¶-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.
precondition(L, ChunkSize) ¶-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.
precondition(L) ¶-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.
stats() ¶-spec stats() -> map().
Get various statistics about the run.