Sat, 24 Feb 2018 12:24:03 -0800 util: enable observing of util.bufferedinputpipe
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 24 Feb 2018 12:24:03 -0800] rev 36525
util: enable observing of util.bufferedinputpipe Our file object proxy is useful. But it doesn't capture all I/O. The "os" module offers low-level interfaces to various system calls. For example, os.read() exposes read(2) to read from a file descriptor. bufferedinputpipe is special in a few ways. First, it acts as a proxy of sorts around our [potentially proxied] file object. In addition, it uses os.read() to satisfy all I/O. This means that our observer doesn't see notifications for reads on this type. This is preventing us from properly instrumenting reads on ssh peers. This commit teaches bufferedinputpipe to be aware of our observed file objects. We do this by introducing a class variation that notifies our observer of os.read() events. Since read() and readline() bypass os.read(), we also teach this instance to notify the observer for buffered variations of these reads as well. We don't report them as actual read() and readline() calls because these methods are never called on the actual file object but rather a buffered version of it. We introduce bufferedinputpipe.__new__ to swap in the new class if the passed file object is a fileobjectproxy. This makes hooking up the observer automatic. And it is a zero cost abstraction for I/O operations on non-proxied file objects. Differential Revision: https://phab.mercurial-scm.org/D2404
Sat, 24 Feb 2018 12:22:20 -0800 util: add a file object proxy that can notify observers
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 24 Feb 2018 12:22:20 -0800] rev 36524
util: add a file object proxy that can notify observers There are various places in Mercurial where we may want to instrument low-level I/O. The use cases I can think of all involve development-type activities like monitoring the raw bytes passing through a file (for testing and debugging), counting the number of I/O function calls (for performance monitoring), and changing the behavior of I/O function calls (e.g. simulating a failure) (to facilitate testing). This commit invents a mechanism to wrap a file object so we can observe activity on it. We have similar functionality in badserverext.py. But that's a test-only extension and is pretty specific to the HTTP server. I would like a mechanism in core that is sufficiently generic so it can be used by multiple consumers, including `hg debug*` commands. The added code consists of a proxy type for file objects. It is bound to an "observer," which receives callbacks whenever I/O methods are called. We also add an implementation of an observer that logs specific I/O events. This observer will be used in an upcoming commit to record low-level wire protocol activity. A helper function to convert a file object into an observed file object has also been implemented. I don't anticipate any critical functionality in core using these types. So I don't think explicit test coverage is worth implementing. Differential Revision: https://phab.mercurial-scm.org/D2462
Sat, 24 Feb 2018 12:07:21 -0800 wireprotoserver: ability to run an SSH server until an event is set
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 24 Feb 2018 12:07:21 -0800] rev 36523
wireprotoserver: ability to run an SSH server until an event is set It seems useful to be able to start an SSH protocol server that won't run forever and won't call sys.exit() when it stops. This could be used to facilitate intra-process testing of the SSH protocol, for example. We teach the server function to loop until a threading.Event is set and invent a new API to run the server until an event is set. It also won't sys.exit() afterwards. There aren't many callers of serve_forever(). So we could refactor them relatively easily. But I was lazy. threading.Event might be a bit heavyweight. An alternative would be a list whose only elements is changed. We can't use a simple scalar value like a bool or int because those types are immutable. Events are what you use in systems programming for this use case, so the use of threading.Event seems justified. Differential Revision: https://phab.mercurial-scm.org/D2461
Thu, 01 Mar 2018 15:46:21 -0500 tests: fix run-tests environment cleanup on Python 3
Augie Fackler <augie@google.com> [Thu, 01 Mar 2018 15:46:21 -0500] rev 36522
tests: fix run-tests environment cleanup on Python 3 Differential Revision: https://phab.mercurial-scm.org/D2521
Sun, 25 Feb 2018 16:14:37 +0900 templatekw: add compatlist() as a replacement for showlist()
Yuya Nishihara <yuya@tcha.org> [Sun, 25 Feb 2018 16:14:37 +0900] rev 36521
templatekw: add compatlist() as a replacement for showlist() Just like compatdict(), this is mostly a copy of showlist(). showchildren() is ported to the new API as an example.
Sun, 25 Feb 2018 16:03:19 +0900 templatekw: add compatdict() as a replacement for showdict()
Yuya Nishihara <yuya@tcha.org> [Sun, 25 Feb 2018 16:03:19 +0900] rev 36520
templatekw: add compatdict() as a replacement for showdict() This is mostly a copy of showdict(), which will be deprecated later. See the docstring for why it's called a "compat" dict. showenvvars() is ported to the new API as an example.
Sun, 25 Feb 2018 15:43:35 +0900 templatekw: pass templater to _showlist() by an explicit argument
Yuya Nishihara <yuya@tcha.org> [Sun, 25 Feb 2018 15:43:35 +0900] rev 36519
templatekw: pass templater to _showlist() by an explicit argument Prepares for switching to the (context, mapping) API.
Fri, 22 Dec 2017 21:59:38 +0900 hgweb: make templater mostly compatible with log templates
Yuya Nishihara <yuya@tcha.org> [Fri, 22 Dec 2017 21:59:38 +0900] rev 36518
hgweb: make templater mostly compatible with log templates Prepares for gradually switching templatekw.showsuccsandmarkers() to new API. This was a PoC showing how to reuse templatekw functions in hgweb. We could remove rev, node, author, etc. from the commonentry() table, but we'll have to carefully remove all corresponding symbols from webcommands.*(). Otherwise, we would face the issue5612. Still templatekw.keywords aren't exported. Otherwise some tests would fail because the atom template expects {files} to be empty in filelog, but templatekw.showfiles() provides the {files} implementation.
Sun, 25 Feb 2018 14:42:18 +0900 log: do not invoke templatekw.showobsfate() as a function
Yuya Nishihara <yuya@tcha.org> [Sun, 25 Feb 2018 14:42:18 +0900] rev 36517
log: do not invoke templatekw.showobsfate() as a function Prepares for switching to the (context, mapping) API. I tried, but it appeared not an one-off change to extract a non-template function from showobsfate(), which deeply depends on the templater internals.
Sun, 25 Feb 2018 16:36:38 +0900 templatekw: inline getfiles()
Yuya Nishihara <yuya@tcha.org> [Sun, 25 Feb 2018 16:36:38 +0900] rev 36516
templatekw: inline getfiles() It's just three lines. We don't need a separate function for that.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip