Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parsing numbers #7

Closed
ilyash-b opened this issue Nov 2, 2019 · 13 comments
Closed

Parsing numbers #7

ilyash-b opened this issue Nov 2, 2019 · 13 comments

Comments

@ilyash-b
Copy link

ilyash-b commented Nov 2, 2019

I'm considering using jc in NGS - ngs-lang/ngs#316

I have seen in the readme that numbers are returned as strings. From my perspective this semantically incorrect and precludes usage of jc in NGS.

Is this by design or is it considered a bug in jc?

@ilyash-b
Copy link
Author

ilyash-b commented Nov 2, 2019

would eliminate |tonumber in jq I guess

From readme:

ls -l /usr/bin | jc --ls | jq '.[] | select(.size|tonumber > 50000000)'

@kellyjonbrazil
Copy link
Owner

kellyjonbrazil commented Nov 2, 2019 via email

@ilyash-b
Copy link
Author

ilyash-b commented Nov 2, 2019

Suggested alternative: have a "schema" and now where the numbers supposed to be. If the user chooses -h for "human" output and then uses jc for machine parse-able that's an error (exception).

@kellyjonbrazil
Copy link
Owner

kellyjonbrazil commented Nov 2, 2019 via email

@ilyash-b
Copy link
Author

ilyash-b commented Nov 2, 2019

I was thinking about stricter behaviour: you know where the numbers need to be. If the input is not a number, it's probably because of -h and jc probably should not parse anything like that because it's kind of sabotage by the user: runs the command explicitly requesting human output and makes jc parse it

@kellyjonbrazil
Copy link
Owner

I think i'd like to keep the original representation, too, for other use cases. Since it's easy to add fields to json that can be ignored if not needed I don't mind making extra _num_x or whatever fields to convert known numbers to number format if they are parsable.

@kellyjonbrazil
Copy link
Owner

Or actually, the opposite way so you can use the results more easily in your application.

Be strict in parsing, but if -h type of input is found and not parsable as a number, add a _fieldname with the non-parsable text output and you can just ignore the _fieldname fields if you just care about machine parsable data?

@kellyjonbrazil
Copy link
Owner

Was thinking about this a bit more and I think it makes more sense to provide the existing output when the user passes a -r or raw=true flag. The default output would be a strict schema representation with additional semantic information.

This allows for both use cases where you can use jc as a layer higher than sed/awk/grep but can also use it for higher level presentation.

I’ll start working on this. This solves the conflict I ran into in the earlier versions and I think it will be good for your project.

@ilyash-b
Copy link
Author

ilyash-b commented Nov 3, 2019

The default output would be a strict schema representation with additional semantic information.

Sounds good!

@kellyjonbrazil
Copy link
Owner

Hi Ilya,

I have incorporated your suggestions into the dev branch. I'm still working on some fixes and documentation, but it's pretty close to being merged in the next week or two.

Feel free to test/provide feedback on the dev branch:

pip3 uninstall jc
git clone --single-branch --branch dev https://github.com/kellyjonbrazil/jc.git
cd jc
./install.sh

@ilyash-b
Copy link
Author

Hi. Not getting to it. I'll take a look later.

@kellyjonbrazil
Copy link
Owner

updates in master version 1.5.1, also via pip3

@kellyjonbrazil
Copy link
Owner

kellyjonbrazil commented Nov 20, 2019 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants