On 04/13/2017 05:56 AM, Gregory Szorc wrote:
On Tue, Apr 11, 2017 at 12:54 PM, Jun Wu <qu...@fb.com <mailto:qu...@fb.com>> wrote: Excerpts from Pierre-Yves David's message of 2017-04-11 20:24:00 +0200: > > On 04/11/2017 07:49 PM, Bryan O'Sullivan wrote: > > > > On Tue, Apr 11, 2017 at 7:15 AM, Augie Fackler <r...@durin42.com <mailto:r...@durin42.com> > > <mailto:r...@durin42.com <mailto:r...@durin42.com>>> wrote: > > > > I'm missing some context. Why do we want timestamps in our output > > like this? > > This is useful to audit the timing of various steps when debugging (eg: > discovery, cache computations, etc…). > > (I'm the one behind who motivated Mathieu to write this patch. I need > this feature on a regular basis) > > > That's what the ts command gives us on Linux. I don't think this needs > > to be integrated into Mercurial proper. > > Yes, `ts` can do this. However, piping to `ts` enable buffered output > for Python (and Mercurial). As a result the timestamp of line has no > relation with the time it was requested in the code. Sure one can > request non-buffered output, but at that point there start to be enough > obstacle than is get in the "complex" territory when requesting a trace > to a random user. That's what `stdbuf` solves. I don't think the "ts" feature should be in core hg, either. > > In addition, `tr` won't handle timestamp for buffered and remote output. > > So I think this patches has value on its own. 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.
Actually, the simplest way to get hg to not buffer the pipe is to set PYTHONUNBUFFERED, so stdbuf bugs does not matters to much.
However, this deficiency does not apply to Mercurial, as color.colorlabel() splits by newline and resets terminal attributes during newline. 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.
Another elements is that windows users (with less performance love) do not have the 'ts' utility handy, so having our own feature would help them.
That changes is not critical to me for now. So I'm fine if we shelve this until we have a more compelling usecase.
Cheers, -- Pierre-Yves David _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
