Re: ntpq: cruft/doc

2016-10-17 Thread Eric S. Raymond
Gary E. Miller : > > Is there a good library/package to do the parsing? Do we want to add > > another library to the list of requirements? > > In PHP it is built in. Reading or writing JSON is a one line function call. > > To write, you just take a nested object and tell PHP

Re: ntpq: cruft/doc

2016-10-17 Thread Gary E. Miller
Yo Hal! On Mon, 17 Oct 2016 03:22:42 -0700 Hal Murray wrote: > Is there a good library/package to do the parsing? Do we want to add > another library to the list of requirements? In PHP it is built in. Reading or writing JSON is a one line function call. To write,

Re: ntpq: cruft/doc

2016-10-17 Thread Hal Murray
e...@thyrsus.com said: > Harder than CSV, where unless someone is being conscientious (and it's > certainly not required in in RFC 4180) you get no self-descriptive clues at > *all*? Er...no. Ah. Sorry. A chunk of context got lost in this discussion. You are talking about the general case.

Re: ntpq: cruft/doc

2016-10-17 Thread Eric S. Raymond
Hal Murray : > > e...@thyrsus.com said: > >> CSV is readable by eye without a lot of effort. JSON is close to > encrypted. > > > Say *what*? Uh, I can only conjecture that you don't have a lot of actual > > experience with JSON. > > I admit that "encrypted" is an

Re: ntpq: cruft/doc

2016-10-16 Thread Hal Murray
e...@thyrsus.com said: >> CSV is readable by eye without a lot of effort. JSON is close to encrypted. > Say *what*? Uh, I can only conjecture that you don't have a lot of actual > experience with JSON. I admit that "encrypted" is an exaggeration, but the signal-noise is pretty low. Yes,

Re: ntpq: cruft/doc

2016-10-16 Thread Gary E. Miller
Yo Hal! On Sun, 16 Oct 2016 13:50:28 -0700 Hal Murray wrote: > g...@rellim.com said: > > I was unaware of RFC 4180, and it mandates CRLF as line ending, not > > the \n that I used. I just pushed a fix to this. Someone familiar > > with RFC4180 should check the format

Re: ntpq: cruft/doc

2016-10-16 Thread Hal Murray
g...@rellim.com said: > And I can't count the number of times people have asked me what the units > are because they can't figure it out. You should not have to read pages of > docc to find the current units. But I shouldn't have to waste valuable screen real estate to tell you what the units

Re: ntpq: cruft/doc

2016-10-16 Thread Hal Murray
g...@rellim.com said: > I was unaware of RFC 4180, and it mandates CRLF as line ending, not the \n > that I used. I just pushed a fix to this. Someone familiar with RFC4180 > should check the format is correct. My guess is that's for network traffic rather than local files. If you make a

Re: ntpq: cruft/doc

2016-10-16 Thread Eric S. Raymond
Gary E. Miller : > And I can't count the number of times people have asked me what the > units are because they can't figure it out. You should not have to read > pages of docc to find the current units. > > Check out chronyc, they do a lot of things much better than ntpq. I

Re: ntpq: cruft/doc

2016-10-16 Thread Gary E. Miller
Yo Eric! On Sun, 16 Oct 2016 15:14:19 -0400 "Eric S. Raymond" wrote: > > Many CSV files have a comment line on top with the field names. > > Good idea. Gonna be *mandatory* for anybody generating CSV in our > pond. Also strict conformance to RFC4180, at pain of my extreme

Re: ntpq: cruft/doc

2016-10-16 Thread Eric S. Raymond
Hal Murray : > > >> The first question is What does "mobilize" mean? > > Is that a rhetorical question? > > No, unfortunately, that's a serious question. I think it has some fine-print > meaning that I don't yet understand. Damn, I was afraid you were going to say

Re: ntpq: cruft/doc

2016-10-16 Thread Eric S. Raymond
Hal Murray : > > e...@thyrsus.com said: > > About CSV, while I'm not opposed to it we have a practice guideline to use > > JSON for machine-parseable output. One reason is that JSON is better at > > being self-describing - the field names give you clues that CSV doesn't.

Re: ntpq: cruft/doc

2016-10-16 Thread Hal Murray
>> The first question is What does "mobilize" mean? > Is that a rhetorical question? No, unfortunately, that's a serious question. I think it has some fine-print meaning that I don't yet understand. If it wasn't for this discussion, I would assume it meant something like create a peer

Re: ntpq: cruft/doc

2016-10-16 Thread Hal Murray
g...@rellim.com said: >> If you were starting over, what would you do? I think there are two >> parts to that question. One is the on-wire API. > I think we are stuck with that part. RFC's right? There is nothing that says we can't add new stuff. I've been happy with the shift from mode 7

Re: ntpq: cruft/doc

2016-10-15 Thread Gary E. Miller
Yo Hal! On Fri, 14 Oct 2016 21:06:49 -0700 Hal Murray wrote: > > But ntpq has likely never been used in any scripts, and is so > > broken in so many ways that I'd prefer to just start all over. > > That sounds like you won't object if I "experiment" with the current

Re: ntpq: cruft/doc

2016-10-14 Thread Gary E. Miller
Yo Hal! On Fri, 14 Oct 2016 17:35:16 -0700 Hal Murray wrote: > If preserving old patterns is more important than sane operations, > I'd suggest that the non-l versions print out a warning if they skip > any slots. (But that changes the UI too.) I hate changes in