sgreben / jp Goto Github PK

View Code? Open in Web Editor NEW

1.3K 19.0 32.0 1.62 MB

dead simple terminal plots from JSON data. single binary, no dependencies. linux, osx, windows.

License: MIT License

Makefile 5.74% Go 94.26%

terminal json plot charts bar-chart line-chart jsonpath

jp's People

Contributors

Stargazers

Watchers

jp's Issues

Histogram legend is missing the first interval

Example:

seq 1000 1000000 | jp -input csv  -x '[*]' -type hist -bins 15

When my terminal is wide enough then the 15 intervals are correctly included below each bar.

But when the terminal to small for inline display, the then displayed legend just includes 14 intervals, i.e. the interval for the zeroth bar is missing.

That means the legend looks like this:

1  [67600,134200) 
2  [134200,200800)
3  [200800,267400)
4  [267400,334000)
5  [334000,400600)
6  [400600,467200)
7  [467200,533800)
8  [533800,600400)
9  [600400,667000)
10 [667000,733600)
11 [733600,800200)
12 [800200,866800)
13 [866800,933400)
14 [933400,1e+06]

The inline display:

[1000,67600)   [67600,134200)   [134200,200800) [200800,267400)  [267400,334000) [334000,400600)  [400600,467200) [467200,533800)  [533800,600400) [600400,667000)  [667000,733600) [733600,800200)  [800200,866800) [866800,933400)  [933400,1e+06]

Sending chart from CLI

Hello, I'd like to use Your utility to send a simple chart via mail from a command line in Linux. But there are an unreadable bunch of chars â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆ in the received email, if I pipe result from jp to "mail -s ..." command although jp works perfectly in CLI.
Do You have any advice on how to send a chart via email from CLI, please?

Manually set the Y axis scale

Love this tool @sgreben !

Is there any way to manually set the min/max values for the Y-axis?

Sub-character resolution

Other libraries - for example, termui - use braille symbols (⣀⡠⡐⡈ etc.) to effectively double the plot resolution. It would be nice if we could do that also (probably by default / simply instead of the current full-block character).

Linux 32bit version

It there a linux 32bit version that I could use?

Thanks

jp v2 - Call for Opinion

Given that some time has passed since jp was released, it's a good moment to reflect on possible changes and improvements. Hence, the question for this issue is:

What should change?
What should definitely not change?

v2 will certainly include breaking changes- which is a chance to adapt the UX of the tool in a more drastic way than usual :) The timeline for this is roughly "until-end-of-year".

Heads-up: jp is now available in FreeBSD Ports Collection

Here's a link: https://www.freshports.org/graphics/jp/

Cheers & thanks for jp :)

Make JSONPath results more consistent

Background

Currently, our version of JSONPath has two index-selection behaviors:

Union-selection

input: [[1,2],["a","b"]]
path: [*][0,1]
output: [1,"a",2,"b"]]

The results are concatenated: first all 0-components, then all 1-components. This is the default behavior for field selection .[myField1, myField2] and was also chosen for index-selection for consistency.

All-selection

input: [[1,2],["a","b"]]
path: [*][*]
output: [1,2,"a","b"]

The results are interleaved: 0,1,0,1. This is the default JSONPath index selection behavior.

Proposal

Having both behaviors is confusing, all of these should have the same result.

Furthermore, it seems like echo '[[0,123],[1,456]]' | jp -xy '[*]', or echo '[[0,123],[1,456]]' | jp -xy '$', or even echo '[[0,123],[1,456]]' | jp should produce a valid plot:

 479.52│                     ▗
       │                  ▗▄▀▘
       │               ▄▄▀▘   
       │            ▄▞▀       
       │         ▄▞▀          
       │      ▄▞▀             
       │  ▗▄▀▀                
       │▄▀▘                   
 116.55└──────────────────────
       0                     1

Currently, only jp -xy '[*][0,1]' produces this.

I would propose that

