cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
_whitelogger has joined #pypy
Dejan_ has joined #pypy
Dejan has quit [Ping timeout: 260 seconds]
jcea has quit [Ping timeout: 260 seconds]
lritter has joined #pypy
_whitelogger has joined #pypy
_whitelogger has joined #pypy
Dejan_ has quit [Ping timeout: 260 seconds]
Dejan has joined #pypy
Gustavo6046 has quit [Quit: ZNC 1.8.2 - https://znc.in]
Gustavo6046 has joined #pypy
forgottenone has joined #pypy
oberstet has quit [Remote host closed the connection]
forgottenone has quit [Quit: Konversation terminated!]
glyph has quit [Quit: End of line.]
glyph has joined #pypy
jevinskie[m] has quit [Quit: Idle for 30+ days]
ronan has quit [Remote host closed the connection]
ronan has joined #pypy
<mattip> cfbolz: any thoughts about corrupted bytecode between nightly and 7.3.3 release (issue 3417)?
<cfbolz> mattip: uh, yeah
<cfbolz> i suppose the STORE_ANNOTATION bytecode removal should indeed have changed the bytecode magic
<mattip> :(
<cfbolz> sorry, my fault
<cfbolz> mattip: how do we fix that? increment the magic now, and then the new nightlies don't have the problem any more?
<mattip> +1, especially since the release is close
<cfbolz> ok
<cfbolz> should I do it?
<mattip> when you have time it would be nice
<cfbolz> on it
<mattip> glad mgurny caught it before the release
<cfbolz> yeah :-(
<cfbolz> I wonder what we can do to prevent such problems in the future?
<cfbolz> can we write a test for it somehow?
<cfbolz> I have a plan
<cfbolz> seems we used to have such a test?
<cfbolz> test_pyc_magic_changes
<mattip> that test has a pytest.skip(). Will you compare the space to the space from the last release?
<cfbolz> mattip: I think I will just hardcode a hash
<cfbolz> and then if you forget the magic change, then the test fails
<mattip> +1
<mattip> muke101 ping
<mattip> there are two open issues that I marked as blockers
<cfbolz> none of these look like any fun :-((((
jcea has joined #pypy
<cfbolz> mattip: #3351 is probably a cpython bug too, if you get creative enough with objects with __del__s that you pass to the Connection, creating a cycle somehow. but that's not our immediate problem
<mattip> the reproducer is pretty simple, I don't think we should fail there
<cfbolz> yeah
<cfbolz> I understand the bug now, I think
<cfbolz> not quite clear how it should be fixed
<cfbolz> I can probably make a smaller reproducer
<mattip> isn't it a failure of the lock?
<mattip> logic
forgottenone has joined #pypy
<cfbolz> mattip: yeah, the logic is broken
<cfbolz> mattip: ok, got a simpler case at alest
<cfbolz> least
lritter has quit [Ping timeout: 260 seconds]
<cfbolz> in other news: tornado looks quite good now
<cfbolz> the sqlite3 stuff is a pile of hacks :-(
<cfbolz> mattip: I have a plan for a fix though. Probably solves both problems
<mattip> cool on both counts
dmalcolm__ has quit [Remote host closed the connection]
dmalcolm has joined #pypy
tsaka__ has joined #pypy
todda7 has quit [Ping timeout: 272 seconds]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7539 [Carl Friedrich Bolz-Tereick: force build, open-ended-traces-3.7]
jcea has quit [Ping timeout: 258 seconds]
<antocuni> cfbolz: what is the open-ended-traces branch?
<cfbolz> antocuni: it's for loops that blow the trace limit
<cfbolz> currently we keep trying to trace them again and again
<cfbolz> making them even slower than the interpreter
<cfbolz> open-ended-traces will just stop tracing, but emit the trace so far, ending it with an always-failing guard
<cfbolz> which can later be extended with a bridge
<antocuni> ah, interesting
<antocuni> have you found any real use case which is helped by this?
<cfbolz> antocuni: autogenerated code by a templating engine, in this case
<antocuni> nice
<cfbolz> antocuni: but i wonder whether eg translating has also stuff like that
<antocuni> in my experience, I had similar problems in the past. Often they were caused because the unoptimized trace was very long, but after optimizations it would become very short
<antocuni> but if you hit the limit, you are screwed
<antocuni> e.g., capnpy is designed in such a way that most operations for accessing fields are optimized away
<cfbolz> yip
<cfbolz> ah, there are probalby more problems anyway
<mattip> I just watched a presentation of papyri,
<mattip> which takes your sphinx doc source (like numpy, scipy, pandas)
<mattip> and renders it into an intermediate representation, that you ship
<mattip> then the end-user can render it
<mattip> so, bottom-line, maybe the sphinx benchmark is not needed ;)
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7539 [Carl Friedrich Bolz-Tereick: force build, open-ended-traces-3.7]
commandoline has quit [Ping timeout: 246 seconds]
commandoline has joined #pypy
<cfbolz> mattip: eh
<cfbolz> It shows a real problem in any case
<mattip> I know, I was just excited to be rid of a need for sphinx in practice
<cfbolz> 😊
<cfbolz> Maybe I should try to fix the other stdlib sqlite test failures on 3.7 while I'm at it
<mattip> up to you, if you have sqlite embedded in your mind maybe the fixes are straightforward
<larstiq> that's the beauty of sqlite innit, it can be embedded everywhere! ;)
<cfbolz> Eh
<cfbolz> Given that I've written a sqlite jit before I'm supposed to know it. But seems not really
sven has quit [Ping timeout: 276 seconds]
sven has joined #pypy
papangoo[m] has quit [*.net *.split]
papangoo[m] has joined #pypy
commandoline has quit [Ping timeout: 246 seconds]
ronny has quit [Ping timeout: 240 seconds]
jryans has quit [Ping timeout: 240 seconds]
toad_polo has quit [Ping timeout: 247 seconds]
astrojl_matrix has quit [Ping timeout: 268 seconds]
commandoline has joined #pypy
ShadeJonathan[m] has quit [Ping timeout: 246 seconds]
papangoo[m] has quit [Ping timeout: 265 seconds]
ronny has joined #pypy
ShadeJonathan[m] has joined #pypy
jryans has joined #pypy
astrojl_matrix has joined #pypy
toad_polo has joined #pypy
papangoo[m] has joined #pypy
<bbot2> Started: http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-64/builds/3217 [Carl Friedrich Bolz-Tereick: force build, open-ended-traces]
_aegis__ has joined #pypy
kbtr has joined #pypy
_aegis_ has quit [Ping timeout: 256 seconds]
kbtr_ has quit [Ping timeout: 256 seconds]
danchr has quit [Ping timeout: 264 seconds]
danchr_ has joined #pypy
forgottenone has quit [Ping timeout: 264 seconds]
todda7 has joined #pypy
tsaka__ has quit [Read error: Connection reset by peer]
jcea has joined #pypy
energizer has quit [*.net *.split]
dddddd has quit [*.net *.split]
[Arfrever] has quit [*.net *.split]
marmoute has quit [*.net *.split]
iko_ has quit [*.net *.split]
lastmikoi has quit [*.net *.split]
iko_ has joined #pypy
dddddd has joined #pypy
[Arfrever] has joined #pypy
marmoute has joined #pypy
lastmikoi has joined #pypy
nulano has quit [Ping timeout: 264 seconds]
energizer has joined #pypy
nulano has joined #pypy
<bbot2> Success: http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-64/builds/3217 [Carl Friedrich Bolz-Tereick: force build, open-ended-traces]
_whitelogger has joined #pypy
_whitelogger has joined #pypy
_whitelogger__ has joined #pypy
_whitelogger__ has joined #pypy
_whitelogger_ has joined #pypy
_whitelogger_ has joined #pypy
_whitelogger_ has joined #pypy