Mon, 18 May 2015 15:34:42 -0400 run-tests: resurrect the wifexited polyfill (backout 6ab5a1c9ea3c)
Matt Harbison <matt_harbison@yahoo.com> [Mon, 18 May 2015 15:34:42 -0400] rev 25177
run-tests: resurrect the wifexited polyfill (backout 6ab5a1c9ea3c) Python 2.7.3 on Windows doesn't have os.WIFEXITED, and the test output looked like this before I interrupted it. $ ./run-tests.py --local -j2 -t700 EEEEEEEEEEEEEEEEEEEEEE
Mon, 18 May 2015 02:53:08 +0900 tests: check import cycles in hgext/**.py, too
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 18 May 2015 02:53:08 +0900] rev 25176
tests: check import cycles in hgext/**.py, too It is important to realize existing cycles in hgext/**.py.
Mon, 18 May 2015 02:52:58 +0900 import-checker: don't treat modules as relative one if not found
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 18 May 2015 02:52:58 +0900] rev 25175
import-checker: don't treat modules as relative one if not found The previous patch ensures all module names are recorded in `imports` as absolute names, so we no longer need to treat modules as ones imported relatively from the target source if they appear to not be from the stdlib.
Mon, 18 May 2015 02:52:55 +0900 import-checker: make imported_modules yield absolute dotted_name_of_path
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 18 May 2015 02:52:55 +0900] rev 25174
import-checker: make imported_modules yield absolute dotted_name_of_path This patch makes `imported_modules()` always yield absolute `dotted_name_of_path()`-ed name by strict detection with `fromlocal()`. This change improves circular detection in some points: - locally defined modules, of which name collides against one of standard library, can be examined correctly For example, circular import related to `commands` is overlooked before this patch. - names not useful for circular detection are ignored Names below are also yielded before this patch: - module names of standard library (= not locally defined one) - non-module names (e.g. `node.nullid` of `from node import nullid`) These redundant names decrease performance of circular detection. For example, with files at 1ef96a3b8b89, average loops per file in `checkmod()` is reduced from 165 to 109. - `__init__` can be handled correctly in `checkmod()` For example, current implementation has problems below: - `from xxx import yyy` doesn't recognize `xxx.__init__` as imported - `xxx.__init__` imported via `import xxx` is treated as `xxx`, and circular detection is aborted, because `key` of such module name is not `xxx` but `xxx.__init__` - it is easy to enhance for `from . import xxx` style or so (in the future) Module name detection in `imported_modules()` can use information in `ast.ImportFrom` fully. It is assumed that all locally defined modules are correctly specified to `import-checker.py` at once. Strictly speaking, when `from foo.bar.baz import module1` imports `foo.bar.baz.module1` module, current `imported_modules()` yields only `foo.bar.baz.__init__`, even though also `foo.__init__` and `foo.bar.__init__` should be yielded to detect circular import exactly. But this limitation is reasonable one for improvement in this patch, because current `__init__` files in Mercurial seems to be implemented carefully.
Mon, 18 May 2015 02:50:22 +0900 import-checker: add utility to examine what module is imported easily
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 18 May 2015 02:50:22 +0900] rev 25173
import-checker: add utility to examine what module is imported easily `fromlocalfunc()` uses: - `modulename` (of the target source) to compose absolute module name imported relatively from it It is assumed that `modulename` is an `dotted_name_of_path()`-ed source file, which may have `.__init__` at the end of it. This assumption makes composing `prefix` of relative name easy. - `localmods` to examine whether there is a locally defined (= Mercurial specific) module matching against the specified name It is assumed that module names not existing in `localmods` are ones of Python standard library.
Mon, 18 May 2015 12:31:41 -0500 subrepo: further replacement of try/except with 'next'
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 18 May 2015 12:31:41 -0500] rev 25172
subrepo: further replacement of try/except with 'next' Burn StopIteration, Burn!
Mon, 18 May 2015 12:27:15 -0500 parsers: use 'next' instead of try/except
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 18 May 2015 12:27:15 -0500] rev 25171
parsers: use 'next' instead of try/except This get rid of another StopIteration abomination. The change in self.current value is supposed to not matter as nobody should be calling '_advance' after that (as per Matt wisdom).
Mon, 18 May 2015 12:22:44 -0500 dagparser: use 'next' instead of try/except for default value
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 18 May 2015 12:22:44 -0500] rev 25170
dagparser: use 'next' instead of try/except for default value "Ich liebe es wenn ein Plan funktioniert."
(0) -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip