Hi!

I've been playing around with this little app, and I think it's a pretty solid waveform viewer and editor. I do have some questions relating to the search expressions, though. Particularly, it would be nice to document the syntax (or link to external documentation, if this is an implementation of a common syntax that I'm just unaware of?)

The second question is about the implementation details... One of the things I love about Rust is the level of control it gives. And I can't help but notice that the expression grammar is very small, but the parser infrastructure is disproportionately heavy. The build time is really hurt (IMHO) by including all of lalrpop for what looks like a very simple expression AST.

There are also a couple of annoying issues with lalrpop; the visibility modifier issue linked in #2, for example. And 70-or-so warnings emitted by cargo clippy are directly related to the code generated by lalrpop. Would you be opposed to replacing the parser with something like nom? This is a very light weight parser generator crate with only a single required dependency. nom does have some problems of its own, but I don't think it will be any trouble with this simplistic expression grammar.

If you would like, I could contribute a new parser. But I'm still interested in the expression syntax docs, and it would really help when working on such a rewrite!

this error happens when trying to view vcd file generated by verilator and icarus verilog

stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:78
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:59
4: core::fmt::write
at src/libcore/fmt/mod.rs:1069
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1504
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:62
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:49
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:198
9: std::panicking::default_hook
at src/libstd/panicking.rs:218
10: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:511
11: rust_begin_unwind
at src/libstd/panicking.rs:419
12: core::panicking::panic_fmt
at src/libcore/panicking.rs:111
13: core::panicking::panic
at src/libcore/panicking.rs:54
14: dwfv::vcd::lexer::Lexer::pop
15: dwfv::vcd::parser::Parser::parse
16: dwfv::signaldb::db::SignalDB::parse_vcd_with_limit

I was trying to open the attached VCD file but the following error message:

⇒  dwfv out.vcd
thread '<unnamed>' panicked at 'Specified path is a signal, not a scope', /<redacted>/dwfv-0.4.0/src/signaldb/scope.rs:49:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The VCD file is generated by Verilator 4.038.

Tool version: 0.4.0
out.vcd.txt

I really like this project, thank you for creating it!

I would like to package this for NixOS, but nix requires reproducible builds, and as part of that a Cargo.lock file is needed. Typically this file is included for binaries, but not for libraries (source: Cargo FAQ).

I know that not everyone likes committing a Cargo.lock file; would you be willing to commit the Cargo.lock file to make this easier to package?

First off, congratulations for this tool. I find it very useful for it to be a terminal application, and the Rust tooling is nice.

I'd like to discuss a couple of features related to fixed-point signals:

Analog visualization

In GtkWave, multi-bit signals can be viewed as binary, unsigned integer, signed integer, hex, etc. but also as "analog" plots. When multi-bit signals represent fixed-point values, it is possible to set the number of fractional bits, so the value is shown as a float/real. A few months ago, I opened gtkwave/gtkwave#9 to discuss some specific details about the feature.

I saw that tui-rs allows plotting XY charts (demo). Would it be feasible to add this feature to dwfv? Is there any plan to do so?

Stats or frequency table

As explained in dbhi/fpconv, I'd like to extract some specific statistics from waveforms. Precisely, for a given set of signals in a synchronous design, I'd like to record all the different values that each signal is assigned, and how many times does each signal hold each value. I prototyped it using a Python script (fpconv.py).

Since dwfv seems to expose a backend API for manipulation of signals, I wonder whether this feature might be added as an argument/subcommand (arguments seem to be subcommands).