Results are always interleaved (i.e. [*][*] = [*][0,1] = 0.0, 0.1, 1.0, 1.1)
An array of arrays is a valid result of the -xy JSONpath.
The default behavior (no JSONPaths specified) is to assume [[x,y],[x,y],...] input.

Proposal 3. in particular is quite debatable, so I'd appreciate any feedback on this.

raspbian support

Hey there,

Was wondering if you'd support raspbian on raspberry pi? I can't seem to make successfully. It just auto-cleans without creating binaries. Also the arm64 doesn't work..

$ ./jp
-bash: ./jp: cannot execute binary file: Exec format error

jp $ uname -a
Linux t5 4.19.75-v7+ #1270 SMP Tue Sep 24 18:45:11 BST 2019 armv7l GNU/Linux

Matrix plot type

hist2d can't be used for this because it expects dis-aggregated data.

jp bar how to order along the y-axis by date

Hi,

sorry if this is a silly question and appreciate your patience.

I'm calling jp with the json input shown further below. For some reason the "date" from the json across the x axis is not showing up in correct order which I expected (e.g., as in the same sequence as the input json). The data in each column is correct (the date matches the new_cases), but I'm having troubles making them appear on the y axes in ascending order by date (e.g. exactly as they are in the input.json)

Here is the output produced by jp:

Here is the input json:

