From home at sbeyer.at Mon Feb 4 03:36:51 2019 From: home at sbeyer.at (Stefan Beyer) Date: Mon, 4 Feb 2019 09:36:51 +0100 Subject: [pypy-dev] PyPy Winter Sprint + cpyext Message-ID: <1f838620-b00c-76f6-ddd6-7f5523f31d46@sbeyer.at> Hey everyone! Those of you who attended or followed one of the last two winter sprints in Leysin might know me, the others probably won't. I'm (still) a Master's student writing my thesis on PyPy's current issue with cross-heap cycles when using cpyext. The main point is, that they are not collected and stay around as floating garbage, even if they are not reachable any more. Correct me if I'm wrong, but I didn't notice anyone else working on that topic (and/or committing something) since I've picked it up two years ago (yeah, I know, that long ago...). I saw that you would be working on "cpyext performance and completeness" during the current winter sprint this week and thought that this might also concern my thesis. So I thought I'll give you an update. I recently pushed my current (non-optimized, breaking-some-tests, but more or less working) implementation of the "CPython-style" GC-extension for cpyext. It is still in an early stage and not all cases (legacy and non-legacy-finalizers, weakrefs) are handled. However, I picked up some pace during the last couple of weeks and I'm determined to finish this implementation during the following weeks (some quirks with the tests have been haunting me, but I think I figured most of them out by now). After that, I will implement a second alternative implementation (to compare to, mostly for the sake of my thesis), which will take some more time. I also added a couple of fancy test cases (the so called "dot-tests"), so that we can test complex object graphs a little bit easier (and also because it was kind of cool to have another language inside PyPy/RPython, even if it was only for the tests...), with more test cases to come (the current ones are a bit messy). None of the new changes concerning low-latency applications are currently integrated, but that should not be too hard. I guess it won't make much sense for me to join you at this year's winter sprint, especially as I won't be able to get there before Thursday, but I might be able to join you over the IRC channel (or some other form of communication if you like). If there is anything that is worth discussing please let me know! Also feel free to comment on my code, but beware that I might change some things once I try to do some optimizations (probably not many, but at least fix the worst issues) and make it a little bit more readable. You can find my code on the cpyext-gc-cycle branch. Looking forward to hearing from you! Greetings, Stefan From anto.cuni at gmail.com Thu Feb 7 05:46:09 2019 From: anto.cuni at gmail.com (Antonio Cuni) Date: Thu, 7 Feb 2019 11:46:09 +0100 Subject: [pypy-dev] PyPy 7.0.0 release candidate Message-ID: Hi, I have uploaded all the packages for PyPy 7.0.0; the release is not yet official and we still need to write the release announcement, but the packages are already available here, for various platforms: https://bitbucket.org/pypy/pypy/downloads/ feel free to try them and please let me know if something is obviously wrong :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.picus at gmail.com Thu Feb 7 16:00:52 2019 From: matti.picus at gmail.com (Matti Picus) Date: Thu, 7 Feb 2019 22:00:52 +0100 Subject: [pypy-dev] Speed benchmarking Message-ID: <979f05de-f56d-b536-de72-6e89a209d818@gmail.com> An HTML attachment was scrubbed... URL: From armin.rigo at gmail.com Thu Feb 7 18:33:15 2019 From: armin.rigo at gmail.com (Armin Rigo) Date: Fri, 8 Feb 2019 00:33:15 +0100 Subject: [pypy-dev] PyPy 7.0.0 release candidate In-Reply-To: References: Message-ID: Hi Anto, On Thu, 7 Feb 2019 at 11:46, Antonio Cuni wrote: > I have uploaded all the packages for PyPy 7.0.0; the release is not yet official and we still need to write the release announcement, but the packages are already available here, for various platforms: It's unclear to me how you managed to translate the release-pypy2.7-v7.0.0 tag. I'm getting "InvalidArgument: Invalid argument deadline" in a call to hypothesis.settings() (rpython/conftest.py:14) and upgrading hypothesis doesn't seem to help... A bient?t, Armin. From armin.rigo at gmail.com Thu Feb 7 18:57:34 2019 From: armin.rigo at gmail.com (Armin Rigo) Date: Fri, 8 Feb 2019 00:57:34 +0100 Subject: [pypy-dev] PyPy 7.0.0 release candidate In-Reply-To: References: Message-ID: Re-hi, On Fri, 8 Feb 2019 at 00:33, Armin Rigo wrote: > getting "InvalidArgument: Invalid argument deadline" in a call to > hypothesis.settings() (rpython/conftest.py:14) and upgrading hypothesis > doesn't seem to help... My mistake, an old "hypothesis" kept being used. But the logic in rpython/conftest.py to detect old versions of hypothesis was broken. Fixed in default in 54492586de6f; maybe this should be cherry-picked for the release branch (for source downloads). A bient?t, Armin. From cfbolz at gmx.de Fri Feb 8 05:15:51 2019 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Fri, 8 Feb 2019 11:15:51 +0100 Subject: [pypy-dev] Users of PyPy on ARM 32bit Message-ID: Hi all, We are trying to gauge how many users there are of PyPy on 32 bit variants of ARM. If you are actively and regularly using PyPy on such a machine, please let us know, and also what kind of stuff you are doing with it. Cheers, Carl Friedrich From fijall at gmail.com Fri Feb 8 05:17:43 2019 From: fijall at gmail.com (Maciej Fijalkowski) Date: Fri, 8 Feb 2019 11:17:43 +0100 Subject: [pypy-dev] Feedback on pypy.org website revamp Message-ID: Hi everyone We are looking to redesign the main pypy website, how do people feel about the new quick look: https://baroquesoftware.com/pypy-website/web/ Best, Maciej Fijalkowski From fijall at gmail.com Fri Feb 8 05:26:38 2019 From: fijall at gmail.com (Maciej Fijalkowski) Date: Fri, 8 Feb 2019 11:26:38 +0100 Subject: [pypy-dev] Feedback on pypy.org website revamp In-Reply-To: References: Message-ID: Feedback from Nathaniel, so he does not have to write it: Imagining a skeptical viewer, the two questions that jump to mind: (1) "what, python 2.7.2? what kind of cooked benchmarks are these", (2) "yeah sure twisted, whatever, they still can't handle the C API or python 3" On Fri, Feb 8, 2019 at 11:17 AM Maciej Fijalkowski wrote: > > Hi everyone > > We are looking to redesign the main pypy website, how do people feel > about the new quick look: > > https://baroquesoftware.com/pypy-website/web/ > > Best, > Maciej Fijalkowski From yury at shurup.com Fri Feb 8 05:27:37 2019 From: yury at shurup.com (Yury V. Zaytsev) Date: Fri, 8 Feb 2019 11:27:37 +0100 (CET) Subject: [pypy-dev] Feedback on pypy.org website revamp In-Reply-To: References: Message-ID: Looks totally hot, only please add a bit more padding between the top navigation bar and browser window edge :) Also maybe add more pythonic details to the bigger version of the logo? a tongue, eyes? Not sure if you want to consciously divorce from the not so subtle reference there was in the past... On Fri, 8 Feb 2019, Maciej Fijalkowski wrote: > Hi everyone > > We are looking to redesign the main pypy website, how do people feel > about the new quick look: > > https://baroquesoftware.com/pypy-website/web/ > > Best, > Maciej Fijalkowski > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > -- Sincerely yours, Yury V. Zaytsev From steve at pearwood.info Fri Feb 8 07:40:14 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Fri, 8 Feb 2019 23:40:14 +1100 Subject: [pypy-dev] Feedback on pypy.org website revamp In-Reply-To: References: Message-ID: <20190208124014.GL1834@ando.pearwood.info> On Fri, Feb 08, 2019 at 11:17:43AM +0100, Maciej Fijalkowski wrote: > Hi everyone > > We are looking to redesign the main pypy website, how do people feel > about the new quick look: > > https://baroquesoftware.com/pypy-website/web/ The bar chart seems to be missing bars for CPython. While the legend shows grey for CPython the chart itself only shows blue PyPy bars. The text is much too low-contrast. Please don't use pale grey text on a white background, that is very difficult to read, especially for those of us who are no longer 16 with perfect 20:20 vision. If I'm reading the CSS properly, the page uses #a8b1b6 for the "muted" text ("PyPy trunk (with JIT) benchmark times...") -- that might as well be invisible. Actually, being invisible would be better for me, because then I wouldn't be straining my eyes trying to read it. The regular text seems to use #606c76 which I can read in small quantities, but not comfortably. It would be difficult to read large quantities of such grey text. (Although it does look nice when bolded, the extra weight makes a big difference.) https://www.contrastrebellion.com/ I don't know why the PyPy logo is shown in grey at the bottom of the page. For thirty years we've been educating users that grey is used for disabled or inactive elements, or text of lesser importance. I'm not saying make the logo screaming fluorescent green, but it shouldn't look like an inactive control. It should use the same blues as the main logo, just smaller. I especially like that there are no menus that pop out and annoy me every time I happen to mouse over parts of the page. The overall design seems nice and clean and not too "busy", which makes me happy. Fix the graph and increase the text contrast a bit and I'll like it a lot. Thank you. -- Steven From jacob at openend.se Fri Feb 8 07:31:56 2019 From: jacob at openend.se (Jacob =?ISO-8859-1?Q?Hall=E9n?=) Date: Fri, 08 Feb 2019 13:31:56 +0100 Subject: [pypy-dev] Feedback on pypy.org website revamp In-Reply-To: References: Message-ID: <96852979.bgDKX7Q48k@nell> I hope the middle button being blue is just an example. Otherwise it is confusing. Jacob fredag 8 februari 2019 kl. 11:17:43 CET skrev Maciej Fijalkowski: > Hi everyone > > We are looking to redesign the main pypy website, how do people feel > about the new quick look: > > https://baroquesoftware.com/pypy-website/web/ > > Best, > Maciej Fijalkowski > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev From ronan.lamy at gmail.com Fri Feb 8 08:15:20 2019 From: ronan.lamy at gmail.com (Ronan Lamy) Date: Fri, 8 Feb 2019 14:15:20 +0100 Subject: [pypy-dev] Feedback on pypy.org website revamp In-Reply-To: References: Message-ID: Do we really need a new logo? The old one has been our identity for years and was more distinctive. Apart from that, I think this is an improvement. Le ven. 8 f?vr. 2019 ? 11:18, Maciej Fijalkowski a ?crit : > Hi everyone > > We are looking to redesign the main pypy website, how do people feel > about the new quick look: > > https://baroquesoftware.com/pypy-website/web/ > > Best, > Maciej Fijalkowski > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anto.cuni at gmail.com Fri Feb 8 08:26:00 2019 From: anto.cuni at gmail.com (Antonio Cuni) Date: Fri, 8 Feb 2019 14:26:00 +0100 Subject: [pypy-dev] Feedback on pypy.org website revamp In-Reply-To: References: Message-ID: I agree, I like the old logo better. On Fri, Feb 8, 2019 at 2:15 PM Ronan Lamy wrote: > Do we really need a new logo? The old one has been our identity for years > and was more distinctive. > > Apart from that, I think this is an improvement. > > > Le ven. 8 f?vr. 2019 ? 11:18, Maciej Fijalkowski a > ?crit : > >> Hi everyone >> >> We are looking to redesign the main pypy website, how do people feel >> about the new quick look: >> >> https://baroquesoftware.com/pypy-website/web/ >> >> Best, >> Maciej Fijalkowski >> _______________________________________________ >> pypy-dev mailing list >> pypy-dev at python.org >> https://mail.python.org/mailman/listinfo/pypy-dev >> > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phyo.arkarlwin at gmail.com Fri Feb 8 10:39:57 2019 From: phyo.arkarlwin at gmail.com (Phyo Arkar) Date: Fri, 8 Feb 2019 22:09:57 +0630 Subject: [pypy-dev] Feedback on pypy.org website revamp In-Reply-To: References: Message-ID: - old logo is better - looks really great on mobile too. - color theme looks too facebookish - overalk huge thumbs up On Fri, Feb 8, 2019, 7:56 PM Antonio Cuni wrote: > I agree, I like the old logo better. > > On Fri, Feb 8, 2019 at 2:15 PM Ronan Lamy wrote: > >> Do we really need a new logo? The old one has been our identity for years >> and was more distinctive. >> >> Apart from that, I think this is an improvement. >> >> >> Le ven. 8 f?vr. 2019 ? 11:18, Maciej Fijalkowski a >> ?crit : >> >>> Hi everyone >>> >>> We are looking to redesign the main pypy website, how do people feel >>> about the new quick look: >>> >>> https://baroquesoftware.com/pypy-website/web/ >>> >>> Best, >>> Maciej Fijalkowski >>> _______________________________________________ >>> pypy-dev mailing list >>> pypy-dev at python.org >>> https://mail.python.org/mailman/listinfo/pypy-dev >>> >> _______________________________________________ >> pypy-dev mailing list >> pypy-dev at python.org >> https://mail.python.org/mailman/listinfo/pypy-dev >> > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfbolz at gmx.de Fri Feb 8 12:44:22 2019 From: cfbolz at gmx.de (Carl Friedrich Bolz-Tereick) Date: Fri, 08 Feb 2019 18:44:22 +0100 Subject: [pypy-dev] Fwd: Re: Users of PyPy on ARM 32bit In-Reply-To: References: Message-ID: -------- Original Message -------- From: Gelin Yan Sent: February 8, 2019 3:26:30 PM GMT+01:00 To: Carl Friedrich Bolz Subject: Re: [pypy-dev] Users of PyPy on ARM 32bit > > Hi Carl > We are using pypy with raspberry pi 3 for smart irrigation. Pypy works fine to us. Regards gelin yan -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Fri Feb 8 15:31:55 2019 From: njs at pobox.com (Nathaniel Smith) Date: Fri, 8 Feb 2019 12:31:55 -0800 Subject: [pypy-dev] Feedback on pypy.org website revamp In-Reply-To: <20190208124014.GL1834@ando.pearwood.info> References: <20190208124014.GL1834@ando.pearwood.info> Message-ID: On Fri, Feb 8, 2019, 04:40 Steven D'Aprano On Fri, Feb 08, 2019 at 11:17:43AM +0100, Maciej Fijalkowski wrote: > > Hi everyone > > > > We are looking to redesign the main pypy website, how do people feel > > about the new quick look: > > > > https://baroquesoftware.com/pypy-website/web/ > > The bar chart seems to be missing bars for CPython. While the legend > shows grey for CPython the chart itself only shows blue PyPy bars. > The grey is referring to the straight line at "1.0". Depending on how you're generating the graph this might be tricky, but often these kinds of graphs are more readable if you get rid of the legend and instead label the items directly. Like put the word "CPython" directly on top of the grey line, and then put "PyPy" next to the bars down below. -n -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.picus at gmail.com Sat Feb 9 05:11:29 2019 From: matti.picus at gmail.com (Matti Picus) Date: Sat, 9 Feb 2019 11:11:29 +0100 Subject: [pypy-dev] Anyone else going to PyCon USA? Message-ID: <643be722-a696-24b3-8331-02f3d125ab4a@gmail.com> An HTML attachment was scrubbed... URL: From ben.jolitz at gmail.com Fri Feb 8 20:21:41 2019 From: ben.jolitz at gmail.com (Ben Jolitz) Date: Fri, 8 Feb 2019 17:21:41 -0800 Subject: [pypy-dev] Feedback on pypy.org website revamp In-Reply-To: References: Message-ID: <665B05D2-F1D4-4FE2-B143-0C773CAC546A@gmail.com> Would it be a good idea to include a brief list of suggested applications for PyPy (web services, et al?) Also, a current practice in new software is to offer a docker image as a ?batteries included?/?try it without polluting user env? base image (alpine and ubuntu usually) - that may be something to consider. Ben > On Feb 8, 2019, at 7:39 AM, Phyo Arkar wrote: > > - old logo is better > - looks really great on mobile too. > - color theme looks too facebookish > - overalk huge thumbs up > > >> On Fri, Feb 8, 2019, 7:56 PM Antonio Cuni wrote: >> I agree, I like the old logo better. >> >>> On Fri, Feb 8, 2019 at 2:15 PM Ronan Lamy wrote: >>> Do we really need a new logo? The old one has been our identity for years and was more distinctive. >>> >>> Apart from that, I think this is an improvement. >>> >>> >>>> Le ven. 8 f?vr. 2019 ? 11:18, Maciej Fijalkowski a ?crit : >>>> Hi everyone >>>> >>>> We are looking to redesign the main pypy website, how do people feel >>>> about the new quick look: >>>> >>>> https://baroquesoftware.com/pypy-website/web/ >>>> >>>> Best, >>>> Maciej Fijalkowski >>>> _______________________________________________ >>>> pypy-dev mailing list >>>> pypy-dev at python.org >>>> https://mail.python.org/mailman/listinfo/pypy-dev >>> _______________________________________________ >>> pypy-dev mailing list >>> pypy-dev at python.org >>> https://mail.python.org/mailman/listinfo/pypy-dev >> _______________________________________________ >> pypy-dev mailing list >> pypy-dev at python.org >> https://mail.python.org/mailman/listinfo/pypy-dev > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From anto.cuni at gmail.com Mon Feb 11 05:57:12 2019 From: anto.cuni at gmail.com (Antonio Cuni) Date: Mon, 11 Feb 2019 11:57:12 +0100 Subject: [pypy-dev] PyPy 7.0.0 is out! Message-ID: ====================================================== PyPy v7.0.0: triple release of 2.7, 3.5 and 3.6-alpha ====================================================== The PyPy team is proud to release the version 7.0.0 of PyPy, which includes three different interpreters: - PyPy2.7, which is an interpreter supporting the syntax and the features of Python 2.7 - PyPy3.5, which supports Python 3.5 - PyPy3.6-alpha: this is the first official release of PyPy to support 3.6 features, although it is still considered alpha quality. All the interpreters are based on much the same codebase, thus the triple release. Until we can work with downstream providers to distribute builds with PyPy, we have made packages for some common packages `available as wheels`_. The `GC hooks`_ , which can be used to gain more insights into its performance, has been improved and it is now possible to manually manage the GC by using a combination of ``gc.disable`` and ``gc.collect_step``. See the `GC blog post`_. .. _`GC hooks`: http://doc.pypy.org/en/latest/gc_info.html#semi-manual-gc-management We updated the `cffi`_ module included in PyPy to version 1.12, and the `cppyy`_ backend to 1.4. Please use these to wrap your C and C++ code, respectively, for a JIT friendly experience. As always, this release is 100% compatible with the previous one and fixed several issues and bugs raised by the growing community of PyPy users. We strongly recommend updating. The PyPy3.6 release and the Windows PyPy3.5 release are still not production quality so your mileage may vary. There are open issues with incomplete compatibility and c-extension support. The utf8 branch that changes internal representation of unicode to utf8 did not make it into the release, so there is still more goodness coming. You can download the v7.0 releases here: http://pypy.org/download.html We would like to thank our donors for the continued support of the PyPy project. If PyPy is not quite good enough for your needs, we are available for direct consulting work. We would also like to thank our contributors and encourage new people to join the project. PyPy has many layers and we need help with all of them: `PyPy`_ and `RPython`_ documentation improvements, tweaking popular modules to run on pypy, or general `help`_ with making RPython's JIT even better. .. _`PyPy`: index.html .. _`RPython`: https://rpython.readthedocs.org .. _`help`: project-ideas.html .. _`cffi`: http://cffi.readthedocs.io .. _`cppyy`: https://cppyy.readthedocs.io .. _`available as wheels`: https://github.com/antocuni/pypy-wheels .. _`GC blog post`: https://morepypy.blogspot.com/2019/01/pypy-for-low-latency-systems.html What is PyPy? ============= PyPy is a very compliant Python interpreter, almost a drop-in replacement for CPython 2.7, 3.5 and 3.6. It's fast (`PyPy and CPython 2.7.x`_ performance comparison) due to its integrated tracing JIT compiler. We also welcome developers of other `dynamic languages`_ to see what RPython can do for them. The PyPy release supports: * **x86** machines on most common operating systems (Linux 32/64 bits, Mac OS X 64 bits, Windows 32 bits, OpenBSD, FreeBSD) * big- and little-endian variants of **PPC64** running Linux, * **s390x** running Linux Unfortunately at the moment of writing our ARM buildbots are out of service, so for now we are **not** releasing any binary for the ARM architecture. .. _`PyPy and CPython 2.7.x`: http://speed.pypy.org .. _`dynamic languages`: http://rpython.readthedocs.io/en/latest/examples.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfbolz at gmx.de Mon Feb 11 10:46:54 2019 From: cfbolz at gmx.de (Carl Friedrich Bolz-Tereick) Date: Mon, 11 Feb 2019 16:46:54 +0100 Subject: [pypy-dev] let's clean up open branches Message-ID: Hi all, Armin and I briefly looked at the long list of our open branches today. Could everybody take a look which of "their" branches could be closed, or maybe merged? see list below, ordered by last committer on the branch, and date. For future reference, the command that I used to get the list is: hg log -r "reverse(head()-parents(merge())-closed()-tag(tip))" --template "{author} {date|isodate} {branch}\n" | sort Thanks Carl Friedrich Alexander Hesse 2013-02-13 19:30 +0100 quiet-rpython Alexander Hesse 2014-01-21 18:51 +0000 pypy-alone Alexander Hesse 2014-01-21 18:51 +0000 rpython-alone Alexander Hesse 2014-01-31 00:23 +0100 prepare-split Alex Gaynor 2012-02-18 12:48 -0500 numpypy-ctypes Alex Gaynor 2012-02-24 13:41 -0500 numpy-record-type-pure-python Alex Gaynor 2012-03-01 17:37 -0500 jit-tracehook Alex Gaynor 2012-03-04 17:40 -0500 struct-double Alex Gaynor 2012-05-12 21:20 +0200 dynamic-specialized-tuple Alex Gaynor 2013-02-02 16:13 -0800 jit-sys-exc-info Alex Gaynor 2013-03-17 10:38 -0700 asm-backend-dupe-removal Alex Gaynor 2013-09-07 11:16 -0700 unroll-virtual-dict-resize Alex Gaynor 2013-10-15 17:50 -0700 python-loop-unroll Amaury Forgeot d'Arc 2010-01-22 17:32 +0000 separate-compilation Amaury Forgeot d'Arc 2010-06-09 15:56 +0000 cpyext-init-cleanup Amaury Forgeot d'Arc 2010-07-16 20:39 +0000 unicode_filename-2 Amaury Forgeot d'Arc 2011-03-05 00:58 +0100 real-rffi.INT Amaury Forgeot d'Arc 2011-04-29 11:58 +0200 mingw32-build Amaury Forgeot d'Arc 2011-08-31 01:34 +0200 compile-from-stream Amaury Forgeot d'Arc 2012-04-03 00:20 +0200 sepcomp2 Amaury Forgeot d'Arc 2013-07-24 12:07 +0200 missing-os-functions Amaury Forgeot d'Arc 2013-09-13 21:54 +0200 const-correctness Amaury Forgeot d'Arc 2014-07-13 23:02 +0200 wrap-bytes Amaury Forgeot d'Arc 2014-08-18 09:16 +0200 split-ast-classes Amaury Forgeot d'Arc 2014-10-05 20:21 +0200 decimal-libmpdec Amaury Forgeot d'Arc 2015-01-12 22:11 +0100 kill_ll_time Amaury Forgeot d'Arc 2016-04-13 20:36 +0200 ast-arena Amaury Forgeot d'Arc 2016-10-01 19:25 +0200 py35-getbuiltin andrewjlawrence 2019-02-10 20:59 +0000 winoverlapped Antonio Cuni 2012-01-20 17:26 +0100 core-only-tracing Antonio Cuni 2012-10-26 14:33 +0200 py3k-listview_str Antonio Cuni 2014-01-17 22:54 +0100 utf8-unicode Antonio Cuni 2017-10-08 00:50 +0200 cpyext-nowrapper Antonio Cuni 2017-11-10 16:42 +0100 vmprof-enable-kwargs Antonio Cuni 2017-11-15 02:11 +0100 continulet-no-frame-loop Antonio Cuni 2017-11-16 19:21 +0100 continulet-no-frame-loop-2 Antonio Cuni 2018-02-05 10:55 +0100 vmprof-resolve_addr Antonio Cuni 2019-02-11 11:50 +0100 default Armin Rigo 2011-02-24 15:33 +0100 lltrace Armin Rigo 2011-09-04 10:47 +0200 shadowstack-perf Armin Rigo 2012-01-22 20:20 +0100 32ptr-on-64bit Armin Rigo 2012-08-29 17:31 +0200 stm-jit Armin Rigo 2013-06-28 15:22 +0200 stm-gc-2 Armin Rigo 2013-09-15 10:35 +0200 stmgc-static-barrier Armin Rigo 2013-09-25 16:11 +0000 gcremovetypeptr-32bit Armin Rigo 2013-11-04 20:51 +0100 array-overallocation-in-nursery Armin Rigo 2014-06-15 11:22 +0200 stringbuilder-perf Armin Rigo 2014-12-14 17:41 +0100 no-silent-merging-of-int-types Armin Rigo 2015-02-08 20:33 +0100 optimize-locks Armin Rigo 2015-07-29 17:21 +0200 fix-strbuf Armin Rigo 2015-11-29 16:17 +0100 stmgc-c8-dictstrategy Armin Rigo 2016-10-08 07:41 +0200 release-5.x Armin Rigo 2016-12-11 15:29 +0100 utf8sp Armin Rigo 2016-12-29 19:02 +0100 sandbox-lib Armin Rigo 2017-01-21 11:12 +0100 nogil-unsafe Armin Rigo 2017-02-24 15:19 +0000 gc-forkfriendly-2 Armin Rigo 2017-09-02 11:33 +0200 nogil-unsafe-2 Armin Rigo 2017-10-01 09:10 +0200 len_w Armin Rigo 2017-12-18 21:52 +0100 mmap-for-arenas Armin Rigo 2018-07-24 14:38 +0200 guard-compatible Armin Rigo 2019-02-08 00:54 +0100 release-pypy2.7-7.x Armin Rigo 2019-02-08 00:54 +0100 release-pypy3.5-7.x Armin Rigo 2019-02-08 00:54 +0100 release-pypy3.6-7.x Brian Kearns 2014-09-20 17:19 -0400 use-file-star-for-file Carl Friedrich Bolz 2013-04-24 17:17 +0200 int-tag-untag-as-operations Carl Friedrich Bolz 2013-07-11 22:13 +0200 faster-set-of-iterator Carl Friedrich Bolz 2015-08-10 15:35 +0200 gc-vmprof Carl Friedrich Bolz 2016-01-22 17:47 +0100 value-profiling Carl Friedrich Bolz 2016-02-23 18:32 +0100 statistics-maps Carl Friedrich Bolz 2016-02-27 17:01 +0100 speed-up-stringsearch Carl Friedrich Bolz 2016-03-05 13:32 +0100 global-cell-cache Carl Friedrich Bolz 2016-04-29 12:08 +0300 share-mapdict-methods Carl Friedrich Bolz 2016-06-06 17:17 +0200 applevel-unroll-safe Carl Friedrich Bolz 2016-06-13 16:44 +0200 hypothesis-apptest Carl Friedrich Bolz 2016-11-20 22:59 +0100 better-storesink Carl Friedrich Bolz 2017-03-29 20:11 +0200 fix-2198 Carl Friedrich Bolz 2017-08-07 00:09 +0200 bridgeopt-improvements Carl Friedrich Bolz-Tereick 2017-12-03 22:24 +0100 intbound-improvements Carl Friedrich Bolz-Tereick 2018-03-12 14:47 +0100 parser-tuning Catalin Gabriel Manciu 2016-04-14 15:52 +0300 detect_cpu_count Corbin Simpson 2014-07-03 11:35 -0700 promote-unicode Daniel Roberts 2011-04-10 15:39 -0700 fold_intadd Dario Bertini 2011-07-01 12:14 +0200 int32on64-experiment David Malcolm 2015-01-12 12:43 -0500 libgccjit-backend Devin Jeanpierre 2016-06-13 15:35 -0700 gc-forkfriendly Edd Barrett 2016-08-15 14:52 +0100 w-xor-x Edd Barrett 2016-09-02 16:14 +0100 asmmemmgr-for-code-only fijal 2016-03-29 14:15 +0200 faster-traceback fijal 2017-05-11 18:20 +0200 str-measure fijal 2017-10-25 09:24 +0200 ssl-context-share fijal 2017-11-02 11:37 +0100 canraise-assertionerror Hakan Ardo 2011-02-02 06:59 +0100 jit-fromstart Hakan Ardo 2011-02-17 14:18 +0100 guard-improvements Hakan Ardo 2011-03-27 18:01 +0200 jit-usable_retrace Hakan Ardo 2011-08-20 09:57 +0200 jit-limit_peeling Hakan Ardo 2012-01-05 10:41 +0100 jit-usable_retrace_2 Hakan Ardo 2013-02-04 22:39 +0100 jit-usable_retrace_3 Ilya Osadchiy 2011-10-19 22:51 +0200 numpy-comparison Joannah Nanjekye 2017-02-25 13:30 +0300 pread/pwrite JohnDoe 2016-04-07 12:10 +0300 get-heap-stats Justin Peel 2011-09-06 09:38 -0600 gc-trace-faster Lars Wassermann 2013-03-08 13:45 +0100 type-specialized-instances Laurence Tratt 2013-11-26 15:45 +0000 more_strategies ?ukasz Langa 2019-02-08 17:39 +0100 py3.6 Maciej Fijalkowski 2019-02-09 16:18 +0000 arm64 Manuel Jacob 2015-03-01 12:35 +0100 spaceops-are-variables Manuel Jacob 2017-03-03 01:47 +0100 gcc-lto Manuel Jacob 2017-04-10 23:58 +0200 llvm-translation-backend Manuel Jacob 2019-02-06 16:55 +0100 ann-systemexit Matti Picus 2016-05-05 18:04 +0300 numpy_broadcast_nd Matti Picus 2016-05-30 22:11 +0300 release-pypy3.3-v5 Matti Picus 2016-06-03 15:44 +0300 cpyext-inheritance Matti Picus 2016-07-10 08:30 -0400 override-tp_as-methods Matti Picus 2016-10-02 09:17 +0300 numpypy_pickle_compat Matti Picus 2016-10-17 22:56 +0300 rmod-radd-slots Matti Picus 2016-10-26 20:10 +0300 pypy-config Matti Picus 2017-06-30 18:26 -0400 cpyext-injection Matti Picus 2017-07-10 22:57 +0300 cpyext-add_newdoc Matti Picus 2017-08-04 13:39 +0300 cpyext-debug-type_dealloc Matti Picus 2017-09-11 18:06 +0300 cpyext-tp_dictoffset Matti Picus 2017-09-25 20:42 +0300 win32-slow-tests Matti Picus 2017-10-03 13:49 +0300 release-pypy2.7-5.x Matti Picus 2017-10-03 13:53 +0300 release-pypy3.5-5.x Matti Picus 2017-11-03 14:19 +0200 matplotlib Matti Picus 2017-11-09 19:58 +0200 win32-vmprof Matti Picus 2017-12-19 11:26 +0200 non-linux-vmprof-stacklet-switch-2 Matti Picus 2017-12-21 20:00 +0200 release-pypy2.7-v5.9.x Matti Picus 2018-01-10 16:58 +0200 release-pypy3.5-v5.9.x Matti Picus 2018-04-23 01:01 +0300 issue2806_tp_init Matti Picus 2018-10-12 10:35 +0300 release-pypy3.5-6.x Matti Picus 2018-10-28 19:35 +0200 unicode-from-unicode-in-c Matti Picus 2019-02-05 17:09 +0200 windowsinstaller Matti Picus 2019-02-11 11:10 +0200 unicode-utf8-py3 mattip 2015-06-26 11:39 +0300 pypy3-release-2.6.x mattip 2015-10-19 17:04 +0800 ndarray-promote Nicolas Truessel 2017-06-16 15:11 +0200 quad-color-gc Philip Jenvey 2014-06-22 18:56 -0700 pypy3-release-2.3.x Philip Jenvey 2014-08-07 17:20 -0700 py3k-qualname Philip Jenvey 2014-10-20 16:41 -0700 pypy3-release-2.4.x Philip Jenvey 2016-05-24 23:14 -0700 py3k-osxfix Remi Meier 2017-06-14 09:51 +0200 stmgc-c8 Remi Meier 2018-03-24 16:52 +0100 guard-value-limit Richard Plangger 2016-03-15 11:31 +0100 gcstress-hypothesis Richard Plangger 2016-10-11 16:56 +0200 py3.3 Richard Plangger 2016-12-20 16:57 +0100 interp-opt Richard Plangger 2017-03-02 18:31 +0100 cpyext-callopt Richard Plangger 2017-04-04 18:03 -0400 vmprof-multiple-eval-funcs Richard Plangger 2017-06-07 10:41 -0400 vmprof-0.4.8 Richard Plangger 2015-06-10 12:06 +0200 vmprof-address Romain Guillebert 2014-01-22 17:19 +0100 numpypy-array_prepare_-array_wrap Ronan Lamy 2013-04-11 20:55 +0100 longdouble2 Ronan Lamy 2013-05-05 19:18 +0100 Opcode-class Ronan Lamy 2014-02-16 03:23 +0000 singledispatch Ronan Lamy 2014-05-14 20:04 +0100 HopArg Ronan Lamy 2014-06-17 19:19 +0100 rpath-enforceargs Ronan Lamy 2014-11-09 00:22 +0000 online-transforms Ronan Lamy 2014-11-18 02:22 +0000 expressions-2 Ronan Lamy 2015-02-16 19:21 +0000 framestate Ronan Lamy 2015-03-03 01:05 +0000 inline-earlier Ronan Lamy 2015-10-11 05:41 +0100 llconst Ronan Lamy 2015-11-22 18:00 +0000 exc-later Ronan Lamy 2016-01-30 18:16 +0000 SomeRange Ronan Lamy 2016-03-09 20:43 +0000 pypy3.3-bootstrap Ronan Lamy 2016-03-16 21:04 +0000 bootstrap-clarity Ronan Lamy 2016-09-06 15:38 +0100 union-side-effects Ronan Lamy 2016-09-12 01:29 +0100 _py3k-cpyext-A Ronan Lamy 2016-11-25 18:55 +0000 reflowing Ronan Lamy 2017-03-14 17:45 +0000 stricter-encode Ronan Lamy 2017-05-20 21:09 +0100 strbufobject Ronan Lamy 2017-05-31 12:15 +0100 rawrefcount-review Ronan Lamy 2017-08-05 14:15 +0100 install-rpython Ronan Lamy 2017-11-05 20:49 +0000 assert-rewrite Ronan Lamy 2017-11-19 01:40 +0000 fix-broken-types Ronan Lamy 2017-12-10 05:27 +0000 unicode-utf8-test Ronan Lamy 2018-03-04 18:48 +0000 rgil-cffi Ronan Lamy 2019-01-31 16:10 +0000 apptest-file Ronan Lamy 2019-01-31 16:13 +0000 py3tests Ronny Pfannschmidt 2014-10-05 17:51 +0200 refine-testrunner Ronny Pfannschmidt 2015-02-18 17:26 +0100 vendoring Ronny Pfannschmidt 2012-07-01 13:57 +0200 kill-import_from_lib_pypy Ronny Pfannschmidt 2013-02-08 15:35 +0100 pytest Ronny Pfannschmidt 2013-04-11 23:17 +0200 pytest-update Spenser Andrew Bauman 2016-11-18 17:26 -0500 value-classes Spenser Bauman 2016-04-05 21:54 -0400 remove-getarrayitem-pure Stefan Beyer 2017-08-31 14:45 +0200 cpyext-gc-trialdeletion Stefan Beyer 2019-02-03 23:06 +0100 cpyext-gc-cycle Timo Paulssen 2011-09-24 20:35 +0200 numpy-random Timo Paulssen 2011-10-04 00:35 +0200 numpy-data-buffer Timo Paulssen 2012-01-10 13:56 +0100 strbuf_by_default Timo Paulssen 2012-11-23 13:28 +0100 py3k-ceil-floor Tyler Wade 2014-07-28 13:02 -0500 rpython-__eq__ Tyler Wade 2014-09-07 12:38 -0500 utf8-unicode2 Vincent Legoll 2015-12-29 11:06 +0100 fix-1674 Vincent Legoll 2016-01-14 22:45 +0100 repeatlist_strategy William ML Leslie 2017-01-24 12:54 +1100 taskengine-sorted-optionals William ML Leslie 2017-01-24 18:55 +1100 inline-taskengine From fijall at gmail.com Mon Feb 11 11:06:38 2019 From: fijall at gmail.com (Maciej Fijalkowski) Date: Mon, 11 Feb 2019 17:06:38 +0100 Subject: [pypy-dev] let's clean up open branches In-Reply-To: References: Message-ID: of course you should have sorted by last name first, but display first name first. Sorry.... On Mon, Feb 11, 2019 at 4:53 PM Carl Friedrich Bolz-Tereick wrote: > > Hi all, > > Armin and I briefly looked at the long list of our open branches today. > Could everybody take a look which of "their" branches could be closed, > or maybe merged? see list below, ordered by last committer on the > branch, and date. > > For future reference, the command that I used to get the list is: > > hg log -r "reverse(head()-parents(merge())-closed()-tag(tip))" > --template "{author} {date|isodate} {branch}\n" | sort > > Thanks > > Carl Friedrich > > > Alexander Hesse 2013-02-13 19:30 +0100 > quiet-rpython > Alexander Hesse 2014-01-21 18:51 +0000 pypy-alone > Alexander Hesse 2014-01-21 18:51 +0000 > rpython-alone > Alexander Hesse 2014-01-31 00:23 +0100 > prepare-split > Alex Gaynor 2012-02-18 12:48 -0500 numpypy-ctypes > Alex Gaynor 2012-02-24 13:41 -0500 > numpy-record-type-pure-python > Alex Gaynor 2012-03-01 17:37 -0500 jit-tracehook > Alex Gaynor 2012-03-04 17:40 -0500 struct-double > Alex Gaynor 2012-05-12 21:20 +0200 > dynamic-specialized-tuple > Alex Gaynor 2013-02-02 16:13 -0800 jit-sys-exc-info > Alex Gaynor 2013-03-17 10:38 -0700 > asm-backend-dupe-removal > Alex Gaynor 2013-09-07 11:16 -0700 > unroll-virtual-dict-resize > Alex Gaynor 2013-10-15 17:50 -0700 > python-loop-unroll > Amaury Forgeot d'Arc 2010-01-22 17:32 +0000 > separate-compilation > Amaury Forgeot d'Arc 2010-06-09 15:56 +0000 > cpyext-init-cleanup > Amaury Forgeot d'Arc 2010-07-16 20:39 +0000 > unicode_filename-2 > Amaury Forgeot d'Arc 2011-03-05 00:58 +0100 > real-rffi.INT > Amaury Forgeot d'Arc 2011-04-29 11:58 +0200 > mingw32-build > Amaury Forgeot d'Arc 2011-08-31 01:34 +0200 > compile-from-stream > Amaury Forgeot d'Arc 2012-04-03 00:20 +0200 sepcomp2 > Amaury Forgeot d'Arc 2013-07-24 12:07 +0200 > missing-os-functions > Amaury Forgeot d'Arc 2013-09-13 21:54 +0200 > const-correctness > Amaury Forgeot d'Arc 2014-07-13 23:02 +0200 wrap-bytes > Amaury Forgeot d'Arc 2014-08-18 09:16 +0200 > split-ast-classes > Amaury Forgeot d'Arc 2014-10-05 20:21 +0200 > decimal-libmpdec > Amaury Forgeot d'Arc 2015-01-12 22:11 +0100 > kill_ll_time > Amaury Forgeot d'Arc 2016-04-13 20:36 +0200 ast-arena > Amaury Forgeot d'Arc 2016-10-01 19:25 +0200 > py35-getbuiltin > andrewjlawrence 2019-02-10 20:59 +0000 winoverlapped > Antonio Cuni 2012-01-20 17:26 +0100 core-only-tracing > Antonio Cuni 2012-10-26 14:33 +0200 py3k-listview_str > Antonio Cuni 2014-01-17 22:54 +0100 utf8-unicode > Antonio Cuni 2017-10-08 00:50 +0200 cpyext-nowrapper > Antonio Cuni 2017-11-10 16:42 +0100 > vmprof-enable-kwargs > Antonio Cuni 2017-11-15 02:11 +0100 > continulet-no-frame-loop > Antonio Cuni 2017-11-16 19:21 +0100 > continulet-no-frame-loop-2 > Antonio Cuni 2018-02-05 10:55 +0100 > vmprof-resolve_addr > Antonio Cuni 2019-02-11 11:50 +0100 default > Armin Rigo 2011-02-24 15:33 +0100 lltrace > Armin Rigo 2011-09-04 10:47 +0200 shadowstack-perf > Armin Rigo 2012-01-22 20:20 +0100 32ptr-on-64bit > Armin Rigo 2012-08-29 17:31 +0200 stm-jit > Armin Rigo 2013-06-28 15:22 +0200 stm-gc-2 > Armin Rigo 2013-09-15 10:35 +0200 stmgc-static-barrier > Armin Rigo 2013-09-25 16:11 +0000 gcremovetypeptr-32bit > Armin Rigo 2013-11-04 20:51 +0100 > array-overallocation-in-nursery > Armin Rigo 2014-06-15 11:22 +0200 stringbuilder-perf > Armin Rigo 2014-12-14 17:41 +0100 > no-silent-merging-of-int-types > Armin Rigo 2015-02-08 20:33 +0100 optimize-locks > Armin Rigo 2015-07-29 17:21 +0200 fix-strbuf > Armin Rigo 2015-11-29 16:17 +0100 stmgc-c8-dictstrategy > Armin Rigo 2016-10-08 07:41 +0200 release-5.x > Armin Rigo 2016-12-11 15:29 +0100 utf8sp > Armin Rigo 2016-12-29 19:02 +0100 sandbox-lib > Armin Rigo 2017-01-21 11:12 +0100 nogil-unsafe > Armin Rigo 2017-02-24 15:19 +0000 gc-forkfriendly-2 > Armin Rigo 2017-09-02 11:33 +0200 nogil-unsafe-2 > Armin Rigo 2017-10-01 09:10 +0200 len_w > Armin Rigo 2017-12-18 21:52 +0100 mmap-for-arenas > Armin Rigo 2018-07-24 14:38 +0200 guard-compatible > Armin Rigo 2019-02-08 00:54 +0100 release-pypy2.7-7.x > Armin Rigo 2019-02-08 00:54 +0100 release-pypy3.5-7.x > Armin Rigo 2019-02-08 00:54 +0100 release-pypy3.6-7.x > Brian Kearns 2014-09-20 17:19 -0400 > use-file-star-for-file > Carl Friedrich Bolz 2013-04-24 17:17 +0200 > int-tag-untag-as-operations > Carl Friedrich Bolz 2013-07-11 22:13 +0200 > faster-set-of-iterator > Carl Friedrich Bolz 2015-08-10 15:35 +0200 gc-vmprof > Carl Friedrich Bolz 2016-01-22 17:47 +0100 value-profiling > Carl Friedrich Bolz 2016-02-23 18:32 +0100 statistics-maps > Carl Friedrich Bolz 2016-02-27 17:01 +0100 > speed-up-stringsearch > Carl Friedrich Bolz 2016-03-05 13:32 +0100 global-cell-cache > Carl Friedrich Bolz 2016-04-29 12:08 +0300 > share-mapdict-methods > Carl Friedrich Bolz 2016-06-06 17:17 +0200 > applevel-unroll-safe > Carl Friedrich Bolz 2016-06-13 16:44 +0200 > hypothesis-apptest > Carl Friedrich Bolz 2016-11-20 22:59 +0100 better-storesink > Carl Friedrich Bolz 2017-03-29 20:11 +0200 fix-2198 > Carl Friedrich Bolz 2017-08-07 00:09 +0200 > bridgeopt-improvements > Carl Friedrich Bolz-Tereick 2017-12-03 22:24 +0100 > intbound-improvements > Carl Friedrich Bolz-Tereick 2018-03-12 14:47 +0100 > parser-tuning > Catalin Gabriel Manciu 2016-04-14 > 15:52 +0300 detect_cpu_count > Corbin Simpson 2014-07-03 11:35 -0700 > promote-unicode > Daniel Roberts 2011-04-10 15:39 -0700 fold_intadd > Dario Bertini 2011-07-01 12:14 +0200 > int32on64-experiment > David Malcolm 2015-01-12 12:43 -0500 libgccjit-backend > Devin Jeanpierre 2016-06-13 15:35 -0700 > gc-forkfriendly > Edd Barrett 2016-08-15 14:52 +0100 w-xor-x > Edd Barrett 2016-09-02 16:14 +0100 > asmmemmgr-for-code-only > fijal 2016-03-29 14:15 +0200 faster-traceback > fijal 2017-05-11 18:20 +0200 str-measure > fijal 2017-10-25 09:24 +0200 ssl-context-share > fijal 2017-11-02 11:37 +0100 canraise-assertionerror > Hakan Ardo 2011-02-02 06:59 +0100 jit-fromstart > Hakan Ardo 2011-02-17 14:18 +0100 guard-improvements > Hakan Ardo 2011-03-27 18:01 +0200 jit-usable_retrace > Hakan Ardo 2011-08-20 09:57 +0200 jit-limit_peeling > Hakan Ardo 2012-01-05 10:41 +0100 jit-usable_retrace_2 > Hakan Ardo 2013-02-04 22:39 +0100 jit-usable_retrace_3 > Ilya Osadchiy 2011-10-19 22:51 +0200 > numpy-comparison > Joannah Nanjekye 2017-02-25 13:30 +0300 > pread/pwrite > JohnDoe 2016-04-07 12:10 +0300 get-heap-stats > Justin Peel 2011-09-06 09:38 -0600 gc-trace-faster > Lars Wassermann 2013-03-08 13:45 +0100 > type-specialized-instances > Laurence Tratt 2013-11-26 15:45 +0000 more_strategies > ?ukasz Langa 2019-02-08 17:39 +0100 py3.6 > Maciej Fijalkowski 2019-02-09 16:18 +0000 arm64 > Manuel Jacob 2015-03-01 12:35 +0100 > spaceops-are-variables > Manuel Jacob 2017-03-03 01:47 +0100 gcc-lto > Manuel Jacob 2017-04-10 23:58 +0200 > llvm-translation-backend > Manuel Jacob 2019-02-06 16:55 +0100 ann-systemexit > Matti Picus 2016-05-05 18:04 +0300 > numpy_broadcast_nd > Matti Picus 2016-05-30 22:11 +0300 > release-pypy3.3-v5 > Matti Picus 2016-06-03 15:44 +0300 > cpyext-inheritance > Matti Picus 2016-07-10 08:30 -0400 > override-tp_as-methods > Matti Picus 2016-10-02 09:17 +0300 > numpypy_pickle_compat > Matti Picus 2016-10-17 22:56 +0300 rmod-radd-slots > Matti Picus 2016-10-26 20:10 +0300 pypy-config > Matti Picus 2017-06-30 18:26 -0400 cpyext-injection > Matti Picus 2017-07-10 22:57 +0300 cpyext-add_newdoc > Matti Picus 2017-08-04 13:39 +0300 > cpyext-debug-type_dealloc > Matti Picus 2017-09-11 18:06 +0300 > cpyext-tp_dictoffset > Matti Picus 2017-09-25 20:42 +0300 win32-slow-tests > Matti Picus 2017-10-03 13:49 +0300 > release-pypy2.7-5.x > Matti Picus 2017-10-03 13:53 +0300 > release-pypy3.5-5.x > Matti Picus 2017-11-03 14:19 +0200 matplotlib > Matti Picus 2017-11-09 19:58 +0200 win32-vmprof > Matti Picus 2017-12-19 11:26 +0200 > non-linux-vmprof-stacklet-switch-2 > Matti Picus 2017-12-21 20:00 +0200 > release-pypy2.7-v5.9.x > Matti Picus 2018-01-10 16:58 +0200 > release-pypy3.5-v5.9.x > Matti Picus 2018-04-23 01:01 +0300 issue2806_tp_init > Matti Picus 2018-10-12 10:35 +0300 > release-pypy3.5-6.x > Matti Picus 2018-10-28 19:35 +0200 > unicode-from-unicode-in-c > Matti Picus 2019-02-05 17:09 +0200 windowsinstaller > Matti Picus 2019-02-11 11:10 +0200 unicode-utf8-py3 > mattip 2015-06-26 11:39 +0300 pypy3-release-2.6.x > mattip 2015-10-19 17:04 +0800 ndarray-promote > Nicolas Truessel 2017-06-16 15:11 +0200 quad-color-gc > Philip Jenvey 2014-06-22 18:56 -0700 > pypy3-release-2.3.x > Philip Jenvey 2014-08-07 17:20 -0700 py3k-qualname > Philip Jenvey 2014-10-20 16:41 -0700 > pypy3-release-2.4.x > Philip Jenvey 2016-05-24 23:14 -0700 py3k-osxfix > Remi Meier 2017-06-14 09:51 +0200 stmgc-c8 > Remi Meier 2018-03-24 16:52 +0100 guard-value-limit > Richard Plangger 2016-03-15 11:31 +0100 > gcstress-hypothesis > Richard Plangger 2016-10-11 16:56 +0200 py3.3 > Richard Plangger 2016-12-20 16:57 +0100 interp-opt > Richard Plangger 2017-03-02 18:31 +0100 cpyext-callopt > Richard Plangger 2017-04-04 18:03 -0400 > vmprof-multiple-eval-funcs > Richard Plangger 2017-06-07 10:41 -0400 vmprof-0.4.8 > Richard Plangger 2015-06-10 12:06 +0200 vmprof-address > Romain Guillebert 2014-01-22 17:19 +0100 > numpypy-array_prepare_-array_wrap > Ronan Lamy 2013-04-11 20:55 +0100 longdouble2 > Ronan Lamy 2013-05-05 19:18 +0100 Opcode-class > Ronan Lamy 2014-02-16 03:23 +0000 singledispatch > Ronan Lamy 2014-05-14 20:04 +0100 HopArg > Ronan Lamy 2014-06-17 19:19 +0100 rpath-enforceargs > Ronan Lamy 2014-11-09 00:22 +0000 online-transforms > Ronan Lamy 2014-11-18 02:22 +0000 expressions-2 > Ronan Lamy 2015-02-16 19:21 +0000 framestate > Ronan Lamy 2015-03-03 01:05 +0000 inline-earlier > Ronan Lamy 2015-10-11 05:41 +0100 llconst > Ronan Lamy 2015-11-22 18:00 +0000 exc-later > Ronan Lamy 2016-01-30 18:16 +0000 SomeRange > Ronan Lamy 2016-03-09 20:43 +0000 pypy3.3-bootstrap > Ronan Lamy 2016-03-16 21:04 +0000 bootstrap-clarity > Ronan Lamy 2016-09-06 15:38 +0100 union-side-effects > Ronan Lamy 2016-09-12 01:29 +0100 _py3k-cpyext-A > Ronan Lamy 2016-11-25 18:55 +0000 reflowing > Ronan Lamy 2017-03-14 17:45 +0000 stricter-encode > Ronan Lamy 2017-05-20 21:09 +0100 strbufobject > Ronan Lamy 2017-05-31 12:15 +0100 rawrefcount-review > Ronan Lamy 2017-08-05 14:15 +0100 install-rpython > Ronan Lamy 2017-11-05 20:49 +0000 assert-rewrite > Ronan Lamy 2017-11-19 01:40 +0000 fix-broken-types > Ronan Lamy 2017-12-10 05:27 +0000 unicode-utf8-test > Ronan Lamy 2018-03-04 18:48 +0000 rgil-cffi > Ronan Lamy 2019-01-31 16:10 +0000 apptest-file > Ronan Lamy 2019-01-31 16:13 +0000 py3tests > Ronny Pfannschmidt 2014-10-05 17:51 > +0200 refine-testrunner > Ronny Pfannschmidt 2015-02-18 17:26 > +0100 vendoring > Ronny Pfannschmidt 2012-07-01 13:57 +0200 > kill-import_from_lib_pypy > Ronny Pfannschmidt 2013-02-08 15:35 +0100 pytest > Ronny Pfannschmidt 2013-04-11 23:17 +0200 > pytest-update > Spenser Andrew Bauman 2016-11-18 17:26 -0500 > value-classes > Spenser Bauman 2016-04-05 21:54 -0400 > remove-getarrayitem-pure > Stefan Beyer 2017-08-31 14:45 +0200 cpyext-gc-trialdeletion > Stefan Beyer 2019-02-03 23:06 +0100 cpyext-gc-cycle > Timo Paulssen 2011-09-24 20:35 +0200 > numpy-random > Timo Paulssen 2011-10-04 00:35 +0200 > numpy-data-buffer > Timo Paulssen 2012-01-10 13:56 +0100 > strbuf_by_default > Timo Paulssen 2012-11-23 13:28 +0100 > py3k-ceil-floor > Tyler Wade 2014-07-28 13:02 -0500 rpython-__eq__ > Tyler Wade 2014-09-07 12:38 -0500 utf8-unicode2 > Vincent Legoll 2015-12-29 11:06 +0100 fix-1674 > Vincent Legoll 2016-01-14 22:45 +0100 > repeatlist_strategy > William ML Leslie 2017-01-24 12:54 +1100 > taskengine-sorted-optionals > William ML Leslie 2017-01-24 18:55 +1100 > inline-taskengine > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev From anto.cuni at gmail.com Mon Feb 11 11:24:51 2019 From: anto.cuni at gmail.com (Antonio Cuni) Date: Mon, 11 Feb 2019 17:24:51 +0100 Subject: [pypy-dev] let's clean up open branches In-Reply-To: References: Message-ID: On Mon, Feb 11, 2019 at 4:52 PM Carl Friedrich Bolz-Tereick wrote: > Antonio Cuni 2019-02-11 11:50 +0100 default > let's close this one :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.picus at gmail.com Mon Feb 11 12:18:08 2019 From: matti.picus at gmail.com (Matti Picus) Date: Mon, 11 Feb 2019 19:18:08 +0200 Subject: [pypy-dev] Fwd: Re: Users of PyPy on ARM 32bit In-Reply-To: References: Message-ID: <23f16d67-4ea2-2053-f8d9-3e46073f9778@gmail.com> On 8/2/19 7:44 pm, Carl Friedrich Bolz-Tereick wrote: > > > ------------------------------------------------------------------------ > *From:* Gelin Yan > *Sent:* February 8, 2019 3:26:30 PM GMT+01:00 > *To:* Carl Friedrich Bolz > *Subject:* Re: [pypy-dev] Users of PyPy on ARM 32bit > > Hi Carl > > > ? ? ?We are using pypy with raspberry pi 3 for smart irrigation. Pypy > works fine to us. > > Regards > > gelin yan > Hi gelin yan. The problem we face is that it takes too long to translate and test ARM32. We need someone to provide us with a powerful ARM machine with at least 4GB of RAM so we can build and test ARM32. Without such support, we cannot guarantee continued support for ARM32. Could you help us? Matti From alex.gaynor at gmail.com Mon Feb 11 16:51:22 2019 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Mon, 11 Feb 2019 16:51:22 -0500 Subject: [pypy-dev] let's clean up open branches In-Reply-To: References: Message-ID: Looking at my branches: - numpypy-ctypes, numpy-record-type-pure-python: can be deleted - jit-tracehook: Seems like a good idea, let's you run the JIT even when there's a trace func -- looks like maybe some parts were landed and some weren't? - struct-double: I think all this work got done in a different way by someone else, can be deleted - dynamic-specialized-tuple: A really good idea; creates specialized tuples dynamically, I think it was basically merge ready except for one missing optimization, but I'm sure it's completely bitrotted now. - jit-sys-exc-info: no clue here - asm-backend-dupe-removal: no clue, maybe fijal remembers - unroll-virtual-dict-resize: probably still a good idea, will be tons of conflicts and I don't know if the heapcache issues that blocked it were ever fixed (needed interiorfield support there) - python-loop-unroll: very cool idea, looks like it was almost working (with huge hacks) I'm not going to have time to finish any of my good idea branches :-) They can either be closed, or maybe someone else some day wants to look at them. Alex On Mon, Feb 11, 2019 at 11:28 AM Antonio Cuni wrote: > On Mon, Feb 11, 2019 at 4:52 PM Carl Friedrich Bolz-Tereick > wrote: > >> Antonio Cuni 2019-02-11 11:50 +0100 default >> > > let's close this one :) > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > -- All that is necessary for evil to succeed is for good people to do nothing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.leslie.ttg at gmail.com Mon Feb 11 21:26:20 2019 From: william.leslie.ttg at gmail.com (William ML Leslie) Date: Tue, 12 Feb 2019 13:26:20 +1100 Subject: [pypy-dev] let's clean up open branches In-Reply-To: References: Message-ID: On Tue., 12 Feb. 2019, 2:53 am Carl Friedrich Bolz-Tereick Hi all, > > Armin and I briefly looked at the long list of our open branches today. > Could everybody take a look which of "their" branches could be closed, > or maybe merged? see list below, ordered by last committer on the > branch, and date. > > William ML Leslie 2017-01-24 12:54 +1100 > taskengine-sorted-optionals > William ML Leslie 2017-01-24 18:55 +1100 > inline-taskengine > Sorry, i closed one branch in this series and forgot the rest. Feel free to delete these. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Tue Feb 12 05:45:10 2019 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 12 Feb 2019 11:45:10 +0100 Subject: [pypy-dev] Fwd: Re: Users of PyPy on ARM 32bit In-Reply-To: <23f16d67-4ea2-2053-f8d9-3e46073f9778@gmail.com> References: <23f16d67-4ea2-2053-f8d9-3e46073f9778@gmail.com> Message-ID: On Mon, Feb 11, 2019 at 6:18 PM Matti Picus wrote: > > > On 8/2/19 7:44 pm, Carl Friedrich Bolz-Tereick wrote: > > > > > > ------------------------------------------------------------------------ > > *From:* Gelin Yan > > *Sent:* February 8, 2019 3:26:30 PM GMT+01:00 > > *To:* Carl Friedrich Bolz > > *Subject:* Re: [pypy-dev] Users of PyPy on ARM 32bit > > > > Hi Carl > > > > > > We are using pypy with raspberry pi 3 for smart irrigation. Pypy > > works fine to us. > > > > Regards > > > > gelin yan > > > > Hi gelin yan. The problem we face is that it takes too long to translate > and test ARM32. We need someone to provide us with a powerful ARM > machine with at least 4GB of RAM so we can build and test ARM32. Without > such support, we cannot guarantee continued support for ARM32. Could you > help us? > > > Matti Hey. We can build ARM32 binaries on ARM64 servers (we have one, we can get access to more) using chroot. It's some effort, but not an unreasonable amount. Would be cool if someone sponsors this work though From ekim94525 at gmail.com Tue Feb 12 18:41:28 2019 From: ekim94525 at gmail.com (Amy) Date: Tue, 12 Feb 2019 18:41:28 -0500 Subject: [pypy-dev] Using Opencv-python with Pypy Message-ID: Hi, I am Amy and using pypy with python3.6.6. I need to import "python -m pip install opencv-python" to run the program and try to import with pypy like "pypy3 -m pip install opencv-python". However, it give an error: "Could not find a version that satisfies the requirement opencv-python (from versions: ) No matching distribution found for opencv-python You are using pip version 9.0.1, however version 19.0.2 is available. You should consider upgrading via the 'python -m pip install --upgrade pip' command." (by the way, I upgraded all the tools (pip and wheel) to the lastest version but they keep saying me to upgrade it). Do you have any idea to solve this problem? I need pypy to upgrade the speed of my program which is reading a large video and want to increase the average frame numbers. Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmbusif at gmail.com Wed Feb 13 04:50:25 2019 From: mmbusif at gmail.com (Mohamed Yousif) Date: Wed, 13 Feb 2019 11:50:25 +0200 Subject: [pypy-dev] Using Opencv-python with Pypy In-Reply-To: References: Message-ID: Apparently, your issue >"Could not find a version that satisfies the requirement opencv-python (from versions: ) is related to pip, and the suggested fix was to upgrade your pip ( https://pypi.org/project/opencv-python/). You may want to start with that. You will also need to find how opencv plays with pypy. Regards On Wed, Feb 13, 2019 at 11:39 AM Amy wrote: > Hi, > > I am Amy and using pypy with python3.6.6. I need to import "python -m pip > install opencv-python" to run the program and try to import with pypy like > "pypy3 -m pip install opencv-python". However, it give an error: "Could not > find a version that satisfies the requirement opencv-python (from versions: > ) > No matching distribution found for opencv-python > You are using pip version 9.0.1, however version 19.0.2 is available. > You should consider upgrading via the 'python -m pip install --upgrade > pip' command." (by the way, I upgraded all the tools (pip and wheel) to the > lastest version but they keep saying me to upgrade it). Do you have any > idea to solve this problem? > > I need pypy to upgrade the speed of my program which is reading a large > video and want to increase the average frame numbers. > > Thank you! > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anto.cuni at gmail.com Wed Feb 13 04:54:30 2019 From: anto.cuni at gmail.com (Antonio Cuni) Date: Wed, 13 Feb 2019 10:54:30 +0100 Subject: [pypy-dev] Using Opencv-python with Pypy In-Reply-To: References: Message-ID: Hello Amy, On Wed, Feb 13, 2019 at 10:38 AM Amy wrote: > "pypy3 -m pip install opencv-python". However, it give an error: "Could > not find a version that satisfies the requirement opencv-python (from > versions: ) > No matching distribution found for opencv-python > This happens because opencv decided to release only binary wheels on PyPI, as you can see here; note that the only files available are *.whl: https://pypi.org/project/opencv-python/#files The great advantage of binary wheels is that you don't have to recompile the package yourself; however, they are tied to a particular combination of OS/python version: opencv didn't release any binary wheel for PyPy, so pip cannot find any. When pip cannot locate a wheel, it tries to download a source package (like .tar.bz2 or .zip) and compile it on the fly; however, opencv didn't release any, that's why you get the error. Your best bet to have opencv on PyPy is to clone the source repo from github and run setup.py yourself: $ git clone https://github.com/skvark/opencv-python $ cd opencv-python $ pypy3 setup.py install ciao, Anto -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.2011 at reagle.org Wed Feb 13 09:10:50 2019 From: joseph.2011 at reagle.org (Joseph Reagle) Date: Wed, 13 Feb 2019 09:10:50 -0500 Subject: [pypy-dev] Why is pypy slower? Message-ID: <87f7e32f-741e-5458-6a5b-53324ffc6e3e@reagle.org> Hello all, thank you for your work on pypy. I'm a pypy newbie and thought to try it on a program I use a lot and where I appreciate fast response times (especially when running on a webhost). I keep my bibliography notes in interconnected XML-based mindmaps (Freeplane). `fe.py` parses and walks those XML files and generates output (bibtex, YAML, wikipedia, or HTML that highlights a queried search) [1]. [1]: https://github.com/reagle/thunderdell/blob/master/fe.py Running it with pypy is slower: ``` > time python3 fe.py -cq Giddens python3 fe.py -cq Giddens 1.46s user 0.16s system 97% cpu 1.649 total > time pypy3 fe.py -cq Giddens pypy3 fe.py -cq Giddens 2.81s user 0.26s system 93% cpu 3.292 total ``` I tried to use the pypy profiler but it would seemingly lockup (and vmprof.com seems down to boot). I've attached a cProfile. As you might expect, it spends a lot of time parsing XML, doing the regex search on nodes, and parsing citation strings. Any idea why pypy is slower? -------------- next part -------------- A non-text attachment was scrubbed... Name: fe.prof Type: application/octet-stream Size: 182660 bytes Desc: not available URL: From fijall at gmail.com Wed Feb 13 09:38:16 2019 From: fijall at gmail.com (Maciej Fijalkowski) Date: Wed, 13 Feb 2019 15:38:16 +0100 Subject: [pypy-dev] Why is pypy slower? In-Reply-To: <87f7e32f-741e-5458-6a5b-53324ffc6e3e@reagle.org> References: <87f7e32f-741e-5458-6a5b-53324ffc6e3e@reagle.org> Message-ID: Hi Joseph My first intuition would be to run it for a bit longer (can you run it in a loop couple times and see if it speeds up?) 2s might not be enough for JIT to kick in on something as complicated On Wed, Feb 13, 2019 at 3:11 PM Joseph Reagle wrote: > > Hello all, thank you for your work on pypy. > > I'm a pypy newbie and thought to try it on a program I use a lot and where I appreciate fast response times (especially when running on a webhost). I keep my bibliography notes in interconnected XML-based mindmaps (Freeplane). `fe.py` parses and walks those XML files and generates output (bibtex, YAML, wikipedia, or HTML that highlights a queried search) [1]. > > [1]: https://github.com/reagle/thunderdell/blob/master/fe.py > > Running it with pypy is slower: > > ``` > > time python3 fe.py -cq Giddens > python3 fe.py -cq Giddens 1.46s user 0.16s system 97% cpu 1.649 total > > time pypy3 fe.py -cq Giddens > pypy3 fe.py -cq Giddens 2.81s user 0.26s system 93% cpu 3.292 total > ``` > > I tried to use the pypy profiler but it would seemingly lockup (and vmprof.com seems down to boot). I've attached a cProfile. As you might expect, it spends a lot of time parsing XML, doing the regex search on nodes, and parsing citation strings. > > Any idea why pypy is slower? > > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev From joseph.2011 at reagle.org Wed Feb 13 09:57:05 2019 From: joseph.2011 at reagle.org (Joseph Reagle) Date: Wed, 13 Feb 2019 09:57:05 -0500 Subject: [pypy-dev] Why is pypy slower? In-Reply-To: References: <87f7e32f-741e-5458-6a5b-53324ffc6e3e@reagle.org> Message-ID: <4a0c4f29-4e0f-5965-b6ab-0b70dc18fc0f@reagle.org> On 2/13/19 9:38 AM, Maciej Fijalkowski wrote: > My first intuition would be to run it for a bit longer (can you run > it in a loop couple times and see if it speeds up?) 2s might not be > enough for JIT to kick in on something as complicated It's a single use utility where each run processes about a 100 XML files, doing things like string regex and munging thousands of times. Is it possible for pypy to remember optimizations across instantiations? From fijall at gmail.com Wed Feb 13 10:19:41 2019 From: fijall at gmail.com (Maciej Fijalkowski) Date: Wed, 13 Feb 2019 16:19:41 +0100 Subject: [pypy-dev] Why is pypy slower? In-Reply-To: <4a0c4f29-4e0f-5965-b6ab-0b70dc18fc0f@reagle.org> References: <87f7e32f-741e-5458-6a5b-53324ffc6e3e@reagle.org> <4a0c4f29-4e0f-5965-b6ab-0b70dc18fc0f@reagle.org> Message-ID: On Wed, Feb 13, 2019 at 3:57 PM Joseph Reagle wrote: > > > On 2/13/19 9:38 AM, Maciej Fijalkowski wrote: > > My first intuition would be to run it for a bit longer (can you run > > it in a loop couple times and see if it speeds up?) 2s might not be > > enough for JIT to kick in on something as complicated > > It's a single use utility where each run processes about a 100 XML files, doing things like string regex and munging thousands of times. > > Is it possible for pypy to remember optimizations across instantiations? It is not possible. Here is the explanation: http://doc.pypy.org/en/latest/faq.html#couldn-t-the-jit-dump-and-reload-already-compiled-machine-code Best, Maciej Fijalkowski From armin.rigo at gmail.com Wed Feb 13 10:39:22 2019 From: armin.rigo at gmail.com (Armin Rigo) Date: Wed, 13 Feb 2019 16:39:22 +0100 Subject: [pypy-dev] Why is pypy slower? In-Reply-To: References: <87f7e32f-741e-5458-6a5b-53324ffc6e3e@reagle.org> <4a0c4f29-4e0f-5965-b6ab-0b70dc18fc0f@reagle.org> Message-ID: Hi Joseph, On Wed, 13 Feb 2019 at 16:19, Maciej Fijalkowski wrote: > On Wed, Feb 13, 2019 at 3:57 PM Joseph Reagle wrote: > > Is it possible for pypy to remember optimizations across instantiations? > > It is not possible. A more constructive answer: in some cases, you can change the overall approach. The problem is likely not that it takes 2s instead of 1s to run the program, but that this difference is multiplied many times because you run the same program many times on different input data. In that case, you may try to convert the single-use script into a local "server" that is only started once. Then you change your ``fe.py`` script to connect to it and "download" the result locally. The point is that the server runs in a single process that remains alive. A bient?t, Armin. From renesd at gmail.com Wed Feb 13 10:42:07 2019 From: renesd at gmail.com (=?UTF-8?Q?Ren=C3=A9_Dudfield?=) Date: Wed, 13 Feb 2019 16:42:07 +0100 Subject: [pypy-dev] Why is pypy slower? In-Reply-To: <4a0c4f29-4e0f-5965-b6ab-0b70dc18fc0f@reagle.org> References: <87f7e32f-741e-5458-6a5b-53324ffc6e3e@reagle.org> <4a0c4f29-4e0f-5965-b6ab-0b70dc18fc0f@reagle.org> Message-ID: Hi, you can run it as a daemon/server(for example a little flask app). This optimization also works for cpython apps if you want to avoid the startup/import time. Can the work be split up per xml file easily? Then perhaps multiprocessing will work nicely for you. Do you need to process all the files each time? Or can you avoid work? cheers, On Wed, Feb 13, 2019 at 3:57 PM Joseph Reagle wrote: > > On 2/13/19 9:38 AM, Maciej Fijalkowski wrote: > > My first intuition would be to run it for a bit longer (can you run > > it in a loop couple times and see if it speeds up?) 2s might not be > > enough for JIT to kick in on something as complicated > > It's a single use utility where each run processes about a 100 XML files, > doing things like string regex and munging thousands of times. > > Is it possible for pypy to remember optimizations across instantiations? > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.2011 at reagle.org Wed Feb 13 10:58:32 2019 From: joseph.2011 at reagle.org (Joseph Reagle) Date: Wed, 13 Feb 2019 10:58:32 -0500 Subject: [pypy-dev] Why is pypy slower? In-Reply-To: References: <87f7e32f-741e-5458-6a5b-53324ffc6e3e@reagle.org> <4a0c4f29-4e0f-5965-b6ab-0b70dc18fc0f@reagle.org> Message-ID: On 2/13/19 10:42 AM, Ren? Dudfield wrote: > you can run it as a daemon/server(for example a little flask app). > This optimization also works for cpython apps if you want to avoid > the startup/import time. That would be a big change for a uncertain improvement, so I'm not willing to go there yet. Performance is okay, but I want to see if I can improve it further as a stand-alone. > Can the work be split up per xml file easily? Then perhaps > multiprocessing will work nicely for you. > > Do you need to process all the files each time? Or can you avoid > work? I've tried multiprocessing too, but it is slower. Parsing the XML can be done in parallel but I suspect the overhead of multi-processing was the drag. I've also thought about caching the XML parse trees, but serializing and reloading pickles of unchanged parse trees seems slower than just parsing the XML anew. Using lru_cache on text processing functions (e.g., removing accents) didn't help either. I haven't been able to find good examples of people using multiprocessing or pypy for XML processing, perhaps this is why. Thank you all for the suggestions! From matt at vazor.com Wed Feb 13 15:15:24 2019 From: matt at vazor.com (Matt Billenstein) Date: Wed, 13 Feb 2019 20:15:24 +0000 Subject: [pypy-dev] Why is pypy slower? In-Reply-To: References: <87f7e32f-741e-5458-6a5b-53324ffc6e3e@reagle.org> <4a0c4f29-4e0f-5965-b6ab-0b70dc18fc0f@reagle.org> Message-ID: <01010168e87fed5f-00768ee4-0ea3-413b-a69b-37f9c9fdf8c7-000000@us-west-2.amazonses.com> I wonder how nuitka might do? http://nuitka.net/pages/overview.html m On Wed, Feb 13, 2019 at 10:58:32AM -0500, Joseph Reagle wrote: > On 2/13/19 10:42 AM, Ren??? Dudfield wrote: > > you can run it as a daemon/server(for example a little flask app). > > This optimization also works for cpython apps if you want to avoid > > the startup/import time. > > That would be a big change for a uncertain improvement, so I'm not willing to go there yet. Performance is okay, but I want to see if I can improve it further as a stand-alone. > > > Can the work be split up per xml file easily? Then perhaps > > multiprocessing will work nicely for you. > > > > Do you need to process all the files each time? Or can you avoid > > work? > > I've tried multiprocessing too, but it is slower. Parsing the XML can be done in parallel but I suspect the overhead of multi-processing was the drag. I've also thought about caching the XML parse trees, but serializing and reloading pickles of unchanged parse trees seems slower than just parsing the XML anew. Using lru_cache on text processing functions (e.g., removing accents) didn't help either. > > I haven't been able to find good examples of people using multiprocessing or pypy for XML processing, perhaps this is why. > > Thank you all for the suggestions! > > > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev -- Matt Billenstein matt at vazor.com http://www.vazor.com/ From cfbolz at gmx.de Wed Feb 13 16:03:31 2019 From: cfbolz at gmx.de (Carl Friedrich Bolz-Tereick) Date: Wed, 13 Feb 2019 22:03:31 +0100 Subject: [pypy-dev] Why is pypy slower? In-Reply-To: References: <87f7e32f-741e-5458-6a5b-53324ffc6e3e@reagle.org> <4a0c4f29-4e0f-5965-b6ab-0b70dc18fc0f@reagle.org> Message-ID: Hi Joseph, wow, interesting project! Would you be up to sharing some example input that you are trying this on? I might be up to looking into why the program is slower than on CPython, but I'd need a way that I can actually run it with realistic input. Cheers, Carl Friedrich On 13/02/2019 16:58, Joseph Reagle wrote: > On 2/13/19 10:42 AM, Ren? Dudfield wrote: >> you can run it as a daemon/server(for example a little flask app). >> This optimization also works for cpython apps if you want to avoid >> the startup/import time. > > That would be a big change for a uncertain improvement, so I'm not willing to go there yet. Performance is okay, but I want to see if I can improve it further as a stand-alone. > >> Can the work be split up per xml file easily? Then perhaps >> multiprocessing will work nicely for you. >> >> Do you need to process all the files each time? Or can you avoid >> work? > > I've tried multiprocessing too, but it is slower. Parsing the XML can be done in parallel but I suspect the overhead of multi-processing was the drag. I've also thought about caching the XML parse trees, but serializing and reloading pickles of unchanged parse trees seems slower than just parsing the XML anew. Using lru_cache on text processing functions (e.g., removing accents) didn't help either. > > I haven't been able to find good examples of people using multiprocessing or pypy for XML processing, perhaps this is why. > > Thank you all for the suggestions! > > > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > From joseph.2011 at reagle.org Wed Feb 13 16:28:39 2019 From: joseph.2011 at reagle.org (Joseph Reagle) Date: Wed, 13 Feb 2019 16:28:39 -0500 Subject: [pypy-dev] Why is pypy slower? In-Reply-To: <01010168e87fed5f-00768ee4-0ea3-413b-a69b-37f9c9fdf8c7-000000@us-west-2.amazonses.com> References: <87f7e32f-741e-5458-6a5b-53324ffc6e3e@reagle.org> <4a0c4f29-4e0f-5965-b6ab-0b70dc18fc0f@reagle.org> <01010168e87fed5f-00768ee4-0ea3-413b-a69b-37f9c9fdf8c7-000000@us-west-2.amazonses.com> Message-ID: <1a5fe96c-15c6-6fda-a5b5-113c0512852f@reagle.org> On 2/13/19 3:15 PM, Matt Billenstein wrote: > http://nuitka.net/pages/overview.html Hi Matt, thanks for the suggestion. For my program, Nuitka's performance is very close to Cpython's. From joseph.2011 at reagle.org Wed Feb 13 16:44:18 2019 From: joseph.2011 at reagle.org (Joseph Reagle) Date: Wed, 13 Feb 2019 16:44:18 -0500 Subject: [pypy-dev] Why is pypy slower? In-Reply-To: References: <87f7e32f-741e-5458-6a5b-53324ffc6e3e@reagle.org> <4a0c4f29-4e0f-5965-b6ab-0b70dc18fc0f@reagle.org> Message-ID: On 2/13/19 4:03 PM, Carl Friedrich Bolz-Tereick wrote: > wow, interesting project! Would you be up to sharing some example > input that you are trying this on? I might be up to looking into why > the program is slower than on CPython, but I'd need a way that I can > actually run it with realistic input. Thanks Carl. I don't have a nice package, but the repo is: https://github.com/reagle/thunderdell/ The dependencies should be easy, `fe.py` imports web_little, which will require requests. Everything else should be stdlib. Below I show how to grab the realistic input and run fe.py on it yielding a 1.6MB YAML file. ``` ??reagle at hom ~/tmp ??? wget http://reagle.org/joseph/2005/ethno/field-notes.zip --2019-02-13 16:40:13-- http://reagle.org/joseph/2005/ethno/field-notes.zip ... 2019-02-13 16:40:13 (4.92 MB/s) - ?field-notes.zip? saved [1987518/1987518] ??reagle at hom ~/tmp ??? unzip field-notes.zip Archive: field-notes.zip inflating: field-notes-2008-cat.mm inflating: field-notes-2009-cat.mm inflating: field-notes-2010-cat.mm inflating: field-notes-2011-cat.mm inflating: field-notes-2012-cat.mm inflating: field-notes-2013-cat.mm inflating: field-notes-2014-cat.mm inflating: field-notes-2015-cat.mm inflating: field-notes-2016-cat.mm inflating: field-notes-2017-cat.mm inflating: field-notes-2017.mm inflating: field-notes-2018.mm inflating: field-notes.mm ??reagle at hom ~/tmp ??? ~/bin/fe/fe.py -i field-notes.mm -c -o ??reagle at hom ~/tmp ??? head field-notes.yaml --- references: - id: ACLU2018acg type: webpage author: - family: "ACLU" container-title: "American Civil Liberties Union" custom2: "field-notes-2018.mm" issued: year: 2018 ``` From ekim94525 at gmail.com Thu Feb 14 19:22:31 2019 From: ekim94525 at gmail.com (Amy) Date: Thu, 14 Feb 2019 19:22:31 -0500 Subject: [pypy-dev] pypy3 - Import cv2 Message-ID: Hi, I found a problem while using cv2. In my code, I already imported cv2 and installed pip install opencv-python already, however, it gives following error. Collecting cv2 Could not find a version that satisfies the requirement cv2 (from versions: ) No matching distribution found for cv2. When I try with python, it is working well, however, when I try with pypy3, it is not importing cv even though there is a opencv-python in the site-packages. Please help me with this error! I have been working on this error for a week. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.picus at gmail.com Fri Feb 15 02:12:09 2019 From: matti.picus at gmail.com (Matti Picus) Date: Fri, 15 Feb 2019 09:12:09 +0200 Subject: [pypy-dev] pypy3 - Import cv2 In-Reply-To: References: Message-ID: On 15/2/19 2:22 am, Amy wrote: > Hi, > > ?I found a problem while using cv2. In my code, I already imported cv2 > and installed pip install opencv-python already, however, it gives > following error. > > Collecting cv2 > ? Could not find a version that satisfies the requirement cv2 (from > versions: ) > No matching distribution found for cv2. > > When I try with python, it is working well, however, when I try with > pypy3, it is not importing cv even though there is a opencv-python in > the site-packages. > > Please help me with this error! I have been working on this error for > a week. > Hi Amy. Thanks for trying PyPy. Since PyPy is an alternative implementation of the python runtime, it needs a spearate installation of all the python packages, it cannot share with the usual python (formally known as cpython since it is written in C). If you run `pypy -c "import sys; print(sys.path)"` you will see where it keeps its site-packages, which is different than `python3 -c "import sys; print(sys.path)"`. As for opencv, it does not provide binary builds for pypy on pypi, you will have to build from source. You can read more about it here https://pypi.org/project/opencv-python/ Matti From joseph.2011 at reagle.org Mon Feb 18 08:33:06 2019 From: joseph.2011 at reagle.org (Joseph Reagle) Date: Mon, 18 Feb 2019 08:33:06 -0500 Subject: [pypy-dev] pip_pypy3 throws exception when updating Message-ID: <4fecc4c0-1141-9929-c9bb-f4c3f8d32308@reagle.org> Homebrew on MacOS Mojave just updated to pypy3 7.0.0 and reminded me to update the setup tools. Doing so, though, throws an exceptions. ``` ?? pip_pypy3 install --upgrade pip setuptools Collecting pip Using cached https://files.pythonhosted.org/packages/d7/41/34dd96bd33958e52cb4da2f1bf0818e396514fd4f4725a79199564cd0c20/pip-19.0.2-py2.py3-none-any.whl Collecting setuptools Using cached https://files.pythonhosted.org/packages/d1/6a/4b2fcefd2ea0868810e92d519dacac1ddc64a2e53ba9e3422c3b62b378a6/setuptools-40.8.0-py2.py3-none-any.whl Installing collected packages: pip, setuptools Found existing installation: pip 10.0.1 Uninstalling pip-10.0.1: Successfully uninstalled pip-10.0.1 Found existing installation: setuptools 39.0.1 Uninstalling setuptools-39.0.1: Successfully uninstalled setuptools-39.0.1 Successfully installed pip-19.0.2 setuptools-40.8.0 Traceback (most recent call last): File "/usr/local/bin/pip_pypy3", line 11, in sys.exit(main()) File "/usr/local/Cellar/pypy3/7.0.0/libexec/site-packages/pip-10.0.1-py3.6.egg/pip/_internal/__init__.py", line 246, in main File "/usr/local/Cellar/pypy3/7.0.0/libexec/site-packages/pip-10.0.1-py3.6.egg/pip/_internal/basecommand.py", line 264, in main File "/usr/local/Cellar/pypy3/7.0.0/libexec/site-packages/pip-10.0.1-py3.6.egg/pip/_internal/basecommand.py", line 81, in _build_session File "/usr/local/Cellar/pypy3/7.0.0/libexec/site-packages/pip-10.0.1-py3.6.egg/pip/_internal/download.py", line 338, in __init__ File "/usr/local/Cellar/pypy3/7.0.0/libexec/site-packages/pip-10.0.1-py3.6.egg/pip/_internal/download.py", line 127, in user_agent File "/usr/local/Cellar/pypy3/7.0.0/libexec/site-packages/pip-10.0.1-py3.6.egg/pip/_internal/utils/misc.py", line 829, in get_installed_version File "/usr/local/Cellar/pypy3/7.0.0/libexec/site-packages/pip-10.0.1-py3.6.egg/pip/_vendor/pkg_resources/__init__.py", line 558, in __init__ File "/usr/local/Cellar/pypy3/7.0.0/libexec/site-packages/pip-10.0.1-py3.6.egg/pip/_vendor/pkg_resources/__init__.py", line 614, in add_entry File "/usr/local/Cellar/pypy3/7.0.0/libexec/site-packages/pip-10.0.1-py3.6.egg/pip/_vendor/pkg_resources/__init__.py", line 1882, in find_eggs_in_zip File "/usr/local/Cellar/pypy3/7.0.0/libexec/site-packages/pip-10.0.1-py3.6.egg/pip/_vendor/pkg_resources/__init__.py", line 1399, in has_metadata File "/usr/local/Cellar/pypy3/7.0.0/libexec/site-packages/pip-10.0.1-py3.6.egg/pip/_vendor/pkg_resources/__init__.py", line 1756, in _has File "/usr/local/Cellar/pypy3/7.0.0/libexec/site-packages/pip-10.0.1-py3.6.egg/pip/_vendor/pkg_resources/__init__.py", line 1633, in zipinfo File "/usr/local/Cellar/pypy3/7.0.0/libexec/site-packages/pip-10.0.1-py3.6.egg/pip/_vendor/pkg_resources/__init__.py", line 1590, in load FileNotFoundError: [Errno 2] No such file or directory: '/usr/local/Cellar/pypy3/7.0.0/libexec/site-packages/setuptools-39.0.1-py3.6.egg' ??reagle at hom ~ ??? pip_pypy3 install --upgrade pip setuptools 1 ? Requirement already up-to-date: pip in /usr/local/Cellar/pypy3/7.0.0/libexec/site-packages (19.0.2) Requirement already up-to-date: setuptools in /usr/local/Cellar/pypy3/7.0.0/libexec/site-packages (40.8.0) ??reagle at hom ~ ??? ``` From armin.rigo at gmail.com Tue Feb 19 02:41:13 2019 From: armin.rigo at gmail.com (Armin Rigo) Date: Tue, 19 Feb 2019 08:41:13 +0100 Subject: [pypy-dev] pip_pypy3 throws exception when updating In-Reply-To: <4fecc4c0-1141-9929-c9bb-f4c3f8d32308@reagle.org> References: <4fecc4c0-1141-9929-c9bb-f4c3f8d32308@reagle.org> Message-ID: Hi Joseph, On Mon, 18 Feb 2019 at 14:33, Joseph Reagle wrote: > Homebrew on MacOS Mojave just updated to pypy3 7.0.0 and reminded me to update the setup tools. Doing so, though, throws an exceptions. We're unlikely to be able to help. The problem might be anywhere from homebrew to setuptools to the way we package pypy3, and my guess would be that nobody can reproduce the problem now (even if we had OS X machines to test with). I assume that if you remove everything and install pypy3 from scratch instead of via an update, everything works fine? A bient?t, Armin. From fijall at gmail.com Tue Feb 19 12:33:42 2019 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 19 Feb 2019 18:33:42 +0100 Subject: [pypy-dev] More feedback on new pypy.org Message-ID: Hi everyone! Here is the next iteration of pypy.org - https://baroquesoftware.com/pypy-website/web/ - after adding some feedback. Note that no work has been done on content just yet. Feel free to provide more feedback. We also need to decide what to do with the logo. Best, Maciej Fijalkowski From dje.gcc at gmail.com Tue Feb 19 12:41:40 2019 From: dje.gcc at gmail.com (David Edelsohn) Date: Tue, 19 Feb 2019 12:41:40 -0500 Subject: [pypy-dev] More feedback on new pypy.org In-Reply-To: References: Message-ID: The new website design is looking better and better. The graph should probably have a label "<--- Better" pointing downward. Otherwise it naively looks like PyPy is striving to approach CPython bar. - David On Tue, Feb 19, 2019 at 12:34 PM Maciej Fijalkowski wrote: > > Hi everyone! > > Here is the next iteration of pypy.org - > https://baroquesoftware.com/pypy-website/web/ - after adding some > feedback. Note that no work has been done on content just yet. > > Feel free to provide more feedback. We also need to decide what to do > with the logo. > > Best, > Maciej Fijalkowski > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev From jherskovic at gmail.com Tue Feb 19 19:13:03 2019 From: jherskovic at gmail.com (Jorge Herskovic) Date: Tue, 19 Feb 2019 18:13:03 -0600 Subject: [pypy-dev] PyPy 2.7 v7.0.0 on ARM HF Message-ID: I use PyPy on a Raspberry Pi 3 to drive Octoprint - it's faster than using Python, and more entertaining. The lack of a v7 for ARM was frustrating, and I tried cross-compiling my own. All I found were the instructions for 2.4.0, and I adapted them the best I could. Unfortunately I couldn't hit the combination of Raspbian and Ubuntu (or Debian) that would compile; headers were missing, or something else invariably broke. In frustration, I ended up translating PyPy using a completely emulated system under QEMU running 32-bit Debian Jessie. The good news: it worked! The translation completed successfully. The bad news: It took 48,800 seconds on a fairly current CPU. I don't recommend it for testing. Cheers, Jorge -------------- next part -------------- An HTML attachment was scrubbed... URL: From frsdun at gmail.com Wed Feb 20 03:01:25 2019 From: frsdun at gmail.com (Duncan) Date: Wed, 20 Feb 2019 10:01:25 +0200 Subject: [pypy-dev] More feedback on new pypy.org In-Reply-To: References: Message-ID: Hi everyone Thank you very much for the feedback on the website. Below are some comments on your feedback: By topic: - The logo - I agree that the new flat logo is missing something that the old one has. I have asked the logo designer if he can look at finding a halfway point between the new and old one. - Ben suggested adding a list of possible applications for PyPy and I was thinking it might be nice to also have a list of software/companies that already use PyPy. If someone has this information then I can add it? - Adding a Docker image is probably also a good idea. By person: - Yury - I added padding to the navigation menu - Jacob - I changed the order of the coloured buttons to try make is less confusing. I still want one button to stand out above the rest. - Steven - I adjusted the colours to improve the contrast ratio. It was previously 5.4:1 and now it is 7.5:1 - Nathaniel - I added the CPython label to the dark grey line, hopefully that makes it a bit clearer Kind regards Duncan On Tue, Feb 19, 2019 at 7:34 PM Maciej Fijalkowski wrote: > Hi everyone! > > Here is the next iteration of pypy.org - > https://baroquesoftware.com/pypy-website/web/ - after adding some > feedback. Note that no work has been done on content just yet. > > Feel free to provide more feedback. We also need to decide what to do > with the logo. > > Best, > Maciej Fijalkowski > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > -- Kind regards Duncan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmbusif at gmail.com Sun Feb 24 17:50:56 2019 From: mmbusif at gmail.com (Mohamed Yousif) Date: Mon, 25 Feb 2019 00:50:56 +0200 Subject: [pypy-dev] Contributing to pypy development Message-ID: Greetings! I'm very interested in contributing to pypy development. But I'm really not sure how (or where) to start. So a little bit of a help would be great! I'm not sure what to do next. - i'm quite interested in jit development and i'd be very excited to work there. - i use Golang in my work and I really like how seamlessly i can integrate C code with it (definitely much easier than python). So, if i can help here that would be fine too. (i only used c++ recently in my work but i think i get some of the basics right and I'm very keen to learn more). My goal is to make python used in different domains. If you want it for its simplicity, no problem! As well as for high performance cases. PS. how much of a time i need to commit per week? I can handle up to 10 hours i guess. Regards Mohamed -------------- next part -------------- An HTML attachment was scrubbed... URL: From dynamicgl at gmail.com Wed Feb 27 13:22:36 2019 From: dynamicgl at gmail.com (Gelin Yan) Date: Thu, 28 Feb 2019 02:22:36 +0800 Subject: [pypy-dev] Fwd: Re: Users of PyPy on ARM 32bit In-Reply-To: <23f16d67-4ea2-2053-f8d9-3e46073f9778@gmail.com> References: <23f16d67-4ea2-2053-f8d9-3e46073f9778@gmail.com> Message-ID: Hi Matti What can I do for you? I never used any ARM device with 4G ram (sure I don't own one) Regards gelin yan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiri at navratil.cz Thu Feb 28 01:06:54 2019 From: jiri at navratil.cz (Jiri Navratil) Date: Thu, 28 Feb 2019 07:06:54 +0100 Subject: [pypy-dev] PyPy3 on OpenBSD? Message-ID: <20190228060654.GA99757@navratil.cz> Hello, I need PyPy3 on OpenBSD 6.4 amd64. I found only pypy-5.3.1p0 in packages, but not any PyPy3 version. Exist some binaries or documentation for OpenBSD? I see PyPy3 only in dependencies on https://pypy.readthedocs.io/en/latest/build.html How I choose pypy3 during build? Thank you, Ji?? -- Jiri Navratil, https://jiri.navratil.cz, +420 222 767 131 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4874 bytes Desc: not available URL: