[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ✘gpsd .23.2~rc1
From: |
Fred Wright |
Subject: |
Re: ✘gpsd .23.2~rc1 |
Date: |
Fri, 15 Apr 2022 13:52:17 -0700 (PDT) |
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.
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.
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".
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; I said the change is a NOP in that case.
Look at the code. The volatile is only present when FLT_EVAL_METHOD >= 2.
Otherwise FLT_VOLATILE is empty.
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, but the point is that the volatile
was very much needed on 32-bit OpenBSD. 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.
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? I believe it was *your* use of FLT_EVAL_METHOD in runtime
code that was the problem. 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".
On Fri, 15 Apr 2022, Gary E. Miller wrote:
On Fri, 15 Apr 2022 02:12:00 -0700 Hal Murray <halmurray@sonic.net>
wrote:
My setup uses clang on OpenBSD and FreeBSD. Both provide a blizzard
of cc: warning: optimization flag '-fexcess-precision=standard' is
not supported [-Wignored-optimization-argument]
OpenBSD clang version 11.1.0
OpenBSD clang version 11.1.0 (32 bit)
FreeBSD clang version 11.0.1
FreeBSD clang version 10.0.0
FreeBSD clang version 11.0.1 (32 bit)
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.
Fred Wright
- Re: ✘gpsd .23.2~rc1, (continued)
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/13
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/13
- Re: ✘gpsd .23.2~rc1, Hal Murray, 2022/04/13
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/13
- Re: ✘gpsd .23.2~rc1, Hal Murray, 2022/04/14
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/14
- Re: ✘gpsd .23.2~rc1, Hal Murray, 2022/04/14
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/14
- Re: ✘gpsd .23.2~rc1, Hal Murray, 2022/04/15
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/15
- Re: ✘gpsd .23.2~rc1,
Fred Wright <=
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/15
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/15
- Re: ✘gpsd .23.2~rc1, Hal Murray, 2022/04/15
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/16
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/16
- Re: ✘gpsd .23.2~rc1, Hal Murray, 2022/04/16
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/17
- Re: ✘gpsd .23.2~rc1, Hal Murray, 2022/04/17
- Re: ✘gpsd .23.2~rc1, Gary E. Miller, 2022/04/17
- Re: ✘gpsd .23.2~rc1, Hal Murray, 2022/04/17