Re: [PATCH 2 of 2 V2] show: implement underway view

On Sat, Apr 15, 2017 at 12:05 PM, Gregory Szorc wrote: > If someone sends a patch to rename to `hg show work` I'll try to use my > new patch queuing powers... > wip – for "work in progress"? ___ Mercurial-devel mailing list

[PATCH 8 of 9 v2] stdio: raise StdioError if something goes wrong in ui.flush

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1491947652 25200 # Tue Apr 11 14:54:12 2017 -0700 # Node ID 800f9ec2664e515d8ad807c0df1efaccda8ff5e5 # Parent fa74f393eaa5663b943eb0544ad4723ae7371385 stdio: raise StdioError if something goes wrong in ui.flush The

[PATCH 7 of 9 v2] stdio: raise StdioError if something goes wrong in ui._write_err

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1491947652 25200 # Tue Apr 11 14:54:12 2017 -0700 # Node ID fa74f393eaa5663b943eb0544ad4723ae7371385 # Parent e2a4bc13996100c5409f2e8561143e9fdad758a9 stdio: raise StdioError if something goes wrong in ui._wri

[PATCH 9 of 9 v2] stdio: add Linux-specific tests for error checking

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1491947652 25200 # Tue Apr 11 14:54:12 2017 -0700 # Node ID 19530f1d18bc0b6697f2996f089c614548f90269 # Parent 800f9ec2664e515d8ad807c0df1efaccda8ff5e5 stdio: add Linux-specific tests for error checking diff --git a

[PATCH 6 of 9 v2] stdio: raise StdioError if something goes wrong in ui._write

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1491947652 25200 # Tue Apr 11 14:54:12 2017 -0700 # Node ID e2a4bc13996100c5409f2e8561143e9fdad758a9 # Parent 942022da49166766fe4a7967b71411879221c197 stdio: raise StdioError if something goes wrong in ui._write diff

[PATCH 5 of 9 v2] stdio: catch StdioError in dispatch.run and clean up appropriately

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1491947652 25200 # Tue Apr 11 14:54:12 2017 -0700 # Node ID 942022da49166766fe4a7967b71411879221c197 # Parent a5aa1dfd9afed15c0cd762c4a72e5e0082ac074c stdio: catch StdioError in dispatch.run and clean up appropriate

[PATCH 2 of 9 v2] atexit: test failing handlers

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1491947652 25200 # Tue Apr 11 14:54:12 2017 -0700 # Node ID b35bc05e7a695ed8cdfd809070965ef9ea9266f9 # Parent f3a5157b39b32245b0bbcb9d7ac3ce7d9cbefde3 atexit: test failing handlers diff --git a/tests/test-bad-extensi

[PATCH 4 of 9 v2] stdio: add machinery to identify failed stdout/stderr writes

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1491947652 25200 # Tue Apr 11 14:54:12 2017 -0700 # Node ID a5aa1dfd9afed15c0cd762c4a72e5e0082ac074c # Parent c9e44f83b04ad81797891ba63b0fa4d1587880ea stdio: add machinery to identify failed stdout/stderr writes Mer

[PATCH 3 of 9 v2] atexit: switch to home-grown implementation

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1491947652 25200 # Tue Apr 11 14:54:12 2017 -0700 # Node ID c9e44f83b04ad81797891ba63b0fa4d1587880ea # Parent b35bc05e7a695ed8cdfd809070965ef9ea9266f9 atexit: switch to home-grown implementation diff --git a/c

[PATCH 1 of 9 v2] ui: add special-purpose atexit functionality

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1491947652 25200 # Tue Apr 11 14:54:12 2017 -0700 # Node ID f3a5157b39b32245b0bbcb9d7ac3ce7d9cbefde3 # Parent e0dc40530c5aa514feb6a09cf79ab6a3aa2ec331 ui: add special-purpose atexit functionality In spite

Re: [PATCH 5 of 9] stdio: catch StdioError in dispatch.run and clean up appropriately