{
  "continent": "Europe",
  "location": "Austria",
  "population": 9006400,
  "population_density": 106.749,
  "median_age": 44.4,
  "aged_65_older": 19.202,
  "aged_70_older": 13.748,
  "gdp_per_capita": 45436.686,
  "cardiovasc_death_rate": 145.183,
  "diabetes_prevalence": 6.35,
  "handwashing_facilities": null,
  "hospital_beds_per_thousand": 7.37,
  "life_expectancy": 81.54,
  "human_development_index": 0.908,
  "day1": {
    "date": "2020-12-29",
    "total_cases": 355352,
    "new_cases": 1868,
    "new_cases_smoothed": 1875.143,
    "total_deaths": 6059,
    "new_deaths": 128,
    "new_deaths_smoothed": 74.143,
    "total_cases_per_million": 39455.498,
    "new_cases_per_million": 207.408,
    "new_cases_smoothed_per_million": 208.201,
    "total_deaths_per_million": 672.744,
    "new_deaths_per_million": 14.212,
    "new_deaths_smoothed_per_million": 8.232,
    "new_tests": 15563,
    "total_tests": 3794046,
    "total_tests_per_thousand": 421.261,
    "new_tests_per_thousand": 1.728,
    "new_tests_smoothed": 21479,
    "new_tests_smoothed_per_thousand": 2.385,
    "positive_rate": 0.087,
    "tests_per_case": 11.5,
    "tests_units": "tests performed"
  },
  "day2": {
    "date": "2020-12-30",
    "total_cases": 357902,
    "new_cases": 2550,
    "new_cases_smoothed": 1935,
    "total_deaths": 6149,
    "new_deaths": 90,
    "new_deaths_smoothed": 70.714,
    "total_cases_per_million": 39738.63,
    "new_cases_per_million": 283.132,
    "new_cases_smoothed_per_million": 214.847,
    "total_deaths_per_million": 682.737,
    "new_deaths_per_million": 9.993,
    "new_deaths_smoothed_per_million": 7.852,
    "new_tests": 16085,
    "total_tests": 3810131,
    "total_tests_per_thousand": 423.047,
    "new_tests_per_thousand": 1.786,
    "new_tests_smoothed": 18285,
    "new_tests_smoothed_per_thousand": 2.03,
    "positive_rate": 0.106,
    "tests_per_case": 9.4,
    "tests_units": "tests performed",
    "total_vaccinations": 6000,
    "total_vaccinations_per_hundred": 0.07
  },
  "day3": {
    "date": "2020-12-31",
    "total_cases": 360815,
    "new_cases": 2913,
    "new_cases_smoothed": 1944.429,
    "total_deaths": 6222,
    "new_deaths": 73,
    "new_deaths_smoothed": 68.143,
    "total_cases_per_million": 40062.067,
    "new_cases_per_million": 323.437,
    "new_cases_smoothed_per_million": 215.894,
    "total_deaths_per_million": 690.842,
    "new_deaths_per_million": 8.105,
    "new_deaths_smoothed_per_million": 7.566,
    "new_tests": 26789,
    "total_tests": 3836920,
    "total_tests_per_thousand": 426.021,
    "new_tests_per_thousand": 2.974,
    "new_tests_smoothed": 17948,
    "new_tests_smoothed_per_thousand": 1.993,
    "positive_rate": 0.108,
    "tests_per_case": 9.2,
    "tests_units": "tests performed"
  },
  "day4": {
    "date": "2021-01-01",
    "total_cases": 362911,
    "new_cases": 2096,
    "new_cases_smoothed": 1979.429,
    "total_deaths": 6261,
    "new_deaths": 39,
    "new_deaths_smoothed": 68.286,
    "total_cases_per_million": 40294.79,
    "new_cases_per_million": 232.723,
    "new_cases_smoothed_per_million": 219.78,
    "total_deaths_per_million": 695.172,
    "new_deaths_per_million": 4.33,
    "new_deaths_smoothed_per_million": 7.582,
    "new_tests": 20462,
    "total_tests": 3857382,
    "total_tests_per_thousand": 428.293,
    "new_tests_per_thousand": 2.272,
    "new_tests_smoothed": 17783,
    "new_tests_smoothed_per_thousand": 1.974,
    "positive_rate": 0.111,
    "tests_per_case": 9,
    "tests_units": "tests performed"
  },
  "day5": {
    "date": "2021-01-02",
    "total_cases": 364302,
    "new_cases": 1391,
    "new_cases_smoothed": 1974,
    "total_deaths": 6275,
    "new_deaths": 14,
    "new_deaths_smoothed": 61.714,
    "total_cases_per_million": 40449.236,
    "new_cases_per_million": 154.446,
    "new_cases_smoothed_per_million": 219.177,
    "total_deaths_per_million": 696.727,
    "new_deaths_per_million": 1.554,
    "new_deaths_smoothed_per_million": 6.852
  },
  "day6": {
    "date": "2021-01-03",
    "total_cases": 365768,
    "new_cases": 1466,
    "new_cases_smoothed": 1982.286,
    "total_deaths": 6324,
    "new_deaths": 49,
    "new_deaths_smoothed": 63.286,
    "total_cases_per_million": 40612.009,
    "new_cases_per_million": 162.773,
    "new_cases_smoothed_per_million": 220.097,
    "total_deaths_per_million": 702.167,
    "new_deaths_per_million": 5.441,
    "new_deaths_smoothed_per_million": 7.027
  },
  "day7": {
    "date": "2021-01-04",
    "total_cases": 367410,
    "new_cases": 1642,
    "new_cases_smoothed": 1989.429,
    "total_deaths": 6357,
    "new_deaths": 33,
    "new_deaths_smoothed": 60.857,
    "total_cases_per_million": 40794.324,
    "new_cases_per_million": 182.315,
    "new_cases_smoothed_per_million": 220.891,
    "total_deaths_per_million": 705.831,
    "new_deaths_per_million": 3.664,
    "new_deaths_smoothed_per_million": 6.757
  }
}

