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
jacob22 has quit [Ping timeout: 276 seconds]
zmt01 has quit [Quit: Leaving]
zmt00 has joined #pypy
CrazyPython has quit [Read error: Connection reset by peer]
<arigato>
can someone help me translate that number into one of the debian names?
<arigato>
""wheezy", after random googling
<Dejan>
Wheezy
<arigato>
ok it seems "wheezy" doesn't have the package creduce
<cfbolz>
arigato: the clang part of creduce is optional. It's basically just a Perl script. If you want, I can try to run in when I'm in the office in a bit
<Dejan>
I have no problem with building on CentOS as we run all our software on Amazon Linux 2 :D
<Dejan>
mattip, 👍
dddddd has joined #pypy
<kenaan>
cfbolz default 292b84d69855 /pypy/objspace/std/mapdict.py: small improvement: if the map can't be promoted (eg when using setattr), check first whether the attribute goes in...
<kenaan>
cfbolz default 6050f7ce8f45 /pypy/: add two get_printable_locations
antocuni has joined #pypy
<Alex_Gaynor>
arigato: that's right -- we don't easily support it, and we looked at the stats and it's <1% of downloads
Rhy0lite has joined #pypy
<kenaan>
cfbolz record-known-result 4315f8c9ff0f /pypy/module/pypyjit/test_pypy_c/test_string.py: these four operations are removed by the branch
<Alex_Gaynor>
arigato: fwiw we dropped cryptography i686 manylinux1 wheels and no one seemed to care. I don't think manylinux2010 (the next version) even supports i686
<YannickJadoul>
Before, the general consensus did seem to be it wasn't worth the effort
xcm has quit [Remote host closed the connection]
<kenaan>
rlamy py3.6-asyncgen 2ca58cb34e7f /: Close branch py3.6-asyncgen
xcm has joined #pypy
<kenaan>
rlamy py3.6 2ccaa27c8549 /pypy/: Merged in py3.6-asyncgen (pull request #672) Fix asyncgen_hooks and refactor coroutine execution
<arigato>
YannickJadoul: on Azure platform, I need to install libffi-dev (debian package name) first
<arigato>
I haven't yet managed to do that
<ronan>
cfbolz: about the coroutine-specific attributes on frames, could we have 2 frame classes?
forgottenone has quit [Quit: Konversation terminated!]
<YannickJadoul>
arigato: Hmmm, since the Linux builds are run inside a docker, it needs to be installed through `CIBW_BEFORE_BUILD` for example. But then you don't have `apt-get` on the CentOS-based manylinux images
<arigato>
OK, that's what I'm trying now
<arigato>
I think I found the command, "yum install -y libffi libffi-devel"
<arigato>
YannickJadoul: I think it's completely ignored---I must be passing it wrongly. I'm trying with this line at the end of the "- bash:" section:
<YannickJadoul>
But that's true for any manylinux1 build, not just with cibuildwheel
<arigato>
seems to work. cibuildwheel sounds like a great tool for people like me that don't want to care too much about distribution
<YannickJadoul>
That's what I thought. Then I needed some features, then got dragged into maintaining it :D
<arigato>
:-)
<arigato>
if you want my opinion, the azure-pipelines is making an "artifact" that contains all the wheels, which is almost perfect---if it also contained the source package (sdist) it would be perfect :-)
<YannickJadoul>
Hmm, that's a good point. I just have a line `python setup.py sdist` before
<ronan>
cfbolz: it was about fixing some obscure corners in async generators, but I also moved some code around
<cfbolz>
ronan: right. What are the new fields?
marky1991 has joined #pypy
<ronan>
cfbolz: it's just PyFrame.w_yielding_from
<cfbolz>
ronan: ok
<cfbolz>
ronan: one option would be to move the field to the frame's FrameDebugData (which is already a badly named class)
<cfbolz>
Then generator frames would have a debug data set (like global frames)
<ronan>
wouldn't that make generators slower?
marky1991 has quit [Ping timeout: 240 seconds]
<cfbolz>
ronan: maybe little bit (we would have to measure), but that sounds better than making every function call a bit slower
<YannickJadoul>
cfbolz: Hello; and thanks :) It's quite fun to figure out these Python internals, actually
<cfbolz>
YannickJadoul: hehe, cool. Do you have an idea what you want to tackle next?
<YannickJadoul>
cfbolz: "PEP 564, Time functions with nanosecond resolution" seemed reasonably straightforward?
<YannickJadoul>
And "PEP 557, Data Classes" seems intriguing but a bit more involved
<YannickJadoul>
Unless you have better suggestions?
<cfbolz>
YannickJadoul: I think data classes might even just work. It's in pure python maybe?
<cfbolz>
YannickJadoul: nanosecond timers sound good! Hope it's not too annoying, OS-wise
<tumbleweed>
arigato: looks like you've been having fun :)
<tumbleweed>
so I guess I was somehow able to avoid generating the code that upset gcc, when translating with a JIT
<ronan>
YannickJadoul: implementing _abc would be useful, virtualenv is failing because of it
<tumbleweed>
it may be interesting to see the difference in the generated C, there...
lritter has quit [Ping timeout: 268 seconds]
<YannickJadoul>
cfbolz: Yeah, it's possible. I haven't actually looked at the CPython implementation of dataclasses yet
<YannickJadoul>
ronan: You mean this innocuous line in the Python docs? "Most functions and methods in abc have been rewritten in C." But I can't find any further specification?
Ai9zO5AP has quit [Ping timeout: 265 seconds]
<ronan>
YannickJadoul: yes, the source is the only spec... see Lib/abc.py and Modules/_abc.c in cpython
oberstet has quit [Remote host closed the connection]
<YannickJadoul>
ronan: Oh. Right, it's an implementation detail, in principle, but now PyPy can't use the same implementation anymore?
<ronan>
well, the issue is that PyPy now requires the _py_abc module to start up
<ronan>
we could also fix that by telling virtualenv to copy over that file when bootstrapping a new environment
<ronan>
but in the long run, we're probably better off having a builtin _abc module like CPython
<arigato>
tumbleweed: creduce is still running. I plan to let it run for as long as necessary and reconsider tomorrow if it's still not finished---unless doing so would mean you need to pay too much money to someone
<arigato>
for now it reduced the test by 67% but that means there is still a lot of cruft left
<YannickJadoul>
ronan: I'm not really getting why the separate _py_abc.py file causes an error for virtualenv, but I did find the files and the CPython PR, so I might know where to start :)
<ronan>
YannickJadoul: you can probably implement all the functions at app-level by slightly adapting the code in _py_abc.py
Ai9zO5AP has joined #pypy
<tumbleweed>
arigato: the cost of this is minimal, we keep it alive as long as you need (I think $20/month or so)
ekaologik has quit [Ping timeout: 245 seconds]
firespeaker has joined #pypy
ekaologik has joined #pypy
<arigato>
I've bitten the bullet and manually rewrote the minimal struct declarations needed to compile the 67%-reduced snippet. now I've got a fast-compiling example, and I can reduce it more much more quickly
<tos9>
I *think* it's an easy one to run into, particularly on macos, but I don't know whose "fault" to consider it, or what if anything should be done and where
<tos9>
On macOS it happens basically because of the way homebrew works
<tos9>
Specifically, any time pypy gets upgraded (either to a new pypy version, or a new version of the homebrew formula for the same pypy release)
<tos9>
Then if you have a virtualenv, that virtualenv wants to find /usr/local/Cellar/pypy3/7.1.1/libexec/lib/libpypy3-c.dylib (or whatever the case may be), but that file's gone missing
<tos9>
Maybe the thing would be PyPy showing a more specific friendly message if it isn't able to find libpypy-c.dylib at all?
<arigato>
it must be finding libpypy3-c.dylib, because this error message is produced by it
<arigato>
the error message is caused by not finding encoding in the stdlib
<tos9>
maybe there's some funny symlink resolution happening in otool though?
<arigato>
possible
dmalcolm__ has quit [Remote host closed the connection]
<arigato>
is there libpypy3-c.dylib locally in the same directory?
<tos9>
because that file normally would not be looked at in /usr/local/Cellar/pypy3/7.1.1/libexec/lib/, it should get symlinked to just /usr/local/opt/pypy3/libexec/lib/libpypy3-c.dylib
dmalcolm__ has joined #pypy
jvesely has quit [Quit: jvesely]
<tos9>
arigato: there's no libpypy3-c.dylib neither in cwd nor in the venv from what I see
<arigato>
the error message you get is the one I get if I run a pypy3 which finds its so/dylib but not its stdlib
<arigato>
in fact, the executable "pypy3" would not start at all if it didn't find libpypy3-c.dylib, no?
<arigato>
you can also convince yourself that the tiny "pypy3" doesn't contain the text "debug:" or "OperationError"
<tos9>
I certainly believe what you'd tell me so probably no need for convincing :P -- will check anyhow, but I think regardless the question is whether there's what to do about the message?
<arigato>
yes, that's probably a good idea
<tos9>
the tiny venv binary has literally the hardcoded path in it /usr/local/Cellar/pypy3/7.1.1/libexec/lib/libpypy3-c.dylib
<tos9>
so not funny symlinking afaict
<tos9>
and that path I've triple checked doesn't exist
<tos9>
but yeah obviously you're also correct that I don't see anything in just here that should produce that message
forgottenone has joined #pypy
<tos9>
dtruss also seems nonhelpful
<arigato>
the source code of the executable is literally one line from the Makefile