Re: ✘gpsd .23.2~rc1

[Fred Wright]

On Fri, 8 Apr 2022, Gary E. Miller wrote:
> On Fri, 8 Apr 2022 19:38:04 -0700 (PDT) Fred Wright <fw@fwright.net> 
> wrote:
>
> > On Thu, 7 Apr 2022, Gary E. Miller wrote:
> >
> > > I just bumped the gpsd version in got to 3.23.2~rc1.  There is
> > > always more to do on gpsd, but this seems like a good pause point.
> >
> > It seems to me that this should really be 3.24 rather than 3.23.2.
> > Will the next release be 3.23.2.1? :-)
>
> Since the last one was 3.23.1, makes sens to me that the next one is
> 3.23.2.
>
> For some reason gpsd users are more reluctant to go from 3.23 to
> 3.24, than from 3.23 to 3.23.1.

Traditionally, the more minor versions were only used for followup 
releases, when the regular release broke something badly enough to warrant 
the quick followup.  If users don't want to upgrade to 3.24, it's probably 
because of an expectation that a 3.24.1 will be necessary.

> > The
> > trouble with the current naming scheme for dev versions is that it
> > assumes that one can predict the *next* version number.
>
> Where did you get that idea?  There has been no previous consistency
> or implication of that.

The dev version number is clearly based on a future version number, with 
an implication that that's ne next version.

> > If the
> > version were a simple integer that would be fine, but with the
> > variable-resolution versioning, not so much.  I suggest basing future
> > dev versions on the *preceding* release version, in order to avoid
> > that.
>
> I tried that once, confused everyone.

It might be a little clearer if it were "+dev" rather than "~dev", though 
I'm not sure how many places assume the tilde.

> > I also saw this on 32-bit OpenBSD (for the same test).  I haven't dug
> > into it yet, but I suspect it's another instance of the older problem
> > fixed by e379bfac5.
>
> Since you have an idea, I'll eave that one to last.

So stop blaming it on rounding.

> > > Apple LLVM version 10.0.0 (clang-1000.10.44.4) on High Sierra
> > > reports:
> > > > clang: warning: treating 'c' input as 'c++' when in C++ mode, this
> > > behavior is deprecated [-Wdeprecated]
> > > for about a dozen .c files in libgps/
> >
> > That's a long-standing problem related to the way Qt support works.
> > The warning only shows up with certain versions of clang, and in
> > spite of the deprecation warning, I've yet to see a version that
> > refuses to compile it.
>
> I suspect you are correct, but without the build log, we are jsut guessing.

I'm not guessing at all.  I explained it in the paragraph you snipped. 
It's fully understood and has been around for years.

> > > > The previous file and gpsd-code-example griped about the rouge
> > > > gems' absence, I gave it to them
> > >
> > > You mean "ruby gems"?  If you are missing that, then your
> > > AasciiDoctor is not installed correctly.  Nothing gpsd can do about
> > > that.  gpsd checks that AsciiDoctor is installed, not that it is
> > > installed correctly.
> >
> > AFAIK, the rouge gems are not a general requirement for asciidoctor.
> > When I looked into this a bit, I found something that indicated that
> > this error is often caused by something being specfied incorrectly so
> > that it falls back to needing 'rouge', but that's as far as I got.
> > I'm not aware of any actual problem caused by the absence of 'rouge',
> > so I didn't bother digging further.
>
> What is "rouge"?  gpsd does not use it, so not a gpsd problem.

It's what the complaint is about.

On Fri, 8 Apr 2022, Gary E. Miller wrote:
> On Thu, 07 Apr 2022 23:02:09 -0700 Hal Murray <halmurray@sonic.net> 
> wrote:

> > 32 bit Debian on X86_64
> >
> > It's reproducable.
>
> Rounding error:
>
> - "altHAE":26.1200,
> + "altHAE":26.1199,
>
> printf() is supposed to round for us.  So another glitch in your libc.

It's not a rounding issue.

Suppose one platform computes 26.1199500000 and another computes 
26.1199499999.  The difference is infinitesimal, but they still round 
differently.  In general, floating-point comparisons should use fuzz. 
*Most of the time*, the discrepancy lands in a single rounding bucket, so 
it's covered up by rounding, but occasionally it straddles a rounding 
boundary and shows up in the output.  Rounding is not a *guaranteed* 
substitute for fuzz.

The current approach here is to play whack-a-mole with the specific cases 
that cause trouble, but every new test log potentially causes new trouble. 
The only systematic way to avoid the problem would be to thoroughly 
eradicate all (inherently opportunistic) uses of long doubles.

Just to save you the incredible hassle of looking up the commit message 
for the commit I referenced earlier (e379bfac5), I'll reproduce it here:

--------------------------------------------------------------------------
commit e379bfac57b1694ff5b28069f4cb3b9d6ee918a6
Author: Fred Wright <fw@fwright.net>
Date:   Thu Jul 2 18:21:52 2020 -0700

    driver_nmea0183: Fix recent regressions on 32-bit OpenBSD

    The issue with OpenBSD 5.6 is that the 32-bit version is set up to use
    FLT_EVAL_METHOD = 2, which is a bit more accurate in principle but
    also inconsistent with other platforms, including 64-bit OpenBSD 5.6.
    The fix is to use a volatile variable for an intermediate value,
    forcing it to be limited to a double.

    Relying on exact comparisons of floating-point results is always
    somewhat iffy, and the only reason it doesn't fail completely is due
    to the consistent use of IEE-754 floating-point formats on all
    platforms of interest.  It would be desirable to use fuzzy comparisons
    on floating-point results, but that would require a major overhaul of
    the test framework.

    TESTED:
    Ran "build-all check" on macOS 10.5-10.13 (including 10.5 PPC), Ubuntu
    14, CentOS 7, Fedora 25, FreeBSD 10.3, OpenBSD 5.6 (32- and 64-bit),
    and NetBSD 6.1.5.  All tests now pass on all platforms.
--------------------------------------------------------------------------

The actual fix for the current issue is probably a one-liner, but it takes 
some digging to find the right line.

On Sat, 9 Apr 2022, Hal Murray wrote:
> gem@rellim.com said:
> > But still a libc error.  printf() is supposed to round, and it is not doing
> > so.  I would not like to change all printf() uses of %f.
>
> Any ideas on how to get a test case so we can file a bug report?

Not a rounding bug.  See above.

On Sat, 9 Apr 2022, Gary E. Miller wrote:
> Uh, this is a new one:
>
> gpsd:ERROR: NTP:SHM: shmat failed,  unit 10: Too many open files(24)
>
> Did you reboot before running this?  What are your system SHM settings?
>
> Does macOS document any POSIX incompatibilities in shmat(), shmdt(),
> shmctl(), etc?

It's not an incompatibility to exhaust the configured file descriptor 
limit.

On Sat, 9 Apr 2022, Gary E. Miller wrote:

> I could try to use typeof() at compile time, but that is not standard C
> either.  So not.

It's not guaranteed to be available, but both gcc and clang have had it 
for a long time.  A configure test for the availability of typeof() would 
be straightforward.  Then the only question is whether there's an 
appropriate default type to use when typeof() isn't available (which is 
probably unusual).

Fred Wright