<fijal>
arigato: ok, so there is an additional complication that really makes it hard to do any tests as is
<fijal>
which is that ffi.memmove would already move string out of nursery, that's a bit bad
<arigato>
if you pass a string to ffi.memmove(), it should explicitly not move it out of the nursery
<arigato>
I think?
<arigato>
OK no, you're probably right
<arigato>
but that's an easy fix
<cfbolz>
arigato: is it ok if I open a cpython PR with your enum fix, or do you want to?
<arigato>
cfbolz: no, please do (note that you first have to port it from 3.8 to 3.10 and I guess 3.9 and maybe trunk)
<cfbolz>
sure
<arigato>
(and I also guess it will be rejected for some versions so some of that work might be wasted)
<cfbolz>
arigato: I am just trying to aim for eventual consistency ;-)
<arigato>
OK :-)
<fijal>
arigato: how is this an easy fix exactly?
<fijal>
I *think* it's ok to get an unsafe pointer there for a copy, because we don't release the GIL at all, but the level of indirection is a bit crazy, so I'm not sure how exactly it is easy
<arigato>
fijal: memmove in func.py already supports "oops I can't take a raw pointer to src" and sets 'src_is_ptr' to False, and then it has got a high-performance case for that too
<arigato>
but it first tries to take a raw pointer, and bytes object say "grumble OK I'll copy things around"
<fijal>
right, ok, but that's a bit bad, still
<fijal>
like we do two copies here, if we want to actually pass something to write
fotis has joined #pypy
<fijal>
first one in ffi.memmove,, second one is the argument to memmove
<fijal>
I'm trying to do experiments with copying strings
<fijal>
but so far I failed to find a way to make a raw copy of a string to start with
<fijal>
every single way I tried does one more copy and even one more to copy it out of the nursery
<fijal>
how would you express:
<fijal>
sorry brb
<fijal>
but I'm trying to make one copy of a string to char[] and that seems to be impossible for a young string?
<arigato>
indeed, I'd have said "ffi.memmove" but without the fix above it requires an extra copy
Dejan has joined #pypy
<cfbolz>
arigato: there's another quadratic case anyway :-(
<cfbolz>
(if you use "auto", instead of explicit values)
<arigato>
ah, didn't know about "auto"
<arigato>
but yes I'm only clamining I fixed the path I tested, not the 137 other paths
<cfbolz>
scary module in any case
<arigato>
yes
<arigato>
ah note that I'm using a set, and relying on it being ordered, which is not the case on cpython
<cfbolz>
yes, I was wondering
<arigato>
so I guess either use a dict or maybe keep the same attribute as a list and add another set, which might be better for compatibility with crazy code that accesses that underscore attribute
<mattip>
fijal: is there a way to go back to using the rpython_ssl for some of the send()/sendall() functionality, but use the cffi _ssl for the rest?
<mattip>
(I assume we fixed the string -> pointer problem for the rpython _ssl ...)
ronan has joined #pypy
<fijal>
arigato: and with the fix how many copies it does? it still copies it twice, right?
<fijal>
mattip: I don't know, in my opinion it kinda defeats the point of cffi if we can't get the right incantation for our own modules
fotis has quit [Ping timeout: 264 seconds]
<arigato>
fijal: with the fix, ffi.memmove(p, bytes_object, n) will do exactly one copy and not make bytes_object old
<fijal>
ok cool, then I don't understand why is there a fast path there?
<fijal>
arigato: eh, this paste site asks me to create an account if I want to see the raw paste :/
<arigato>
if you mean, why was there already a fast path but it was still doing two copies, that was because StringBuffer.get_raw_address()
<arigato>
my fix is to special-case bytes object to not call get_raw_address(), which is pointless because the rest of the code (below the paste) already supports getting an RPython string and will perform well with it
<arigato>
if you implement ffi.pointer_valid_only_for_the_call() to pass to arguments of C function calls, then we should likely support it in ffi.memmove()'s src argument too
<arigato>
(tested that it translates, this patch is now checked in the 'default' branch)
<fijal>
ok cool
<fijal>
I'm translating pypy to see how does that perform
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
fotis has joined #pypy
<arigato>
(I have no clue why you can see the paste on ubuntu's pastebin, and you can also have them copied to your clipboard, but you cannot *view* them raw without logging)
<fijal>
arigato: my guess would be "make them sign up at every opportunity, but also have some minimum working so they actually come"
<fijal>
or something
<fijal>
like instagram will let you see a few posts, but not more, etc., it's a widely adopted and absolutely infuriating practice
<fijal>
do we know why inlining GC helpers takes so much time these days?
Atque has joined #pypy
<fijal>
cfbolz: ?
fotis has quit [Ping timeout: 265 seconds]
<fijal>
oh right, I run out of memory
<cfbolz>
fijal: yeah, GC helpers are a problem
<fijal>
cfbolz: I think not in this particular case
fotis has joined #pypy
fotis has quit [Ping timeout: 250 seconds]
fotis has joined #pypy
<mattip>
cpython 3.9 broke the topological sort out of functools and into a new "graphlib" top-level stdlib module
<mattip>
so of course now there is discussion on the mailing list about making this a full-blown graph library, along the lines of networkx
<marmoute>
there is a graphlib in python ?
<fijal>
heh
<fijal>
mattip: I'm impressed you are able to follow that and not loose your shit
fotis has quit [Ping timeout: 265 seconds]
<mattip>
well, I _am_ venting by sharing it here
<mattip>
marmoute: it is very limited to a single tpopological_sort() that used to live inside functools, and rather than drop it altogether they moved it
<fijal>
ok, better, there is a magic incantation that gets the right thing going
<fijal>
I'm surprised pip works at all ever
<mattip>
strange, that is the same version of pip reported by my local pypy2.7, but I don't see six in site-packages/pip/_vendor
<mattip>
maybe we can document what went wrong and how to fix it somewhere discoverable, like on pypy.org/blog or doc.pypy.org
<LarstiQ>
fijal: that message looks close to what I've seen on Debian/Ubuntu that I solved with updating what `python-pip-whl` had cached in /usr/share/python-wheels