Wow. That's crazy.

Genuine question: is this actually useful in real life, or just a cool "because I could" project?

Not being a Julia programmer I'd assume that producing charts in a REPL would be done in a Jupyter notebook with real pixels, not Unicode.

Is producing elaborate charts in a terminal something people actually need?

Edit: some fantastic responses. Makes perfect sense. Thank you!

Yes, it's useful when you're ssh'd into some production system somewhere and just want to get a quick sense of some data in memory instead of going through the steps of installing a full graphics stack (which fortunately is pretty much a one-liner in Julia also, but can take a few mins).

Yeah, I find it super useful when you want a maximally quick look at the shape of your data. Even if I'm local (ie not SSH'd onto a remote system where displaying graphics could be a hassle), using UnicodePlots can "break my flow" less than generating prettier plots in another window.

It is useful for people who don't realize xterm(1) supports Sixel graphics. :-)

It still blows people away when I set my GNUTERM var to 'sixelgd font "Arial,8" size 800, 600'

In xterm, you can use bash to type these two lines:

   $ export GNUTERM='sixelgd font "Arial, 8" size 800, 600'
   $ gnuplot -e 'plot sin(x)'

And poof! a plot will appear.

It's useful for people who work with data, like in ml, data science, etc.

Or for sysadmin or anything where a quick plot at the data gives you hints at what's happening.

In the example screenshot I put on https://raw.githubusercontent.com/csdvrx/sixel-gnuplot/maste..., I was investigating time sync issues.

A plot immediately told me my first fix had corrected the issue on 2 servers, but I had mistakenly applied the same change to a 3rd one.

I added comparative histograms (normalized to the same axis) for derailed benchmarks so that when I send a perf PR they get the distribution data in an accessible format.

You can copy and paste it right into the comments or description.

That’s one use case.

You can normally add images to PRs though?

Turning the same data into an image provides no additional info and requires extra steps. The key requirement here for my feature is copy and paste from the terminal.

Best example I can think of is cases where you can’t really put an image, eg commit messages (especially if you don’t have something like pull requests where you can put images).

Some terminal emulators have support for images, which fit most of the use cases here but not the one I described.

I would hope that most people would generate charts with a notebook (jupyter, pluto, orgmode can all have actual images though when I briefly used pluto, I was going mad trying to (a) not get an svg which would suck for a lot of points and (b) get bigger plots in the notebook) or that at the repl you would get something like R and have an X window with the plot rendered to it (tip: dbcairo makes plots over X forwarding much better).

> Some terminal emulators have support for images, which fit most of the use cases here but not the one I described.

That what sixel-tmux is for, when you're in a hurry and needs images with your current terminal emulator: https://github.com/csdvrx/sixel-tmux

I used it for a cli script that reads a log file and creates a histogram of the IPs. Pretty good if you don't want to save an image every couple of minutes. It's just text.

Another possible use case is for inline expect tests.

It can both help someone understand the function easier by seeing a plot in the source while also serving as a test.

Very nice, this can be used to build a cool motd :)

Not about this project specifically, but there seems to be a general trend towards TUIs. As someone currently working on a native GTK+ app, the state of native deskop UIs is horrible. GTK+ with all the depreciations? Painful. Win32? Oh god. UWP? Please, no. UIKit or Swift? Desktop software is no longer important enough to support multiple platforms natively...

I feel like we are headed towards a split between Electron for end user applications and TUI for portable tools. They even run on servers and modern terminals on any platform can "render" the UI!

> I feel like we are headed towards a split between Electron for end user applications and TUI for portable tools

Another common hack is for a tool to serve a web UI on localhost, like Jupyter or Datasette. If you need to run the tool on a firewalled server, you can use SSH port forwarding to access the web UI.

So, VT220 (with some extensions like Unicode) is again going to become the common ground of somehow rich interfaces?

In fact, this is happening. My filesystem UI is Midnight Commander for a long time, but my k8s UI is k9s, and it's new, and works equally effortlessly on a Mac and on a Linux box.

> Win32? Oh god.

Uh, no?

Win32: Simple to write, and works anywhere, thanks to wine.

