Refclocks and formatting

[Eric S. Raymond]

Ian Bruene <ianbruene at gmail.com>:
> @ESR
> 
> In the units project I discovered that the string formatting for refclocks
> is handled in a completely different manner from the rest of the code.
> Specifically ntpq/mon call ntp.ntpc.statustoa which is a C library, instead
> of calling hypothetical formatting functions in pylib/util.py like they do
> for everything else.
> 
> As far as I can tell from a cursory examination of the code the reason for
> this is so it can use the same bitmask #defines as the rest of the system.
> Is this correct? If so does that need to remain the case, if not then why is
> the complexity of a language bridge being maintained? If it has to stay this
> way the unit formatters *can* munch on the output of statustoa.

Well spotted.  The truth is, this split is a historical hangover from
the sequence in which I wrote the Python tools - there's nothing
principled about it at all.  I wrote the extension early; afterwards
I figured out how to mechanically generate the required #defines into
control.py and the need for ntp.ntpc.statustoa went away. 

If it were otherwise possible to get rid of the Python extension I'd
have gotten rid of ntp.ntpc.statustoa already.  As it is, every time I
have remembered this minor wart I've either had something more urgent
to work on or (the last couple of weeeks) been so ill that I couldn't
easily summon up the energy to deal with code issues below emergency priority.

(I'm feeling better now.  Slow recovery, though; stamina isn't 100% yet.
Post-viral fatigue syndrome is a *bitch*.)

If you want to clean this up, go right ahead.  I think it would be a
good way for you to get your fingers into the C code, with a simple
excision.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.