Re: DCF77 driver seems to be broken

Eric S. Raymond writes: > Achim Gratz : >> Hal Murray writes: >> > Thanks for making it match what other cmp type routines do. >> >> Someone(TM) still needs to commit this patch. > > I'll do it. Where's the patch?

Re: DCF77 driver seems to be broken

Achim Gratz : > Hal Murray writes: > > Thanks for making it match what other cmp type routines do. > > Someone(TM) still needs to commit this patch. I'll do it. Where's the patch? It would be useful if you started submitting merge requests via GitLab. --

Re: DCF77 driver seems to be broken

Hal Murray writes: > Thanks for making it match what other cmp type routines do. Someone(TM) still needs to commit this patch. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1:

Re: l_fp access macros (was: DCF77 driver seems to be broken)

Achim Gratz : > Just out of curiosity, why have you defined the l_fp access macros in > such an overly redundant manner? I realize that the compiler will > optimize most of that away, but it seems odd to do that in the first > place unless you're expecting to support a platform

l_fp access macros (was: DCF77 driver seems to be broken)

Just out of curiosity, why have you defined the l_fp access macros in such an overly redundant manner? I realize that the compiler will optimize most of that away, but it seems odd to do that in the first place unless you're expecting to support a platform that has a non-conforming compiler that

Re: DCF77 driver seems to be broken

Achim Gratz : > Achim Gratz writes: > […] > > Just out of curiosity, why have you defined the lfp access macros in > > such an overly redundant manner? > […] > > The lack of responses makes me wonder if it was a bad idea to tuck that > section after the patch… any insights?

Re: DCF77 driver seems to be broken

Achim Gratz writes: […] > Just out of curiosity, why have you defined the lfp access macros in > such an overly redundant manner? […] The lack of responses makes me wonder if it was a bad idea to tuck that section after the patch… any insights? :-) Regards, Achim. -- +<[Q+ Matrix-12

Re: DCF77 driver seems to be broken

Yo Achim! On Mon, 20 Feb 2017 21:23:48 +0100 Achim Gratz wrote: > Subject: [PATCH] Fix parse and DCF77 refclock > > include/timespecops: Remove misleading definitions of the result > coding of the ternary comparison macros (the comments in that file are > still wrong).

Re: DCF77 driver seems to be broken

Eric S. Raymond writes: > Achim Gratz : >> It wasn't a timeout, but a reversed application of an offset and a wrong >> conversion of the resulting delta value as an absolute timestamp… sigh. >> Here's the full patch that restores the DCF77 driver to function. > > I'll apply this

Re: DCF77 driver seems to be broken

Achim Gratz writes: > So, while the above gets the code to recognize the refclock time again, > there's some timeout somewhere that makes the clock lose reach in the > time between each successful detection of the minute. That's probably > somewhere where a constant should now be multiplied by

Re: DCF77 driver seems to be broken

Achim Gratz writes: > I believe that the definition of timestamp_t as a union of timeval and > l_fp in parse.h is the root of these troubles. If some code somewhere > in parseclock assigns a timespec to that union instead, that would > overwrite some stuff past that memory, I think. That turned

Re: DCF77 driver seems to be broken

Achim Gratz writes: > Achim Gratz writes: > I believe that the definition of timestamp_t as a union of timeval and > l_fp in parse.h is the root of these troubles. If some code somewhere > in parseclock assigns a timespec to that union instead, that would > overwrite some stuff past that memory,

Re: DCF77 driver seems to be broken

Achim Gratz writes: > Eric S. Raymond writes: >> I'd revert this, but I didn't understand it well enough to avoid breaking it. >> Can you supply a fix patch? >> >> If not, file an issue and I'll give it a try. > > I'll first have to understand what all the original functions were doing > and then

Re: DCF77 driver seems to be broken

Yo Achim! On Sat, 18 Feb 2017 22:15:56 +0100 Achim Gratz wrote: > Gary E. Miller writes: > > There is nothing in C++, as defined by Stroustrup, that you can not > > do in C. > > You know, I've actually used Cfront and read all of Stroustrups books, > so please spare me

Re: DCF77 driver seems to be broken

Yo Achim! On Sat, 18 Feb 2017 21:30:33 +0100 Achim Gratz wrote: > Eric S. Raymond writes: > > I'd revert this, but I didn't understand it well enough to avoid > > breaking it. Can you supply a fix patch? > > > > If not, file an issue and I'll give it a try. > > I'll first

Re: DCF77 driver seems to be broken

Eric S. Raymond writes: > I'd revert this, but I didn't understand it well enough to avoid breaking it. > Can you supply a fix patch? > > If not, file an issue and I'll give it a try. I'll first have to understand what all the original functions were doing and then what the replacements do

Re: DCF77 driver seems to be broken

Achim Gratz : > Achim Gratz writes: > > This bisects to 96fff4a, although I have a hard time understanding why. > > Some of that seems to have been "prepared" in the commits running up to > > this. Anyway, the DCF77 driver thinks that each second is the last one > > in the

Re: DCF77 driver seems to be broken

Achim Gratz writes: > This bisects to 96fff4a, although I have a hard time understanding why. > Some of that seems to have been "prepared" in the commits running up to > this. Anyway, the DCF77 driver thinks that each second is the last one > in the minute after this commit landed. The latter

Re: DCF77 driver seems to be broken

Achim Gratz writes: > Was any work done on the parse refclock driver in the last half year or > so? It seems that the DCF77 driver based on it stopped working and the > symptoms are that the timecode is always just a single character. I'll > try to bisect that later, but maybe someone already

DCF77 driver seems to be broken

Was any work done on the parse refclock driver in the last half year or so? It seems that the DCF77 driver based on it stopped working and the symptoms are that the timecode is always just a single character. I'll try to bisect that later, but maybe someone already knows where this was