> Desktop software is no longer important enough to support multiple platforms natively

Win32 is the closest we have to native multiplatform support with a single binary

> TUI for portable tools

If you use cosmopolitan, yes it can be even better: one binary working everywhere, with no need for emulators.

I think wine compiled with cosmopolitan is the future: - if running on windows, don't use wine - on linux or macos, use wine

> They even run on servers and modern terminals on any platform can "render" the UI!

There are X servers rendering in sixel format, so the above could be completed by adding a this X server to render within a sixel-aware terminal (say for when X will be deprecated)

Is there such a tool for use with python? preferably matplotlib compatible. I often find myself needing to plot some data to get a quick idea of what it looks like, and my work is generally on a remote host. Having to open a new ssh session with X forwarding is not difficult but a more frictionless approach would be nice.

If you happen to use `iTerm2`, then https://github.com/daleroberts/itermplot works very well. I've used it before and can recommend it pretty highly.

Is iTerm2 GPU accelerated? Wasn't aware it could do that kind of thing. I didn't use it in years, admittedly, haven't had a Mac for a while.

You don't really need GPU acceleration for 2d graphics (and neither for simple 3D). The CPU is more than enough for that.

I understand, but without some kind of direct rendering going on, I can't see how this would work on a terminal emulator.

> without some kind of direct rendering going on, I can't see how this would work on a terminal emulator.

Nah.

You just dump the pixels one by one to the screen using a for loop. You can even do some cpu math with each pixel if you want, and at the end you call XPutImage with the raster (or whatever your toolkit offers). This runs at more than 30fps in fullhd on a 10 year old cpu.

Notice that xterm is blazingly fast and runs entirely on the cpu. Think about it, the plots that this iterm2 demo shows were already done in realtime in the late nineties using the first pentium cpus.

The GPU is not really needed for the basic stuff a terminal emulator does. Of course, if you want to do crazy stuff like scaling by enormous factors, or ultra-fast scroll without skipping tricks, you'll need GPU support.

I see. I'm not nearly qualified enough to talk about that, admittedly. Drawing the pixels isn't the problem, it's updating them fast enough, then?

I guess there is no problem? You only need the gpu to compute fancy 3d graphics in high resolution. For normal terminal stuff and low resolution plots, anything should work.

iTerm2 is GPU accelerated since 2018, yes. Other terminals on Mac that I know of (Kitty, Alacritty, Warp) are also GPU accelerated.

If you use euporie [1], you can draw plots in a Jupyter notebook in the terminal using matotlib and friends, and have them displayed using terminal graphics.

[1] https://github.com/joouha/euporie

Yup for years. https://github.com/jktr/matplotlib-backend-kitty

There are [1, 2], and AFAICT they rely on gnuplot [3].

[1] https://github.com/nschloe/termplotlib [2] https://github.com/dkogan/gnuplotlib [3] http://www.gnuplot.info/

The last time I used gnuplot was around 25 years ago. And it is still around!

A few years ago, you had to recompile it to add sixel support on debian, so I provided https://github.com/csdvrx/sixel-gnuplot

Now it's included by default IIRC

Have a look at Uniplot - https://github.com/olavolav/uniplot

Could this be adapted to be a backend for graphviz?

I use org mode for notes, and sometimes want to draw graphs or diagrams using graphviz. With something like this, you could integrate graphviz source blocks with org-babel and evaluate the blocks to get nice textual output in your org file.

There’s absolutely a place in the world for sparkline plots in TUIs and I need to get back to looking at things like that soon.

Nice to see a non-trivial package with 100% code coverage, can't remember the last time I saw that.

Really neat! Every time I see this I'm reminded of what we lost from the 1990s, when xterm supported Tektronix 4014 emulation. Vector graphics right there via a tty interface! It wasn't terribly useful in practice but it could do some nice things with plotting.

iterm2/wezterm/etc will display images.

https://iterm2.com/documentation-images.html

there is also sixel. https://github.com/saitoha/libsixel

Rubyists may be interested in https://github.com/red-data-tools/unicode_plot.rb which is mostly a port of this package.