[PATCH] ui: add optional timestamp to output
pierre-yves.david at ens-lyon.org
Fri Apr 14 18:07:38 EDT 2017
On 04/13/2017 05:56 AM, Gregory Szorc wrote:
> On Tue, Apr 11, 2017 at 12:54 PM, Jun Wu <quark at fb.com
> <mailto:quark at 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 <raf at durin42.com <mailto:raf at durin42.com>
> > > <mailto:raf at durin42.com <mailto:raf at 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
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.
More information about the Mercurial-devel