gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ✘gpsd .23.2~rc1


From: Gary E. Miller
Subject: Re: ✘gpsd .23.2~rc1
Date: Wed, 13 Apr 2022 20:51:52 -0700

Yo Fred!

On Wed, 13 Apr 2022 20:40:16 -0700 (PDT)
Fred Wright <fw@fwright.net> wrote:

> On Tue, 12 Apr 2022, Fred Wright wrote:
> 
> > I found where the problem is, but don't have any more time tonight.
> >  I should be able to fix it tomorrow.  
> 
> I have a working fix, but haven't extensively tested it yet, which
> will have to wait until tomorrow.  It relates to how the extra 8-bit
> extensions are combined in the high-precision reports.  The actual
> inconsistent case was the altHAE from HPPOSLLH, but I applied the
> same fix to all the similar cases there and in HPPOSECEF and
> RELPOSNED as well.

If you check git head, you'll see all the tests are fixed up
to test/daemon/ublox-zed-f9p-hp.log.

Hal is confirming.

That log is your HPPOSLLH issue.  I have a working fix for that too, but
not tonight.

Sort of like whack-a-mole.  If only we could just reset FLT_EVAL_METHOD
to 0 and be done with it!

> I haven't yet rebased beyond 06560a3ae, since that would just muddy
> the waters.

It will be interesting to compare fixes.

I looked into forcing (long double), like FLT_EVAL_METHOD=2, but
then found that C does not define what a (long double) is, so that
jsut amkes things worse...

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

Attachment: pgp8qCOEx83aD.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]