cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | the secret reason for us trying to get PyPy users: to test the JIT well enough that we're somewhat confident about it
marr has quit [Ping timeout: 240 seconds]
<kenaan>
mattip pypy.org[extradoc] 76349268013a /: tweak for win32 new compiler (no runtime needed?), formatting
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<arigato>
"making a nursery" => "starting a new 'main loop' equivalent", where the 'main loops' of async/await become local to functions
<arigato>
"passing the nursery as an argument" => "calling a async function"
jaffachief has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<arigato>
the only problem with the current syntax is when you want to pass several nurseries as arguments (or one async-for-IO and one nursery)
<arigato>
but anyway, my point here is that nurseries should maybe not be available as plain variables because then it's too tempting to stick a nursery somewhere globally, and then you're back to the goto world
pulkitg has joined #pypy
agates has joined #pypy
bendlas has joined #pypy
yuvipanda has joined #pypy
abvi[m] has joined #pypy
<arigato>
as you can see, I like the idea but have a distrust of async/await to start with so I won't assume that it's something to build on :-)
<nedbat>
The downloads page says "Python 3.5.3 compatible PyPy3.5 v6.0.1", but all of the downloads there have "6.0.0" in the file names. Is that right?
<nedbat>
thanks! When I try to make a virtualenv with pypy3, I get a screenful of error: https://gist.github.com/nedbat/73492d76d2fa960dcfd9bbcfcab131f6 Does this ring any bells? I know the fault might lie elsewhere. is this the failure to expect if running pypy3 on Sierra?
lazka has joined #pypy
<mattip>
I seem to remember some high sierra/sierra issues with 5.10, maybe the same thing?
lazka has quit [Ping timeout: 248 seconds]
jaffachief has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Rhy0lite has joined #pypy
jaffachief has joined #pypy
ronan_ is now known as ronan
jaffachief has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
adamholmberg has joined #pypy
jaffachief has joined #pypy
mcyprian has quit [Remote host closed the connection]
mcyprian has joined #pypy
lazka has joined #pypy
<lazka>
nedbat, "pypy3 -m venv" has last worked for me on debian, where virtualenv also failed
lazka has quit [Quit: Leaving]
<mattip>
lazka: I'm pretty sure it is a MacOS issue with "dyld: Symbol not found: _utimensat"
<mattip>
:(
<nedbat>
mattip: to be fair, the pypy3 mac build says, "Not for Sierra and below"
<mattip>
indeed, you are using Sierra, not High Sierra?
Hasimir has quit [Ping timeout: 240 seconds]
Hasimir has joined #pypy
jaffachief has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lritter has joined #pypy
jaffachief has joined #pypy
pf_moore has joined #pypy
jaffachief has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jaffachief has joined #pypy
dustinm- has quit [Quit: Leaving]
dustinm has joined #pypy
exarkun has quit [Read error: Connection reset by peer]
kirma has quit [Ping timeout: 260 seconds]
jaffachief has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
exarkun has joined #pypy
<nedbat>
mattip: yes, I am using Sierra
tayfun26 has quit [Quit: tayfun26]
jaffachief has joined #pypy
mcyprian has quit [Ping timeout: 240 seconds]
jaffachief has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mcyprian has joined #pypy
mcyprian has left #pypy [#pypy]
asmeurer_ has joined #pypy
asmeurer_ has quit [Ping timeout: 248 seconds]
asmeurer has joined #pypy
kirma has joined #pypy
asmeurer has quit [Ping timeout: 240 seconds]
<kenaan>
wlav cppyy-packaging e7331182c14c /pypy/module/_cppyy/: const correctness for data members and associated tests
<kenaan>
wlav cppyy-packaging 682a43ef7a89 /pypy/module/_cppyy/: support anonymous enums
<kenaan>
wlav cppyy-packaging f8f27990a737 /pypy/module/_cppyy/: initial support for function pointer arguments
<kenaan>
wlav cppyy-packaging b762bdca4513 /pypy/module/_cppyy/src/dummy_backend.cxx: add extra info in dummy_backend for const_int test
energizer has joined #pypy
marr has joined #pypy
tbodt has joined #pypy
jaffachief has joined #pypy
jaffachief has quit [Client Quit]
energizer has quit [Disconnected by services]
energizer has joined #pypy
energizer has quit [Remote host closed the connection]
energizer has joined #pypy
jaffachief has joined #pypy
asmeurer__ has joined #pypy
lritter has quit [Ping timeout: 240 seconds]
lritter has joined #pypy
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
tbodt has joined #pypy
jaffachief has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jaffachief has joined #pypy
Rhy0lite has quit [Quit: Leaving]
raynold has joined #pypy
zmt01 has quit [Quit: Leaving]
zmt00 has joined #pypy
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jaffachief has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tbodt has joined #pypy
catern has joined #pypy
<catern>
hey #pypy, I am trying to use CFFI, and I've got a library whose header includes inline functions
<catern>
is there some way I can still programmatically read that header and generate bindings for all the functions in it, excluding the inline functions?
kipras is now known as kipras`away
kipras`away is now known as kipras
tbodt has quit [Read error: Connection reset by peer]
tbodt has joined #pypy
jcea has quit [Remote host closed the connection]
jcea has joined #pypy
<arigato>
catern: if you're using the recommended API mode of CFFI, the fact that functions are marked inline should have no importance
<arigato>
if you're asking "can I just dump this .h file to ffibuilder.cdef()", then the answer is generally no, for this and other reasons
<catern>
arigato: yes, I am using API mode
<catern>
I realize that this is one reason why I can't just dump a .h file to cdef, but I have done it before with header files which don't have inline functions, and it's worked fine
<catern>
I would like to find a programmatic workaround so I don't have to manually edit the .h file just because it includes inline functions
<catern>
I don't think there is any principled reason why I can't just dump a .h file to ffibuilder.cdef :)
<arigato>
well, I can give you one :-)
<arigato>
it assumes a certain style of C; if you have a header full of #ifs, or if you have other machine-specific configuration, then it will break
<arigato>
in other words, it only works if your C header is nice and simple
<arigato>
for all other cases, that's what the cffi-cdef-specific "..." syntax is for
<arigato>
but anyway
<arigato>
in short, although I think it's kind of the wrong approach, I know there exist some tools to help you convert a real .h file to a cdef-friendly one
<arigato>
it's the wrong approach in general, but it might be the right approach if you have a specific set of .h files from a library, say, and you use the corresponding tool
<arigato>
in your case, I'd look for or make a tool that manually strips the inline function bodies
<arigato>
it's C so it's a bit of a mess, but doable
<arigato>
maybe using the pycparser library
<arigato>
in fact, I'm not sure that having function bodies is really a problem for a cffi cdef()
<arigato>
I would expect them to be just ignored
<arigato>
are you sure the problem isn't just the "inline" or "__inline__" keywords? maybe it's enough to do .replace("inline", "")
jaffachief has joined #pypy
<arigato>
"inline" is accepted but the gcc-only "__inline__" is not, for example
jaffachief has quit [Client Quit]
<arigato>
(that's because "inline" is standard C (maybe C99) but "__inline__" is gcc-specific)
<arigato>
(a general warning, some corner cases are not tested if cdef() is sent actual C expressions containing a literal string, because it assumes that they don't show up in cdef(); but they would if the cdef() is passed functions with bodies)