cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
CrazyPython has joined #pypy
jcea has quit [Remote host closed the connection]
jcea has joined #pypy
_whitelogger has joined #pypy
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
_whitelogger has joined #pypy
CrazyPyt_ has joined #pypy
CrazyPython has quit [Ping timeout: 260 seconds]
CrazyPyt_ has quit [Ping timeout: 240 seconds]
_whitelogger has joined #pypy
jcea has quit [Quit: jcea]
<tumbleweed> I didn't realise just how bad it was, but the ppc64 JIT seems totally broken
_whitelogger has joined #pypy
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
_whitelogger has joined #pypy
ronan has quit [Remote host closed the connection]
<arigato> tumbleweed: I'm looking now, it may be my fault
<mgorny> mattip: now that we're past release, should i look into doing a final stdlib sync with python2.7?
_whitelogger has joined #pypy
pmp-p has quit [Quit: No Ping reply in 180 seconds.]
pmp-p has joined #pypy
<mattip> mgorny: yes that would be great
<mattip> there are old directions from the days cpython was on hg still
<mattip> in lib-python
simpson has quit [Ping timeout: 244 seconds]
simpson has joined #pypy
jacob22 has quit [Read error: Connection reset by peer]
oberstet has joined #pypy
jacob22 has joined #pypy
kirma has joined #pypy
rubdos has quit [Read error: Connection reset by peer]
rubdos has joined #pypy
rindolf has joined #pypy
<rindolf> Hi all! This program: https://paste.centos.org/view/d3ae94d4 takes roughly 5s to run while the equiv using sum and list comrehension takes 11s : https://paste.centos.org/view/b42c9fdf (fedora 32 x86-64 ; core i5 kaby lake;)
CrazyPython has joined #pypy
<CrazyPython> What text editor does Bright use?
astrojl_matrix has quit [*.net *.split]
nopf has quit [*.net *.split]
whitewolf has quit [*.net *.split]
ulope has quit [Ping timeout: 246 seconds]
astrojl_matrix has joined #pypy
ulope has joined #pypy
nopf has joined #pypy
whitewolf has joined #pypy
<rindolf> CrazyPython: who is Bright?
<CrazyPython> rindolf: Walter Bright, originator of Dlang
<simpson> Does it matter? (Why this channel?)
<CrazyPython> Sorry, wrong channel!
CrazyPython has left #pypy [#pypy]
<mattip> rindolf: are you using the latest 7.3.2 release?
<rindolf> mattip: i am using 7.3.1 - let me try with 7.3.2
<rindolf> mattip: with 7.3.2 from https://www.pypy.org/download.html (which says 7.3.2-alpha0), the faster code is down to 2.8s while the slower code runs at ~9s
infernix has quit [Quit: ZNC - http://znc.sourceforge.net]
rubdos has quit [Read error: Connection reset by peer]
dnshane has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
dnshane has joined #pypy
ronan has joined #pypy
rubdos has joined #pypy
infernix has joined #pypy
rubdos has quit [Ping timeout: 272 seconds]
rubdos has joined #pypy
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
<tumbleweed> arigato: thanks, testing
rubdos_ has joined #pypy
rubdos has quit [Ping timeout: 240 seconds]
rubdos_ has quit [Remote host closed the connection]
<mattip> rindolf: the difference boils down to
<mattip> sum(a*b for a,b in p)
<mattip> vs
<mattip> new = 0; for a,b in p: new += a*b
<mattip> in the first version, the code creates the generator expresssion, then needs to sum over it
<mattip> in the second, there is no intermediate expression
<mattip> sum((a * b) for a, b in p)
<mattip> I guess the JIT could somehow be taught to unroll the generator expression, maybe?
rubdos has joined #pypy
<mattip> len(seq) < 10 in your code, I imagine the slowdown would be more significant if the sequences were longer
<rindolf> mattip: ah
<arigato> mattip: re your blog post comment: I think (not sure) that the web site updates instantly, after you regenerate it and commit the generated files
<arigato> that's what I noticed when I changed the ppc links earlier
<mattip> the salt job linked to in the pypy.org README runs every 15 minutes
<mattip> I added another 15 minutes just to be sure
<mattip> not sure where the actual crontab is generated in that salt repo, but I just checked the logs on the pypy.org server to make sure
<mattip> arigato: thanks for readjusting the ppc64 downloads
<arigato> OK
rindolf has quit [Quit: http://www.shlomifish.org/ ; Some people grow older and wiser. Not I. I grow older and more foolish.]
lritter has joined #pypy
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
YannickJadoul has joined #pypy
<YannickJadoul> This wasn't a problem in pypy 2.7 rc1 or rc2, but it now seems like the actual release is failing to pass cibuildwheel's tests :-(
<YannickJadoul> If I'm reading this correctly, this is where things fail: WARNING: pip is configured with locations that require TLS/SSL, however the ssl module in Python is not available.
<agronholm> I just tried making a virtualenv with pypy3.7 7.3.2 on Windows but it fails due to "Error: [WinError 2]: Cannot find specified file"
<agronholm> this works with the same pypy3.6 release, and pypy3.7 on Linux
<agronholm> it ends up creating a defunct virtualenv
<tumbleweed> YannickJadoul: have the CFFI modules been built?
<YannickJadoul> tumbleweed: We just download https://downloads.python.org/pypy/pypy2.7-v7.3.2-osx64.tar.bz2
<YannickJadoul> The actual error seems to be: RuntimeWarning: The _hashlib module is not available, falling back to a much slower implementation (unable to load extension module '/tmp/pypy2.7-v7.3.2-osx64/lib_pypy/_pypy_openssl.pypy-73.so': dlopen(/tmp/pypy2.7-v7.3.2-osx64/lib_pypy/_pypy_openssl.pypy-73.so, 6): Symbol not found: ____chkstk_darwin
<tumbleweed> OK, I do see _pypy_openssl.pypy-73.so in there
<YannickJadoul> As far as I know, things worked smoothly for the two release candidates
<tumbleweed> hrm, can't reproduce that on OSX here
<tumbleweed> guessing that's an incompatibility between macos versions
<tumbleweed> (or rather, a new feature)
<YannickJadoul> It also doesn't fail on GitHub actions, Azure, or AppVeyor
<YannickJadoul> So you're probably right
<YannickJadoul> Guess I'll log an issue?
<tumbleweed> yeah. I certainly don't know enough about the details of the release, there. Whether it was built on a different system or what
<YannickJadoul> OK, thanks for checking!
<tumbleweed> so, that seems to be the binary in the release with that symbol
<tumbleweed> hrm, no some of the dylibs have it too
<tumbleweed> probably everything there needs to be rebuilt with a lower deployment target
<tumbleweed> not sure why it isn't everywhere or nowhere...
<tumbleweed> not a macos person :)
<mattip> according to some random issue on github
<mattip> we could try adding -fno-stack-check
<YannickJadoul> Not a macOS person either :-/
<mattip> agronholm: thanks for the report. Strange it doesn't happen on the buildbot, building a virtualenv is part of the testing
<agronholm> how can I debug the problem?
<mattip> agronholm: is there no more information?
<agronholm> nope
<mattip> windows 10?
<agronholm> yes, with the latest updates
<mattip> maybe it is some missing runtime?
<agronholm> does it use a different runtime than pypy3.6?
<agronholm> that one works fine
<mattip> it shouldn't, they are built on the same machine
<mattip> YannickJadoul: what version of MacOS are you testing?
<YannickJadoul> mattip: CircleCI is running 10.13.3, it seems
<YannickJadoul> Ah, and yes, Travis as well: macos10.13-xcode9.4.1
<YannickJadoul> Wikipedia announces 10.13's EOL as "November 30, 2020"
<mattip> ok, so that is the problem. The buildbot updated xcode, and they must have broken something.
<YannickJadoul> Yes, to confirm, AppVeyor runs 10.14, Azure & GitHub Actions run 10.15. Those jobs succeed
<YannickJadoul> So should we just update our tests and consider 10.14 the minimum for PyPy to run?
<mattip> that is one approach, but then all your wheels will be 10.14+, which might not be good for cibuildwheel's users
<mattip> I added that flag to tonights build, and if it runs to completion will merge to the py3.6, py3.7 branches tomorrow
<mattip> so maybe you could try a nightly build if those builds succeed
<YannickJadoul> Will they be? I'm not entirely sure; we do set this MACOSX_DEPLOYMENT_TARGET env-var to 10.9
<YannickJadoul> OK, great! I don't think we're in a hurry to merge this branch, so I can test with the nightlies tomorrow
<mattip> agronholm: I cannot reproduce if I open the windows zip, do
<mattip> pypy3.exe -m ensurepip; pypy3.exe -m pip3.exe install virtualenv; pypy3.exe -m virtualenv \venv
<YannickJadoul> (If it doesn't work, for those 2 months of 10.13 support left, just updating the download page might actually be easier; and we'll just test with a later version)
<mattip> it succeeds
<agronholm> mattip: I tried with pypy3 -m venv venv
<agronholm> not with virtualenv
<agronholm> isn't the venv module the recommended way these days?
<mattip> cool, that reproduces the failure, thanks
jcea has joined #pypy
<mattip> agronholm: ok, I see the problem. venv is not copying pypy3.exe + libpypyc.dll to the new Scripts directory
<mattip> dunnot why yet
<agronholm> well, I trust this will be fixed in the next release
<mattip> yup. It seems venv changed between 3.6 to 3.7, they explicitly list the python.exe they wish to find
<mattip> and we didn't check that test_venv passes
<mattip> there is a specific exe called venvlauncher.exe, and another one called py.exe
oberstet has quit [Quit: Leaving]
<mattip> so to start a venv on windows, you launch this venvlauncher, which reads the pyenv.cfg in the venv,
<mattip> and it loads the original python.exe
<mattip> so that PR made venv very specific for CPython, without even thinking about other implementations
<agronholm> :(
<mattip> and that launcher script is 2000 lines of code without a clear document laying out the algorithm for finding a python to run
<mattip> it uses the windows registry, climbing around directories and various environment variables
<mattip> ahh, sorry, there is documentation
<mattip> and a PEP
stillinbeta has quit [Ping timeout: 260 seconds]
avakdh has quit [Read error: Connection reset by peer]
idnar has quit [Read error: Connection reset by peer]
idnar has joined #pypy
stillinbeta has joined #pypy
avakdh has joined #pypy
YannickJadoul has quit [Quit: Leaving]
<mattip> or we could just hack venv to copy the exe + dll, and forget this launcher
<bbot2> Started: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8355 [mattip: force build, py3.7]
<bbot2> Started: http://buildbot.pypy.org/builders/own-win-x86-32/builds/2461 [mattip: force build, py3.7]