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
Comments
would eliminate From readme:
|
I originally was converting numbers to int or float but then I found that if the user chooses -h for human readable format then it made things more complicated to correctly parse. So then I figured it would be best to keep everything a string representation and leave the conversion to the user downstream. Maybe I could add a flag that allows the user to choose to have the parser to keep numbers?
Kelly Brazil
+1 415 602 7929
Sent from my mobile device
… On Nov 2, 2019, at 9:42 AM, Ilya Sher ***@***.***> wrote:
would eliminate |tonumber in jq I guess
From readme:
ls -l /usr/bin | jc --ls | jq '.[] | select(.size|tonumber > 50000000)'
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Suggested alternative: have a "schema" and now where the numbers supposed to be. If the user chooses |
Yeah, good idea, I was thinking similar after I responded. I could leave the string representation and add fields for the number representation (eg. size_num). X_num fields, if they exist, would be the int/float version if the regular field contains only digits and a ‘.’.
Something like that. Btw, I’m working on an improved netstat implementation.
Kelly Brazil
+1 415 602 7929
Sent from my mobile device
… On Nov 2, 2019, at 10:08 AM, Ilya Sher ***@***.***> wrote:
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).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
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 |
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 |
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 |
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. |
Sounds good! |
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 |
Hi. Not getting to it. I'll take a look later. |
updates in master version 1.5.1, also via pip3 |
BT2|~SktOUkc1TUhETjR8fktlbGx5fH45Nzg0NA==
Kelly Brazil
+1 415 602 7929
Sent from my mobile device
|
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?
The text was updated successfully, but these errors were encountered: