Re: ✘gpsd .23.2~rc1

[Gary E. Miller]

Yo Fred!

On Fri, 15 Apr 2022 13:52:17 -0700 (PDT)
Fred Wright <fw@fwright.net> wrote:

> On Thu, 14 Apr 2022, Gary E. Miller wrote:
> > On Thu, 14 Apr 2022 20:26:06 -0700 (PDT) Fred Wright
> > <fw@fwright.net> wrote:
> >  
> >> It's all very nitpicking except for the
> >> tests, since it's about rounding a value that's nominally exactly
> >> halfway between two allowable values in the JSON precision, which
> >> is less than the uBlox precision.  
> >
> > Yeah, one decimal digit is lost in the JSON.  When I see a mm
> > precise GNSS, that will have to change.  
> 
> Sure, hence the "nitpicking".  But the wobbly results arise from the 
> "lost" digit.

Nothing is "wobbly", reregressions, as confirmed by you and Hall are
100% consistent over all tests.

> >> The whole JSON precision issue needs looking into, but not right
> >> now.  
> >
> > Been there, done that:
> >
> >    https://gpsd.io/gpsd-numbers-matter.html  
> 
> I think it would make sense to vary the JSON precison based on what
> the receiver provides.  For further study.

Feel free to open that can of worms, after the release.

> 
> >> For example, uBlox NAV-PVT reports altitudes with millimeter
> >> precision, and NAV_HPPOSLLH provides 10-micron precision.  The JSON
> >> has 100-micron precision, so it's overkill in the standard case and
> >> deficient in the high-precision case.  Not that it's very likely to
> >> matter in real use cases, since a receiver is hard pressed even to
> >> deliver millimeter accuracy on a single real-time fix, especially
> >> in the vertical dimension.  
> >
> > I think you mean hard pressed to deliver 0.01 meter accuracy.  
> 
> I meant millimeter because that's what the receiver nominally
> provides even without "high precision".

Pretends to provide.  When someone find that last digit useful, we'll
have to revist this whole mess again.

> >> Also, in spite of your attempts to control FLT_EVAL_METHOD, the
> >> FLT_VOLATILE hack is still needed.  Taking it out caused about a
> >> dozen errors on nmea-fuzzy-cases in 32-bit OpenBSD, so I put it
> >> back.  
> >
> > I tested it on FreeBSD, are they really different?
> >  
> >>  It's a complete NOP any time FLT_EVAL_METHOD < 2, anyway.  
> >
> > No, valatile has real costs.  
> 
> I didn't say "volatile" is a NOP;

No one suggested that.  Please, no straw men.

> I said the change is a NOP in that
> case. Look at the code.

I think that is what we have been doing.

>  The volatile is only present when
> FLT_EVAL_METHOD >= 2. Otherwise FLT_VOLATILE is empty.

Which is wrong, every case except FLT_EVAL_METHOD == 0 needs is.
What ever "it" is.

I'll be changing that.

> >> My version now passes all tests on the 22 platforms I tested, which
> >> wasn't true of yours.  
> >
> > Can you be more specific on the failing case?  I know that volatile
> > is not needed, but the full fix was not needed on my test case.  
> 
> I could reconstruct that if necessary,

Please do.  Better yet, tell me so I can.

> but the point is that the
> volatile was very much needed on 32-bit OpenBSD.

"something" is needed, it does not have to be volatile, or a code
branch of any kind.

> In my end result,
> only one value in a .chk file needed to be changed from everything
> before the recent changes, and I vetted that one.  You can always
> diff the .chk files to see what changed.

Which we both know we have been ding.  You misrepresent my objection to
that kludge.

> > And your #if broke one of Hal's old test cases.  Older cc do
> > not define FLT_EVAL_METHOD, your code requires it, thus an errorf.  
> 
> Are you sure?

Yes.  FLT_EVAL_METHOD is not upported by all C compilers.  I'd rather
not have to justify that all the cc we care about do support it.  It
is just good defensive programming to check that it exists.

>  I believe it was *your* use of FLT_EVAL_METHOD in
> runtime code that was the problem.

An explicit hack as a test for Hal.

> Preprocessor numeric conditionals
> are supposed to regard undefined macros as having a value of 0, so my
> use of it is perfectly OK *in the preprocessor*.  If for some reason
> it has to work with some really ancient compiler that doesn't follow
> that rule, then one could always apply the "+0 hack".

Depends on CCFLAGS.  Note -Wundef  Our goal, that we'll never achieve,
is zero warnings.  So we need to fix that.

> > Yeah, for some reason the scons option checker misses that one.
> > I'll play with it.  
> 
> I believe the SCons option checker treats warnings as success, so it 
> happily includes the gcc-only option for clang.  Since gcc considers
> the clang-only option to be an error, and clang considers the
> gcc-only option to be a warning, the obvious fix is to try the clang
> option first and then only try the gcc option if the clang option is
> rejected, rather than just throwing them both into the general pile
> of optional options.

Yeah, I'm workong on this one.  CheckCompilerOption() has been
broken that way since 2012..

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgp1b_16wjuSR.pgp
Description: OpenPGP digital signature