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
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-aarch64/builds/688 [tumbleweed: force build, stdlib-2.7.18-3]
asmeurer_ has quit [Quit: asmeurer_]
Kronuz has quit [Ping timeout: 260 seconds]
holdsworth has quit [Quit: No Ping reply in 180 seconds.]
yajadoul has quit [Quit: Leaving]
holdsworth has joined #pypy
Kronuz has joined #pypy
<bbot2> Failure: http://buildbot.pypy.org/builders/rpython-win-x86-32/builds/351 [tumbleweed: force build, stdlib-2.7.18-3]
jcea has quit [Quit: jcea]
proteusguy has quit [Ping timeout: 258 seconds]
proteusguy has joined #pypy
<mattip> nice work with the stdlib branch
<mattip> the next step would be to merge default into it,
<mattip> and solve any merge conflicts
<tumbleweed> it was a little more of a beast than I expected...
<tumbleweed> I'm busy picking through macos regegressions
<tumbleweed> Ignoring windows, they seem fairly benign, but it's hardly my area of expertise
<mattip> the branch looks better than default on wndows
<mattip> in any case, more work can be done after merging the branch, it doesn’t have to be perfect
<mattip> thanks for the non-trivial amount of digging
<tumbleweed> the merge of default with this into 3.x isn't going to be fun :(
<tumbleweed> lots of backported patches that we've already made in py3.6
<mattip> :¯\_(ツ)_/¯:
<tumbleweed> macos regressions done. And merged default into stdlib-2.7.18-3
<psprint> I'm here because I've read about the # on cffi page. But what's Pypy?
proteusguy has quit [Ping timeout: 260 seconds]
proteusguy has joined #pypy
rfgpfeiffer has joined #pypy
fling is now known as bedflinger
bedflinger is now known as surfaceflinger
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/5256 [mattip: force build, stdlib-2.7.18-3]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7253 [mattip: force build, stdlib-2.7.18-3]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/5578 [mattip: force build, stdlib-2.7.18-3]
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7253 [mattip: force build, stdlib-2.7.18-3]
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/5256 [mattip: force build, stdlib-2.7.18-3]
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/5578 [mattip: force build, stdlib-2.7.18-3]
camelCaser has quit [Ping timeout: 258 seconds]
rfgpfeiffer has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/6051 [tumbleweed: force build, stdlib-2.7.18-3]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/5257 [tumbleweed: force build, stdlib-2.7.18-3]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7254 [tumbleweed: force build, stdlib-2.7.18-3]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/5579 [tumbleweed: force build, stdlib-2.7.18-3]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-aarch64/builds/691 [tumbleweed: force build, stdlib-2.7.18-3]
<bbot2> Success: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7254 [tumbleweed: force build, stdlib-2.7.18-3]
<bbot2> Success: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/6051 [tumbleweed: force build, stdlib-2.7.18-3]
YannickJadoul has joined #pypy
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/5257 [tumbleweed: force build, stdlib-2.7.18-3]
<mattip> tumbleweed: I think the stdlib-2.7.18-3 branch is in good enough shape to merge
<mattip> right?
<mattip> nulano: now that we have a win64 pypy, is there a reason to prefer using the cpython6464 hybrid for testing/translation,
<mattip> or does it make sense to try the pypy win64 instead?
<nulano> I'm not sure if all of the issues with translating on pypy are fixed (in default), but if so, it would probably be better to translate with pypy
<nulano> IIRC I saw a ~2x translation speed up on my system
<nulano> I think the only advantage of cpython6464 is that I think it is easier to set up (I haven't tried packaging pypy yet so I'm not sure how complicated that is)
<tumbleweed> mattip: yep
<mattip> nulano, tumbleweed: thanks. Will go ahead with these then
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/5579 [tumbleweed: force build, stdlib-2.7.18-3]
<mattip> nulano: the buildbots upload tarballs (or zip file for windows) to
<mattip> so the latest win64 build is here http://buildbot.pypy.org/nightly/win64/
<tumbleweed> there are a couple of things from stdlib-2.7.18-3 that aren't perfect
<nulano> mattip, oh right, didn't think of that :D
<tumbleweed> I'd imagine 9010767b210a can be optimized - presumably on most archs these structs were being passed in registers before, so there's a cutoff point somewhere where we don't need a copy
<tumbleweed> but meh, that can't be critical
<tumbleweed> test_asctime is failing on macos, because we haven't done the asctime rewrite from https://bugs.python.org/issue31339 (I must still investigate the py3k story, there. That was a 2.7-only patch)
<tumbleweed> and https://bugs.python.org/issue30807 concluded with a rewrite on py3k that I don't think we've got
<mattip> those can be follow-up fixes
<mattip> merged, thanks so much
<tumbleweed> more likely to be forgotten, but I'll at least have a look into them :)
<nulano> would it make sense to rename "nt_pypy" from 0af58f5e (issue 3321) to "pypy_nt" to match f1aa5bb836b (issue 3155)?
<mattip> nulano: yes it would. I thought that change looked familiar :)
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-64/builds/21 [mattip: test pypy-as-python, win64]
<bbot2> Started: http://buildbot.pypy.org/builders/own-win-x86-64/builds/104 [mattip: test pypy-as-python, win64]
<bbot2> Failure: http://buildbot.pypy.org/builders/own-win-x86-64/builds/104 [mattip: test pypy-as-python, win64]
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-64/builds/21 [mattip: test pypy-as-python, win64]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-64/builds/22 [mattip: test pypy2-64 as cpython6464, win64]
<bbot2> Started: http://buildbot.pypy.org/builders/own-win-x86-64/builds/105 [mattip: test pypy2-64 as cpython6464, win64]
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-aarch64/builds/691 [tumbleweed: force build, stdlib-2.7.18-3]
jcea has joined #pypy
<bbot2> Failure: http://buildbot.pypy.org/builders/own-win-x86-64/builds/105 [mattip: test pypy2-64 as cpython6464, win64]
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-64/builds/22 [mattip: test pypy2-64 as cpython6464, win64]
<mattip> nulano: the pypy64-as-host seems to work, except it did not skip cpyext tests
<nulano> pytest_ignore_collect is being ignored because testrunner_cfg is calling each file directly
<mattip> nice catch
<nulano> maybe somthing like 51a0030d can be added
<mattip> 51a0030d ?
<nulano> I'm not sure why heptapod uses different commit IDs...
<mattip> underneath it is git, so those are git hashes. They are working on changing it
<mattip> at the top you see 07686618d7e, which is the hg hash
<bbot2> Started: http://buildbot.pypy.org/builders/own-win-x86-64/builds/106 [nulano: test branch, win64]
<nulano> I see
<nulano> it's confusing that the heptapod search function only looks at the git hash
<nulano> and also uses it in the commit url
pmp-p has quit [Ping timeout: 256 seconds]
<mattip> tumbleweed: off the top of your head, are there any changes from stdlib-2.7.18-3 that should be merged into py3.6?
<mattip> I am tempted to merge-but-reject-all-changes, since from what I can tell it was all backports of things that are already fixed
pmp-p has joined #pypy
<bbot2> Failure: http://buildbot.pypy.org/builders/own-win-x86-64/builds/106 [nulano: test branch, win64]
<tumbleweed> mattip: hrm...
<tumbleweed> so the things I landed today after you merged probably apply to 3.x too
<tumbleweed> f801807de06f (kqueue) looks relevant
<tumbleweed> 9010767b210a (pass structs by value in ctypes) does
<tumbleweed> 094914e678b4 (avoid disabling timers) too, and then that rewrite I mentioned earlier
<tumbleweed> basically everything in the stdlib-2.7.18-3 branch was in response to failed tests, so you could just merge-but-reject-all-changes, update to the latest 3.6 stdlib, and then look for failed tests that we recognise from stdlib-2.7.18-3