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
<arigato>
simpson: C++ support is not going to happen in cffi. the official story is to first wrap your C++ code in a C API (or use something else than cffi)
<simpson>
arigato: Okay, thanks.
<Alex_Gaynor>
arigato: Have you seen rust's bindgen, which uses libclang to generate bindings for C and C++?
<arigato>
no
<arigato>
I'm not going to go for C++ in cffi anyway
<kenaan>
arigo default 61041045408c /pypy/interpreter/pyparser/: Back-port from py3.5: this makes it easier to regenerate the DFA. See comments in dfa_generated.py
<arigato>
cfbolz: note that we'll have to tweak a little bit more in py3.6, to account for the bytecode format change
<arigato>
(not much)
<cfbolz>
arigato: right
tsutsumi46 has joined #pypy
tsutsumi46 has quit [Client Quit]
<arigato>
possibly not at all, if the format of co_lnotab didn't change and still measures amounts in bytes---but I guess it now measures them in 2-byte units, right?
<arigato>
or maybe not, to avoid complications and compatibility issues?
<arigato>
indeed, seems not
<arigato>
so I guess chances are that it works out of the box
Taggnostr has quit [Quit: No Ping reply in 180 seconds.]
Taggnostr has joined #pypy
<cfbolz>
arigato: 'cool'
<cfbolz>
arigato: I wonder a bit how much I should follow all the bytecode micro optimizations that CPython 3.6 introduced
tsutsumi19 has joined #pypy
tsutsumi19 has quit [Client Quit]
tsutsumi19 has joined #pypy
tbodt has joined #pypy
dfee has quit [Ping timeout: 245 seconds]
<arigato>
if you ask me, I wouldn't worry about that
<cfbolz>
arigato: agreed. I ported the one that was an actual optimization
<cfbolz>
MAKE_CONST_KEY_DICT
<cfbolz>
(actually it would need some rpython support to be really efficient, because in theory we don't even need to hash the keys every time, but just copy an existing dict and change the values in the copy)
<arigato>
you convinced yourself (or checked) that it makes a virtual dict, with the jit?
<arigato>
i.e. isn't worse than the old way
<arigato>
interesting idea btw, might also help jitted code when it is forcing a virtual dict
<cfbolz>
right
<cfbolz>
arigato: the other place where it could be used is in the json decoder, where we decode dicts with exactly the same structure quite often
<arigato>
the two places inside pypy might benefit from an alternative dict implementation, instead
<cfbolz>
arigato: yes, of course
<cfbolz>
good point :-)
<cfbolz>
arigato: but that can't be used when forcing dicts in the jit ;-)
<cfbolz>
arigato: maybe I should do my first CPython patch :-)
<arigato>
be ready for it to wait at least some years on the patch :-)
<arigato>
...on the issue tracker
<cfbolz>
no, I just won't bother
<arigato>
although, I didn't try recently, so maybe pure micro-optimizations go quicker in than corner-case bug fixes
<cfbolz>
:-(
<cfbolz>
arigato: I think using a dict strategy isn't a good idea anyway, because when you actually mutate the dict, the first thing you have to do is then make a copy of the template and insert the keys
<cfbolz>
so you might as well do it right away
<cfbolz>
*insert the values
<arigato>
yes, agreed, and also a dict strategy might be slower for lookups
<arigato>
even if it's not modified
<cfbolz>
maybe wouldn't be so bad, just one more indirection
oberstet has quit [Read error: Connection reset by peer]
<arigato>
ok no clue why:
<kenaan>
arigo default 6a1df86a6f7a /pypy/module/: uh revert this
<arigato>
ah, that's because the release-pypy2.7-6.x branch contains changesets that turn the version from 6.1.0-alpha to 6.0.0, and I have merged release-pypy2.7-6.x into reverse-debugger at some point