Hi,

I noticed that ticks on the y axis aren't really placed accurately, as a result of the interface with tui::widgets::Chart and having a fixed number of ticks, as demonstrated here:

I have started to work on a fix for this, in fact I think I'm almost done, but this is my first time working with Rust and I have a problem which I think is quicker to solve if I just ask you:

My problem

Between the calls to y_axis_bounds() and y_axis_labels(), I need to store the number of y axis ticks, which is now dynamically calculated in y_axis_bounds(). More specifically, I need to store an int in y_axis_bounds() and read it from y_axis_labels(). Where should I store this value?

I thought adding a member to the struct DataStore would be the obivous way to do this but that just leads me down a path of mutability issues, which would probably take me hours to solve since I don't really have an overview of the whole codebase. I imagine you know where to store the value right away, so if that is the case, I'd be grateful for a quick pointer.

Thanks!

First of all: this is amazing!

It would be nice to be able to use a different color for graphing, and to specify a maximum width for the graph.

Thanks for this gem!

I think this is just my lack of sophistication, but I'm trying to graph a number that is extracted from a text block and it's not working. For example, this produces a float:

./smag "ping -c 1 -R 8.8.8.8 | grep time= | awk '{print $7}' | cut -c 6-"
and this produces an integer:
./smag "ping -c 1 -R 8.8.8.8 | grep time= | awk '{print $7}' | cut -c 6-7"
but neither produces a graph.
Yes, I realize this reproduces gping :), but a lot of commands produce a block of text with embedded numbers. Thanks for your help!

Something about the v0.5.3 release does not like building with --locked, but the tip of main is fine w/ it. I'm trying to create an AUR package for Arch Linux and they like that option for reproducible builds. I'm not very familiar w/ rust building or rust packaging, so I'm just kind of messing around.

0 ✓ fryfrog@apollo ~/git/smag $[main] git checkout tags/v0.5.3 -b v0.5.3
Switched to a new branch 'v0.5.3'
0 ✓ fryfrog@apollo ~/git/smag $[v0.5.3] cargo build --release --locked --all-features --target-dir=target
error: the lock file /home/fryfrog/git/smag/Cargo.lock needs to be updated but --locked was passed to prevent this
If you want to try to generate the lock file without accessing the network, use the --offline flag.

101 ✗ fryfrog@apollo ~/git/smag $[v0.5.3] git checkout main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
0 ✓ fryfrog@apollo ~/git/smag $[main] cargo build --release --locked --all-features --target-dir=target
   Compiling libc v0.2.80
   Compiling proc-macro2 v1.0.24
   Compiling version_check v0.9.2
   Compiling cfg-if v0.1.10
   Compiling unicode-xid v0.2.1
   Compiling log v0.4.11
   Compiling bitflags v1.2.1

E.g., smag --y-label=MB ...

My motivation for this suggestion comes from plotting the total number of transferred bytes during a Time Machine backup. My command is

smag "tmutil status | awk '/bytes =/ {print \$3/1000000}' | sed 's/;//g'"

which outputs the total number of transferred bytes in MB. However, sometimes when I use this command I change it to GB, especially if I'm doing a fresh backup to a new drive. For incremental backups MB is fine, but for fresh ones GB gives a better picture of the progress.

as per the title

At time of writing, this d1d7b62 is tagged as v0.7.0. However, the corresponding Cargo.toml has version = "0.6.0" in it.

As I understand it, the "last" indicator in the top left is supposed to show the most recent value. However, at the moment, it shows the oldest value still in the buffer:

If this is in fact unintended behaviour, I can try my hand at a fix.

I want to package smag for nix but the last tagged release is four years old. Can you please bump the version number and create a new tag for it?

Maybe something along the lines of optional flags such as smag --y-min=0 --y-max=12 ...?

A motivational example is graphing load average. A user might want to see the graph plotted in the context of the CPU's full capability, e.g. seeing the graph plotted in the range 0...12 (for 6-core hyperthreaded processor) instead of smag automatically shrinking the y-range from 1.25 to 2.00.

On the latest code (25091d3 at time of writing), smag builds successfully on cargo/rustc 1.72.0, but fails on cargo/rustc 1.74.0

Working:

$ cargo --version
cargo 1.72.0
$ cargo build
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s

Broken:

$ cargo --version
cargo 1.74.0
$ cargo build
   Compiling smag v0.6.0 (/home/jeremy/src/github.com/aantn/smag)
error[E0283]: type annotations needed
  --> src/ui.rs:19:18
   |
19 |                 .constraints(
   |                  ^^^^^^^^^^^ cannot infer type of the type parameter `C` declared on the method `constraints`
...
24 |                         .as_ref(),
   |                          ------ type must be known at this point
   |
   = note: multiple `impl`s satisfying `Vec<Constraint>: AsRef<_>` found in the `alloc` crate:
           - impl<T, A> AsRef<Vec<T, A>> for Vec<T, A>
             where A: Allocator;
           - impl<T, A> AsRef<[T]> for Vec<T, A>
             where A: Allocator;
help: consider specifying the generic argument
   |
19 |                 .constraints::<&T>(
   |                             ++++++

For more information about this error, try `rustc --explain E0283`.
error: could not compile `smag` (bin "smag") due to previous error