Eric S. Raymond
esr at thyrsus.com
Sat Nov 26 20:01:56 UTC 2016
Achim Gratz <Stromeko at nexgo.de>:
> The waf build or install needs to create the correct shebang
> lines when a different python binary is configured, I suppose.
Oh dear Goddess, no. I tried that approach once during GPSD's history.
It was horrible, a maintainance nightmare. Better practice is to write your
Python so it will run under either 2 or 3. See:
The GPSD project uses this approach successfully. We've tried to
write the NTPsec Python this way, but the packet library is still
under active development on a Python 2 system and that sometimes
breaks Python 3 compatibility. One of our guys, Matt Selsky, is
working on catching it up and I expect fixes will land soon.
> So I've installed python-dev to get pathon-conf for 2.7 and ntpq finally
Well, that's good.
> The shortest unique abbreviation for commands isn't working
> anymore (Hal already notedt that).
Yes, on my list, but I can't give it high priority. I have a couple
of fires I need to fight first.
> Also, while it's good that the print
> can use a wide terminal now, it really shouldn't move the data to the
> right as far as possible (my text console is 320 characters wide and the
> usual graphics terminal 176 characters). Can the fields please be
> widened only so much that they show the data without truncation? Else
> I'd need some option to limit the width of the printout.
No can do. You're going to have to live with using the --wide option.
If this problem could be solved with clever programming, I'd do it.
Unfortunately it's fundamental. You can't know the right width to pad
to until you've reverse-DNsed all the addresses. But if you do that,
you can't report even the first line until after a potentially
unbounded amount of DNS-lookup stalls.
The C ntpq code was carefully written not to require this (and had a
control flow that looked really odd unless you understood this
constraint). The Python port preserves these properties. Use -w.
> The output from the cv command mangles the timecode string from the GPS:
> timecode=""$GPZDA", 120543.000="", 26="", 11="", 2016="", 00="", 00*56"="",
> This used to look like that (and really still should):
Oh, bletch. I see the problem. I'm going to have to write a real
parser rather than using a naive split(",") call.
...or maybe not. Rather klugey fix pushed. Complain if it needs
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the devel