<kenaan_>
arigo default 1cbb46d0ce7a /rpython/rtyper/: Complain clearly when we rtype ``_immutable_fields_=['foo[*]']'' and ``.foo'' is not actually a list
<kenaan_>
arigo py3.5 1e60d5cc28f1 /pypy/objspace/std/memoryobject.py: Temporary performance fix for turning a memoryview to bytes
oberstet has joined #pypy
vkirilichev has joined #pypy
vkirilichev has quit [Remote host closed the connection]
vkirilichev has joined #pypy
adamholmberg has quit [Remote host closed the connection]
adamholmberg has joined #pypy
forgottenone has quit [Ping timeout: 260 seconds]
adamholmberg has quit [Ping timeout: 260 seconds]
asmeurer_ has joined #pypy
vkirilichev has quit [Remote host closed the connection]
asmeurer_ has quit [Client Quit]
jamesaxl has quit [Read error: Connection reset by peer]
jamesaxl has joined #pypy
antocuni_ has joined #pypy
antocuni has quit [Ping timeout: 240 seconds]
adamholmberg has joined #pypy
adamholmberg has quit [Ping timeout: 255 seconds]
fryguybob has quit [Ping timeout: 240 seconds]
Tiberium has quit [Remote host closed the connection]
Tiberium has quit [Remote host closed the connection]
Tiberium has joined #pypy
<kenaan_>
arigo extradoc a251a14c1a6f /talk/ep2017/pypy-whats-new.txt: fix last para
mattip has joined #pypy
<mattip>
arigato: last night's builds left lots of failures, probably connected to f0ba81de1e4f or b13b7c8e4fe7
<mattip>
any ideas?
vkirilichev has joined #pypy
<arigato>
meh, yes
<arigato>
as we can see, test_zll_stress now passes!
<arigato>
everything else fails
<mattip>
:)
<arigato>
thanks for telling me, and sorry about that. fixing
<arigato>
it's f0ba81de1e4f
<arigato>
basically the JIT throws an assertion as soon as it builds the write barrier helper (so untranslated tests pass)
<mattip>
hope it wasn;t too painful to find
<arigato>
no
<kenaan_>
arigo default 9fca81f13918 /rpython/jit/backend/x86/codebuf.py: Fix for f0ba81de1e4f: there is one caller using SlowPath with mc._frame_size != DEFAULT_FRAME_BYTES
<mattip>
should it be expected that, given two numpy arrays, calling
<mattip>
val = objarray[i]; intarray[i] = val
<mattip>
and setting gdb breakpoints in setitem and getitem (c-api functions)
<mattip>
the value returned from objarray[i] is not the same as the one passed to intarry[i]
<mattip>
?
<arigato>
it's a W_IntObject in both cases, with the same value? (still the answer is no afaict)
<mattip>
yes, a W_IntObject (well, a PyINtObject with a pypy-link) but the linked object is different,
<mattip>
and the refcount of the new one is our equivalent of 0
<arigato>
I mean, what is returned from setitem, it's a W_IntObject, right?
<mattip>
the int value of the PyObject is the same
<mattip>
I cannot tell in gdb that it is an W_IntObject, can I?
<arigato>
it's a W_Root?
<arigato>
you can tell looking at the C source when it's a W_Root and when it's a PyObject
<mattip>
the PyObject has a pypy_link
<mattip>
and that link changes betweeen the getitem() and the setitem
<arigato>
my question is: what type does getitem return
<arigato>
it's certainly a W_Root at some point, when stored as the "val" variable
<mattip>
I will have to write a test to see, it should be a W_IntObject since that is what is passed around
<mattip>
or test it with an lldebug0 version of PyPy
<arigato>
so, getitem() gives a W_Root that should be a W_IntObject, and that is passed around the setitem(), so my first question is, is it the same W_Root instance
<arigato>
..passed around *to* the setitem()
<mattip>
yes, AFAICT it is not the same instance, the pypy_link has a different address
<mattip>
and the refcount is zeroed out
<arigato>
you're answering a different question :-)
<mattip>
I am debugging only in numpy, not in pypy
<arigato>
ok
<mattip>
so I only can answer about PyObject* attributes
vkirilichev has quit [Ping timeout: 240 seconds]
<arigato>
another approach then: what do you get in setitem()? even if it's a different PyObject, is it really broken? it has ob_refcount == REFCNT_FROM_PYPY but that should be fine
<arigato>
unless the setitem() steals a reference
<mattip>
the setitem does not store the PyObject, only the int value, so it should incref only if calling a capi function,
<arigato>
so what is the crash?
<mattip>
hmm, maybe setitem is not doing the incref/decref dance around a Py* call?
<mattip>
the crash is that somewhere in a gc cycle there is a segfault
<mattip>
valgrind complains about memory read past an allocation
<arigato>
ah
<arigato>
wait a sec, how can that work:
<arigato>
if the call to setitem(pyobj) occurs with the wrong kind of argument passing, then maybe the GC doesn't know that the w_obj should be kept alive until the return of setitem()
<arigato>
so, if you add a manual keepalive of 'val' does it help? e.g. add it in a big but local list
<arigato>
append() it there
<mattip>
ok
<arigato>
ah no
<arigato>
well
<arigato>
append() it to a list that is initialized with "lst = ['foo']"
<arigato>
to make sure it is not a pure list of ints
<mattip>
+1
<mattip>
my concern is trying to understand why the PyObject returned from getitem() is not the same as the one passed to setitem()
<mattip>
I expected them naively to be the same, and that is a test I can write, but I wanted to make sure
<mattip>
that my naive assumption should hold
<arigato>
yes, I'd also expect it to be true (right now), but nothing should depend on the exact W_Root identity of int objects
<arigato>
I agree that if it is not true, it's at least strange for cpyext
<mattip>
well, then object copying should also copy the ob_refcount
<arigato>
no, it's more: the JIT gets a W_IntObject but only remembers its value, and later it re-creates the W_IntObject around it, because nobody can depend on the identity of the W_IntObject
<arigato>
as far as I can tell the JIT doesn't do that right now
<arigato>
but I'm saying that it could validly do that
<mattip>
(I am running this with --jit off)
<arigato>
ok
<arigato>
ah, are you sure about what you're measuring in gdb?
<mattip>
+1 for jit remembering ob_refcount, and also for adding a check about ob_refcount crossing REFCNT_FROM_PYPY in decref
<arigato>
e.g. the setitem() could be from a different thread than the getitem()
<mattip>
never :)
<mattip>
never sure :)
<mattip>
but I reduced the threads to 1 and ran again
<mattip>
and it still was a rebuilt PyObject
<arigato>
strange
<mattip>
cool, so worth a test in cpyext
<mattip>
thanks for diving in
<arigato>
another reason for getting a different PyObject would be the GC, but again like the JIT it doesn't do that right now---I'm thinking about, if you have 7 W_IntObjects with the same value in the nursery, when you do a minor collection, you turn them all to a single old object
<arigato>
that would be a valid optimization, again ignoring cpyext-specific issues
<mattip>
is that an optimization we already do (coalating similar values)?
<arigato>
no
<arigato>
and I guess that if we do it, we would specifically look for PyObjects and disable the optimization in this case
<mattip>
so we should have a cpyext test that makes sure the recounts don't get screwed up before someone does that optimization
<mattip>
so that's two tests I need to write :)
<mattip>
just for the record, in ULONG_setitem there is a call to PyNumber_Long(obj), where obj has ob_refcount==REFCNT_FROM_PYPY
<arigato>
that should be fine
<arigato>
if the PyObject is passed straight from PyPy it can have ob_refcount==REFCNT_FROM_PYPY
jamesaxl has quit [Ping timeout: 260 seconds]
jamesaxl has joined #pypy
<mattip>
it seems to me there are a few lines in unwrapper() in api.py where the GC _could_ collect a value passed in as a PyObject,
<mattip>
until the from_ref() call in line 367
vkirilichev has joined #pypy
adamholmberg has joined #pypy
adamholmberg has quit [Ping timeout: 260 seconds]
DragonSA has quit [Quit: Konversation terminated!]
<mattip>
gnite
mattip has left #pypy ["bye"]
vkirilichev has quit [Remote host closed the connection]
vkirilichev has joined #pypy
* arigato
fights samba and mostly gives up
<arigato>
why??? I can list the directory from Windows, but I can't even read any file
<arigato>
*slap*
<arigato>
sorry for the noise, I had to complain to find the solution (which is: they are symlinks, apparently samba doesn't do anything with them)
tilgovi has joined #pypy
jcea has quit [Ping timeout: 240 seconds]
jcea has joined #pypy
adamholmberg has joined #pypy
adamholmberg has quit [Ping timeout: 252 seconds]
nimaje1 has joined #pypy
nimaje1 is now known as nimaje
nimaje has quit [Killed (rajaniemi.freenode.net (Nickname regained by services))]