From matti.picus at gmail.com Mon Sep 13 11:21:50 2021 From: matti.picus at gmail.com (Matti Picus) Date: Mon, 13 Sep 2021 18:21:50 +0300 Subject: [pypy-dev] PyPy v7.3.6rc1 is available for testing Message-ID: <647b11e6-27ce-05b5-c8f8-e230258e0136@gmail.com> The release candidates for pypy v7.3.6rc1 for python2.7, python3.7, and python3.8 are up. This is our first release of 3.8. This release also includes a backend for HPy0.0.2 (may be upgraded to 0.0.3 by the final release). This release has a number of enhancements and speed-ups, as well as the usual bug fixes. The win64 rollout on conda is going well, over 600 packages are already built. Many of the bug fixes in this version were discovered while building those packages. Thanks to all who contributed code, comments, or otherwise support PyPy. The downloads are at https://downloads.python.org/pypy/ and the checksums https://www.pypy.org/checksums.html Please try them out. The directory layout of the 3.8 release has changed, so I hope it still builds c-extension modules on your platform. The release notice https://doc.pypy.org/en/latest/release-v7.3.6.html As always, edits are welcome. Matti From yury at shurup.com Mon Sep 13 11:29:17 2021 From: yury at shurup.com (Yury V. Zaytsev) Date: Mon, 13 Sep 2021 17:29:17 +0200 (CEST) Subject: [pypy-dev] PyPy v7.3.6rc1 is available for testing In-Reply-To: <647b11e6-27ce-05b5-c8f8-e230258e0136@gmail.com> References: <647b11e6-27ce-05b5-c8f8-e230258e0136@gmail.com> Message-ID: <36fa4e25-a85f-6235-da26-8750fea13ec@shurup.com> On Mon, 13 Sep 2021, Matti Picus wrote: > The release notice https://doc.pypy.org/en/latest/release-v7.3.6.html > As always, edits are welcome. It would be very interesting to know, how the amazing translation speedup has been achieved (I hope not by removing the fractal rendering, right?), but in this version of release notes, the issues are mostly not linked... -- Sincerely yours, Yury V. Zaytsev From cfbolz at gmx.de Mon Sep 13 15:47:19 2021 From: cfbolz at gmx.de (Carl Friedrich Bolz-Tereick) Date: Mon, 13 Sep 2021 21:47:19 +0200 Subject: [pypy-dev] PyPy v7.3.6rc1 is available for testing In-Reply-To: <36fa4e25-a85f-6235-da26-8750fea13ec@shurup.com> References: <647b11e6-27ce-05b5-c8f8-e230258e0136@gmail.com> <36fa4e25-a85f-6235-da26-8750fea13ec@shurup.com> Message-ID: On 13.09.21 17:29, Yury V. Zaytsev wrote: > On Mon, 13 Sep 2021, Matti Picus wrote: > >> The release notice https://doc.pypy.org/en/latest/release-v7.3.6.html >> As always, edits are welcome. > > It would be very interesting to know, how the amazing translation > speedup has been achieved (I hope not by removing the fractal rendering, > right?), but in this version of release notes, the issues are mostly not > linked... Not to worry, the fractal is still there :-) ? computing it takes ~1s of the total runtime. The speedup was achieved in relatively boring ways: - there was an algorithm that was (weakly) quadratic in one of the translation phases, in the number of functions analyzed. Making this linear already helped a lot. - many minutes were saved by implementing a graph algorithm in a somewhat more clever way: the algorithm finds cycles in the call graph to insert stack checks. The algorithm walks the call graph many times. I managed to speed that up by first removing all obvious leaves and trees of leaves from the call graph, that can definitely not contribute to a cycle. - When GCC is used we now use a pre-compiled shared header. This also helps massively, because the C code that we produce shares a single enormous header that hundreds of other files include. This leads to the header being parsed and analyzed again and again, which is particularly annoying if the .c file that includes it is itself tiny. In summary, nothing deep, lots of legwork. Cheers, Carl Friedrich From mgorny at gentoo.org Tue Sep 14 05:21:25 2021 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Tue, 14 Sep 2021 11:21:25 +0200 Subject: [pypy-dev] PyPy v7.3.6rc1 is available for testing In-Reply-To: <647b11e6-27ce-05b5-c8f8-e230258e0136@gmail.com> References: <647b11e6-27ce-05b5-c8f8-e230258e0136@gmail.com> Message-ID: <9d5075879f77660c1085a15dd3906e976256db0a.camel@gentoo.org> On Mon, 2021-09-13 at 18:21 +0300, Matti Picus wrote: > The release candidates for pypy v7.3.6rc1 for python2.7, python3.7, and > python3.8 are up. This is our first release of 3.8. This release also > includes a backend for HPy0.0.2 (may be upgraded to 0.0.3 by the final > release). This release has a number of enhancements and speed-ups, as > well as the usual bug fixes. The win64 rollout on conda is going well, > over 600 packages are already built. Many of the bug fixes in this > version were discovered while building those packages. > > > Thanks to all who contributed code, comments, or otherwise support PyPy. > > > The downloads are at https://downloads.python.org/pypy/ > > and the checksums https://www.pypy.org/checksums.html > > Please try them out. The directory layout of the 3.8 release has > changed, so I hope it still builds c-extension modules on your platform. > I really appreciate the effort on standardizing the install layout. However, could you also move lib_pypy inside lib/pypy3.8? Right now it seems to imply installing /usr/lib_pypy which is a no-go per FHS. -- Best regards, Micha? G?rny From yury at shurup.com Tue Sep 14 15:45:37 2021 From: yury at shurup.com (Yury V. Zaytsev) Date: Tue, 14 Sep 2021 21:45:37 +0200 (CEST) Subject: [pypy-dev] PyPy v7.3.6rc1 is available for testing In-Reply-To: References: <647b11e6-27ce-05b5-c8f8-e230258e0136@gmail.com> <36fa4e25-a85f-6235-da26-8750fea13ec@shurup.com> Message-ID: <629d3c-26eb-f973-c757-feaffa7223cf@shurup.com> On Mon, 13 Sep 2021, Carl Friedrich Bolz-Tereick wrote: > The speedup was achieved in relatively boring ways. In summary, nothing > deep, lots of legwork. Hi Carl, Thank you very much for the summary, it was very interesting to read! Congratulations to the PyPy Team even (or even more so) if the speedup has been achieved by doing "boring" work, and not by applying some crazy algorithms or clever tricks! -- Sincerely yours, Yury V. Zaytsev From tinchester at gmail.com Sat Sep 18 15:57:13 2021 From: tinchester at gmail.com (=?UTF-8?Q?Tin_Tvrtkovi=C4=87?=) Date: Sat, 18 Sep 2021 21:57:13 +0200 Subject: [pypy-dev] Does PyPy memory use benefit from preforking? Message-ID: Hello! A little bit of context: roughly speaking, preforking is a technique where a (supervisor) process is started, the process performs some initialization and then forks off into child worker processes, which it then supervises. It's usually used to make several worker processes share a server TCP socket (which they inherit from the supervisor). In some runtimes preforking can also be used to save memory since the child processes get copy-on-write access to the supervisor memory pages. My understanding is this doesn't actually yield anything on CPython since essentially everything is reference counted and memory pages get copied quickly. PyPy doesn't use reference counting though, so I was wondering if preforking could be used with PyPy for memory saving purposes. All of this is a little low-level for me, and I would appreciate any insight from the resident experts :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From teammember0x01 at gmail.com Sun Sep 19 15:13:06 2021 From: teammember0x01 at gmail.com (M A) Date: Sun, 19 Sep 2021 15:13:06 -0400 Subject: [pypy-dev] [PATCH] Correctly set MACOSX_DEPLOYMENT_TARGET on arm, x86, and ppc Message-ID: Currently the variable MACOSX_DEPLOYMENT_TARGET was being set to 10.7 without regard to the CPU. This does not work because building a binary that targets the Mac OS 10.7 SDK is not possible on PowerPC. This value also prevents the building of an ARM native version for ARM based Macs. So we decide with architecture to use by looking at the CPU of the computer when on Darwin (Mac OS). I would like some feedback on if this patch looks good or if there a problem I'm not seeing. Thank you. --- lib-python/2.7/distutils/sysconfig_pypy.py | 28 +++++++++++++++------- 1 file changed, 19 insertions(+), 9 deletions(-) diff --git a/lib-python/2.7/distutils/sysconfig_pypy.py b/lib-python/2.7/distutils/sysconfig_pypy.py index ec9f5a31db..61ab3d4f7c 100644 --- a/lib-python/2.7/distutils/sysconfig_pypy.py +++ b/lib-python/2.7/distutils/sysconfig_pypy.py @@ -75,18 +75,28 @@ def _init_posix(): g['VERSION'] = get_python_version() if sys.platform[:6] == "darwin": - import platform - if platform.machine() == 'i386': - if platform.architecture()[0] == '32bit': - arch = 'i386' - else: - arch = 'x86_64' + _, _, _, kernel_string, _, = os.uname() + begin = kernel_string.find("_") + 1 # position of the architecture string + arch = kernel_string[begin:] + arch = arch.lower() + + if "arm64" in arch: + arch = "arm64" + g['MACOSX_DEPLOYMENT_TARGET'] = '11.0' + elif "x86_64" in arch: + arch = "x86_64" + g['MACOSX_DEPLOYMENT_TARGET'] = '10.5' + elif "i386" in arch: + arch = "i386" + g['MACOSX_DEPLOYMENT_TARGET'] = '10.4' + elif "ppc" in arch: + arch = "ppc" + g['MACOSX_DEPLOYMENT_TARGET'] = '10.1' else: - # just a guess - arch = platform.machine() + raise Exception("Error in sysconfig_pypy.py: unknown architecture encountered: " + arch) + g['LDSHARED'] += ' -undefined dynamic_lookup' g['CC'] += ' -arch %s' % (arch,) - g['MACOSX_DEPLOYMENT_TARGET'] = '10.7' # pypy only: give us control over the ABI tag in a wheel name if '__pypy__' in sys.builtin_module_names: -- 2.24.3 (Apple Git-128) From armin.rigo at gmail.com Sun Sep 19 15:50:07 2021 From: armin.rigo at gmail.com (Armin Rigo) Date: Sun, 19 Sep 2021 21:50:07 +0200 Subject: [pypy-dev] [PATCH] Correctly set MACOSX_DEPLOYMENT_TARGET on arm, x86, and ppc In-Reply-To: References: Message-ID: Hi, On Sun, 19 Sept 2021 at 21:13, M A wrote: > + elif "x86_64" in arch: > + arch = "x86_64" > + g['MACOSX_DEPLOYMENT_TARGET'] = '10.5' This would change MACOSX_DEPLOYMENT_TARGET in our existing builds for x86_64 machines from '10.7' to '10.5'. Can you explain why you propose such a change? A bient?t, Armin From teammember0x01 at gmail.com Sun Sep 19 16:30:36 2021 From: teammember0x01 at gmail.com (M A) Date: Sun, 19 Sep 2021 16:30:36 -0400 Subject: [pypy-dev] [PATCH] Correctly set MACOSX_DEPLOYMENT_TARGET on arm, x86, and ppc In-Reply-To: References: Message-ID: <76C03E4A-FBAF-4B6E-8EA7-ECEB49DF974E@gmail.com> > On Sep 19, 2021, at 3:50 PM, Armin Rigo wrote: > > Hi, > > On Sun, 19 Sept 2021 at 21:13, M A wrote: >> + elif "x86_64" in arch: >> + arch = "x86_64" >> + g['MACOSX_DEPLOYMENT_TARGET'] = '10.5' > > This would change MACOSX_DEPLOYMENT_TARGET in our existing builds for > x86_64 machines from '10.7' to '10.5'. Can you explain why you > propose such a change? > > > A bient?t, > > Armin So people with Mac OS 10.5 can use PyPy on their x86_64 systems. Thank you. From armin.rigo at gmail.com Mon Sep 20 01:23:45 2021 From: armin.rigo at gmail.com (Armin Rigo) Date: Mon, 20 Sep 2021 07:23:45 +0200 Subject: [pypy-dev] [PATCH] Correctly set MACOSX_DEPLOYMENT_TARGET on arm, x86, and ppc In-Reply-To: <76C03E4A-FBAF-4B6E-8EA7-ECEB49DF974E@gmail.com> References: <76C03E4A-FBAF-4B6E-8EA7-ECEB49DF974E@gmail.com> Message-ID: Hi, On Sun, 19 Sept 2021 at 22:30, M A wrote: > > This would change MACOSX_DEPLOYMENT_TARGET in our existing builds for > > x86_64 machines from '10.7' to '10.5'. Can you explain why you > > propose such a change? > > So people with Mac OS 10.5 can use PyPy on their x86_64 systems. This might need some more care. The value was bumped in the past to 10.7 because we're using important features in that version of OS X, if I remember correctly. It's not a random value we had since the start of the project, because PyPy is much older than that. You or someone else would need to dig into the hg history to figure out why it was the case, and if it's still needed. Armin On Sun, 19 Sept 2021 at 22:30, M A wrote: > > > > > On Sep 19, 2021, at 3:50 PM, Armin Rigo wrote: > > > > Hi, > > > > On Sun, 19 Sept 2021 at 21:13, M A wrote: > >> + elif "x86_64" in arch: > >> + arch = "x86_64" > >> + g['MACOSX_DEPLOYMENT_TARGET'] = '10.5' > > > > This would change MACOSX_DEPLOYMENT_TARGET in our existing builds for > > x86_64 machines from '10.7' to '10.5'. Can you explain why you > > propose such a change? > > > > > > A bient?t, > > > > Armin > > So people with Mac OS 10.5 can use PyPy on their x86_64 systems. > > Thank you. From teammember0x01 at gmail.com Sun Sep 19 13:44:54 2021 From: teammember0x01 at gmail.com (M A) Date: Sun, 19 Sep 2021 13:44:54 -0400 Subject: [pypy-dev] Contributing to PyPy Message-ID: Hi I am interested in contributing to PyPy. I tried to clone the source code repository using hg but saw errors. I then found this git repo: https://github.com/mozillazg/pypy. I was actually able to clone it successfully. Could someone still contribute to PyPy using git instead of hg? If you are curious here are the errors I see when I try to clone the repository using hg: hg clone https://foss.heptapod.net/pypy/pypy destination directory: pypy applying clone bundle from https://cellar-c2.services.clever-cloud.com/heptapod-foss-clonebundles/pypy/pypy-2020-02-12-13-12-optimized-zstd-v2.hg adding changesets adding manifests adding file changes transaction abort! rollback completed ** unknown exception encountered, please report by visiting ** https://mercurial-scm.org/wiki/BugTracker ** Python 3.9.7 (default, Sep 3 2021, 04:31:11) [Clang 12.0.5 (clang-1205.0.22.9)] ** Mercurial Distributed SCM (version 5.9.1) ** Extensions loaded: Traceback (most recent call last): File "/opt/homebrew/bin/hg", line 61, in dispatch.run() File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 144, in run status = dispatch(req) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 250, in dispatch status = _rundispatch(req) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 294, in _rundispatch ret = _runcatch(req) or 0 File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 470, in _runcatch return _callcatch(ui, _runcatchfunc) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 480, in _callcatch return scmutil.callcatch(ui, func) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/scmutil.py", line 153, in callcatch return func() File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 460, in _runcatchfunc return _dispatch(req) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 1273, in _dispatch return runcommand( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 918, in runcommand ret = _runcommand(ui, options, cmd, d) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 1285, in _runcommand return cmdfunc() File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 1271, in d = lambda: util.checksignature(func)(ui, *args, **strcmdopt) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/util.py", line 1886, in check return func(*args, **kwargs) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/commands.py", line 1955, in clone r = hg.clone( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/hg.py", line 942, in clone exchange.pull( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/exchange.py", line 1668, in pull _maybeapplyclonebundle(pullop) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/exchange.py", line 2779, in _maybeapplyclonebundle if trypullbundlefromurl(repo.ui, repo, url): File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/exchange.py", line 2810, in trypullbundlefromurl bundle2.applybundle(repo, cg, tr, b'clonebundles', url) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/bundle2.py", line 375, in applybundle return processbundle(repo, unbundler, lambda: tr, source=source) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/bundle2.py", line 486, in processbundle processparts(repo, op, unbundler) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/bundle2.py", line 494, in processparts _processpart(op, part) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/bundle2.py", line 568, in _processpart handler(op, part) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/bundle2.py", line 2025, in handlechangegroup ret = _processchangegroup( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/bundle2.py", line 498, in _processchangegroup ret = cg.apply(op.repo, tr, source, url, **kwargs) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/changegroup.py", line 444, in apply newrevs, newfiles = _addchangegroupfiles( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/changegroup.py", line 1946, in _addchangegroupfiles added = fl.addgroup( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/filelog.py", line 168, in addgroup return self._revlog.addgroup( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/revlog.py", line 2620, in addgroup for data in deltas: File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/revlogutils/rewrite.py", line 783, in filter_delta_issue6528 is_affected = _is_revision_affected_fast_inner( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/revlogutils/rewrite.py", line 649, in _is_revision_affected_fast_inner return _is_revision_affected_inner( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/revlogutils/rewrite.py", line 592, in _is_revision_affected_inner has_meta = raw_text.startswith(b'\x01\n') AttributeError: 'memoryview' object has no attribute 'startswith' ** Extensions loaded: Traceback (most recent call last): File "/opt/homebrew/bin/hg", line 61, in dispatch.run() File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 144, in run status = dispatch(req) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 250, in dispatch status = _rundispatch(req) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 294, in _rundispatch ret = _runcatch(req) or 0 File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 470, in _runcatch return _callcatch(ui, _runcatchfunc) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 480, in _callcatch return scmutil.callcatch(ui, func) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/scmutil.py", line 153, in callcatch return func() File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 460, in _runcatchfunc return _dispatch(req) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 1273, in _dispatch return runcommand( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 918, in runcommand ret = _runcommand(ui, options, cmd, d) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 1285, in _runcommand return cmdfunc() File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/dispatch.py", line 1271, in d = lambda: util.checksignature(func)(ui, *args, **strcmdopt) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/util.py", line 1886, in check return func(*args, **kwargs) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/commands.py", line 1955, in clone r = hg.clone( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/hg.py", line 942, in clone exchange.pull( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/exchange.py", line 1668, in pull _maybeapplyclonebundle(pullop) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/exchange.py", line 2779, in _maybeapplyclonebundle if trypullbundlefromurl(repo.ui, repo, url): File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/exchange.py", line 2810, in trypullbundlefromurl bundle2.applybundle(repo, cg, tr, b'clonebundles', url) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/bundle2.py", line 375, in applybundle return processbundle(repo, unbundler, lambda: tr, source=source) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/bundle2.py", line 486, in processbundle processparts(repo, op, unbundler) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/bundle2.py", line 494, in processparts _processpart(op, part) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/bundle2.py", line 568, in _processpart handler(op, part) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/bundle2.py", line 2025, in handlechangegroup ret = _processchangegroup( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/bundle2.py", line 498, in _processchangegroup ret = cg.apply(op.repo, tr, source, url, **kwargs) File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/changegroup.py", line 444, in apply newrevs, newfiles = _addchangegroupfiles( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/changegroup.py", line 1946, in _addchangegroupfiles added = fl.addgroup( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/filelog.py", line 168, in addgroup return self._revlog.addgroup( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/revlog.py", line 2620, in addgroup for data in deltas: File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/revlogutils/rewrite.py", line 783, in filter_delta_issue6528 is_affected = _is_revision_affected_fast_inner( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/revlogutils/rewrite.py", line 649, in _is_revision_affected_fast_inner return _is_revision_affected_inner( File "/opt/homebrew/Cellar/mercurial/5.9.1/lib/python3.9/site-packages/mercurial/revlogutils/rewrite.py", line 592, in _is_revision_affected_inner has_meta = raw_text.startswith(b'\x01\n') AttributeError: 'memoryview' object has no attribute 'startswith' From teammember0x01 at gmail.com Mon Sep 20 16:32:56 2021 From: teammember0x01 at gmail.com (M A) Date: Mon, 20 Sep 2021 16:32:56 -0400 Subject: [pypy-dev] _init_posix() not ever called? Message-ID: <243D820F-6C19-4DCB-A504-547525E5382A@gmail.com> Hi I was working in the file lib-python/2.7/distutils/sysconfig_pypy.py, on the function _init_posix(). I placed print() statements in the function to indicate when this function is called. After fully building pypy the print() statements were never called. I then used grep to try to find out where this function is called in the source code. I ran this command: grep "_init_posix()" -r *. After looking at the results it looks like this function is never called by anything. Why do we have it? More importantly can we delete it? Thank you. From teammember0x01 at gmail.com Mon Sep 20 22:30:28 2021 From: teammember0x01 at gmail.com (M A) Date: Mon, 20 Sep 2021 22:30:28 -0400 Subject: [pypy-dev] Changes to file not being noticed Message-ID: <0E86647E-F6AF-41DD-9B9B-838DB38DF8B8@gmail.com> I recently added some functions to a file called _osx_support.py. When I imported the module and tried to use the functions I added, I see an error messages stating the name could not be imported. Would anyone know how to solve this kind of problem? Thank you. From armin.rigo at gmail.com Tue Sep 21 04:28:24 2021 From: armin.rigo at gmail.com (Armin Rigo) Date: Tue, 21 Sep 2021 10:28:24 +0200 Subject: [pypy-dev] _init_posix() not ever called? In-Reply-To: <243D820F-6C19-4DCB-A504-547525E5382A@gmail.com> References: <243D820F-6C19-4DCB-A504-547525E5382A@gmail.com> Message-ID: Hi, On Mon, 20 Sept 2021 at 22:33, M A wrote: > Hi I was working in the file lib-python/2.7/distutils/sysconfig_pypy.py, on the function _init_posix(). I placed print() statements in the function to indicate when this function is called. After fully building pypy the print() statements were never called. I then used grep to try to find out where this function is called in the source code. I ran this command: grep "_init_posix()" -r *. After looking at the results it looks like this function is never called by anything. Why do we have it? More importantly can we delete it? It is called from the same file by these line: func = globals().get("_init_" + os.name) if func: func() If you don't see print statements at runtime, then it might be the case that it's called at translation time instead. The module's state with _init_posix() already called would then get frozen inside the translated pypy. A bient?t, Armin From teammember0x01 at gmail.com Tue Sep 21 06:36:29 2021 From: teammember0x01 at gmail.com (M A) Date: Tue, 21 Sep 2021 06:36:29 -0400 Subject: [pypy-dev] _init_posix() not ever called? In-Reply-To: References: <243D820F-6C19-4DCB-A504-547525E5382A@gmail.com> Message-ID: <1D070A76-D76A-4D30-A0B6-C111D260230E@gmail.com> > On Sep 21, 2021, at 4:28 AM, Armin Rigo wrote: > > Hi, > > On Mon, 20 Sept 2021 at 22:33, M A wrote: >> Hi I was working in the file lib-python/2.7/distutils/sysconfig_pypy.py, on the function _init_posix(). I placed print() statements in the function to indicate when this function is called. After fully building pypy the print() statements were never called. I then used grep to try to find out where this function is called in the source code. I ran this command: grep "_init_posix()" -r *. After looking at the results it looks like this function is never called by anything. Why do we have it? More importantly can we delete it? > > It is called from the same file by these line: > > func = globals().get("_init_" + os.name) > if func: > func() > > If you don't see print statements at runtime, then it might be the > case that it's called at translation time instead. The module's state > with _init_posix() already called would then get frozen inside the > translated pypy. > > > A bient?t, > Armin Thank you Armin. So how do I make this function run again? For most projects I would be something like "make clean" to remove all the object files and start from the beginning. Does PyPy have anything like this? From teammember0x01 at gmail.com Tue Sep 21 21:11:21 2021 From: teammember0x01 at gmail.com (M A) Date: Tue, 21 Sep 2021 21:11:21 -0400 Subject: [pypy-dev] Advice on code location Message-ID: Hi I'm trying to use Python to build PyPy. One problem I noticed is the search paths for modules is not the same For PyPy and Python. I want to add code to the build process that will check if PyPy or Python is running. If Python is running, add paths to sys.path that would enable Python to find needed modules. Which file would be a good place to add such code? Thank you. From fijall at gmail.com Fri Sep 24 02:39:19 2021 From: fijall at gmail.com (Maciej Fijalkowski) Date: Fri, 24 Sep 2021 08:39:19 +0200 Subject: [pypy-dev] Does PyPy memory use benefit from preforking? In-Reply-To: References: Message-ID: Hi Tin As far as I remember PyPy has GC headers that have various bits set and cleared when walking the heap for garbage collection, so while it does not use reference counting, it would not benefit really from pre-forking either. There are some ideas how to make that work, btu none of them have been implemented. Best, Maciej Fijalkowski On Sat, 18 Sept 2021 at 21:58, Tin Tvrtkovi? wrote: > > Hello! > > A little bit of context: roughly speaking, preforking is a technique where a (supervisor) process is started, the process performs some initialization and then forks off into child worker processes, which it then supervises. It's usually used to make several worker processes share a server TCP socket (which they inherit from the supervisor). > > In some runtimes preforking can also be used to save memory since the child processes get copy-on-write access to the supervisor memory pages. My understanding is this doesn't actually yield anything on CPython since essentially everything is reference counted and memory pages get copied quickly. > > PyPy doesn't use reference counting though, so I was wondering if preforking could be used with PyPy for memory saving purposes. All of this is a little low-level for me, and I would appreciate any insight from the resident experts :) > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev From cfbolz at gmx.de Fri Sep 24 06:56:33 2021 From: cfbolz at gmx.de (Carl Friedrich Bolz-Tereick) Date: Fri, 24 Sep 2021 12:56:33 +0200 Subject: [pypy-dev] Advice on code location In-Reply-To: References: Message-ID: Hi Misbah, Welcome to the project! I am not going to reply to your actual question, but will give some general hints, based on your mails and your issues so far: - I think the most important question is, what are your plans? What do you actually want to work on? - A good way to get some faster feedback is to hang out on our IRC channel, #pypy on Libera: https://www.pypy.org/posts/2021/05/pypy-irc-moves-to-libera-chat.html - The Apple M1 is not supported yet, so you are bound to run into all kinds of errors. Maciej is planning to do some more work on it in the next couple of weeks. Cheers, Carl Friedrich On 22.09.21 03:11, M A wrote: > Hi I'm trying to use Python to build PyPy. One problem I noticed is > the search paths for modules is not the same For PyPy and Python. I > want to add code to the build process that will check if PyPy or > Python is running. If Python is running, add paths to sys.path that > would enable Python to find needed modules. Which file would be a > good place to add such code?