Re: ✘gpsd .23.2~rc1

[Gary E. Miller]

Yo Fred!

On Sat, 9 Apr 2022 13:26:00 -0700 (PDT)
Fred Wright <fw@fwright.net> wrote:

> > 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.

I feel like Linus does.  When people sart assuming things, but to break
them of that habbit.

For now, 3.23.2 only brings new features, so feel like a .2 to me.
Like any variable, it only makes sense when you read the doc.

> > 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.

Whan you "assume", you make an ass" of "u" and "me".
.

> > 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.

Distros specifically asked for the tilda.  I try to comply with their
wishes.  This was an easy one.


> >> 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.

Until there is a better explanation, I'll take that one.

Feel free to dig in a fix it.

> >>> 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.

Then I obviously failed to comprehend.  But rather than explain it to
someone that does not care, maybe just go fix it?

> >> 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.

Now we are just getting circular.  I am totally lost.

> > 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.

In IEEE754, it is guaranteed.  Modern C compilers are supposed to
follow IEEE 754.

OTOH, if you see a fix, please give it a try.

> The current approach here is to play whack-a-mole with the specific
> cases that cause trouble,

Uh, no.  Exactly why I'm not going to try to rifle shot altHAE.

> 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.

gpsd never, intentionally, uses long doubles.  If you spot some, or
have an idea how to stop them from being used, please suggest a fix.

> 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.

Since you understand the problem, why don't you just fix it?

> 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.

Sure looks like one to me.  If the explanation is long oubles, that is
still a rounding bug (non-compliance with IEE754).

> > 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.

Yes, your point?

> 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).

I'm having this conversation in stereo (other channels). gpsd supports
far more than just recent gcc and clang. gpsd tries very hard not to do
compiler dependent things.  We need a way that is standards compliant to
work around this musl bug.  Yes, it is clearly a musl bug.  But I can't
find where to report musl bugs.

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

pgpRxcT5Bb3Gl.pgp
Description: OpenPGP digital signature