>> Yea, I have the same conclusions. Maybe just a toy NTP client that
>> compared one peer or refclock to the sysclock? Then compare that to what
>> the local ntpd thinks about the sysclock.
> No, because, agauin, that's not far short of the real thing.
There is a lot of wiggle room in "toy cl
Hal Murray :
>
> e...@thyrsus.com said:
> > I still don't understand that suggestion at all. Would it be implementing
> > the Byzantine time=sync algorithms? If so, howe is it simple?
>
> No. That's what makes it simple.
>
> > I guess I need to see something more like a functional spec for yo
Gary E. Miller :
> Yea, I have the same conclusions. Maybe just a toy NTP client that
> compared one peer or refclock to the sysclock? Then compare that to what
> the local ntpd thinks about the sysclock.
>
> No simple way forward...
No, because, agauin, that's not far short of the real thing.
e...@thyrsus.com said:
> I still don't understand that suggestion at all. Would it be implementing
> the Byzantine time=sync algorithms? If so, howe is it simple?
No. That's what makes it simple.
> I guess I need to see something more like a functional spec for your
> concept. It sounds like
Yo Eric!
On Wed, 8 Nov 2017 15:15:38 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller :
> > You're the expert at this. I believe it might not be bad for you to
> > do. But you would prolly like some help from others less expert.
>
> An easy task for non-experts would be porting tests.
I'd h
Hal Murray via devel :
>
> eric said:
> > Do you have any suggestions about a test target? I've been giving that some
> > thought, and it's not easy to come up with anything that I think has close
> > to the same near-realtime constraints as ntpd.
>
> How about the simple ntpd server I suggeste
eric said:
> Do you have any suggestions about a test target? I've been giving that some
> thought, and it's not easy to come up with anything that I think has close
> to the same near-realtime constraints as ntpd.
How about the simple ntpd server I suggested a few days ago?
Even if you can't
Gary E. Miller :
> You're the expert at this. I believe it might not be bad for you to
> do. But you would prolly like some help from others less expert.
An easy task for non-experts would be porting tests.
> And I'd like to see something small converted first, something that
> can allow us to
Yo Eric!
On Wed, 8 Nov 2017 05:03:57 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > So then what? Any alternatives? Translating by hand would be a
> > PITA and error prone. Rewriting from scratch even worse.
>
> I was assuming we'd do translation by hand with acript assist
On 11/07/2017 11:01 PM, Eric S. Raymond via devel wrote:
> The problem is that the hard parts of language translation really need a
> parser making an AST (Augmented Syntax Tree), then a transformation on the
> AST generating a report in the target syntax. That's what you hit in the
> last 15% - i
Gary E. Miller via devel :
> So then what? Any alternatives? Translating by hand would be a PITA and
> error prone. Rewriting from scratch even worse.
I was assuming we'd do translation by hand with acript assistence.
But that's not as bad as you might think it would be.
The reason is this: wh
Yo Eric!
On Tue, 7 Nov 2017 23:01:43 -0500
"Eric S. Raymond" wrote:
> The Go guys gave up. They were almost certainly rightv to do so.
OK.
> We should not expect c2go to be helpful.
So then what? Any alternatives? Translating by hand would be a PITA and
error prone. Rewriting from scratch
Gary E. Miller via devel :
> Maybe simple, maybe not, Maybe someone with Go skills has a clue?
Go skills aren't going to help. Those error messages are quite revealing - they
hint strongly that the translation is done by running a buttload of regexp
transformations on the input source code.
I'm
13 matches
Mail list logo
