antocuni changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | "PyPy: the Gradual Reduction of Magic (tm)"
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
marky1991 has joined #pypy
mattip_ has joined #pypy
mattip has quit [Ping timeout: 248 seconds]
mattip_ has quit [Ping timeout: 268 seconds]
mattip has joined #pypy
tbodt has joined #pypy
marky1991 has quit [Read error: Connection reset by peer]
marky1991 has joined #pypy
<nanonyme>
Sounds good
<nanonyme>
mattip, I'm not to be honest sure how much benefit it brings as it's not as if the new C++ features would do you much good but doesn't hurt to use a modern compiler
<mattip>
someday we may
<mattip>
decide enough of win32 2.7 and be able to use modern C
<nanonyme>
MSVS doesn't really follow up on modern C as well as it does on modern C++
<nanonyme>
But sure, it might win you some as well
<mattip>
stdint.h would be nice
antocuni has joined #pypy
<nanonyme>
Or rather, MSVS has been known to implement a lot of new C standards but leave holes never completely finishing up on the support
<nanonyme>
If you don't hit the holes, it's probably fine. They're typically things with less demand anyway
<tos9>
How can I debug why it looks like vmprof is hanging forever trying to profile a script
<tos9>
Maybe I guess I can start by using vmprof.enable instead of running the module...
<antocuni>
tos9: which pypy and vmprof versions?
<tos9>
vmprof==0.4.10
<tos9>
pypy... 5.9.0
<tos9>
antocuni: ^
<antocuni>
are you using greenlets/eventlet/gevent?
<tos9>
antocuni: so, hypothesis is involved, and I think hypothesis is using coverage these days
<tos9>
so I think no to those, but yes to trace function shenanigans
<tos9>
actually I wonder if I can disable that and see if it still hangs...
<antocuni>
I suggest you to try with a pypy nightly
marky1991 has quit [Ping timeout: 240 seconds]
<antocuni>
recently I realized that the C code in vmprof and inside pypy were gone out of sync
<antocuni>
so I updated them on the pypy side
<antocuni>
but this was after 5.9
<tos9>
A ha.
<tos9>
OK, let's see if I can get my hands on a nightly...
<kenaan>
arigo unicode-utf8 3b96420db19a /rpython/rlib/test/test_rutf8.py: On wide hosts, though, we should continue to run this test about lone sorrogates
<tos9>
man 1 strip also says "-d filename Save the debugging symbol table entries for each source file name listed in filename."
<antocuni>
sounds promising
<antocuni>
note that there are also tests for smartstrip, so it's easy to check whether it works
marky1991 has quit [Ping timeout: 276 seconds]
<njs>
mattip: regarding Windows compilers, there's also some mess around how the compiler you choose affects the compiler people use for extension modules
<njs>
for pypy3 you probably want to get onto msvc2015+ ASAP, because that's when they switched to a much more reasonable setup (like, they're no longer breaking compatibility every year?), and that's what cpython is on. For pypy2 it's not quite as obvious; there's an argument for going to MSVC2015+ there too because it's better and 99% of the time everyone has to recompile for pypy2 anyway, but this might annoy mitsuhiko who wants to ship wheels that work on both
<njs>
cpython and pypy.
<mitsuhiko>
why would my wheels change?
<njs>
mitsuhiko: if pypy and cpython were using a different C ABI, then you would have trouble shipping a single .dll that worked for both. (That's the very very high level summary; windows ABI compatibility has endless caveats. And maybe you don't care about windows, idk)
<tos9>
antocuni: cool, iwll have a look, thanks
<mitsuhiko>
njs: clue me in. how does a dll work differently on different msvc versions?
<njs>
mitsuhiko: traditionally every new release of msvc comes with a new incompatible version of libc
<mitsuhiko>
so the concern would be assuming that malloc on the pypy side is a different one than the one in the extension?
<mitsuhiko>
or something along those lines?
nunatak has quit [Quit: Leaving]
<antocuni>
mitsuhiko: how do your cross-compatible wheels work? Do you simply ship both *.so and *.pypy-41.so?
<antocuni>
or it's really a single .so which is compatible with both?
<mitsuhiko>
it's a single .so that is loaded via cffi
<mitsuhiko>
and does not link against python symbols
<antocuni>
interesting
<njs>
mitsuhiko: right exactly
<mitsuhiko>
njs: so not that i'm an expert in c on windows but in the past i compiled dlls with old compilers and i never had an issue loading that on newers
<mitsuhiko>
(assuming nothing c++ fancy)
<nanonyme>
njs, nothing's changed on that front really. If your target platform doesn't have the C++ runtime you want, your libraries simply will not load
<nanonyme>
Assuming you don't link statically but that's another jungle
<njs>
mitsuhiko: technically it can be made to work but there's a lot of confusing and subtle issues you can run into, so the general advice for those who don't have a deep understanding of C runtimes is to stick to using the same compiler for both the interpreter and all extensions
<mitsuhiko>
njs: for c++ sure, but for c?
<nanonyme>
It's the same runtime
<nanonyme>
MSVC works in a funky way
<njs>
mitsuhiko: yeah, for C. you can have two different heaps (malloc/free), you can have incompatible FILE* objects, etc.
<nanonyme>
Afaik the jist is that malloc etc are in reality high-level abstractions over what the platform actually has
<mitsuhiko>
njs: yeah. but that's not really an issue
<nanonyme>
Runtime gives you something reasonable to work with
<mitsuhiko>
we don't pass file handles or memory across boundaries and assume same allocator
<njs>
mitsuhiko: cool
<mitsuhiko>
so we're good. break the world!
<njs>
mitsuhiko: hopefully milksnake doesn't have any users who are doing those silly things :-)
<njs>
I guess the other thing to watch out for is that distutils/setuptools may have some hard-coded magic that "knows" that python 2 + windows -> use msvc 2008
yuyichao_ has quit [Ping timeout: 248 seconds]
<kenaan>
arigo unicode-utf8 7839b53125bb /rpython/rlib/: Add a utility function that I might use in rsre
<kenaan>
arigo unicode-utf8 a5ddce968cd5 /rpython/rlib/test/test_rutf8.py: Fix test (?)
yuyichao_ has joined #pypy
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]