Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #1555 .
Changelog
Add new
ValueInner::Numbersvariant for collections of values. Supports two formatting modes:EngFormatter: (default) just renders the last value of the set like a regularValue::Number.BarFormatter: if vertical, renders a barchart with the lastwidthvalues from the set; if horizontal, renders the last value as a "meter" bar.Refactor
EngFormatterandBarFormatterto implement formatting of newValue::Numbersvariant. Add unit tests with examples forBarFormatter.Refactor
cpuandnetblocks to use the newBarFormatterfunctionality.Open questions
widthormax_valueof the bar charts. This has to be manually be set in the user'sconfig.tomlfile.1.1.
max_value: can be automatically detected in the BarFormatter on the fly, while rendering the barchart. But then, the manualmax_valueuser formatting argument has to be made optional in some cases. When?1.2.
width: should be exposed somehow to the blocks by the formatter, and vice-versa? In case of thenetblock, we should only accumulate as much data as we would render. In case of thecpublock, it has to be enforced the other way around: number of cores from the block to the formatter.1.3. the examples and solutions proposed above would create some confusion both code-wise (block-logic and formatting logic are now aware of each-other and coupled) and usage-wise (the user's formatting arguments in their config file should be followed or ignored in some cases).
@MaxVerevkin , @bim9262 , thoughts on the current implementation and the open questions?