cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | "nothing compares to the timeshifter, my personal polar expedition in software" - pedronis
rokujyouhitoma has quit [Ping timeout: 248 seconds]
realitix has joined #pypy
cloudyplain has quit [Remote host closed the connection]
cloudyplain has joined #pypy
forgottenone has quit [Ping timeout: 240 seconds]
cloudyplain has quit [Ping timeout: 248 seconds]
cloudyplain has joined #pypy
vkirilichev has joined #pypy
antocuni_ has joined #pypy
cloudyplain has quit [Remote host closed the connection]
cloudyplain has joined #pypy
vkirilichev has quit [Ping timeout: 260 seconds]
<DRMacIver>
How much of a performance impact is settrace(None) likely to have if gettrace() is already None? I see it's marked as @jit.dont_look_inside but I don't actually know the implications of that
<DRMacIver>
I'm assuming this means that calling it in this context would defeat some optimisations.
<mattip>
ronan: (also in something I did, fixing both)
<DRMacIver>
Context: I have some code that basically does "t = sys.gettrace(); sys.settrace(None); do_stuff(); sys.settrace(t)" and am wondering if it's a worthwhile optimisation to check if t is None (which will be the common path) and not call sys.settrace() in that context.
<arigato>
DRMacIver: likely, but only if that's very hot code
<DRMacIver>
It's pretty hot
<DRMacIver>
It's basically the main function that Hypothesis calls repeatedly inside its data generation
<DRMacIver>
Expected thousands-ish calls per test.
<DRMacIver>
(that's the whole test function, not per example)
<arigato>
try and measure, I guess
<DRMacIver>
Yeah, fair enough
rokujyouhitoma has joined #pypy
<arigato>
@jit.dont_look_inside means the JIT compiles the call as a CALL assembler instruction, instead of inlining the content
<arigato>
it should have much impact here
<arigato>
you need many millions per second before noticing
<arigato>
it *shouldn't* have much impact here
<DRMacIver>
Yeah I was less worried about the call being slow and more about it defeating other optimisations/inlining
rokujyouhitoma has quit [Ping timeout: 240 seconds]
<arigato>
not really. the call is marked as "can do crazy things" because of force_all_frames(), but it's just one check after the CALL, and if there is never any trace function it will always pass
<DRMacIver>
Fair enough
<DRMacIver>
Ah, I just realised this path is way less hot than I thought it was anyway.
<DRMacIver>
Because although this function is called 1000-ish times a lot of those are recursive calls and it doesn't get hit on those.
cloudyplain has quit [Remote host closed the connection]
cloudyplain has joined #pypy
cloudyplain has quit [Remote host closed the connection]
cloudyplain has joined #pypy
forgottenone has joined #pypy
<kenaan>
mattip py3.5 d733a59858a7 /pypy/module/cpyext/include/unicodeobject.h: fix issue 2657, but why is this even an exported API function?
<kenaan>
mattip buildbot[cleanup-hg-bookmarks] 06d6f0d7b2c2 /master/templates/layout.html: remove link to numpy results from page top, add link to py3.5 instead
<kenaan>
mattip buildbot[cleanup-hg-bookmarks] be49507c1176 /: close branch to be merged
<kenaan>
mattip buildbot 201463d5f98a /: merge branch to remove hg bookmarks during hg cleanup
<mattip>
as long as buildbot is not busy, could someone update it, then we can get a better view of py3.5 status
forgottenone has quit [Ping timeout: 252 seconds]
antocuni_ has quit [Ping timeout: 255 seconds]
oberstet has joined #pypy
* mattip
off, later
vkirilichev has joined #pypy
rokujyouhitoma has joined #pypy
adamholmberg has joined #pypy
cloudyplain has quit [Remote host closed the connection]
rokujyouhitoma has quit [Ping timeout: 248 seconds]
adamholmberg has quit [Ping timeout: 240 seconds]
vkirilichev has quit [Ping timeout: 248 seconds]
rokujyouhitoma has joined #pypy
rokujyouhitoma has quit [Ping timeout: 240 seconds]
vkirilichev has joined #pypy
adamholmberg has joined #pypy
vkirilichev has quit [Ping timeout: 240 seconds]
Rhy0lite has joined #pypy
raynold has quit [Quit: Connection closed for inactivity]
rokujyouhitoma has joined #pypy
rokujyouhitoma has quit [Ping timeout: 240 seconds]
vkirilichev has joined #pypy
vkirilichev has quit [Ping timeout: 248 seconds]
antocuni_ has joined #pypy
yuyichao has quit [Ping timeout: 248 seconds]
yuyichao has joined #pypy
marky1991 has joined #pypy
yuyichao has quit [Ping timeout: 260 seconds]
antocuni__ has joined #pypy
ELFrederich has joined #pypy
antocuni_ has quit [Ping timeout: 248 seconds]
<ELFrederich>
so API is the preferred binding approach. I thought there was a way to do it lazily, or at runtime. Is that still the case?
<ELFrederich>
... sorry, this is regarding CFFI
rokujyouhitoma has joined #pypy
jwhisnant has quit [Quit: Bye.]
jwhisnant has joined #pypy
jwhisnant has quit [Changing host]
jwhisnant has joined #pypy
jwhisnant has joined #pypy
jwhisnant has left #pypy [#pypy]
rokujyouhitoma has quit [Ping timeout: 252 seconds]
yuyichao has joined #pypy
vkirilichev has joined #pypy
antocuni__ is now known as antocuni
vkirilichev has quit [Ping timeout: 255 seconds]
antocuni has quit [Quit: Leaving]
antocuni has joined #pypy
yuyichao has quit [Ping timeout: 248 seconds]
<realitix>
ELFrederich, yes the ABI mode
realitix has quit [Quit: Leaving]
yuyichao has joined #pypy
yuyichao has quit [Ping timeout: 240 seconds]
<kenaan>
mattip py3.5 5574c7edd8e2 /pypy/module/cpyext/: argument pbyteorder should be precisely int*
<ELFrederich>
I thought there was a mode that was lazy but still used a compiler.
rokujyouhitoma has joined #pypy
<LarstiQ>
ELFrederich: verify()?
rokujyouhitoma has quit [Ping timeout: 240 seconds]
yuyichao has joined #pypy
<ELFrederich>
yeah... that's it
<ELFrederich>
What do you guys think of this idea...
<ELFrederich>
annotate the C types and get bindings for free
<LarstiQ>
ELFrederich: what's the usecase?
<ELFrederich>
LarstiQ, from a single declarative definition of a function you get an automatically created C binding as well as a an automatically created idiomatic Python wrapper
<LarstiQ>
ELFrederich: the normal case for cffi I expect is that you have C to access, writing functions in python seems to defeat the point?
* LarstiQ
feels he is missing something
<ELFrederich>
here's a snippet from my existing project. I have a single definition. It creates the binding in a .pdx file and the wrapper in a .pyx file
<ELFrederich>
I was just thinking... that with type annotations I could embed all that info as well
<ELFrederich>
Right now my declarations are data-only. Mostly strings, or lists of strings, etc. I'm porting this over to target cffi instead of Cython. But in doing so I was wondering if I should switch the way I define these functions in the first place.
<ELFrederich>
I could switch them over to JSON to keep them purely data (even though they're currently data only but defined in Python syntax). If I switch to JSON, maybe some other language could consume them to create bindings. ... or, I could go 100% Python and use this new type annotation to denote the C types and calling conventions
<windy>
Hi guys, is there any performance difference in the following two approaches? Basically I just want to at least support W_IntObject and W_BoolObject while W_BoolObject inherits from W_IntObject. Approach #1: if type(x) is W_IntObject or type(x) is W_BoolObject. Approach #2: if isinstance(x, W_IntObject)
<windy>
I know the second approach will also accommodate other classes that inherits from W_IntObject
marky1991_2 has quit [Ping timeout: 240 seconds]
adamholmberg has quit [Remote host closed the connection]