[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: some observations on the design intent of gpsd
From: |
Gary E. Miller |
Subject: |
Re: some observations on the design intent of gpsd |
Date: |
Wed, 5 Jan 2022 13:29:36 -0800 |
Yo Don!
On Wed, 5 Jan 2022 16:10:02 -0500
Don Rolph <don.rolph@gmail.com> wrote:
> The key question is why strip out the rest of the functionality from
> the interface.
Uh? Lacking any suggestion to do so, I'll ignore this.
> And I simply note that we have spent a fair amount of time on the
> present interface which based on my testing so far seems to be driven
> by the relative complexity of the interface.
>
> We have a working 3.17 piece of software.
No, you don't. And not from us. last time I'll address it.
> And I have shown that the same software fails against the 3.23.2~dev
> server. And so far no one seems to be able to explain why or provide
> a viable path forward.
I have asked you for the new code, and have told you I know why it is
broken. Last time I'll ask for code.
> A single location interface which is invariant would seem to ease this
> problem.
Already have it. More than one in fact. If you keep asserting that
not fact, I'll ignore it too.
> I made a comment because the present migration seems to be having
> issues and this triggers my thought on how could this be made simpler.
What migration? I only see self infllcted bad code in Dire Wolf,
In C when you do code that has undefined results, expect those
to shange with time and place.
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
pgprKO5Xk9kDt.pgp
Description: OpenPGP digital signature
Re: some observations on the design intent of gpsd, Greg Troxel, 2022/01/05
Re: some observations on the design intent of gpsd, Владимир Калачихин, 2022/01/06