<kenaan>
arigo sandbox-2 322c4bfc9c42 /rpython/: Revert the changes to backendopt done in 906b820ecdac; instead move the review-checking before running backendopt...
<mattip>
the text for `python3 --help` and pypy3-c --help` is slightly different for -O and -OO
<mattip>
cpython says:
<mattip>
something about adding opt-1 or opt-2 to the pyc file, and also ignores __debug__ statements
<mattip>
should we sync to that, or do we still only do the python2 optimizations?
<kenaan>
mattip py3.6 39096734e7bc /pypy/interpreter/app_main.py: pypy3 -b and pypy3 -d now exist, add them to the --help text
tsaka__ has quit [Ping timeout: 245 seconds]
<kenaan>
arigo sandbox-2 f4ba641484fa /rpython/translator/sandbox/graphchecker.py: Write docs about the @sandbox_review() and llexternal(sandboxsafe=..).
<kenaan>
arigo py3.6-sandbox-2 6dcefdad5651 /pypy/module/: More sandbox_reviews
<kenaan>
arigo py3.6-sandbox-2 3a1756763860 /pypy/module/: Found out there are two versions of os.urandom() around, and figured out when one is shadowed by the other
<mattip>
cfbolz: 520b3c9072f2 seems to be causing some test failures
<kenaan>
mattip default 2fc0a2974836 /rpython/rlib/test/test_rbigint.py: remove pdb from test
<Dejan>
I wish to thank you guys for the aarch64 support
<mattip>
Dejan: is it working for you?
<Dejan>
I use a nightly build from few days ago
<Dejan>
so far so good
<mattip>
we would love to hear more, especially if it is good, and even better if there are real world benchmarks
<cfbolz>
Dejan: cool!
<Dejan>
I have a VPS on Scaleway with 6 AArch64 vCPUs, and few tiny Python services running there, nothing fancy
<Dejan>
they are all running on pypy3 now
<Dejan>
it is just some personal stuff, nothing serious
<mattip>
can you share what happened when you moved from cpython3 to pypy3?
<mattip>
memory, cpu?
dddddd has joined #pypy
<Dejan>
i did not look at monitor/cpu :) i just wanted my service to work with pypy3 :D
<Dejan>
and it did
<Dejan>
Python 3.6.9 (1cd037049338, Aug 22 2019, 01:13:56)
<Dejan>
[PyPy 7.2.0-alpha0 with GCC 7.4.0]
<Dejan>
this is what I am using there
<Dejan>
I tried Celery 4.3.0 with Redis as broker
<Dejan>
managed to run few dummy tasks without problems
tsaka_ has joined #pypy
tsaka__ has quit [Ping timeout: 272 seconds]
<mattip>
cool, thanks for the feedback. Would be nice if you could compare to cpython3, we love getting real-world data
<mattip>
but I understand that means setting up monitoring and then running them on some real tasks
<Dejan>
i was wondering if PyPy could in theory do some internal optimization with IO - to automatically use memoryviews when it detects usage of buffers
<cfbolz>
mattip: thanks matti, too hot to think it seems :-(
<Dejan>
i am boiling here in the office... (London)
tsaka__ has joined #pypy
tsaka_ has quit [Read error: Connection reset by peer]
* mattip
updated the aarch64 buildslave to use latest pypy2 build, maybe that will improve the success rate for py3.6 builds
ionelmc has joined #pypy
<tos9>
github actions has support for pypy, that's nice
<tos9>
maybe they are sending an olive branch :)
the_rat has joined #pypy
dddddd has quit [Quit: Hasta otra..]
dddddd has joined #pypy
<ionelmc>
what make cffi produce a .py instead of a .so when using a builder (eg:cffi_modules=[i + ':ffi' for i in glob('src/*/_*_build.py')] in setup.py)
<kenaan>
rlamy py3.6 92ad09ea1c06 /lib-python/3/collections/__main__.py: Remove file deleted in CPython
<tos9>
ionelmc: probably would need to see the code there, nothing I know of, but yeah
<tos9>
ionelmc: doubt it'd be related to using a list comp of course, so it's something about one of those files themselves presumably
<mattip>
ionelmc: ffi.cdef / ffi.set_source / ffi.compile will produce an importable so
<mattip>
ffi.cdef / ffi.dlopen will not compile at all, so it will remain a py file
<kenaan>
rlamy py3.6 79ea93489fc4 /lib-python/3/ssl.py: fix bad merge
<cfbolz>
tos9: cool, link?
xorAxAx has quit [Quit: Idle timeout reached: 172800s]
<ionelmc>
ah ... i was using set_source("stuff", None)
<ionelmc>
now it makes sense
<ionelmc>
could i produce universal wheels in theory? without compilation the resulting py file only has a bunch of _cffi_backend calls - that should be cross platform right?
<mattip>
cfbolz: I think github actions is built on "azure pipelines" which is travisCI but from Microsoft, and offers windows, macos and linux images
<mattip>
for instance, here is the vs2019 image for windows, with pypy 2.7.13 and 3.5.3
<cfbolz>
mattip: cool, thanks. I should tweet about that
<mattip>
ionelmc: once you do ffi.compile, you get a c-extension module compiled for a platform
<mattip>
without compilation it should be pure python
<mattip>
you may have to "trick" the call to ffi.dlopen() to find the right thing though
Dejan has quit [Quit: Leaving]
<kenaan>
rlamy py3.6 b70c9c1a4b02 /lib-python/3/test/: fix old merge cruft
<arigato>
more on git-vs-mercurial in this old post, which at least gives me some hint about how you're supposed to use git: https://jhw.dreamwidth.org/1868.html
<kenaan>
rlamy py3.6 dfa10ae95bae /lib-python/3/ctypes/test/: Don't use @xfail for tests that can't possibly work on pypy
<kenaan>
rlamy py3.6 18630a74b4d0 /lib-python/3/: Use @support.refcount_test to skip tests relying on sys.getrefcount()
<tos9>
(i.e. basically saying: os: [ubuntu-latest, windows-latest, macOS-latest] python-version: [pypy2, pypy3, 3.5, 3.6, 3.7] gets you a build that in theory runs on that cross product)
<tos9>
in practice I haven't gotten a successful run yet, but... tomorrow, tomorrow will be the day