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>
so, I was thinking about just moving the "raise space.w_TypeError" in its own method, and overwrite that method in cpyext's W_GetSetPropertyEx
<arigato>
but now I'm finding other issues, like "del" never works
<mattip>
ahh, that's much worse
illume has joined #pypy
<fijal>
arigato: morning
<arigato>
hi
illume has quit [Client Quit]
<fijal>
arigato: see slack for a second
<mattip>
arigato: so I will leave 2788 to you
<mattip>
I am going through other issues seeing if any are release-critical
<arigato>
mattip: ok, I'm mostly done
<arigato>
thanks
inhahe_ has joined #pypy
inhahe__ has quit [Ping timeout: 260 seconds]
<kenaan>
arigo default 1843dd2013b4 /pypy/: Test and fix for issue #2788. Also implements "del obj.getsetprop".
forgottenone has joined #pypy
utkarsh_ has quit [Ping timeout: 265 seconds]
lazka has joined #pypy
<lazka>
when is 6.0 planned?
utkarsh has joined #pypy
<mattip>
lazka: when it is ready, soonish
* mattip
looking at issue 2752
<lazka>
ok, I'm seeing some more failures compared to 5.10, /me starts a translation
<lazka>
(if the nightly was portable, things would be easier..)
<mattip>
getting closer, I smell a refcount problem
<mattip>
nope, my bad. Cannot use pyyp for untranslated tests
<arigato>
if the string is created outside the loop, it's likely old and doesn't move any more
<arigato>
after a few iterations
<arigato>
maybe the problem is simply that we have an unsafe bit of code ("# no GC operation here!")
<arigato>
but inside a function that the JIT nowadays sees inside
<arigato>
this is always wrong and can give us this kind of problems
<mattip>
so the issue would only arise with GC between PyObject_GetBuffer and PyBuffer_Release
<arigato>
I'd say instead that PyObject_GetBuffer() calls code that contains a "# no GC" bit of unsafe code, but that code is jitted anyway at some point,
<arigato>
and thus the no-GC code does nonsense because a GC can occur anywhere when running in the JIT tracer
<arigato>
anywhere = even between two operations that don't seem to have anything to do with the JIT
<lazka>
mattip, no new errors compared to 5.10, seems the things I saw were just side effects of the tuple resize
<lazka>
ship it! ;)
<mattip>
lazka: cool. Thanks. got a few more issues to iron out, 2752 seems to be a regression, and there may be more
<mattip>
I am single-tasking today
dddddd has joined #pypy
<kenaan>
cfbolz pyparser-improvements-2 0066fc716a62 /pypy/interpreter/pyparser/test/targetparse.py: make it possible to pass diferent files to the parsing target
<kenaan>
cfbolz pyparser-improvements-2 7fb340b040e0 /pypy/interpreter/pyparser/pytokenizer.py: probably doesn't matter because code isn't indentend super deep, but don't copy the indentation li...
<kenaan>
cfbolz pyparser-improvements-2 61275f7cf5ea /pypy/interpreter/pyparser/test/test_pytokenizer.py: add at least a very simple test for the tokenizer
<kenaan>
cfbolz pyparser-improvements-2 8b6d076bb5b7 /pypy/interpreter/pyparser/test/test_pytokenizer.py: a test for parenthesis error msgs
<kenaan>
cfbolz pyparser-improvements-2 0682e48513a0 /pypy/interpreter/pyparser/: fix position of error
<kenaan>
cfbolz pyparser-improvements-2 52f6bfe8f3cd /pypy/interpreter/pyparser/: fix more offsets
<kenaan>
cfbolz pyparser-improvements-2 692d3ce9de27 /pypy/interpreter/pyparser/: tweak error message and position
<kenaan>
cfbolz pyparser-improvements-2 2a295eea4b53 /pypy/interpreter/pyparser/: expand these abbreviations
jacob22__ has quit [Quit: Konversation terminated!]
nimaje has quit [Ping timeout: 255 seconds]
nimaje has joined #pypy
nimaje has quit [Excess Flood]
mcyprian has joined #pypy
nimaje has joined #pypy
mcyprian has quit [Quit: Leaving.]
marr has quit [Ping timeout: 265 seconds]
Knio has quit [Ping timeout: 255 seconds]
Knio has joined #pypy
<mattip>
the good news - it's not a regression, the bad - it seems to always have been there, at least back to when we first started supporting the buffer interface in cpyext
<mattip>
if I call PyObject_GetBuffer() again, after the failure, it once again gets a buffer that does *not* contain the correct data
<mattip>
which means it is not that the object simple moved out of the nursery
<mattip>
s/simple/simply/
raynold has quit [Quit: Connection closed for inactivity]
<kenaan>
cfbolz pyparser-improvements-2 3405c95f9e61 /pypy/interpreter/pyparser/: fix SyntaxError offsets (so far, the errors that came from the parser had an off-by-one error, whi...
<mattip>
rffi.get_raw_address_of_string() tries to ensure that rgc.can_move(string) is False, but something is moving it anyway?
jacob22__ has joined #pypy
jacob22__ is now known as jacob22
<mattip>
taking another tack - the call to PyBuffer_Release does nothing since StringType->tp_as_buffer->bf_releasebuffer is NULL
agronholm_ is now known as agronholm
<mattip>
yeah, that too seems ok
<kenaan>
rlamy py3.5 ab173e2698f9 /pypy/module/_io/interp_textio.py: Refactor W_TextIOWrapper.read_w and .readline_w to ensure that the expensive calls to ._check_closed() get jitted (is...