On Tue, Apr 11, 2017 at 6:54 AM, Yuya Nishihara wrote: > 255 would be better, too. > Done. > > +if util.safehasattr(req.ui, 'ferr'): > > +if err is not None and err.errno != errno.EPIPE: > > +req.ui.ferr.write('abort: %s\n' % err.strerror) > > +

Re: [PATCH] ui: add optional timestamp to output

On Tue, Apr 11, 2017 at 7:15 AM, Augie Fackler wrote: > I'm missing some context. Why do we want timestamps in our output like > this? > That's what the ts command gives us on Linux. I don't think this needs to be integrated into Mercurial proper.

Re: [PATCH 1 of 9] atexit: add special-purpose atexit functionality to util

On Tue, Apr 11, 2017 at 6:48 AM, Yuya Nishihara wrote: > Perhaps -1 (= 255) would be better since 1 generally means expected > failure. > Sure. > > +finally: > > +if excinfo is not None: > > +raise excinfo[0], excinfo[1], excinfo[2] > > This breaks

Re: [PATCH 1 of 9] atexit: add special-purpose atexit functionality to util

On Mon, Apr 10, 2017 at 12:49 PM, Jun Wu wrote: > I wonder if it's better if the global state is moved to a > "dispatch.request" > or "ui" object. That may give threaded request handlers more confidence. > The new atexit code is only run during process exit. I was careful to

[PATCH 8 of 9] stdio: raise StdioError if something goes wrong in ui.flush

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1490915085 25200 # Thu Mar 30 16:04:45 2017 -0700 # Node ID fd3b4caa7c4fca4c7df1bdf9110ca0b8f56b1677 # Parent fdac23ea683f6b2b76885e3aafb9a6bdb53218ab stdio: raise StdioError if something goes wrong in ui.flush The

[PATCH 7 of 9] stdio: raise StdioError if something goes wrong in ui._write_err

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1490915085 25200 # Thu Mar 30 16:04:45 2017 -0700 # Node ID fdac23ea683f6b2b76885e3aafb9a6bdb53218ab # Parent 5134460363aeaac3c50f982c611a113344923155 stdio: raise StdioError if something goes wrong in ui._wri

[PATCH 9 of 9] stdio: add Linux-specific tests for error checking

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1490915085 25200 # Thu Mar 30 16:04:45 2017 -0700 # Node ID 0137657c5b5ffc114b4f654278b41a8e2d48ca93 # Parent fd3b4caa7c4fca4c7df1bdf9110ca0b8f56b1677 stdio: add Linux-specific tests for error checking diff --git a

[PATCH 3 of 9] atexit: switch to home-grown implementation

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1490804813 25200 # Wed Mar 29 09:26:53 2017 -0700 # Node ID c1a8ca31d3ade6c8bb0085008bdcf30593edd78f # Parent 77f74d955776d7eee5e6fe451f6fd94791a7b92f atexit: switch to home-grown implementation diff --git a/c

[PATCH 2 of 9] atexit: test failing handlers

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1490914978 25200 # Thu Mar 30 16:02:58 2017 -0700 # Node ID 77f74d955776d7eee5e6fe451f6fd94791a7b92f # Parent fdc0de79d651dccee118d19cb6b04f58d33a2727 atexit: test failing handlers diff --git a/tests/test-bad-extensi

[PATCH 6 of 9] stdio: raise StdioError if something goes wrong in ui._write

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1490915085 25200 # Thu Mar 30 16:04:45 2017 -0700 # Node ID 5134460363aeaac3c50f982c611a113344923155 # Parent 024364c1aa2e8b247d6156208394ebf01913f85a stdio: raise StdioError if something goes wrong in ui._write diff

[PATCH 1 of 9] atexit: add special-purpose atexit functionality to util

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1490914899 25200 # Thu Mar 30 16:01:39 2017 -0700 # Node ID fdc0de79d651dccee118d19cb6b04f58d33a2727 # Parent e0dc40530c5aa514feb6a09cf79ab6a3aa2ec331 atexit: add special-purpose atexit functionality to util In spite

