UnicodePlots
github.com
github.com
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!
You can copy and paste it right into the comments or description.
That’s one use case.
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).
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
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.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.
It can both help someone understand the function easier by seeing a plot in the source while also serving as a test.
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!
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.
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.
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)
[1] https://github.com/nschloe/termplotlib [2] https://github.com/dkogan/gnuplotlib [3] http://www.gnuplot.info/
Now it's included by default IIRC
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 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.
https://iterm2.com/documentation-images.html
there is also sixel. https://github.com/saitoha/libsixel