tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
tilgovi has quit [Remote host closed the connection]
tilgovi has joined #pypy
altendky has quit [Quit: Connection closed for inactivity]
jacob22_ has quit [Quit: Konversation terminated!]
forgottenone has joined #pypy
jamadden has quit [Quit: Leaving.]
vkirilichev has joined #pypy
vkirilichev has quit [Read error: Connection reset by peer]
tilgovi has quit [Quit: No Ping reply in 180 seconds.]
tilgovi has joined #pypy
vkirilichev has joined #pypy
amaury has joined #pypy
brent_ has quit [Ping timeout: 240 seconds]
<kenaan>
amauryfa py3.5 09eee048800a /pypy/module/sys/vm.py: Add a fake getwindowsversion()._platform_version, so that platform.win32_ver() can return something. (it will alwa...
tilgovi has quit [Quit: No Ping reply in 180 seconds.]
tilgovi has joined #pypy
arigato has joined #pypy
vkirilichev has quit [Remote host closed the connection]
<o11c>
the line number is *wrong*, and there's no detail of *what* went wrong
<arigato>
based on pycparser, itself based on ply; you can put the blame anywhere
<o11c>
I did a little source diving and at least some of it is obviously on cffi
<arigato>
yes, I'm sure, and I would appreciate feedback in the form of issues
<o11c>
pycparser actually handles it AFAICT, it's just cffi bailing out
tilgovi has quit [Ping timeout: 255 seconds]
<arigato>
I admit I didn't send too much efforts in the C parsing parts, because syntax parsing is really not an interesting topic for me
<arigato>
I should have done a bit more efforts sometimes
<o11c>
seriously, bitbucket is up the creek right now
<o11c>
try to sign in with OpenID -> "we've signed you out". Never recorded the password, so do an email reset. Finally log in ... it asks me to verify my email. The one I just used to reset it.
<realitix>
+1 about bitbucket, github is better from my point of view but it's not easy to migrate from bitbucket to github. After all, it depends on arigato preference, he is the maintainer but maybe cffi would have more visibility on github
<o11c>
realitix: at least it's not on launchpad
<ronny>
main pain is mapping bb usernames to gh usernames when moving the issues
cstratak has quit [Read error: Connection reset by peer]
<mihaid>
Hello, guys. I recently made a branch, and I was working on enabling profile guide optimizations for PyPy. I have made it work for now by adding some new rules and definitions in the makefile generation in genc.py. However, I have also commented out the old way profopt was done. My question is, would this be a problem when I make a pull request?
cstratak has joined #pypy
<LarstiQ>
mihaid: PRs are a basis for discussion anyway
<mihaid>
I tested the pgo build with the PyPy proposed benchmark, and it shows an average improvement of 5%, with the exception of n-body simulations which are slowed down by 45%. However, I talked a bit with Carl about this and he said it should be fine. Maybe not as the default option, but rather as one of the options available when translating. I also ha
<mihaid>
ve a Google Spreadsheet with the results, if you want to look at it.
john51 has quit [Read error: Connection reset by peer]
lukasa has quit [Excess Flood]
john51_ has joined #pypy
lukasa has joined #pypy
<kenaan>
tobweber stmgc[c8-adaptive-trx-length-prolonged-backoff] b8316d20df70 /c8/stm/nursery.c: Prolong the reduction in transaction length for a number of validations ...
<ebarrett>
who's working on the PyPy C extension API these days?
<ebarrett>
cpyext, right?
jacob22_ has joined #pypy
<arigato>
mostly matti&ronan, a bit of me
<arigato>
plus others like mjacob, cfbolz, etc., but matti&ronan are the main workers
<ebarrett>
do you know chris seaton, of oracle?
<arigato>
maybe?
<ebarrett>
he's asked if I could introduce him to someone who knows about how cpyext works
<ebarrett>
he's the truffleruby guy
<arigato>
no
<ebarrett>
ah, ok
<ebarrett>
mind if i invite him here?
<arigato>
sure, please do
<ebarrett>
thanks
jamadden has joined #pypy
jamadden has quit [Client Quit]
arigato has quit [Quit: Leaving]
chrisseaton has joined #pypy
arigo has joined #pypy
arigo is now known as arigato
jamadden has joined #pypy
jamadden has quit [Client Quit]
<ebarrett>
hi chrisseaton, I'll leave you with these guys :)
<ebarrett>
arigato: meat chris
<ebarrett>
*meet
antocuni has quit [Ping timeout: 246 seconds]
<chrisseaton>
arigato: hi, I was wondering how I can learn more about cpyext and what challenges there are in implementing the Python C API and how you solve them? I have a project implementing Ruby's C API and I want to compare and contrast for papers and presentations
mihaid has joined #pypy
<arigato>
hi! it depends a bit about the underlying system. in PyPy, we tweaked the GC a little bit to help cpyext
<arigato>
are you running in the JVM?
<chrisseaton>
Yes
<arigato>
there's a paper that shows how it was done in the past, let me see
<chrisseaton>
As a concrete example, Ruby has an API call RARRAY_PTR that gives you the internal VALUE* to the array, which C code reads, writes, and stores wherever it wants. This doesn't interact well with storage strategies, so we've implemented as system of virtual C pointers, that look like a VALUE* but actually reads and writes get redirected back into our VM
<chrisseaton>
I don't know if Python has that level of challenge, or if the API is a bit better designed
<LarstiQ>
"hah"
<ebarrett>
ah, that sounds fiddly
<arigato>
no, the API is not well-defined either
<chrisseaton>
The same thing with strings, you can get a char*, but our strings are actually ropes, so we virtualise the pointer
<arigato>
right
<arigato>
you can do that because you don't run the native compiled C code
<chrisseaton>
Yes
<chrisseaton>
But you do? And you still manage to solve problems like that? Or you have fewer problems?
<arigato>
yes, we do
<arigato>
so I fear there isn't much to share between our solutions because the tradeoffs are very different
jamadden has joined #pypy
<arigato>
our solution is not general, but case-by-case
<arigato>
for example, for strings, we use a method whereby if the GC won't move the string object we return a pointer inside it, and otherwise we make a copy
<arigato>
for tuples or lists, you can indeed get it as an array of "PyObject *" with the C API
<arigato>
when we do, we really force the representation as an array of "PyObject *"
<arigato>
for tuples it's just a copy
<arigato>
(they are immutable)
<arigato>
for lists, it's using a "list strategy", which is our otherwise-useful technique to change the representation of lists
<chrisseaton>
Yes we talk about 'deoptimising objects to native' when they start to be accessed from C code - strings are flattened if they go to real native code and things like that
<arigato>
(e.g. lists of integers represented with an array of ints, as opposed to lists of general objects)
<arigato>
yes, we do that
<arigato>
at least, the C API contains some but not too many of these "direct" access points
<arigato>
usually you're supposed to use at least macros, and these macros are implemented as regular functions on pypy
<arigato>
so, what we offer is not binary compatibility with CPython, but you need to recompile
<chrisseaton>
Thanks
<chrisseaton>
Ruby has better functions, but the key C extensions like openssl don't use them
<arigato>
hah
<arigato>
anyway, you're in a very different world from both pypy and the JNI I think
<chrisseaton>
We can't keep everything in our interpreted mode unfortunately - if you want to call functions in a compiled so, like a database driver, or of course sys calls, at some point we do have to go into native
<arigato>
right
<arigato>
at this point, do you have to handle turning objects into raw pointers? or is it always late enough that you should never pass object pointers across these interfaces?
<chrisseaton>
If you are passing a pointer to an object as something like a void* callback parameter, then we have to allocate a handle
<arigato>
right
<arigato>
sounds more like what you do with CFFI, but automatically deduced from the C code of the C extension, rather than being a different way to program in the first place
<chrisseaton>
Yes that's a clever way to talk about it
<arigato>
in pypy's cpyext, it's more like we use the same way except the boundary is much sooner, as soon as we touch the C extension
<arigato>
so we pass the C extension "PyObject *" pointers that are manually-generated handles, too
jamesaxl has quit [Read error: Connection reset by peer]
jamesaxl has joined #pypy
amaury has joined #pypy
arigato has joined #pypy
realitix has quit [Ping timeout: 260 seconds]
jacob22 has joined #pypy
jacob22_ has quit [Ping timeout: 258 seconds]
jamesaxl has quit [Read error: Connection reset by peer]
jamesaxl has joined #pypy
pilne has joined #pypy
vkirilichev has joined #pypy
vkirilichev has quit [Remote host closed the connection]
vkirilichev has joined #pypy
<kenaan>
antocuni faster-rstruct-2 8b4330b7b7bc /: start a branch in which to make rstruct faster in a more general way, by using llops.gc_load_indexed wh...
<kenaan>
antocuni faster-rstruct-2 19988cc7db57 /rpython/rlib/: add a new Buffer.typed_read method, which does the same as the current strstorage.py: the idea is that ...
<kenaan>
antocuni faster-rstruct-2 29b4a2158631 /rpython/rlib/test/test_buffer.py: add the compiled version of the tests. We still need to add the correct @specialize to Buffer.typed_rea...