<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 11, 2017 at 12:54 PM, Jun Wu <span dir="ltr"><<a href="mailto:quark@fb.com" target="_blank">quark@fb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Pierre-Yves David's message of 2017-04-11 20:24:00 +0200:<br>
<span class="">><br>
> On 04/11/2017 07:49 PM, Bryan O'Sullivan wrote:<br>
> ><br>
> > On Tue, Apr 11, 2017 at 7:15 AM, Augie Fackler <<a href="mailto:raf@durin42.com">raf@durin42.com</a><br>
> > <mailto:<a href="mailto:raf@durin42.com">raf@durin42.com</a>>> wrote:<br>
> ><br>
> >     I'm missing some context. Why do we want timestamps in our output<br>
> >     like this?<br>
><br>
> This is useful to audit the timing of various steps when debugging (eg:<br>
> discovery, cache computations, etc…).<br>
><br>
> (I'm the one behind who motivated Mathieu to write this patch. I need<br>
> this feature on a regular basis)<br>
><br>
> > That's what the ts command gives us on Linux. I don't think this needs<br>
> > to be integrated into Mercurial proper.<br>
><br>
> Yes, `ts` can do this. However, piping to `ts` enable buffered output<br>
> for Python (and Mercurial). As a result the timestamp of line has no<br>
> relation with the time it was requested in the code. Sure one can<br>
> request non-buffered output, but at that point there start to be enough<br>
> obstacle than is get in the "complex" territory when requesting a trace<br>
> to a random user.<br>
<br>
</span>That's what `stdbuf` solves. I don't think the "ts" feature should be in<br>
core hg, either.<br>
<span class="im HOEnZb"><br>
><br>
> In addition, `tr` won't handle timestamp for buffered and remote output.<br>
><br>
> So I think this patches has value on its own.</span></blockquote><div><br></div><div>One thing that stdbuf + ts won't give you is correct handling of some terminal control characters, such as coloring. For example, Clang doesn't reset terminal attributes (sgr0) around newlines. So when piping `clang -fcolor-diagnostics` to ts (you need -fcolor-diagnostics b/c clang will turn off color when not writing to a TTY), the timestamps printed by ts will be using whatever attributes the last output was using. This can result in inconsistently colored and difficult-to-read output.</div><div><br></div><div>However, this deficiency does not apply to Mercurial, as color.colorlabel() splits by newline and resets terminal attributes during newline.</div><div><br></div><div>The only real benefit I see to having this feature in core is convenience, built-in support for coloring, and perhaps better integration with forensic logging. I'm -0 on this feature because I don't see a compelling need for it at this time.<br></div></div></div></div>