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.
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.
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
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
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.
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.
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.
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)
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.
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.