Tue, 14 Jan 2020 17:08:45 +0100 rust-utils: add `Escaped` trait
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 17:08:45 +0100] rev 44315
rust-utils: add `Escaped` trait This will be used as a general interface for displaying things to the user. The upcoming `IncludeMatcher` will use it to store its patterns in a user-displayable string. Differential Revision: https://phab.mercurial-scm.org/D7870
Tue, 14 Jan 2020 17:04:32 +0100 rust-dirs-multiset: add `DirsChildrenMultiset`
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 17:04:32 +0100] rev 44314
rust-dirs-multiset: add `DirsChildrenMultiset` In a future patch, this structure will be needed to store information needed by the (also upcoming) `IgnoreMatcher`. Differential Revision: https://phab.mercurial-scm.org/D7869
Tue, 14 Jan 2020 16:50:35 +0100 rust-hg-path: add useful methods to `HgPath`
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 16:50:35 +0100] rev 44313
rust-hg-path: add useful methods to `HgPath` This changeset introduces the use of the `pretty_assertions` crate for easier to read test output. Differential Revision: https://phab.mercurial-scm.org/D7867
Wed, 05 Feb 2020 17:05:37 +0100 rust-pathauditor: add Rust implementation of the `pathauditor`
Raphaël Gomès <rgomes@octobus.net> [Wed, 05 Feb 2020 17:05:37 +0100] rev 44312
rust-pathauditor: add Rust implementation of the `pathauditor` It does not offer the same flexibility as the Python implementation, but should check incoming paths just as well. Differential Revision: https://phab.mercurial-scm.org/D7866
Wed, 22 Jan 2020 03:17:06 +0530 py3: catch AttributeError too with ImportError
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 22 Jan 2020 03:17:06 +0530] rev 44311
py3: catch AttributeError too with ImportError Looks like py3 raises AttributeError instead of ImportError. This is caught on windows. Differential Revision: https://phab.mercurial-scm.org/D7965
Wed, 05 Feb 2020 15:15:18 -0500 context: use manifest.walk() instead of manifest.match() to get file list
Augie Fackler <augie@google.com> [Wed, 05 Feb 2020 15:15:18 -0500] rev 44310
context: use manifest.walk() instead of manifest.match() to get file list The former doesn't create a whole extra manifest in order to produce the matching file list, which is all we actually cared about here. Sigh. Differential Revision: https://phab.mercurial-scm.org/D8080
Wed, 05 Feb 2020 15:01:22 -0500 manifest: remove `.new()` from the interface
Augie Fackler <augie@google.com> [Wed, 05 Feb 2020 15:01:22 -0500] rev 44309
manifest: remove `.new()` from the interface Nothing used it. Differential Revision: https://phab.mercurial-scm.org/D8079
Wed, 29 Jan 2020 13:39:50 -0800 chg: force-set LC_CTYPE on server start to actual value from the environment
Kyle Lippincott <spectral@google.com> [Wed, 29 Jan 2020 13:39:50 -0800] rev 44308
chg: force-set LC_CTYPE on server start to actual value from the environment Python 3.7+ will "coerce" the LC_CTYPE variable in many instances, and this can cause issues with chg being able to start up. D7550 attempted to fix this, but a combination of a misreading of the way that python3.7 does the coercion and an untested state (LC_CTYPE being set to an invalid value) meant that this was still not quite working. This change will cause differences between chg and hg: hg will have the LC_CTYPE environment variable coerced, while chg will not. This is unlikely to cause any detectable behavior differences in what Mercurial itself outputs, but it does have two known effects: - When using hg, the coerced LC_CTYPE will be passed to subprocesses, even non-python ones. Using chg will remove the coercion, and this will not happen. This is arguably more correct behavior on chg's part. - On macOS, if you set your region to Brazil but your language to English, this isn't representable in locale strings, so macOS sets LC_CTYPE=UTF-8. If this value is passed along when ssh'ing to a non-macOS machine, some functions (such as locale.setlocale()) may raise an exception due to an unsupported locale setting. This is most easily encountered when doing an interactive commit/split/etc. when using ui.interface=curses. Differential Revision: https://phab.mercurial-scm.org/D8039
Mon, 03 Feb 2020 09:00:05 +0100 perf: fix list formatting in perfindex documentation
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 03 Feb 2020 09:00:05 +0100] rev 44307
perf: fix list formatting in perfindex documentation Differential Revision: https://phab.mercurial-scm.org/D8067
Sat, 01 Feb 2020 09:14:36 +0100 test: simplify test-amend.t to avoid race condition
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 01 Feb 2020 09:14:36 +0100] rev 44306
test: simplify test-amend.t to avoid race condition Insted on relying on sleep, we could simply have the editor do the file change. This remove the reliance on "sleep" and avoid test failing on heavy load machine. To test this, I reverted the code change in 5558e3437872 and the test started failing again. Differential Revision: https://phab.mercurial-scm.org/D8065
Fri, 13 Dec 2019 11:32:36 +0100 test: document test-copy-move-merge.t
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 13 Dec 2019 11:32:36 +0100] rev 44305
test: document test-copy-move-merge.t Differential Revision: https://phab.mercurial-scm.org/D8077
Mon, 03 Feb 2020 22:16:36 -0500 manifest: remove optional default= argument on flags(path)
Augie Fackler <augie@google.com> [Mon, 03 Feb 2020 22:16:36 -0500] rev 44304
manifest: remove optional default= argument on flags(path) It had only one caller inside manifest.py, and treemanifest was actually incorrectly implemented. treemanifest is still missing the fastdelta() method from the interface (and so doesn't yet conform), but this is at least progress. Differential Revision: https://phab.mercurial-scm.org/D8069
Mon, 03 Feb 2020 11:56:02 -0500 resourceutil: blacken
Augie Fackler <augie@google.com> [Mon, 03 Feb 2020 11:56:02 -0500] rev 44303
resourceutil: blacken
Mon, 03 Feb 2020 11:51:52 -0500 merge with stable
Augie Fackler <augie@google.com> [Mon, 03 Feb 2020 11:51:52 -0500] rev 44302
merge with stable
Fri, 31 Jan 2020 10:53:50 -0800 rebase: abort if the user tries to rebase the working copy
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 Jan 2020 10:53:50 -0800] rev 44301
rebase: abort if the user tries to rebase the working copy I think it's more correct to treat `hg rebase -r 'wdir()' -d foo` as `hg co -m foo`, but I'm instead making it error out. That's partly because it's probably what the user wanted (in the case I heard from a user, they had done `hg rebase -s f` where `f` resolved to `wdir()`) and partly because I don't want to think about more complicated cases where the user specifies the working copy together with other commits. Differential Revision: https://phab.mercurial-scm.org/D8057
Fri, 31 Jan 2020 10:41:50 -0800 tests: add tests for rebasing wdir() revision
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 Jan 2020 10:41:50 -0800] rev 44300
tests: add tests for rebasing wdir() revision Differential Revision: https://phab.mercurial-scm.org/D8056
Wed, 22 Jan 2020 13:29:26 -0800 merge: when rename was made on both sides, use ancestor as merge base
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 13:29:26 -0800] rev 44299
merge: when rename was made on both sides, use ancestor as merge base When both sides of a merge have renamed a file to the same place, we would treat that as a "both created" action in merge.py. That means that we'd use an empty diffbase. It seems better to use the copy source as diffbase. That can be done by simply dropping code that prevented us from doing that. I think I did it that way in 57203e0210f8 (copies: calculate mergecopies() based on pathcopies(), 2019-04-11) only to preserve the existing behavior. I also suspect it was just an accident that it behaved that way before that commit. Note that until fa9ad1da2e77 (merge: start using the per-side copy dicts, 2020-01-23), it was non-deterministic (depending on iteration order of the `allsources` set in `copies._fullcopytracing()`) which source was used in the affected test case in test-rename-merge1.t. We could easily have fixed that by sorting them, but now we can instead detect the case (the TODO added in the previous patch). Differential Revision: https://phab.mercurial-scm.org/D7974
Fri, 31 Jan 2020 08:47:32 -0800 absorb: graduate -i flag from experimental
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 Jan 2020 08:47:32 -0800] rev 44298
absorb: graduate -i flag from experimental The interactive mode seems to work well. I have previously thought that `-i` should be what `-e` does, but the current behavior matches what other `-i` flags do (select a subset of the hunks), so I think that is what we want. Differential Revision: https://phab.mercurial-scm.org/D8055
Sat, 25 Jan 2020 17:30:24 +0900 rust-cpython: remove PySharedRefCell and its companion structs
Yuya Nishihara <yuya@tcha.org> [Sat, 25 Jan 2020 17:30:24 +0900] rev 44297
rust-cpython: remove PySharedRefCell and its companion structs Also updates py_shared_iterator!() documentation accordingly.
Sat, 25 Jan 2020 17:26:23 +0900 rust-cpython: switch to upstreamed version of PySharedRefCell
Yuya Nishihara <yuya@tcha.org> [Sat, 25 Jan 2020 17:26:23 +0900] rev 44296
rust-cpython: switch to upstreamed version of PySharedRefCell Our PyLeaked is identical to cpython::UnsafePyLeaked. I've renamed it because it provides mostly unsafe functions.
Sat, 25 Jan 2020 17:21:06 +0900 rust-cpython: rename inner_shared() to inner()
Yuya Nishihara <yuya@tcha.org> [Sat, 25 Jan 2020 17:21:06 +0900] rev 44295
rust-cpython: rename inner_shared() to inner() The "shared" accessor will be automatically generated, and will have the same name as the data itself.
Fri, 31 Jan 2020 00:08:30 +0900 rust-cpython: use PyList.insert() instead of .insert_item()
Yuya Nishihara <yuya@tcha.org> [Fri, 31 Jan 2020 00:08:30 +0900] rev 44294
rust-cpython: use PyList.insert() instead of .insert_item() Silences the deprecated warning. https://github.com/dgrunwald/rust-cpython/commit/e8cbe864841714c5555db8c90e057bd11e360c7f
Fri, 31 Jan 2020 00:01:29 +0900 rust-cpython: bump cpython to 0.4 to switch to upstreamed PySharedRef
Yuya Nishihara <yuya@tcha.org> [Fri, 31 Jan 2020 00:01:29 +0900] rev 44293
rust-cpython: bump cpython to 0.4 to switch to upstreamed PySharedRef
Thu, 30 Jan 2020 23:57:19 +0900 rust: update dependencies
Yuya Nishihara <yuya@tcha.org> [Thu, 30 Jan 2020 23:57:19 +0900] rev 44292
rust: update dependencies For no particular reason, but just because I'll bump the rust-cpython version.
Fri, 24 Jan 2020 12:50:27 +0100 contrib: a small script to nudge lingering diff
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 24 Jan 2020 12:50:27 +0100] rev 44291
contrib: a small script to nudge lingering diff After a discussion on IRC with various reviewers. It seems like a good idea to have some automatic cleanup of old, inactive diffs. Here is a small script able to do so. I am preparing to unleash it on our phabricator instance.
Sun, 26 Jan 2020 16:23:57 -0800 packaging: add support for PyOxidizer
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 26 Jan 2020 16:23:57 -0800] rev 44290
packaging: add support for PyOxidizer I've successfully built Mercurial on the development tip of PyOxidizer on Linux and Windows. It mostly "just works" on Linux. Windows is a bit more finicky. In-memory resource files are probably not all working correctly due to bugs in PyOxidizer's naming of modules. PyOxidizer now now supports installing files next to the produced binary. (We do this for templates in the added file.) So a workaround should be available. Also, since the last time I submitted support for PyOxidizer, PyOxidizer gained the ability to auto-generate Rust projects to build executables. So we don't need to worry about vendoring any Rust code to initially support PyOxidizer. However, at some point we will likely want to write our own command line driver that embeds a Python interpreter via PyOxidizer so we can run Rust code outside the confines of a Python interpreter. But that will be a follow-up. I would also like to add packaging.py CLI commands to build PyOxidizer distributions. This can come later, if ever. PyOxidizer's new "targets" feature makes it really easy to define packaging tasks in its Starlark configuration file. While not much is implemented yet, eventually we should be able to produce MSIs, etc using a `pyoxidizer build` one-liner. We'll get there... Differential Revision: https://phab.mercurial-scm.org/D7450
Wed, 29 Jan 2020 11:30:16 -0800 mergestate: add accessors for local and other nodeid, not just contexts
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Jan 2020 11:30:16 -0800] rev 44289
mergestate: add accessors for local and other nodeid, not just contexts The mergestate can contain invalid nodeids. In that case, `mergestate.localctx` or `mergestate.otherctx` will fail. This patch provides a way of accessing the nodeid without failing in such cases. Differential Revision: https://phab.mercurial-scm.org/D8040
Wed, 15 Jan 2020 22:24:16 -0800 rebase: define base in only place in defineparents()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 22:24:16 -0800] rev 44288
rebase: define base in only place in defineparents() Just a little refactoring to prepare for the next patch. Differential Revision: https://phab.mercurial-scm.org/D7906
Fri, 20 Dec 2019 16:16:57 -0800 tests: use full `uncommit` command name in tests
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Dec 2019 16:16:57 -0800] rev 44287
tests: use full `uncommit` command name in tests I'm about to add a `hg uncopy`, so the `hg unc` we used for `hg uncommit` would become ambiguous. Differential Revision: https://phab.mercurial-scm.org/D8028
Tue, 28 Jan 2020 14:53:23 -0800 graft: default `base` argument to common case of `ctx.p1()`
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Jan 2020 14:53:23 -0800] rev 44286
graft: default `base` argument to common case of `ctx.p1()` I also updated the callers that wanted that, partly to simplify and partly to show that it works. Differential Revision: https://phab.mercurial-scm.org/D8027
Fri, 10 Jan 2020 13:12:24 -0800 graft: let caller pass in overlayworkingctx to merge.graft()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 13:12:24 -0800] rev 44285
graft: let caller pass in overlayworkingctx to merge.graft() Passing in a different `wctx` than `repo[None]` is useful because it allows the caller to decide to not touch the working directory. Differential Revision: https://phab.mercurial-scm.org/D8026
Wed, 29 Jan 2020 23:14:31 -0800 copies: fix crash when copy source is not in graft base
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Jan 2020 23:14:31 -0800] rev 44284
copies: fix crash when copy source is not in graft base Differential Revision: https://phab.mercurial-scm.org/D8046
Wed, 29 Jan 2020 23:05:02 -0800 tests: add test showing crash when shelving ghosted rename target
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Jan 2020 23:05:02 -0800] rev 44283
tests: add test showing crash when shelving ghosted rename target When you `hg rename` a file and then delete the rename target, `hg shelve` will give you a traceback. Note that the shelve succeeds and the shelve is correct, it's just the update to the parent that fails (i.e. to the parent of the commit that was created for the shelve). This can be squashed into the next commit if the reviewer prefers. Differential Revision: https://phab.mercurial-scm.org/D8045
Tue, 22 Oct 2019 16:04:34 +0900 rust-cpython: mark all PyLeaked methods as unsafe
Yuya Nishihara <yuya@tcha.org> [Tue, 22 Oct 2019 16:04:34 +0900] rev 44282
rust-cpython: mark all PyLeaked methods as unsafe Unfortunately, these methods can be abused to obtain the inner 'static reference. The simplest (pseudo-code) example is: let leaked: PyLeaked<&'static _> = shared.leak_immutable(); let static_ref: &'static _ = &*leaked.try_borrow(py)?; // PyLeakedRef::deref() tries to bound the lifetime to itself, but // the underlying data is a &'static reference, so the returned // reference can be &'static. This problem can be easily fixed by coercing the lifetime, but there are many other ways to achieve that, and there wouldn't be a generic solution: let leaked: PyLeaked<&'static [_]> = shared.leak_immutable(); let leaked_iter: PyLeaked<slice::Iter<'static, _>> = unsafe { leaked.map(|v| v.iter()) }; let static_slice: &'static [_] = leaked_iter.try_borrow(py)?.as_slice(); So basically I failed to design the safe borrowing interface. Maybe we'll instead have to add much more restricted interface on top of the unsafe PyLeaked methods? For instance, Iterator::next() could be implemented if its Item type is not &'a (where 'a may be cheated.) Anyway, this seems not an easy issue, so it's probably better to leave the current interface as unsafe, and get broader comments while upstreaming this feature.
Sat, 19 Oct 2019 17:01:28 +0900 rust-cpython: make PySharedRef::try_borrow_mut() return BorrowMutError
Yuya Nishihara <yuya@tcha.org> [Sat, 19 Oct 2019 17:01:28 +0900] rev 44281
rust-cpython: make PySharedRef::try_borrow_mut() return BorrowMutError As I said, it shouldn't be an error of Python layer, but is something like a coding error. Returning BorrowMutError makes more sense. There's a weird hack to propagate the borrow-by-leaked state to RefCell to obtain BorrowMutError. If we don't like it, maybe we can add our own BorrowMutError.
Sat, 19 Oct 2019 16:48:34 +0900 rust-cpython: inline PySharedState::leak_immutable() and PyLeaked::new()
Yuya Nishihara <yuya@tcha.org> [Sat, 19 Oct 2019 16:48:34 +0900] rev 44280
rust-cpython: inline PySharedState::leak_immutable() and PyLeaked::new() For the same reason as the previous patch. The unsafe stuff can be better documented if these functions are inlined.
Sat, 19 Oct 2019 16:34:02 +0900 rust-cpython: inline PySharedState::try_borrow_mut()
Yuya Nishihara <yuya@tcha.org> [Sat, 19 Oct 2019 16:34:02 +0900] rev 44279
rust-cpython: inline PySharedState::try_borrow_mut() Since the core borrowing/leaking logic has been moved to PySharedRef* and PyLeaked*, it doesn't make sense that PySharedState had a function named "try_borrow_mut". Let's turn it into a pure data struct.
Sat, 12 Oct 2019 23:34:05 +0900 rust-cpython: add panicking version of borrow_mut() and use it
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Oct 2019 23:34:05 +0900] rev 44278
rust-cpython: add panicking version of borrow_mut() and use it The original borrow_mut() is renamed to try_borrow_mut(). Since leak_immutable() no longer incref the borrow count, the caller should know if the underlying value is borrowed or not. No Python world is involved. That's why we can simply use the panicking borrow_mut().
Tue, 28 Jan 2020 22:27:30 -0500 setup: don't skip the search for global hg.exe if there is no local instance
Matt Harbison <matt_harbison@yahoo.com> [Tue, 28 Jan 2020 22:27:30 -0500] rev 44277
setup: don't skip the search for global hg.exe if there is no local instance The point of trying not to blindly execute `hg` on Windows is that the local hg.exe would be given precedence, and if py3 isn't on PATH, it errors out with a modal dialog. But that's not a problem if there is no local executable that could be run. The problem that I recently ran into was I upgraded the repo format to use zstd. But doing a `make clean` deletes all of the supporting libraries, causing the next run to abort with a message about not understanding the `revlog-compression-zstd` requirement. By getting rid of the local executable in the previous commit when cleaning, we avoid leaving a broken executable around, and avoid the py3 PATH problem too. There is still a small hole in that `hg.exe` needs to be deleted before switching between py2/py3/PyOxidizer builds, because the zstd module won't load. But that seems like good hygiene anyway. Differential Revision: https://phab.mercurial-scm.org/D8038
Tue, 28 Jan 2020 22:35:08 -0500 make: also delete hg.exe when cleaning
Matt Harbison <matt_harbison@yahoo.com> [Tue, 28 Jan 2020 22:35:08 -0500] rev 44276
make: also delete hg.exe when cleaning This will be needed for the next patch, which has more details. It has to come before the call into setup.py because even `python setup.py clean` calls hg to generate the version file. Differential Revision: https://phab.mercurial-scm.org/D8037
Thu, 23 Jan 2020 15:44:30 -0800 merge: start using the per-side copy dicts
Martin von Zweigbergk <martinvonz@google.com> [Thu, 23 Jan 2020 15:44:30 -0800] rev 44275
merge: start using the per-side copy dicts The point of this patch is mostly to clarify `manifestmerge()`. I find it much easier to reason about now. Differential Revision: https://phab.mercurial-scm.org/D7990
Wed, 22 Jan 2020 14:35:30 -0800 copies: define a type to return from mergecopies()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 14:35:30 -0800] rev 44274
copies: define a type to return from mergecopies() We'll soon return two instances of many of the dicts from `copies.mergecopies()`. That will mean that we need to return 9 different dicts, which is clearly not manageable. This patch instead encapsulates the 4 dicts we'll duplicate in a new type. For now, we still just return one instance of it (plus the separate `diverge` dict). Differential Revision: https://phab.mercurial-scm.org/D7989
Wed, 22 Jan 2020 16:45:56 -0800 merge: move initialization of copy dicts to one place
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 16:45:56 -0800] rev 44273
merge: move initialization of copy dicts to one place Differential Revision: https://phab.mercurial-scm.org/D7988
Fri, 24 Jan 2020 10:39:55 -0800 copies: print debug information about copies per side/branch
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 10:39:55 -0800] rev 44272
copies: print debug information about copies per side/branch Differential Revision: https://phab.mercurial-scm.org/D7987
Wed, 22 Jan 2020 15:31:17 -0800 copies: make mergecopies() distinguish between copies on each side
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 15:31:17 -0800] rev 44271
copies: make mergecopies() distinguish between copies on each side I find it confusing that most of the dicts returned from `mergecopies()` have entries specific to one branch of the merge, but they're still combined into dict. For example, you can't tell if `copy = {"bar": "foo"}` means that "foo" was copied to "bar" on the first branch or the second. It also feels like there are bugs lurking here because we may mistake which side the copy happened on. However, for most of the dicts, it's not possible that there is disagreement. For example, `renamedelete` keeps track of renames that happened on one side of the merge where the other side deleted the file. There can't be a disagreement there (because we record that in the `diverge` dict instead). For regular copies/renames, there can be a disagreement. Let's say file "foo" was copied to "bar" on one branch and file "baz" was copied to "bar" on the other. Beacause we only return one `copy` dict, we end up replacing the `{"bar": "foo"}` entry by `{"bar": "baz"}`. The merge code (`manifestmerge()`) will then decide that that means "both renamed from 'baz'". We should probably treat it as a conflict instead. The next few patches will make `mergecopies()` return two instances of most of the returned copies. That will lead to a bit more code (~40 lines), but I think it makes both `copies.mergecopies()` and `merge.manifestmerge()` clearer. Differential Revision: https://phab.mercurial-scm.org/D7986
Fri, 24 Jan 2020 17:25:40 -0800 pathutil: mark parent directories as audited as we go
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 17:25:40 -0800] rev 44270
pathutil: mark parent directories as audited as we go Before 0b7ce0b16d8a (pathauditor: change parts verification order to be root first, 2016-02-11), we used to validate child directories before parents. It was then important to only mark the child audited only after we had audited its parent (ancestors). I'm pretty sure we don't need to do that any more, now that we audit parents before children. Differential Revision: https://phab.mercurial-scm.org/D8002
Mon, 27 Jan 2020 09:14:19 -0800 cmdutil: change check_incompatible_arguments() *arg to single iterable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 27 Jan 2020 09:14:19 -0800] rev 44269
cmdutil: change check_incompatible_arguments() *arg to single iterable This makes it clearer on the call-sites that the first argument is special. Thanks to Yuya for the suggestion. Differential Revision: https://phab.mercurial-scm.org/D8018
Mon, 27 Jan 2020 12:38:59 -0800 rust: remove an unnecessary set of parentheses
Martin von Zweigbergk <martinvonz@google.com> [Mon, 27 Jan 2020 12:38:59 -0800] rev 44268
rust: remove an unnecessary set of parentheses My build complained about this. I guess it started after I upgraded rustc. Differential Revision: https://phab.mercurial-scm.org/D8020
Mon, 27 Jan 2020 18:16:05 -0800 profiling: flush stdout before writing profile to stderr
Kyle Lippincott <spectral@google.com> [Mon, 27 Jan 2020 18:16:05 -0800] rev 44267
profiling: flush stdout before writing profile to stderr On py3, stdout and stderr appear to be buffered and this causes my command's output to be intermixed with the profiling output. Differential Revision: https://phab.mercurial-scm.org/D8024
Tue, 28 Jan 2020 10:40:19 -0800 rust: re-format with nightly rustfmt
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Jan 2020 10:40:19 -0800] rev 44266
rust: re-format with nightly rustfmt This fixes test-check-rust-format.t. Differential Revision: https://phab.mercurial-scm.org/D8025
Tue, 28 Jan 2020 22:03:00 -0500 tests: stablize test-rename-merge1.t on Windows
Matt Harbison <matt_harbison@yahoo.com> [Tue, 28 Jan 2020 22:03:00 -0500] rev 44265
tests: stablize test-rename-merge1.t on Windows This goes with d7622fdec3b5. Differential Revision: https://phab.mercurial-scm.org/D8036
Sat, 21 Sep 2019 17:27:14 +0900 rust-cpython: make sure PySharedRef::borrow_mut() never panics
Yuya Nishihara <yuya@tcha.org> [Sat, 21 Sep 2019 17:27:14 +0900] rev 44264
rust-cpython: make sure PySharedRef::borrow_mut() never panics Since it returns a Result, it shouldn't panic depending on where the borrowing fails. PySharedRef::borrow_mut() will be renamed to try_borrow_mut() by the next patch.
Tue, 22 Oct 2019 11:38:43 +0900 rust-cpython: remove useless wrappers from PyLeaked, just move by map()
Yuya Nishihara <yuya@tcha.org> [Tue, 22 Oct 2019 11:38:43 +0900] rev 44263
rust-cpython: remove useless wrappers from PyLeaked, just move by map() This series prepares for migrating to the upstreamed version of PySharedRef. I found this last batch wasn't queued while rewriting the callers. While Option<T> was historically needed, it shouldn't be required anymore. I wasn't aware that each filed can be just moved.
Mon, 27 Jan 2020 20:28:47 +0100 rust-node: avoid meaningless read at the end of odd prefix
Georges Racinet <georges.racinet@octobus.net> [Mon, 27 Jan 2020 20:28:47 +0100] rev 44262
rust-node: avoid meaningless read at the end of odd prefix This should be heavily factored out by the CPU branch predictor anyway. Differential Revision: https://phab.mercurial-scm.org/D8019
Fri, 27 Dec 2019 16:06:54 +0100 rust-nodemap: generic NodeTreeVisitor
Georges Racinet <georges.racinet@octobus.net> [Fri, 27 Dec 2019 16:06:54 +0100] rev 44261
rust-nodemap: generic NodeTreeVisitor This iterator will help avoid code duplication when we'll implement `insert()`, in which we will need to traverse the node tree, and to remember the visited blocks. The structured iterator item will allow different usages from `lookup()` and the upcoming `insert()`. Differential Revision: https://phab.mercurial-scm.org/D7794
Fri, 27 Dec 2019 15:11:43 +0100 rust-nodemap: mutable NodeTree data structure
Georges Racinet <georges.racinet@octobus.net> [Fri, 27 Dec 2019 15:11:43 +0100] rev 44260
rust-nodemap: mutable NodeTree data structure Thanks to the previously indexing abstraction, the only difference in the lookup algorithm is that we don't need the special case for an empty NodeTree any more. We've considered making the mutable root an `Option<Block>`, but that leads to unpleasant checks and `unwrap()` unless we abstract it as typestate patterns (`NodeTree<Immutable>` and `NodeTree<Mutated>`) which seem exaggerated in that case. The initial copy of the root block is a very minor performance penalty, given that it typically occurs just once per transaction. Differential Revision: https://phab.mercurial-scm.org/D7793
Thu, 26 Dec 2019 15:47:14 +0100 rust-nodemap: abstracting the indexing
Georges Racinet <georges.racinet@octobus.net> [Thu, 26 Dec 2019 15:47:14 +0100] rev 44259
rust-nodemap: abstracting the indexing In the forthcoming mutable implementation, we'll have to visit node trees that are more complex than a single slice, although the algorithm will still be expressed in simple indexing terms. We still refrain using `#[inline]` indications as being premature optimizations, but we strongly hope the compiler will indeed inline most of the glue. Differential Revision: https://phab.mercurial-scm.org/D7792
Thu, 23 Jan 2020 17:18:13 +0100 rust-nodemap: NodeMap trait with simplest implementation
Georges Racinet <georges.racinet@octobus.net> [Thu, 23 Jan 2020 17:18:13 +0100] rev 44258
rust-nodemap: NodeMap trait with simplest implementation We're defining here only a small part of the immutable methods it will have at the end. This is so we can focus in the following changesets on the needed abstractions for a mutable append-only serializable version. The first implementor exposes the actual lookup algorithm in its simplest form. It will have to be expanded to account for the missing methods, and the special cases related to NULL_NODE. Differential Revision: https://phab.mercurial-scm.org/D7791
Fri, 27 Dec 2019 23:04:18 +0100 rust-node: handling binary Node prefix
Georges Racinet <georges.racinet@octobus.net> [Fri, 27 Dec 2019 23:04:18 +0100] rev 44257
rust-node: handling binary Node prefix Parallel to the inner signatures of the nodetree functions in revlog.c, we'll have to handle prefixes of `Node` in binary form. Another motivation is that it allows to convert from full Node references to `NodePrefixRef` without copy. This is expected to be by far the most common case in practice. There's a slight complication due to the fact that we'll be sometimes interested in prefixes with an odd number of hexadecimal digits, which translates in binary form by a last byte in which only the highest weight 4 bits are considered. This is totally transparent for callers and could be revised once we have proper means to measure performance. The C implementation does the same, passing the length in nybbles as function arguments. Because Rust byte slices already have a length, we carry the even/odd informaton as a boolean, to avoid introducing logical redundancies and the related potential inconsistency bugs. There are a few candidates for inlining here, but we refrain from such premature optimizations, letting the compiler decide. Differential Revision: https://phab.mercurial-scm.org/D7790
Wed, 22 Jan 2020 16:35:56 +0100 rust-revlog: a trait for the revlog index
Georges Racinet <georges.racinet@octobus.net> [Wed, 22 Jan 2020 16:35:56 +0100] rev 44256
rust-revlog: a trait for the revlog index As explained in the doc comment, this is the minimum needed for our immediate concern, which is to implement a nodemap in Rust. The trait will be later implemented in `hg-cpython` by the index Python object implemented in C, thanks to exposition of the corresponding functions as a capsule. The `None` return cases in `node()` match what the `index_node()` C function does. Differential Revision: https://phab.mercurial-scm.org/D7789
Fri, 24 Jan 2020 17:10:45 -0800 pathauditor: drop a redundant call to bytes.lower()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 17:10:45 -0800] rev 44255
pathauditor: drop a redundant call to bytes.lower() `_lowerclean(s)` calls `s.lower()`, so we don't need to do that before calling it. Differential Revision: https://phab.mercurial-scm.org/D8001
Fri, 24 Jan 2020 15:18:19 -0800 merge: replace a repo.lookup('.') by more typical repo['.'].node()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 15:18:19 -0800] rev 44254
merge: replace a repo.lookup('.') by more typical repo['.'].node() The `repo.lookup('.')` form comes from b3311e26f94f (merge: fix --preview to show all nodes that will be merged (issue2043)., 2010-02-15). I don't know why that commit changed from `repo['.']`, but I don't think there's any reason to do that. Note that performance should not be a reason (anymore?), because repo.lookup() is implemented by first creating a context object. Differential Revision: https://phab.mercurial-scm.org/D7998
Fri, 24 Jan 2020 16:07:42 -0800 merge: drop now-unused "abort" argument from hg.merge()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 16:07:42 -0800] rev 44253
merge: drop now-unused "abort" argument from hg.merge() Differential Revision: https://phab.mercurial-scm.org/D7997
Fri, 24 Jan 2020 17:49:21 -0800 merge: don't auto-pick destination with `hg merge 'wdir()'`
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 17:49:21 -0800] rev 44252
merge: don't auto-pick destination with `hg merge 'wdir()'` If the user doesn't specify a commit to merge with, we'll have `node==None` in `commands.merge()`. We'll then try to find a good commit to merge with. However, if the user, for some strange reason, runs `hg merge 'wdir()'`, we'll also have `node==None` and we'll do that same. That's clearly not the intent, so let's not do that. It turns out we'd instead crash on that command after this patch, so I added special handling of it too. Differential Revision: https://phab.mercurial-scm.org/D7996
Fri, 24 Jan 2020 16:05:11 -0800 merge: call hg.abortmerge() directly and return early
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 16:05:11 -0800] rev 44251
merge: call hg.abortmerge() directly and return early It's seem really weird to go through a lot of unrelated code before we call `hg.merge(..., abort=True)` when we can just call `hg.abortmerge()` and return early. Differential Revision: https://phab.mercurial-scm.org/D7995
Fri, 24 Jan 2020 16:00:54 -0800 merge: check that there are no conflicts after --abort
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 16:00:54 -0800] rev 44250
merge: check that there are no conflicts after --abort Same idea as in abcc82bf0717 (clean: check that there are no conflicts after, 2020-01-24). We should reuse more code here, but that will come later. Differential Revision: https://phab.mercurial-scm.org/D7994
Fri, 24 Jan 2020 15:07:44 -0800 merge: use check_incompatible_arguments() for --abort
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 15:07:44 -0800] rev 44249
merge: use check_incompatible_arguments() for --abort Differential Revision: https://phab.mercurial-scm.org/D7993
Wed, 15 Jan 2020 17:15:45 -0800 rebase: move some variables after an error cases where they're not needed
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 17:15:45 -0800] rev 44248
rebase: move some variables after an error cases where they're not needed Differential Revision: https://phab.mercurial-scm.org/D7905
Wed, 15 Jan 2020 10:44:23 -0800 rebase: clarify a little by calculating a set in Python instead of in revset
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 10:44:23 -0800] rev 44247
rebase: clarify a little by calculating a set in Python instead of in revset By calculating the set in Python, we can give it a name, which helps readability. Differential Revision: https://phab.mercurial-scm.org/D7904
Wed, 15 Jan 2020 15:12:50 -0800 merge: avoid a negation in the definition of updatedirstate
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 15:12:50 -0800] rev 44246
merge: avoid a negation in the definition of updatedirstate We only use `partial` in one place: the definition of `updatedirstate`. Let's simplify that a little. Differential Revision: https://phab.mercurial-scm.org/D7900
Fri, 24 Jan 2020 08:32:35 -0800 merge: move definition of `partial` closer to where it's used
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 08:32:35 -0800] rev 44245
merge: move definition of `partial` closer to where it's used Differential Revision: https://phab.mercurial-scm.org/D7983
Wed, 22 Jan 2020 13:06:56 -0800 copies: extract function for finding directory renames
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 13:06:56 -0800] rev 44244
copies: extract function for finding directory renames The directory rename code is logically quite isolated, so it makes sense to make it physically isolated as well. Differential Revision: https://phab.mercurial-scm.org/D7977
Wed, 22 Jan 2020 15:23:30 -0800 copies: avoid calculating debug-only stuff without --debug
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 15:23:30 -0800] rev 44243
copies: avoid calculating debug-only stuff without --debug `renamedeleteset` and `divergeset` is only used with `repo.ui.debugflag`, so let's avoid calculating them otherwise. While at it, I also added a `del renamedeleteset` for consistency. Differential Revision: https://phab.mercurial-scm.org/D7976
Wed, 22 Jan 2020 15:20:12 -0800 copies: move early return in mergecopies() earlier
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 15:20:12 -0800] rev 44242
copies: move early return in mergecopies() earlier It wasn't obvious that the early return happened only when there are no copies. That is the case, however, because if `fullcopy` is empty, then so is `copies1` and `copies2`, and then so is `inversecopies1` and `inversecopies2`, and then so is `allsources`, and then so is `copy`, `diverge` and `renamedelete`. By moving the early return earlier, we also avoid calculating the set of added files from the base to each side. Differential Revision: https://phab.mercurial-scm.org/D7975
Fri, 24 Jan 2020 07:00:45 -0800 tests: test merge of renames of different sources to same target
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 07:00:45 -0800] rev 44241
tests: test merge of renames of different sources to same target This is a really obscure scenario, but let's still have it tested so we know when it changes. Differential Revision: https://phab.mercurial-scm.org/D7985
Fri, 24 Jan 2020 09:33:02 -0800 clean: check that there are no conflicts after
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 09:33:02 -0800] rev 44240
clean: check that there are no conflicts after As noted by Pulkit, there should never be any conflicts after doing a clean update, so `hg.clean()` should never return `True`. Let's check that assertion instead to clarify the code. The callers will now get a `None` instead of a `False` returned, but that should be fine (both result in a 0 exit status). Differential Revision: https://phab.mercurial-scm.org/D7984
Fri, 24 Jan 2020 14:32:53 -0800 progress: delete deprecated ui.progress()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 14:32:53 -0800] rev 44239
progress: delete deprecated ui.progress() Differential Revision: https://phab.mercurial-scm.org/D7991
Fri, 17 Jan 2020 15:34:11 +0100 rust-dependencies: update rayon
Raphaël Gomès <rgomes@octobus.net> [Fri, 17 Jan 2020 15:34:11 +0100] rev 44238
rust-dependencies: update rayon This is just to make sure we use the latest version and also makes it easier to peruse the docs. Differential Revision: https://phab.mercurial-scm.org/D7926
Fri, 24 Jan 2020 11:05:42 -0500 merge with stable
Augie Fackler <augie@google.com> [Fri, 24 Jan 2020 11:05:42 -0500] rev 44237
merge with stable
Wed, 15 Jan 2020 15:08:42 -0800 merge: define updatedirstate a little earlier and reuse it
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 15:08:42 -0800] rev 44236
merge: define updatedirstate a little earlier and reuse it Differential Revision: https://phab.mercurial-scm.org/D7899
Wed, 15 Jan 2020 15:07:43 -0800 merge: don't call update hook when using in-memory context
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 15:07:43 -0800] rev 44235
merge: don't call update hook when using in-memory context I'm pretty sure many hook implementors will assume that they can inspect the working copy and/or dirstate parents when the hook is called, so I don't think we should call the hook when using an in-memory context. The new behavior matches that of the preupdate hook. Differential Revision: https://phab.mercurial-scm.org/D7898
Thu, 23 Jan 2020 13:10:48 -0800 merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 23 Jan 2020 13:10:48 -0800] rev 44234
merge with stable
Wed, 22 Jan 2020 20:01:38 -0800 packaging: add configparser to inno requirements file
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 22 Jan 2020 20:01:38 -0800] rev 44233
packaging: add configparser to inno requirements file This dependency is missing and pip complains about it in strict hashing mode. How this was missed, I have no clue. Differential Revision: https://phab.mercurial-scm.org/D7973
Wed, 22 Jan 2020 22:23:04 -0800 python-zstandard: blacken at 80 characters
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 22 Jan 2020 22:23:04 -0800] rev 44232
python-zstandard: blacken at 80 characters I made this change upstream and it will make it into the next release of python-zstandard. I figured I'd send it Mercurial's way because it will allow us to drop this directory from the black exclusion list. # skip-blame blackening Differential Revision: https://phab.mercurial-scm.org/D7937
Tue, 21 Jan 2020 15:45:06 -0800 tests: move non-collapse test out of test-rebase-collapse
Martin von Zweigbergk <martinvonz@google.com> [Tue, 21 Jan 2020 15:45:06 -0800] rev 44231
tests: move non-collapse test out of test-rebase-collapse The test case was added in 76630fbbf4fa (test-rebase-collapse: Add test for rebase regression introduced in 12309c09d19a, 2012-01-23). I think `hg rebase --collapse` was involved in either the regression or in the fix that caused the regression, but the test that was added doesn't use `--collapse`, so it doesn't seem to belong in test-rebase-collapse.t. The test case is about copies, so I moved it to test-rebase-rename.t. Differential Revision: https://phab.mercurial-scm.org/D7968
Fri, 22 Nov 2019 20:27:09 -0800 debugcommands: add Python implementation to debuginstall
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 22 Nov 2019 20:27:09 -0800] rev 44230
debugcommands: add Python implementation to debuginstall This seems like a useful detail to print. Differential Revision: https://phab.mercurial-scm.org/D7979
Fri, 22 Nov 2019 20:12:10 -0800 run-tests: remove --py3-warnings
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 22 Nov 2019 20:12:10 -0800] rev 44229
run-tests: remove --py3-warnings This Python 2 only mode was to help Python 2 alert when doing things not supported on Python 3. Now that we have test coverage with Python 3, I don't think we need it. Differential Revision: https://phab.mercurial-scm.org/D7978
Wed, 22 Jan 2020 16:37:05 +0100 rust-node: binary Node ID and conversion utilities
Georges Racinet <georges.racinet@octobus.net> [Wed, 22 Jan 2020 16:37:05 +0100] rev 44228
rust-node: binary Node ID and conversion utilities The choice of type makes sure that a `Node` has the exact wanted size. We'll use a different type for prefixes. Added dependency: hexadecimal conversion relies on the `hex` crate. The fact that sooner or later Mercurial is going to need to change its hash sizes has been taken strongly in consideration: - the hash length is a constant, but that is not directly exposed to callers. Changing the value of that constant is the only thing to do to change the hash length (even in unit tests) - the code could be adapted to support several sizes of hashes, if that turned out to be useful. To that effect, only the size of a given `Node` is exposed in the public API. - callers not involved in initial computation, I/O and FFI are able to operate without a priori assumptions on the hash size. The traits `FromHex` and `ToHex` have not been directly implemented, so that the doc-comments explaining these restrictions would stay really visible in `cargo doc` Differential Revision: https://phab.mercurial-scm.org/D7788
Wed, 22 Jan 2020 16:23:29 +0100 rust-nodemap: building blocks for nodetree structures
Georges Racinet <georges.racinet@octobus.net> [Wed, 22 Jan 2020 16:23:29 +0100] rev 44227
rust-nodemap: building blocks for nodetree structures This is similar to `nodetreenode` in `revlog.c`. We give it a higher level feeling for ease of handling in Rust context and provide tools for tests and debugging. The encoding choice is dictated by our ultimate goal in this series, that is to make an append-only persistent version of `nodetree`: the 0th Block must be adressed from other Blocks. Differential Revision: https://phab.mercurial-scm.org/D7787
Tue, 21 Jan 2020 10:13:08 -0500 lfs: move the initialization of the upload request into the try block
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 10:13:08 -0500] rev 44226
lfs: move the initialization of the upload request into the try block This (almost) guarantees that the file is closed in the case of an exception. The one hole is if the `seek(SEEK_END)`/`tell()`/`seek(0)` sequence fails. But that's going to go away when subclassing `httpconnection.httpsendfile` to fix the worker problem, so I'm not going to worry too much. (And that class appears to have the same problem.) Differential Revision: https://phab.mercurial-scm.org/D7959
Tue, 21 Jan 2020 09:55:35 -0500 lfs: drop an unnecessary r'' prefix
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 09:55:35 -0500] rev 44225
lfs: drop an unnecessary r'' prefix No longer necessary since the source transformer was removed. # skip-blame for changing string prefixes Differential Revision: https://phab.mercurial-scm.org/D7958
Tue, 21 Jan 2020 09:51:39 -0500 lfs: explicitly close the file handle for the blob being uploaded
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 09:51:39 -0500] rev 44224
lfs: explicitly close the file handle for the blob being uploaded The previous code relied on reading the blob fully to close it. The obvious problem is if an error occurs before that point. But there is also a problem when using workers where the data may need to be re-read, which can't happen once it is closed. This eliminates the surprising behavior before attempting to fix the worker problem. Differential Revision: https://phab.mercurial-scm.org/D7957
Tue, 21 Jan 2020 09:40:40 -0500 lfs: drop the unused progressbar code in the `filewithprogress` class
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 09:40:40 -0500] rev 44223
lfs: drop the unused progressbar code in the `filewithprogress` class This has been unused since f98fac24b757, which added worker based transfers for concurrency, shifting the progressbar maintenance to the single thread waiting on the worker to complete. Since the name no longer fits, rename the class. Differential Revision: https://phab.mercurial-scm.org/D7956
Tue, 14 Jan 2020 16:58:07 +0100 rust-filepatterns: remove bridge code for filepatterns-related functions
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 16:58:07 +0100] rev 44222
rust-filepatterns: remove bridge code for filepatterns-related functions These functions will be used internally by `hg-core` without needed to be exposed to Python. Differential Revision: https://phab.mercurial-scm.org/D7868
Tue, 14 Jan 2020 18:03:28 +0100 rust-utils: add Rust implementation of Python's "os.path.splitdrive"
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 18:03:28 +0100] rev 44221
rust-utils: add Rust implementation of Python's "os.path.splitdrive" I also wrote the NT version although I didn't mean to at first, so I thought I would keep it, so that any further effort to get the Rust code working on Windows is a little easier. Differential Revision: https://phab.mercurial-scm.org/D7864
Mon, 13 Apr 2020 16:30:13 +0300 setup: link osutil.so to libsocket on Solaris/illumos (issue6299) stable
Alexander Pyhalov <apyhalov@gmail.com> [Mon, 13 Apr 2020 16:30:13 +0300] rev 44220
setup: link osutil.so to libsocket on Solaris/illumos (issue6299)
(0) -30000 -10000 -3000 -1000 -300 -100 -96 +96 +100 +300 +1000 +3000 tip