[PATCH 5 of 9] stdio: catch StdioError in dispatch.run and clean up appropriately

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1490804813 25200 # Wed Mar 29 09:26:53 2017 -0700 # Node ID 024364c1aa2e8b247d6156208394ebf01913f85a # Parent 935d0e5af9001f3a0730e7c477dc14ae5baf4799 stdio: catch StdioError in dispatch.run and clean up appropriate

[PATCH 4 of 9] stdio: add machinery to identify failed stdout/stderr writes

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1490804813 25200 # Wed Mar 29 09:26:53 2017 -0700 # Node ID 935d0e5af9001f3a0730e7c477dc14ae5baf4799 # Parent c1a8ca31d3ade6c8bb0085008bdcf30593edd78f stdio: add machinery to identify failed stdout/stderr writes Mer

Re: [PATCH 2 of 3] lock: add ability to store additional metadata on filesytem

On Mon, Mar 20, 2017 at 12:49 AM, Phil Cohen wrote: > @@ -248,6 +253,7 @@ > if not self._parentheld: > try: > self.vfs.unlink(self.f) > +self.vfs.unlink(self.f + '.info') >

stdio handling is broken

For complicated historical reasons, Mercurial doesn't handle errors upon writes to stdout or stderr correctly. You can test this on a Linux box very easily. Correct behaviour involves trying to print an error message, followed by an error exit: $ /bin/echo a > /dev/full /bin/echo: write error:

Re: [PATCH 1 of 2] dispatch: move detection of profiling earlier during startup

On Fri, Feb 17, 2017 at 4:16 PM, Jun Wu wrote: > This breaks extensions that wraps maybeprofile, namely > fb-hgext/profiling.py which tries to log interactive time. > > That said, I think we could just remove profiling.py as Simon's change is > a > superior solution. > Breaking

Re: [PATCH] Make test suite more immune to environment variables

On Mon, Feb 20, 2017 at 9:27 AM, Dr Rainer Woitok wrote: > tests: make test suite more immune to environment variables > Good catch! ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org

Re: RFC: bitmap storage for precursors and phases

On Fri, Feb 17, 2017 at 10:30 AM, Jun Wu wrote: > Excerpts from Stanislau Hlebik's message of 2017-02-17 11:24:34 +: > > As I said before we will load all non-public revs in one set and all > > The problem is, loading a Python set from disk is O(size-of-the-set). > > Bitmap's

Re: [PATCH 1 of 8 v4] mercurial: use best available timer for perf measurements

On Thu, Feb 16, 2017 at 10:35 AM, Martin von Zweigbergk via Mercurial-devel wrote: > As discussed on #mercurial, Augie and I find "timer" confusing, > because it sounds like it returns a timer object, but in fact it just > returns a time. Can we have a followup

Re: [PATCH 10 of 10 v5] histedit: log the time taken to read in the commands list

On Wed, Feb 15, 2017 at 2:07 PM, Simon Farnsworth wrote: > histedit: log the time taken to read in the commands list > Series looks great. Ship it! ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org

Re: test-merge-changedelete.t fails with my hgmerge

On Tue, Feb 14, 2017 at 8:10 AM, timeless wrote: > Two points: > 1. The tests afaik are supposed to be self-contained. > 2. The error reporting here was incredibly unhelpful. I shouldn't have > to insert dozens of debug statements to find out that `hg merge` > called an

[PATCH 1 of 2] dispatch: move detection of profiling earlier during startup

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1487047460 28800 # Mon Feb 13 20:44:20 2017 -0800 # Node ID 82467bdb090b2500a97ae92e239bcdf72974f3f7 # Parent a0e3d808690d57d1c9dff840e0b8ee099526397b dispatch: move detection of profiling earlier during startup diff

[PATCH 2 of 2] dispatch: start profiling earlier

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1487047661 28800 # Mon Feb 13 20:47:41 2017 -0800 # Node ID fa6f486c80910c2a3ce6df58be0b8e616f2ae679 # Parent 82467bdb090b2500a97ae92e239bcdf72974f3f7 dispatch: start profiling earlier This makes it possible to p

Re: [PATCH 4 of 5 v2] statprof: allow rendering in the Chrome trace viewer format

On Mon, Feb 13, 2017 at 3:13 PM, Augie Fackler wrote: > My Rust brain was reading this code and was about to get puzzled that you > didn't use an enum and have these just be > fn write(, data, fp) -> Result<(), Error>. And then I got sad. > The code that makes you sad is a

Re: [PATCH 7 of 8 v4] extdiff: log time spent in external diff program

On Mon, Feb 13, 2017 at 10:25 AM, Simon Farnsworth wrote: > I want the caller to tell me what tag to apply to this blocking reason, so > that I can account for the blocking in hook.py (where it's running a > non-interactive process) and sshpeer.py (where it's network blocking as

Re: [PATCH 1 of 2] localrepo: cache self.changelog in local variable

On Mon, Feb 13, 2017 at 2:32 AM, Stanislau Hlebik wrote: > localrepo: cache self.changelog in local variable > > Repeated self.changelog lookups can incur overhead. Let's cache it in the > separate variable. > I'm not suggesting that you should change this since Yuya has already

Re: [PATCH 1 of 8 v4] mercurial: use best available timer for perf measurements

On Mon, Feb 13, 2017 at 9:29 AM, Simon Farnsworth wrote: > mercurial: use best available timer for perf measurements > Thanks for iterating on this patch series so quickly. After you're done with my latest round of comments, this series looks great to ship.

Re: [PATCH 7 of 8 v4] extdiff: log time spent in external diff program

On Mon, Feb 13, 2017 at 9:29 AM, Simon Farnsworth wrote: > +with ui.timeblockedsection('extdiff'): > +ui.system(cmdline, cwd=tmproot) > Why not simply instrument ui.system directly, and leave its callers untouched?

Re: [PATCH 8 of 8 v4] histedit: log the time taken to read in the commands list

On Mon, Feb 13, 2017 at 9:29 AM, Simon Farnsworth wrote: > histedit: log the time taken to read in the commands list > > If we're being fed an external command list (histedit --commands), then the > time spent reading that file is out of our control. Log it. > I don't think

Re: [PATCH 4 of 8 v4] ui: log time spent blocked on stdio

On Mon, Feb 13, 2017 at 9:29 AM, Simon Farnsworth wrote: > The perfwrite microbenchmark shifts to: > Linux: > ! wall 3.316087 comb 0.90 user 0.81 sys 0.09 (best of 3) > Mac: > ! wall 0.939282 comb 0.58 user 0.47 sys 0.11 (best of 8) > > If I open-code

Re: [PATCH 5 of 5 v2] profiling: add statprof support for Chrome trace viewer rendering

On Sun, Feb 12, 2017 at 10:39 PM, Bryan O'Sullivan <b...@serpentine.com> wrote: > profiling: add statprof support for Chrome trace viewer rendering > Here's an example screenshot of the Chrome trace viewer: http://imgur.com/gallery/I3Qmu And the trace data from which that was gene

[PATCH 3 of 5 v2] statprof: add a path simplification function

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1486966618 28800 # Sun Feb 12 22:16:58 2017 -0800 # Node ID 857b6377296f47a9504e482981c90303986108b6 # Parent 270342e743efcba76028840c357bb930cd1166f4 statprof: add a path simplification function diff --git a/mer

[PATCH 5 of 5 v2] profiling: add statprof support for Chrome trace viewer rendering

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1486967289 28800 # Sun Feb 12 22:28:09 2017 -0800 # Node ID 292f937ad6e36d6c8bfadec43ba07103ae75d04f # Parent 9c4ac8a20bd95c4069a20cf03a84b2c5c7b58def profiling: add statprof support for Chrome trace viewer renderi

[PATCH 4 of 5 v2] statprof: allow rendering in the Chrome trace viewer format

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1486966820 28800 # Sun Feb 12 22:20:20 2017 -0800 # Node ID 9c4ac8a20bd95c4069a20cf03a84b2c5c7b58def # Parent 857b6377296f47a9504e482981c90303986108b6 statprof: allow rendering in the Chrome trace viewer format diff

[PATCH 1 of 5 v2] ui: add a configwith method

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1486964446 28800 # Sun Feb 12 21:40:46 2017 -0800 # Node ID 0be0dffb7a83d1a973a0913230223cfd456a3148 # Parent a0e3d808690d57d1c9dff840e0b8ee099526397b ui: add a configwith method This is a long-overdue generali

[PATCH 2 of 5 v2] ui: rewrite configint in terms of configwith

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1486964695 28800 # Sun Feb 12 21:44:55 2017 -0800 # Node ID 270342e743efcba76028840c357bb930cd1166f4 # Parent 0be0dffb7a83d1a973a0913230223cfd456a3148 ui: rewrite configint in terms of configwith diff --git a/mer

[PATCH 1 of 5] ui: add a configwith method

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1486964446 28800 # Sun Feb 12 21:40:46 2017 -0800 # Node ID 0be0dffb7a83d1a973a0913230223cfd456a3148 # Parent a0e3d808690d57d1c9dff840e0b8ee099526397b ui: add a configwith method This is a long-overdue generali

[PATCH 3 of 4] statprof: add a path simplification function

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1486966618 28800 # Sun Feb 12 22:16:58 2017 -0800 # Node ID 857b6377296f47a9504e482981c90303986108b6 # Parent 270342e743efcba76028840c357bb930cd1166f4 statprof: add a path simplification function diff --git a/mer

[PATCH 2 of 4] ui: rewrite configint in terms of configwith

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1486964695 28800 # Sun Feb 12 21:44:55 2017 -0800 # Node ID 270342e743efcba76028840c357bb930cd1166f4 # Parent 0be0dffb7a83d1a973a0913230223cfd456a3148 ui: rewrite configint in terms of configwith diff --git a/mer

[PATCH 1 of 4] ui: add a configwith method

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1486964446 28800 # Sun Feb 12 21:40:46 2017 -0800 # Node ID 0be0dffb7a83d1a973a0913230223cfd456a3148 # Parent a0e3d808690d57d1c9dff840e0b8ee099526397b ui: add a configwith method This is a long-overdue generali

Re: [PATCH 1 of 8 v3] mercurial: use timeit.default_timer for interval measurement

On Sun, Feb 12, 2017 at 12:16 AM, Simon Farnsworth wrote: > It ends up more complex than that, because Python 3.3 introduces > time.perf_counter(), which ties into platform specific performance counters > where available to get a very high resolution clock. > Ah yes. That looks

Chrome tracing

I put together a proof of concept patch tonight that adds the ability to use light(ish)weight instrumentation to generate trace files that the Chrome trace tool can render. Here's a local clone --pull of Mercurial itself: http://i.imgur.com/efWjFyE.png And the corresponding trace file, so you

Re: [PATCH 3 of 8 v3] contrib: add a write microbenchmark to perf.py

On Fri, Feb 10, 2017 at 1:06 PM, Simon Farnsworth wrote: > +def write(): > +ui.write(('Testing write performance\n')) > You'll want to do this in a loop 10,000 times or something instead of just once, so that the numbers you get actually give you some idea of what's

Re: [PATCH 1 of 6 v2] ui: provide a mechanism to track and log blocked time

On Thu, Feb 9, 2017 at 1:52 PM, Simon Farnsworth wrote: > ui: provide a mechanism to track and log blocked time > I looked through the whole series, and it generally looks good. Could you please add a contrib/perf.py benchmark to measure the performance of ui.write with this

Re: [PATCH 1 of 6 v2] ui: provide a mechanism to track and log blocked time

On Thu, Feb 9, 2017 at 1:52 PM, Simon Farnsworth wrote: > > diff --git a/mercurial/dispatch.py b/mercurial/dispatch.py > --- a/mercurial/dispatch.py > +++ b/mercurial/dispatch.py > @@ -17,6 +17,7 @@ > import signal > import sys > import time > +import timeit > import

Re: [PATCH 1 of 3 pager-in-core-prep] pager: add a test of --pager=no functionality

On Tue, Feb 7, 2017 at 2:23 PM, Augie Fackler wrote: > These three patches are the prep work for a long series that moves > pager to core and makes it on by default. > These 3 look good. Thanks! ___ Mercurial-devel mailing list

Re: Gardening extensions

On Mon, Feb 6, 2017 at 1:45 PM, Kevin Bullock < kbullock+mercur...@ringworld.org> wrote: > > Both of these are still extensions because they enable history editing. I > recall discussions around moving these into core being predicated on evolve > going in first. But phases are already in core,

Gardening extensions

Not surprisingly, the pager extension isn't the only one in my sights at the moment. Here are a few others I've been thinking about. Proposals to move into core: * color - approaching its tenth anniversary, and widely used. * histedit - widely used for 5+ years. * rebase - almost a decode

Backwards compatibility before all else? [was Re: [PATCH v2] pager: migrate heavily-used extension into core]

On Sun, Feb 5, 2017 at 7:24 PM, Augie Fackler wrote: > > > I'm inclined to *not* add special code to see if the old pager extension > has been disabled. That's achievable by disabling the pager instead. This > would require a release note, of course (just in case anyone reads

[PATCH v3 rebased] pager: migrate heavily-used extension into core

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1486160890 28800 # Fri Feb 03 14:28:10 2017 -0800 # Node ID ae22925dafd4a270cb80a7bb54c9d70bce49a633 # Parent 1f51b4658f21bbb797e922d155c1046eddccf91d pager: migrate heavily-used extension into core No default beha

Re: [PATCH v2] pager: migrate heavily-used extension into core

On Mon, Feb 6, 2017 at 9:44 AM, Augie Fackler wrote: > Yes, we should definitely make pager easier to use. My own informal > surveys of users are that even a setting in hgrc would be better than an > extension, because there's a perception that an extension is somehow >

Re: [PATCH v2] pager: migrate heavily-used extension into core

On Sun, Feb 5, 2017 at 1:44 AM, Yuya Nishihara wrote: > I like the direction of this patch, but this still involves a behavior > change. If PAGER variable is set but pager extension disabled, pager will > be started wrongly. > I'm inclined to *not* add special code to see if the

[PATCH v2] pager: migrate heavily-used extension into core

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1486160890 28800 # Fri Feb 03 14:28:10 2017 -0800 # Node ID 30ee18bf947b97eca3582555f63eb3b2441e9db8 # Parent abf029200e198878a4576a87e095bd8d77d9cea9 pager: migrate heavily-used extension into core No default beha

Re: [PATCH 2 of 6 v2] util: add an elapsed time wrapper

On Fri, Feb 3, 2017 at 2:55 PM, Simon Farnsworth wrote: > We already capture start and exit times in the external wrapper process - > so your added detail of measuring "useful work" (in addition to "total > time") tells us if we're seeing a huge overhead in setup/teardown of >

Re: [PATCH] pager: migrate heavily-used extension into core

On Fri, Feb 3, 2017 at 2:28 PM, Bryan O'Sullivan <b...@serpentine.com> wrote: > pager: migrate heavily-used extension into core > This patch has a couple of bugs, but the basic idea remains the same even after they're fixed, so review away :-) The changes are all code motion,

Re: [PATCH 2 of 6 v2] util: add an elapsed time wrapper

On Fri, Feb 3, 2017 at 2:26 PM, Simon Farnsworth wrote: I'd assumed that with Mercurial encouraging extension authors to wrap > functions, the overhead wasn't significant. Well, those functions are usually called just a tiny handful of times, so that tends to be true in those

[PATCH] pager: migrate heavily-used extension into core

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1486160890 28800 # Fri Feb 03 14:28:10 2017 -0800 # Node ID a4d9e5c20bd72caefcc8efe29a46b6a31a816606 # Parent abf029200e198878a4576a87e095bd8d77d9cea9 pager: migrate heavily-used extension into core No default beha

Re: [PATCH 2 of 2] ui: record and print wall clock time

On Thu, Feb 2, 2017 at 4:33 PM, Bryan O'Sullivan <b...@serpentine.com> wrote: > ui: record and print wall clock time > This patch is a total hack, but it contains an interesting few nuggets that it doesn't call out explicitly. As Simon mentions in one of his patches, we log command

[PATCH 1 of 2] ui: track time spent reading and writing

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1486062596 28800 # Thu Feb 02 11:09:56 2017 -0800 # Node ID 61c6d4a49500f37aca3a7ae58b83d43c64eaa846 # Parent abf029200e198878a4576a87e095bd8d77d9cea9 ui: track time spent reading and writing diff --git a/mercurial/u

[PATCH 2 of 2] ui: record and print wall clock time

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1486062809 28800 # Thu Feb 02 11:13:29 2017 -0800 # Node ID 97f1791e99b8def3903b8e287c6192f17fbf0151 # Parent 61c6d4a49500f37aca3a7ae58b83d43c64eaa846 ui: record and print wall clock time diff --git a/mercurial/dispa

Re: [PATCH 1 of 6 v2] pager: don't terminate with extreme prejudice on SIGPIPE (BC)

On Thu, Feb 2, 2017 at 11:18 AM, Simon Farnsworth wrote: > pager: don't terminate with extreme prejudice on SIGPIPE (BC) > Looks good! ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org

Re: [PATCH 2 of 6 v2] util: add an elapsed time wrapper

On Thu, Feb 2, 2017 at 11:18 AM, Simon Farnsworth wrote: > util: add an elapsed time wrapper > To be honest, this seems like a heavily over-engineered approach to me. As it happens, I've got a less mature patch set in the same space, which I'll put out as an RFC within the

Re: Better release notes

On Thu, Feb 2, 2017 at 10:53 AM, Gregory Szorc wrote: > I think some of the goals should be: > > * Call out major new features, preferably with a user story around them > * Prune out changes not relevant to end users > * Actually document minor new features (e.g. "patch:

[PATCH] keepalive: drop check for unsupported version of Python

# HG changeset patch # User Bryan O'Sullivan <bry...@fb.com> # Date 1480437473 28800 # Tue Nov 29 08:37:53 2016 -0800 # Node ID 540fa940cd226021726c27475d4754cbf70246e4 # Parent 6a8aff737a17ada068b8ce4501184eacc66e827f keepalive: drop check for unsupported version of Python diff

Re: [PATCH 2 of 2] worker: use os._exit for posix worker in all cases

On Wed, Nov 23, 2016 at 5:17 PM, Jun Wu wrote: > worker: use os._exit for posix worker in all cases > This looks good to me. Thanks! ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org

Re: Fixing .hg file open ordering

Yep, your reasoning here makes sense. While I'm glad that you discovered after some investigation that we're doing the right thing already, it's a little troubling that this wasn't easy to understand from reading the code, and that (from my interpretation of what you wrote) you had to think and

Re: Fixing .hg file open ordering

On Wed, Nov 2, 2016 at 3:30 PM, Durham Goode wrote: > Bookmark writes are now within the wlock, and any inmemory read you did > prior to taking the lock will be invalidated (during the next > repo._bookmarks access) and thrown away when you take the lock. So once > you're in the

Re: Fixing .hg file open ordering

There's long been a well-defined order for accessing historical data: changelog first, then manifest, then revlog, and the reverse for writes. I think that what has happened with bookmarks is that we literally forgot about the next necessary ordering constraint: you must read bookmarks before the

Re: [PATCH V3] update: warn if cwd was deleted

You are performing these getcwd calls inside what should be a fast inner loop. This is going to dramatically slow the common case down by doing a whole lot of redundant work. All you need to do to fix this is check getcwd once before the loop begins, and then again after it ends. On Mon, Sep 5,

Re: RFC: bitmap storage for hidden

I agree that it would make a lot of sense to not use a plain bitmap. The current state of the art for compressed high-performance bitmaps is here: http://roaringbitmap.org/ On Fri, Sep 2, 2016 at 8:09 AM, Augie Fackler wrote: > I've considered doing a bitmap index for hidden

Re: zstd experimentations

It would be valuable to target a general-purpose package, if only because the existing Python zstd bindings (somewhere on github) are not good. You're right that zstd is a big win over zlib in every way. On Thu, Sep 1, 2016 at 12:01 AM, Gregory Szorc wrote: > I got