Mon, 22 Jul 2024 18:20:03 +0200 utils: fix resourceutil use of deprecated importlib.resources
Mads Kiilerich <mads@kiilerich.com> [Mon, 22 Jul 2024 18:20:03 +0200] rev 51749
utils: fix resourceutil use of deprecated importlib.resources Some importlib functionality was deprecated in 3.11 . The documentation on https://docs.python.org/3.12/library/importlib.resources.html recommends using the new .files() API that was introduced in 3.9.
Thu, 11 Jan 2024 20:32:07 +0100 cext: use sys.executable instead of deprecated Py_GetProgramFullPath
Mads Kiilerich <mads@kiilerich.com> [Thu, 11 Jan 2024 20:32:07 +0100] rev 51748
cext: use sys.executable instead of deprecated Py_GetProgramFullPath Fix warning with Python 3.13: mercurial/cext/parsers.c: In function 'check_python_version': mercurial/cext/parsers.c:1243:30: warning: 'Py_GetProgramFullPath' is deprecated [-Wdeprecated-declarations] 1243 | Py_GetProgramFullPath()); | ^~~~~~~~~~~~~~~~~~~~~ In file included from /usr/include/python3.13/Python.h:119, from mercurial/cext/parsers.c:11: /usr/include/python3.13/pylifecycle.h:43:43: note: declared here 43 | Py_DEPRECATED(3.13) PyAPI_FUNC(wchar_t *) Py_GetProgramFullPath(void); | ^~~~~~~~~~~~~~~~~~~~~ At this point in time, the PyConfig struct memory has been released and the PyConfig API can't be used. https://docs.python.org/3.13/c-api/init.html#c.Py_GetProgramFullPath recommands using sys.executable instead. Let's assume that will work in all versions. It would perhaps be better to use PySys_GetObject, but I prefer to stay consistent with how the same function is retrieving sys.hexversion.
Thu, 11 Jan 2024 21:58:55 +0100 subrepoutil: pass re.sub 'count' argument by name
Mads Kiilerich <mads@kiilerich.com> [Thu, 11 Jan 2024 21:58:55 +0100] rev 51747
subrepoutil: pass re.sub 'count' argument by name Python 3.13 started warning: DeprecationWarning: 'count' is passed as positional argument
Thu, 11 Jan 2024 21:58:55 +0100 tests: pass re.MULTILINE to re.sub as 'flags' - not in 'count' position
Mads Kiilerich <mads@kiilerich.com> [Thu, 11 Jan 2024 21:58:55 +0100] rev 51746
tests: pass re.MULTILINE to re.sub as 'flags' - not in 'count' position This bug was caught by the new Python 3.13 warning: DeprecationWarning: 'count' is passed as positional argument
Mon, 26 Jun 2023 21:31:41 +0200 tests: use packaging from setuptools instead of deprecated distutils
Mads Kiilerich <mads@kiilerich.com> [Mon, 26 Jun 2023 21:31:41 +0200] rev 51745
tests: use packaging from setuptools instead of deprecated distutils When invoking StrictVersion in 3.12 we got: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead. distutils is dead in the standard library, and we have to move towards using `setuptools` as general extern dependency. Instead of also requiring the extern `packaging`, we will just use the packaging that is vendored in setuptools.
Mon, 26 Jun 2023 15:16:51 +0200 tests: drop test-demandimport.py distutils test that failed with warnings
Mads Kiilerich <mads@kiilerich.com> [Mon, 26 Jun 2023 15:16:51 +0200] rev 51744
tests: drop test-demandimport.py distutils test that failed with warnings The test would fail because warnings: /usr/lib/python3.11/site-packages/_distutils_hack/__init__.py:18: UserWarning: Distutils was imported before Setuptools, but importing Setuptools also replaces the `distutils` module in `sys.modules`. This may lead to undesirable behaviors or errors. To avoid these issues, avoid using distutils directly, ensure that setuptools is installed in the traditional way (e.g. not an editable install), and/or make sure that setuptools is always imported before distutils. warnings.warn( /usr/lib/python3.11/site-packages/_distutils_hack/__init__.py:33: UserWarning: Setuptools is replacing distutils. warnings.warn("Setuptools is replacing distutils.") The test for distutils.msvc9compiler comes from 2205d00b6d2b. But since then, distutils is going away, and this test must change somehow. It is unclear exactly how setuptools depended on msvc9compiler, but setuptools also moved forward, and this exact test no longer seems relevant. It thus seems like a fair solution to remove the test while keeping the demandimport blacklist of distutils.msvc9compiler.
Thu, 29 Jun 2023 20:02:27 +0200 utils: test coverage of makedate
Mads Kiilerich <mads@kiilerich.com> [Thu, 29 Jun 2023 20:02:27 +0200] rev 51743
utils: test coverage of makedate Explore the scenario from ae04af1ce78d to avoid future regressions. This was intended to give some coverage of the change in faccec1edc2c.
Tue, 09 Jul 2024 20:08:48 +0200 mmap: populate mapping in a background thread
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 09 Jul 2024 20:08:48 +0200] rev 51742
mmap: populate mapping in a background thread When possible, we populate the memory mapping in a second thread. The mmap population does not only read the data from disk to memory. It also actually fill the memory mapping between process memory address and the physical memory used by the file system cache containing the mmap'ed data. Doing so buy back the slowdown from pre-population when it matters. When most data is accessed, only a few page fault will occurs, while the background thread fill the memory controller. When few data is accessed, the non-blocking mmap won't have to wait for all data to be populated. Here is a few example of improvement seen in benchmark around unbundle and push: ### data-env-vars.name = netbeans-2018-08-01-zstd-sparse-revlog # benchmark.name = hg.command.unbundle # benchmark.variants.issue6528 = disabled # benchmark.variants.reuse-external-delta-parent = yes # benchmark.variants.revs = any-100-extra-rev before: 0.758101 after: 0.732129 (-3.43%, -0.03) ## data-env-vars.name = mozilla-try-2019-02-18-zstd-sparse-revlog before: 1.519941 after: 1.503473 (-1.08%, -0.02) ### data-env-vars.name = mozilla-try-2019-02-18-zstd-sparse-revlog # benchmark.name = hg.command.push # bin-env-vars.hg.flavor = default # benchmark.variants.issue6528 = disabled # benchmark.variants.protocol = ssh # benchmark.variants.reuse-external-delta-parent = yes # benchmark.variants.revs = any-1-extra-rev before: 4.801442 after: 4.695810 (-1.46%, -0.07) # benchmark.variants.revs = any-100-extra-rev before: 4.848596 after: 4.794075 (-1.12%, -0.05) # bin-env-vars.hg.flavor = rust # benchmark.variants.revs = any-1-extra-rev before: 4.818410 after: 4.700053 (-2.46%, -0.12)
Thu, 25 Jul 2024 14:40:38 -0400 pure: stringify builtin exception messages
Matt Harbison <matt_harbison@yahoo.com> [Thu, 25 Jul 2024 14:40:38 -0400] rev 51741
pure: stringify builtin exception messages Builtin exceptions usually want strings, and display with a wierd b'' prefix if given bytes.
Mon, 29 Jul 2024 12:10:08 -0400 httppeer: avoid another bad reference before assignment warning
Matt Harbison <matt_harbison@yahoo.com> [Mon, 29 Jul 2024 12:10:08 -0400] rev 51740
httppeer: avoid another bad reference before assignment warning This wasn't a problem, because `b''` from the `AttributeError` handler is in `bundle2.bundletypes`, so the following loop and conditional always run at least once. But PyCharm can't figure that out on its own, and it took a little exploring to figure out it wasn't a problem. The usage in `bundle2.writebundle` is to look it up in the map of bundle types, so it will break in a more obvious way in the unlikely event that the empty string is removed from the map in the future.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 tip