00:10 <simpson> Well, no, I have two more thoughts: If he has *already manifested* the first speedup, then this would be interesting to read; we can rip off anything actually good from his first two phases, and we're currently over three phases' worth of speedup ahead of CPython. https://lobste.rs/s/5qwgri/implementation_plan_for_speeding_up#c_1rr2yv

06:23 <mattip> I think hotpy was already presented in 2011

06:23 <mattip> https://sites.google.com/site/makingcpythonfast/home

06:24 <mattip> so we have had plenty of time to "rip off anything actually good" already

06:26 <mattip> (there is also https://hotpy.blogspot.com/)

06:33 <mattip> (and the code is in the bitbucket archive, search here for "markshannon" https://bitbucket-archive.softwareheritage.org/projects/ma.html)

06:58 <LarstiQ> tiered execution to get a faster interpreter before the jit kicks in might be nice

11:35 <bbot2> Started: http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-64/builds/3057 [mattip: force build, py3.6]

13:15 <bbot2> Success: http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-64/builds/3057 [mattip: force build, py3.6]

14:04 <toad_polo> How is one supposed to install PyPy on Windows? When I download the file from pypy.org it's a zip file containing executables, and when I extract them somewhere and try to run `pypy.exe`, it complains about a missing `VCRUNTIME140.dll` file.

14:05 <toad_polo> I installed the vcredist.msi or whatever that is mentioned in the notes for the Windows download, that didn't help.

14:06 <toad_polo> I'm having an issue where `tox` is broken on Windows with PyPy 3.6.9-7.3.2 -7.3.1-final worked.: https://github.com/pganssle/zoneinfo/pull/93/checks?check_run_id=1287176999

14:06 <toad_polo> Pinning `tox` doesn't help, but weirdly none of the code implicated in the traceback has changed in years.

14:17 <mattip> I think we now use a newer runtime. Could you try the latest x86 one from

14:17 <mattip> https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads

14:17 <mattip> which is

14:17 <mattip> https://aka.ms/vs/16/release/vc_redist.x86.exe

14:17 <mattip> If that works I will update the web page

15:30 <mattip> can reproduce the tox failure. I don't yet understand which variable in the call has an invalid value

17:53 <mattip> what should os.path.exists('') produce: True or False?

17:54 <mattip> toad_polo: it turns out that is the problem with pypy7.3.2 on windows

17:54 <mattip> the correct answer is False, but somehow we changed it to True

17:54 <toad_polo> mattip: Ah, nice, sorry I was a bit away there.

17:54 <toad_polo> Having some trouble with my Windows VM and also doing CPython sprint stuff at the same time.

17:55 <mattip> so I am not sure how to fix this for tox, can you pin to 7.3.1 somehow?

17:55 <toad_polo> I think not easily.

17:55 <toad_polo> https://github.com/tox-dev/tox/issues/1704

19:43 <toad_polo> mattip: Do you know offhand the canonical easiest way to get a reliable indicator of whether or not I'm on PyPy 7.3.2? `python --version | grep 7.3.2` or something?

19:44 <toad_polo> I'm thinking that I'll solve this problem in the short term by simply skipping the tests if I'm on a broken version of PyPy on Windows, and hopefully it can be re-enabled automatically even if I forget that I did that, when PyPy updates.

19:55 <mgorny> toad_polo: sys.pypy_version_info has what you want

21:02 <mattip> the problem is caused by too many options to the path_or_fd unwrap_spec in interp_posix

21:02 <mattip> for some functions, like listdir, '' is turned into '.'

21:03 <mattip> but for stat, it should remain ''

21:04 <mattip> (it is more nuanced than that)