From matti.picus at gmail.com Wed Nov 11 04:02:21 2020 From: matti.picus at gmail.com (Matti Picus) Date: Wed, 11 Nov 2020 11:02:21 +0200 Subject: [pypy-dev] PyPy 7.3.3rc1 release candidates Message-ID: <33ff6636-2938-6a71-10ac-02e6cf1d8dc2@gmail.com> I have uploaded release candidates for PyPy 7.3.3rc1 to https://buildbot.pypy.org/pypy/ The hashes can be found at https://foss.heptapod.net/pypy/pypy.org/-/blob/branch/default/pages/download_advanced.rst#id45 The draft release note is at https://doc.pypy.org/en/latest/release-v7.3.3.html. I have decided to declare the python3.7 support "beta" level since we did get much feedback with issues with the previous "alpha" release. The conda migration is progressing and is the major motivating factor for this release. There are some slight packaging/c-api bugs that were exposed when trying to build the conda packages. We now can run scikit-learn and better support pybind11. Please try it out. Suggestions to improve the release note are also welcome. Matti From matti.picus at gmail.com Wed Nov 11 07:22:55 2020 From: matti.picus at gmail.com (Matti Picus) Date: Wed, 11 Nov 2020 14:22:55 +0200 Subject: [pypy-dev] Things to work on next Message-ID: <2fc066b0-3e1f-da2f-5f93-4338daaffba5@gmail.com> Here are PyPy things I want to do in the near future: - once the dust settles from the 7.3.3 release, merge the win64 branch to default - continue work to merge the win64-py3.6 branch to py3.6 - continue work on the rpython3 branch to see if we can get "cd pypy/doc; make html" to work with python3, for the future day when readthedocs drops python2 support (the idea is to make parts of rpython support both python2 and python3). Another solution for this may be to simplify the docs building so it does not import half of rpython just to document the options. At what point do we stop releasing python3.6? It is under long-term CPython support (no more binaries) and will be dropped from the next round of releases by the scientific python stack. I would like to move to py3.7 as the main branch of python development, but we should have clear criteria for deciding 3.7 is no longer beta. Here are a few things worth doing: - get it into conda by submitting a new conda recipe a PR along the lines of this comment https://github.com/conda-forge/conda-forge.github.io/issues/867#issuecomment-699536803. Once that is merged, conda will begin updating the ~1000 packages that already work for pypy3.6 ot pypy3.7. You can checkout the migration status at https://conda-forge.org/status/#pypy - finish the py3.7-rsre branch Is that enough? Once we drop 3.6, we should start a py3.8 branch. At what point would we consider it mature enough that we would want to make noise about asking for outside contributors to pitch in and make it work? Who else besides me would be up for reviewing and merging PRs? Matti N.B. Thanks to Ronan for a review of this mail before it went out here. Here are some interesting PyPy tidbits I saw lately: - run pypy in the cloud on binder (click on the "launch binder" badge) https://gist.github.com/bollwyvl/b5443c87c58b2e04ac5faba4d62ff232 - someone made a youtube video where they show 10 minutes about PyPy on a macOSx: they read parts of the website and show 'hello world' https://www.reddit.com/r/PyPy/comments/jreiud/made_this_tutorial_on_pypy/ From matti.picus at gmail.com Wed Nov 18 15:17:52 2020 From: matti.picus at gmail.com (Matti Picus) Date: Wed, 18 Nov 2020 22:17:52 +0200 Subject: [pypy-dev] PyPy 7.3.3rc2 release candidates Message-ID: I have uploaded release candidates for the second release candidate PyPy 7.3.3rc2 to https://buildbot.pypy.org/pypy/ The hashes can be found at https://foss.heptapod.net/pypy/pypy.org/-/blob/branch/default/pages/download_advanced.rst#id45 The draft release note is at https://doc.pypy.org/en/latest/release-v7.3.3.html. I have decided to declare the python3.7 support "beta" level since we did get much feedback with issues with the previous "alpha" release. The conda migration is progressing and is the major motivating factor for this release. There are some slight packaging/c-api bugs that were exposed when trying to build the conda packages. We now can run scikit-learn and better support pybind11. Please try it out. Suggestions to improve the release note are also welcome. If there are no issues I intend to release this on Friday Nov 20, unless there is demand that we ship the _hpy_universal module (which still need some tweaks) in the release. Matti From janusz.marecki at gmail.com Sun Nov 22 10:12:29 2020 From: janusz.marecki at gmail.com (Janusz Marecki) Date: Sun, 22 Nov 2020 15:12:29 +0000 Subject: [pypy-dev] Support for OS X arm64 Message-ID: Hi PyPy dev team -- Are there any plans for adding native support for the newly released OSX arm64 (M1) platform? Thank you! --Janusz Marecki From armin.rigo at gmail.com Mon Nov 23 02:02:38 2020 From: armin.rigo at gmail.com (Armin Rigo) Date: Mon, 23 Nov 2020 08:02:38 +0100 Subject: [pypy-dev] Support for OS X arm64 In-Reply-To: References: Message-ID: Hi Janusz, On Sun, 22 Nov 2020 at 16:51, Janusz Marecki wrote: > Hi PyPy dev team -- Are there any plans for adding native support for the newly released OSX arm64 (M1) platform? We can make such plans provided we get some support. It requires some work because we need to adapt the JIT (we support arm64 but of course OS X comes with its own calling convention and likely other differences). So far, two people in our group might each be willing, on some condition. My conditions are getting ssh access and a small-ish bounty of $3000. Fijal said "I think if someone sends me an arm64 OS X laptop, I'm willing to do it too", which may or may not be a cheaper option. In both cases, we need a machine to add to our buildbots; one solution would be to buy us an additional Mac Mini; another would be to guarantee 24/7 ssh access for the foreseeable future (i.e. not dropping out after 3 months, like occurred too often with our Mac buildbots). A bient?t, Armin. From matti.picus at gmail.com Thu Nov 26 13:16:05 2020 From: matti.picus at gmail.com (Matti Picus) Date: Thu, 26 Nov 2020 20:16:05 +0200 Subject: [pypy-dev] Switching nightly builds from py3.6 to py3.7 Message-ID: <99fae133-c7d8-87e5-1e9c-324200ddfd82@gmail.com> Now that the re fixes are in for py3.7, I think our primary branch for development should be py3.7, with backports to py3.6 if needed. PEP 494 for python 3.6 has that version in a security-fixes-only stage, so we should adopt a similar strategy (although some bug-fixes may be needed, especially around utf8 problems that are still cropping up). Toward that end, I have updated the buildbot configuration to build nightlies off the py3.7 branch instead of the py3.6 branch. So if you wish to obtain a newer build of py3.6, you will need to manually trigger the buildbots. This does not change the status of the default branch. Please let me know if this was too fast and you feel we should continue to use py3.6 as our primary branch for development. Matti From ronan.lamy at gmail.com Fri Nov 27 12:03:07 2020 From: ronan.lamy at gmail.com (Ronan Lamy) Date: Fri, 27 Nov 2020 17:03:07 +0000 Subject: [pypy-dev] Switching nightly builds from py3.6 to py3.7 In-Reply-To: <99fae133-c7d8-87e5-1e9c-324200ddfd82@gmail.com> References: <99fae133-c7d8-87e5-1e9c-324200ddfd82@gmail.com> Message-ID: <875ed6b2-8f20-68ec-5ec8-279474891913@gmail.com> On 26/11/2020 18:16, Matti Picus wrote: > Now that the re fixes are in for py3.7, I think our primary branch for > development should be py3.7, with backports to py3.6 if needed. PEP 494 > for python 3.6 has that version in a security-fixes-only stage, so we > should adopt a similar strategy (although some bug-fixes may be needed, > especially around utf8 problems that are still cropping up). I think it's a bad idea to reverse the direction of merges now. We still have quite a few fixes coming in for 3.6. > Toward that end, I have updated the buildbot configuration to build > nightlies off the py3.7 branch instead of the py3.6 branch. So if you > wish to obtain a newer build of py3.6, you will need to manually trigger > the buildbots. +1 though ideally we would just run both as nightlies. > This does not change the status of the default branch. > > > Please let me know if this was too fast and you feel we should continue > to use py3.6 as our primary branch for development. > > > Matti > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev From matti.picus at gmail.com Sat Nov 28 11:46:08 2020 From: matti.picus at gmail.com (Matti Picus) Date: Sat, 28 Nov 2020 18:46:08 +0200 Subject: [pypy-dev] Switching nightly builds from py3.6 to py3.7 In-Reply-To: <875ed6b2-8f20-68ec-5ec8-279474891913@gmail.com> References: <99fae133-c7d8-87e5-1e9c-324200ddfd82@gmail.com> <875ed6b2-8f20-68ec-5ec8-279474891913@gmail.com> Message-ID: <936326da-3a6f-deb8-222f-264790e12b39@gmail.com> On 11/27/20 7:03 PM, Ronan Lamy wrote: > On 26/11/2020 18:16, Matti Picus wrote: >> Now that the re fixes are in for py3.7, I think our primary branch >> for development should be py3.7, with backports to py3.6 if needed. >> PEP 494 for python 3.6 has that version in a security-fixes-only >> stage, so we should adopt a similar strategy (although some bug-fixes >> may be needed, especially around utf8 problems that are still >> cropping up). > > I think it's a bad idea to reverse the direction of merges now. We > still have quite a few fixes coming in for 3.6. > >> Toward that end, I have updated the buildbot configuration to build >> nightlies off the py3.7 branch instead of the py3.6 branch. So if you >> wish to obtain a newer build of py3.6, you will need to manually >> trigger the buildbots. > > +1 though ideally we would just run both as nightlies. The fixes so far for 3.6 (after the last release) have been - merge from default to fix default attributes in XML (issue 3333) - merges from default to support the py3.7 regex changes - merge from default of rpy-cparser (code rearrangement) - fixing _crypt import - fix utf_8_decode(... final=False) (issue 3348) - merge workaround to detect failed imports intests from default, which exposed missing _opcode builtin module The bug fixes were for XML, utf_8_decode, and _crypt, which could have been backported from py3.7 to py3.6 instead of forward merged from py3.6 to py3.7. Since we depend on contributed machines for our buildbot machines, I do not feel comfortable running 3 nightly builds. To be fair, maybe only the macOSx (contributed by someone who also runs CPython builds) and the windows (which I run on a VM at home) machines would notice the extra load, but it still seems an imposition. So if you accept the limitation of 2 nightly builds on windows and macOSx, which would you choose? Also take into account after we merge the win64 branch, windows runs may become unstable for a while. Matti