PyPy 3.3? (and: informal Cape Town sprint)
Hi Ronan, hi all, Can we fix a date after which we stop needing to update pypy 3.3? It is a (minor) mess that, whenever I find a bug or small missing feature in pypy 3.5, I usually try first to see if it should be done in the py3k (3.3) branch or directly in py3.5. In fact I would guess by now that I have misplaced one or two such fixes. Sorry about that. It would help reduce the overhead if we could all focus on py3.5. At the start of August, Ronan mentioned the last pypy 3.3 release being 1 or 2 months away. Ronan, can you say what you'd still like to do and what you'd like fixed first for the release? I can help you with that. I suggest that we tentatively fix the date of October the 8th for the release (this is just after PyCon ZA). Then we can then focus our South African sprint on py3.5. About the sprint: anyone around Cape Town for the two weeks after PyCon ZA is welcome to join. We don't have exactly a plan so far; for sure we will not be sprinting without some break days. A bientôt, Armin.
Le 17/09/16 à 10:02, Armin Rigo a écrit :
Hi Ronan, hi all,
Can we fix a date after which we stop needing to update pypy 3.3? It is a (minor) mess that, whenever I find a bug or small missing feature in pypy 3.5, I usually try first to see if it should be done in the py3k (3.3) branch or directly in py3.5. In fact I would guess by now that I have misplaced one or two such fixes. Sorry about that. It would help reduce the overhead if we could all focus on py3.5.
The advantage of having py3k is that regressions are much more visible there than on py3.5, but I agree that the overhead of having two py3 branches is too high. We can't go on like this for much longer.
At the start of August, Ronan mentioned the last pypy 3.3 release being 1 or 2 months away. Ronan, can you say what you'd still like to do and what you'd like fixed first for the release? I can help you with that.
For all remaining linux64 test failures, we should either fix them or explicitly decide not to bother (e.g. in cpyext). This mostly means reviewing and stabilising the buffer interface. Some issues also need to be fixed, like #2278 (os.stat()) and #2312 (venv). Also, win32 doesn't seem too far from working, so we should try to fix it as well. Finishing the posix module would be also be nice, though the last missing bits seem obscure enough that we can live without.
I suggest that we tentatively fix the date of October the 8th for the release (this is just after PyCon ZA). Then we can then focus our South African sprint on py3.5.
8 October seems doable, so +1.
About the sprint: anyone around Cape Town for the two weeks after PyCon ZA is welcome to join. We don't have exactly a plan so far; for sure we will not be sprinting without some break days.
A bientôt,
Armin.
I added PyPy to the list of PyConZA sprint topics -- https://za.pycon.org/news/sprints/.
Hi Simon, On 20 September 2016 at 18:08, Simon Cross <hodgestar@gmail.com> wrote:
I added PyPy to the list of PyConZA sprint topics -- https://za.pycon.org/news/sprints/.
Thanks! Armin
Hi Ronan, On 20 September 2016 at 17:34, Ronan Lamy <ronan.lamy@gmail.com> wrote:
For all remaining linux64 test failures, we should either fix them or explicitly decide not to bother (e.g. in cpyext). This mostly means reviewing and stabilising the buffer interface. Some issues also need to be fixed, like #2278 (os.stat()) and #2312 (venv).
Also, win32 doesn't seem too far from working, so we should try to fix it as well. Finishing the posix module would be also be nice, though the last missing bits seem obscure enough that we can live without.
Ok! I'll start with #2278 and then look at Windows, assuming nobody else does it before me. A bientôt, Armin.
On Sep 20, 2016, at 10:00 AM, Armin Rigo <arigo@tunes.org> wrote:
Hi Ronan,
On 20 September 2016 at 17:34, Ronan Lamy <ronan.lamy@gmail.com> wrote:
For all remaining linux64 test failures, we should either fix them or explicitly decide not to bother (e.g. in cpyext). This mostly means reviewing and stabilising the buffer interface. Some issues also need to be fixed, like #2278 (os.stat()) and #2312 (venv).
Also, win32 doesn't seem too far from working, so we should try to fix it as well. Finishing the posix module would be also be nice, though the last missing bits seem obscure enough that we can live without.
Ok! I'll start with #2278 and then look at Windows, assuming nobody else does it before me.
Mark Young and I have been slowly kicking py3k win32 back into shape. It’s to the point now where I thought it might translate again but py3k has been failing translation on all platforms for a couple weeks now (win32 fails in the same way as others). Assuming it translates when that's fixed, the major issue pending for it is #2310. — Philip Jenvey
Hi, On 21 September 2016 at 05:22, Philip Jenvey <pjenvey@underboss.org> wrote:
Mark Young and I have been slowly kicking py3k win32 back into shape. It’s to the point now where I thought it might translate again but py3k has been failing translation on all platforms for a couple weeks now (win32 fails in the same way as others).
Assuming it translates when that's fixed, the major issue pending for it is #2310.
Now win32 translates. But the list of failing tests is still impressively long. I have some doubts about fixing them quickly. Just looking around randomly, I found for example that sys.maxunicode has been changed to 1114111 even on Windows. This is part of the whole unicode refactoring: maxunicode is always 1114111, and you can get unichr(1114111); then on Windows when you try to use such a unicode string for a native FooW() function, the unicode string is converted into a wchar_t string, using surrogates if needed. Unsure if it is something we can quickly hack together to make Windows happy, or if it requires some more thinking about the whole unicode refactoring. As far as I can tell it's only one of the many failures. Maybe we can still translate and ship a Windows version of PyPy3.3, but it might be more broken than useful to users... Or maybe I'm just too negative. A bientôt, Armin.
Ah, you might be right about it being too broken/too much trouble, thanks for looking. I’m just happy to keep it translating to avoid collecting more subtle issues over time. Other than that finishing 3.3 on other platforms/moving 3.5 along is higher priority. -- Philip Jenvey
On Sep 22, 2016, at 12:23 AM, Armin Rigo <arigo@tunes.org> wrote:
Now win32 translates. But the list of failing tests is still impressively long. I have some doubts about fixing them quickly.
Just looking around randomly, I found for example that sys.maxunicode has been changed to 1114111 even on Windows. This is part of the whole unicode refactoring: maxunicode is always 1114111, and you can get unichr(1114111); then on Windows when you try to use such a unicode string for a native FooW() function, the unicode string is converted into a wchar_t string, using surrogates if needed. Unsure if it is something we can quickly hack together to make Windows happy, or if it requires some more thinking about the whole unicode refactoring.
As far as I can tell it's only one of the many failures. Maybe we can still translate and ship a Windows version of PyPy3.3, but it might be more broken than useful to users... Or maybe I'm just too negative.
participants (4)
-
Armin Rigo -
Philip Jenvey -
Ronan Lamy -
Simon Cross