And this is how the input json is processed with jp (it needs the input.json as it's only argument)

#!/bin/bash

if [ -z "$1" ]; then
  echo "Usage $0 input.json"
  exit 1
fi

corpus_tmp=~/.cache/covid_status/tmp/
mkdir -p $corpus_tmp

declare -r jp_chart_txt=`mktemp --suffix=.txt $corpus_tmp/covid_status_jp.XXXXXXXXX` || {
      echo "eror mktemp --suffix=.txt $corpus_tmp/covid_status_jp.XXXXXXXXX returned $?: $!" >&2; exit 1
  }

## date on x axis will cause the order get messed up. 
## FIXME!!
< "$@" ~/src/go/bin/jp -xy '..[date,new_cases]' -type bar -canvas full-escape &> $jp_chart_txt || {
  echo "jp failed ($?) - Sorry no chart :(" &>> $jp_chart_txt
  exit 1
}

less -X $jp_chart_txt
rm -f $jp_chart_txt
exit 0

thanks

edit: updated/corrected the input.json

arm64 version

Compiling and running the program on an arm64 machine (Packet Type 2A) works without any issues. If you have the chance to generate a binary for arm64, I'm happy to also give it a quick test.

CSV support?

CSV is the format I end up more often than not when dealing with older systems. It would be welcome to have some well-thought out strategy for plotting and graphing CSV information, whether that's changes to jp, or documentation of other tools that neatly transform CSV to JSON in a format that's readily consumable by jp.

LICENSE?

Which license should jp have? Currently it includes (modified) code from goterm (MIT) and kubernetes (Apache).

The goterm derived code is likely to be replaced soon, but I don't think anyone feels like re-implementing the jsonpath parser/interpreter from scratch...

I'd like to pick the maximally permissive license possible under these constraints.

update embedded golang-sys by fead79001313

Hi,
Is it possible to update embedded golang-sys by fead79001313, it fixes the build on FreeBSD/aarch64
Thanks!

edit: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243779

Graphic mode support

It would be great if it supported ReGIS, Sixel, Tektronix 4010.
GNUplot already supports them.
Semigraphics would also be a nice addition.

Question: JSONLines support

Thanks for this project. It looks very promising and match made in heaven for integration with Vegeta in ways similar to these: https://github.com/tsenart/vegeta#usage-real-time-analysis

Vegeta can dump results in JSONLines format and I couldn't figure out if JSONPath supports this.

A current workaround is to use a rather difficult jq expression to convert JSONLines to JSON:
jq -nr '"[", try (input|tojson, repeat(",\n\(input|tojson)")), "]"'

Comments

Histogram plot type

It's tedious to have to bucket & count data yourself, when jp could just do it for you. We should have a histogram plot type with some default number of buckets (or strategy for auto-choosing one) and a way to specify other (numbers of) buckets.

null input causes panic: reflect: call of reflect.Value.Interface on zero Value

Eds-MacBook-Pro:~ ed$ echo "" | go/bin/jp
2018/03/22 15:23:37 EOF

panic: reflect: call of reflect.Value.Interface on zero Value

goroutine 1 [running]:
reflect.valueInterface(0x0, 0x0, 0x0, 0x10e2301, 0x1104540, 0x11f8c18)
	/usr/local/Cellar/go/1.9.3/libexec/src/reflect/value.go:936 +0x1bf
reflect.Value.Interface(0x0, 0x0, 0x0, 0x1, 0x1)
	/usr/local/Cellar/go/1.9.3/libexec/src/reflect/value.go:931 +0x44
main.linePlotData(0xc42008c200, 0x1, 0x1, 0xc42008c240, 0x1, 0x1, 0x0, 0x1, 0x0, 0xc42003be90, ...)
	/Users/ed/go/src/github.com/sgreben/jp/cmd/jp/line.go:13 +0xc5
main.linePlot(0xc42008c200, 0x1, 0x1, 0xc42008c240, 0x1, 0x1, 0xb6, 0x36, 0x11136c0, 0xc42007a501)
	/Users/ed/go/src/github.com/sgreben/jp/cmd/jp/line.go:31 +0x81
main.main()
	/Users/ed/go/src/github.com/sgreben/jp/cmd/jp/main.go:105 +0x22e

I'm not 100% sure what the right behavior is in the face of a zero-length input file, but a panic is probably not the right thing do to.

sgreben / jp Goto Github PK

jp's People

Contributors

Stargazers

Watchers

Forkers

jp's Issues

Recommend Projects

Recommend Topics

Recommend Org