feedgnuplot VS vnlog

Thanks for the post. The obvious comparison is feedgnuplot: https://github.com/dkogan/feedgnuplot/

That works similarly in that it plots standard input. The backend is gnuplot, which is a double-edged sword: it's far more full-featured than brplot, but almost certainly is much slower also. I'll try out brplot to see if it would be a good replacement for cases where speed is important. Thanks!

Oh hey Dima.

Feedgnuplot is really slick.

https://github.com/dkogan/feedgnuplot

It's in the debian repos too.

Is there a declarative language or framework to create ad-hoc GUIs that consume structured data from stdin stream and spit-out a GUI?

Like feedgnuplot [1] but not only restricted to graphs.

[1] https://github.com/dkogan/feedgnuplot

I found using shell as an interactive environment to be pretty productive using https://github.com/dkogan/feedgnuplot and https://github.com/dkogan/vnlog. The filesystem becomes your state (instead of in memory state of your Python interpreter) which forces you to write Unix-style tools. Plotting with feedgnuplot spins up an interactive Qt plotter which I often used to explore 3D plots. It's not "inline" and fancy and does take a bit of grokking but I eventually found it more productive than Jupyter, especially as my development moved away from Python.

One of the tools I absolutely love is feedgnuplot which presents a stdin CLI interface to gnuplot.

Also, if one doesn't want to learn Gnuplot's DSL try using feedgnuplot which presents a stdin interface for whitespace delimited tabular data.

Write space delimited tabular data (ideally in vnlog format) and plot it using feedgnuplot. Also helps decouple concerns (data generating application focuses on generating data).

For simple analyses (i.e. what most people do most of the time) doing this on the commandline gets you there faster. I use vnlog (https://github.com/dkogan/vnlog/). By the time you fired up your editor to write your Python code, I already have analyses and plots ready.

Alternative very appropriate for some uses cases: `vnl-join` from the vnlog toolkit (https://github.com/dkogan/vnlog). Uses the `join` tool from coreutils (works well, has been around forever), and `vnlog` for nice column labelling

There's also https://github.com/dkogan/vnlog/ which is a wrapper around the existing coreutils, so all the options work, and there's nothing to learn

And to improve the ergonomics, the vnlog wrappers are available to operate on field names, while retaining the internals of the core tools:

  https://github.com/dkogan/vnlog/

I sorta, kinda agree. Tools written in AWK (and friends) are indeed somewhat unmaintainable, but they're really close to being just right for a LOT of applications. The vnlog toolkit (https://github.com/dkogan/vnlog) adds just a little bit of syntactic sugar to the usual commandline tools to make processing scripts robust and easy to read and write. This was not my intent initially, but I now do most of my data processing with the shell and vnl-wrapped awk (and sort and join, ...) It's really nice. If you write stuff in awk, you should check it out. (Disclaimer: I'm the author)