Refinement of the application

[MuratovAS]

good day I started using and improving this application. I plan to keep the ideology of a minimalistic solution. My todo:

• [x] Added support for icarus vvp
• [x] Fixed bug with display UZX on binary lines
• [x] Fixed display 0 status on binary lines
• [x] Added timeline
• [ ] TUI

Are you planning to develop a project? Will you be happy with "Pull requests"? Maybe I should develop it myself?

Here you can see how the work is going: https://github.com/MuratovAS/vcd

[yne]

I'll be happy with a PR :)

TUI is somewhat out of scope, see: https://github.com/yne/vcd/issues/2#issuecomment-893182942

[MuratovAS]

I beg your pardon. I misinterpreted your message for the first time. Specifically the abbreviation (PR). I think it's worth discussing some nuances. :)

[MuratovAS]

I think TUI is essential. I want to implement functions for convenient work with the chart. An important point. I believe that TUI is an additional function, the program will retain your original capabilities. You can even consider disabling the TUI feature when compiling. In particular:

• Ability to move horizontally and vertically between charts (scrolling)
• Ability to scale the graph (stretch / shrink)
• Most important. Ability to re-read the file without losing the viewing position.
• Color-coded signals (so far questionable)
• It would be cool to provide a function for folding and unrolling data buses.

I want to hear your opinion on this issue.

P.S. I did this work because I want to build a TUI IDE for "lattice".

[yne]

I'd prefere to keep vcd focused on parsing, and use a more parsable output (TOML, JSON, YAML, SVG...) so it graphs could be piped into on of the many existing TUI wrapper.

[MuratovAS]

I reflect on ideas, tui in a separate application. Really the source code of the program has grown, and reached 12kb. Now it looks like this:

[yne]

can -w be used as zoom for you ?

[MuratovAS]

Certainly, the argument -w can be used to stretch the graphics. Much more interests the procedure for compressing the graphics. Which will allow the number of samples on the work field exceeding the number of characters in the string.

I interpreted the argument -w as the value characterizing the maximum width of one sample

[yne]

In addition to output a parsable-friendly format (probably JSON), I thinking about moving to a user-defined waveform (using environement variable ?).

This shall greatly lower the code complexity.

[MuratovAS]

As far as I understand, do you want to turn the application into the format converter? Suppose to analyze JSON to visualize hard work than VCD. Why then need it?
"User-Defined Waveform" is a third-party GUI?

It is important for me to be visualization in the terminal. The application must be independent, written on RUST, C LANG.

[yne]

the ASCII output will stay the default, but the JSON output could be enabled (with --json ?) so users can use TUI wrapper to browse/cut/extract the waveform (vcd | grep -V).

"User-Defined Waveform" is a third-party GUI?

Default: vcd --low=▁ --high=▔ --raise=╱ --drown=╲ < basic.vcd (same as vcd < basic.vcd)

Custom: vcd --low=▁ --high=▇ --raise= --drown= < basic.vcd (full block + no transition)

Also, I'll document a way to refresh the display without losing position (you need 2 terminals) :

1. a "viewer" terminal with tmux+vim opened on an existing vcd "out.txt" file:

tmux new-session -s vcd
# then, inside the tmux session, run:
vim -c ":set nowrap" out.txt

2. a "watcher" terminal that update "out.txt" when the "in.vcd" file change, then send a refresh command to the "viewer" terminal.

while inotifywait -q -e MODIFY in.vcd ; do
  vcd < in.vcd > out.txt
  tmux send-keys -t vcd ':edit' Enter
done

[yne]

@MuratovAS I pushed on master the last version with some "advanced" use case in README.md (including TUI integration)

Edit: I just noticed that the new pipeline generate a huge executable for windows 383KB vs 7.5KB when I compile with TCC

[MuratovAS]

Played with the parameters of the build system for Windows. It turned out that the compilation process passes correctly, everything is in order in ASM. The file size increases when converting ASM -> EXE. Mingw adds something to the final file. The most adequate solution is likely to use the image of a Windows provided by GitHub. For Linux, still use Docker.

[yne]

@MuratovAS I think this mingw issue shall be fixed in a new ticket... later :)

About vcd functionalities, do you think it's okay now ?

[MuratovAS]

In the previous version there were problems with the SKIP parameter, it skipped the graph, but not the timeline.

I liked your new VCD implementation. I appreciate your hard work and your willingness to stick to the "unix way". But, my task with TUI is not fully realizable in the form of a filter, it is simply not rational. For my needs, I made a fork, based on the old version of VCD.

I am thinking about applying your new version.

[yne]

SKIP parameter, it skipped the graph, but not the timeline.

You are right, the timeline shall start counting at the SKIP sample => fixed in 5fecd71

There are two way of shifting the graph :

• Using SKIP : will shift the graph but keep the labels on the left
• Using less -S : Allow to horizontally scroll but won't keep the label on left when scrolling