Thu, 08 Jun 2017 01:38:48 +0100 profile: upgrade the "profile" context manager to a full class
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Jun 2017 01:38:48 +0100] rev 32783
profile: upgrade the "profile" context manager to a full class So far we have been able to use a simple decorator for this. However using the current context manager makes the scope of the profiling in dispatch constrainted and the time frame to decide to enable profiling quite limited (using "maybeprofile") This is the first step toward the ability to enable the profiling from within the profiling scope. eg:: with maybeprofiling(ui) as profiler: ... bar.foo(): ... if options['profile']: profiler.start() ... fooz() ... My target usecase is adding support for "--profile" to alias definitions with effect. These are to be used with "profiling.output=blackbox" to gather data about operation that get slow from time to time (eg: pull being minutes instead of seconds from time to time). Of course, in such case, the scope of the profiling would be smaller since profiler would be started after running extensions 'reposetup' (and other potentially costly logic), but these are not relevant for my target usecase (multiple second commits, multiple tens of seconds pull). Currently adding '--profile' to a command through alias requires to re-spin a Mercurial binary (using "!$HG" in alias), which as a significant performance impact, especially in context where startup performance is being worked on... An alternative approach would be to stop using the context manager in dispatch and move back to a try/finally setup.
Fri, 09 Jun 2017 22:15:53 -0400 setup: avoid linker warnings on Windows about multiple export specifications
Matt Harbison <matt_harbison@yahoo.com> [Fri, 09 Jun 2017 22:15:53 -0400] rev 32782
setup: avoid linker warnings on Windows about multiple export specifications The PyMODINIT_FUNC macro contains __declspec(dllexport), and then the build process adds an "/EXPORT func" to the command line. The 64-bit linker flags this [1]. Everything except zstd.c and bser.c are covered by redefining the macro in util.h [2]. These modules aren't built with util.h in the #include path, so the redefining hack would have to be open coded two more times. After seeing that extra_linker_flags didn't work, I couldn't find anything authoritative indicating why, though I did see an offhand comment on SO that CFLAGS is also ignored on Windows. I also don't fully understand the interaction between msvccompiler and msvc9compiler- I first subclassed the latter, but it isn't used when building with VS2008. I know the camelcase naming isn't the standard, but the HackedMingw32CCompiler class above it was introduced 5 years ago (and I think the current style was in place by then), so I assume that there's some reason for it. [1] https://support.microsoft.com/en-us/help/835326/you-receive-an-lnk4197-error-in-the-64-bit-version-of-the-visual-c-compiler [2] https://bugs.python.org/issue9709#msg120859
Sat, 10 Jun 2017 16:00:18 -0700 memctx: always use cache for filectxfn
Sean Farley <sean@farley.io> [Sat, 10 Jun 2017 16:00:18 -0700] rev 32781
memctx: always use cache for filectxfn I don't see a downside to doing this unless I'm missing something. Thanks to foozy for correcting my previous bad logic.
Sat, 10 Jun 2017 00:06:57 -0400 test-hardlinks: stabilize for Windows
Matt Harbison <matt_harbison@yahoo.com> [Sat, 10 Jun 2017 00:06:57 -0400] rev 32780
test-hardlinks: stabilize for Windows This broke in c2cb0de25120, which breaks hardlinks when the executable bit is toggled.
Sun, 04 Jun 2017 00:16:45 +0200 releasenotes: add more tests for formatting and merging of release notes
Rishabh Madan <rishabhmadan96@gmail.com> [Sun, 04 Jun 2017 00:16:45 +0200] rev 32779
releasenotes: add more tests for formatting and merging of release notes
Fri, 02 Jun 2017 23:33:30 +0200 releasenotes: command to manage release notes files
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 02 Jun 2017 23:33:30 +0200] rev 32778
releasenotes: command to manage release notes files Per discussion on the mailing list, we want better release notes for Mercurial. This patch introduces an extension that provides a command for producing release notes files. Functionality is implemented as an extension because it could be useful outside of the Mercurial project and because there is some code (like rst parsing) that already exists in Mercurial and it doesn't make sense to reinvent the wheel. The general idea with the extension is that changeset authors declare release notes in commit messages using rst directives. Periodically (such as at publishing or release time), a project maintainer runs `hg releasenotes` to extract release notes fragments from commit messages and format them to an auto-generated release notes file. More details are explained inline in docstrings. There are several things that need addressed before this is ready for prime time: * Moar tests * Interactive merge mode * Implement similarity detection for individual notes items * Support customizing section names/titles * Parsing improvements for bullet lists and paragraphs * Document which rst primitives can be parsed * Retain arbitrary content (e.g. header section/paragraphs) from existing release notes file * Better error messages (line numbers, hints, etc)
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip