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
<mattip>
if it would have come in after the release, I don't think we would do a patch release for it, but on the other hand it will be annoying for people who use the Makefile
<mattip>
Oh well, I guess it should go in. Back to spamming IRC with builds
<tumbleweed>
mattip: that looks like it was broken forever
<tumbleweed>
close to a year
<tumbleweed>
I just noticed it when fixing something else that was pointing to that tool
<mattip>
ahh, ok. Anyway it looks like I missed something else too. The hg commit history for the past two days is really messy
<tumbleweed>
so presumably nothnig in the release machinery is using that Makefile
<mattip>
correct. It is another piece of PyPy that is never tested
<mattip>
but used downstream
<tumbleweed>
yeah
<tumbleweed>
wouldn't hurt to cherry pick
<tumbleweed>
BTW, I'm picking through my test failures
<mattip>
I messed up the rc3 tag for release-py2.7.x
<mattip>
cool
<tumbleweed>
looks like a type issue in FAIL module/micronumpy/test/test_dtypes.py::AppTestDtypes::()::test_record_hash
<tumbleweed>
and I see a handful of problems due to no /usr/bin/python on Debian systems any more
<mattip>
We are getting closer to using pypy2 as a host for running tests, but still not there on linux
<mattip>
we have no concrete plans to move rpython to python3
<mattip>
thanks. It is nice to have someone actively fixing tests :)
<danchr>
actually, the MRs already targeted default and py3.7 :D
<danchr>
here's an interesting tiny point: PyPy is consistently slightly inconsistent with the year ranges allowed for time.mktime() compared to CPython
<mattip>
danchr: can you create some failing tests? Is it on all platforms?
<danchr>
I wrote a small script comparing all installed pythons; the results are wildly inconsistent between the three platforms I have access to (darwin/x86_64; freebsd/x86_64; linux/arm64)
<mattip>
yeah, that was my impression too. I think it is pretty hopeless to acurately mimic CPython
<danchr>
but darwin/freebsd agree that the minimal year for mktime() is ~1900
<danchr>
so essentially, if users are relying on mktime() with a year of 1 or 2, their code is broken anyway…