cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | hacking on TLS is fun, way more fun than arguing over petty shit, turns out
greedom has quit [Remote host closed the connection]
glyph has quit [Quit: End of line.]
glyph has joined #pypy
hynek has joined #pypy
Atque is now known as hammond
hammond is now known as Atque
mjacob has quit [*.net *.split]
habnabit has quit [*.net *.split]
danchr has quit [*.net *.split]
marmoute has quit [*.net *.split]
marmoute has joined #pypy
danchr_ has joined #pypy
mjacob has joined #pypy
habnabit_ has joined #pypy
nimaje has quit [*.net *.split]
indyZ has quit [*.net *.split]
indyZ has joined #pypy
nimaje has joined #pypy
marmoute has quit [Ping timeout: 256 seconds]
marmoute has joined #pypy
Guest96 has joined #pypy
Guest96 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest96 has joined #pypy
greedom has joined #pypy
indyZ has quit [Changing host]
indyZ has joined #pypy
<cfbolz> Snow, snow!
otisolsen70 has joined #pypy
<arigo> mattip: re Hao Wang: the error message is 15 lines long, I'm not sure how I can explain better what it means. It really means what it says, i.e. that pandas._libs.parsers.TextReader is potentially bogus and should be fixed in the C code
<arigo> the error is exactly that the C code of pandas calls a generic PyXxx function from a tp_dealloc, which is bad because of the reasons written there. There is no need for the OP to show any more code
<arigo> nor is there any way for the OP to write code differently
<arigo> cfbolz, fijal: I don't remember merging (or even looking) at any of the M1 patches
<cfbolz> You commented on the issue though?
<arigo> yes, I was about to post the same url
<cfbolz> Ah, 'I didn't look at the patches in detail' further down
<cfbolz> Right
<arigo> exactly: I looked and thought "uh it might be better done that way instead" and wrote it down, but didn't do anything more
<cfbolz> Fair
<arigo> re Slow function call with float and None (#3598), we can decide to write a short preamble to a random place even if that means adding guards that are wrong right now?
<cfbolz> arigo: yes, we can
<cfbolz> But what we should not do is move those wrong guards earlier in the bridge
<cfbolz> Because then we can get bridges that basically make no progress at all
<fijal> arigo: ok cool
<arigo> shouldn't we check that we're writing sensible guards for the short preamble? we have the objects around at the moment, no?
<cfbolz> arigo: then we would need a 'short preamble executor' that goes through the short preamble and runs it on the real objects?
<arigo> yes
<cfbolz> Right
<cfbolz> arigo: my intermediate fix is, I disabled guard strengthening when emitting short preamble ops
<arigo> throw it to the blackhole interpreter and check if a guard fail, something like that
<cfbolz> Right
<arigo> short preambles have no side effects, right?
<cfbolz> Yup
<cfbolz> arigo: note also that we have a component like this already, virtualstate
<cfbolz> It does matching, takes runtime values into account
<arigo> disabling guard strengthening might be good enough
<cfbolz> So a possible refactoring would be to integrate short preamble capabilities into virtualstate
<arigo> I'm not sure we measured if it makes a real difference anyway
<arigo> in general
<arigo> but it compresses the traces resume info, I think
<cfbolz> Guard strengthening? It helps for very small loops
<arigo> OK, so I guess it's not that bad if we disable it in one case
<cfbolz> Agreed
<cfbolz> arigo: there's a bit of a general pattern in which we realize that small loops don't really matter all that much 😅
<fijal> haha, yep
<cfbolz> funnily enough, the JS VMs have been going through that same cycle
<arigo> we might even disable some of the guard strengthening that occurs normally, like if the older guard is too far behind
<arigo> because that might fail even though the whole portion of code between the two locations would still be fine
<fijal> cfbolz: because microbenchmarks have small loops
greedom has quit [Remote host closed the connection]
<mattip> arigo: pandas would be more likely to fix the issue if we can provide a reproducer
<mattip> they are using cython, so probably non-trivial to find exactly where the call is happening
<cfbolz> nice, test_sys_settrace went from 44 failures to 3
greedom has joined #pypy
wleslie has quit [Quit: ~~~ Crash in JIT!]
Guest96 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
otisolsen70_ has joined #pypy
otisolsen70 has quit [Ping timeout: 264 seconds]
otisolsen70_ has quit [Read error: Connection reset by peer]
Atque has quit [Quit: ...]
Guest96 has joined #pypy
Julian has joined #pypy
x88x88x has joined #pypy
x88x88x has quit [Read error: Connection reset by peer]
greedom has quit [Remote host closed the connection]
x88x88x has joined #pypy
x88x88x has quit [Remote host closed the connection]
danchr_ has quit [Quit: ZNC -]
danchr_ has joined #pypy
tazle has quit [Quit: Lost terminal]
x88x88x has joined #pypy
tazle has joined #pypy
stkrdknmibalz has joined #pypy
<cfbolz> ok, I seem to be able to get assert reinterpretation back on py3.x
<cfbolz> without significant overhead
<Julian> what's assert reinterpretation
<Julian> I assume neither the rpython thing nor the pytest thing? or is it somehow related to the latter?
<cfbolz> Julian: no, I mean the pytest thing
<Julian> ah. in like the vendored pytest?
<cfbolz> Julian: it's complicated ;-)
<Julian> right...
<cfbolz> Julian: specifically I am talking about apptests
<cfbolz> ie tests that run on
* Julian nods
<cfbolz> there, we can't use the pytest code
<Julian> aha
<cfbolz> we used to be able to hack it, with pypy2 and pytest
<cfbolz> but with pypy3 we currently just get "AssertionError"
<cfbolz> without *any* extra info
<Julian> I see.
<cfbolz> which is painful
<cfbolz> there was a mode to still get it, but it would make test running 3x slower
<cfbolz> and off by default
<mattip> something is off with own tests
<mattip> if I run "python2 pypy/module/sys/test/" alone, it passes
<mattip> but if I run "python2 pypy/module/sys/test", then
<mattip> test_sysmodule fails a test, and then test_version fails
<mattip> cfbolz: maybe side effects of caching gcc results?
<cfbolz> mattip: will look into it
<cfbolz> mattip: whihch branch?
<mattip> py3.7
Julian has quit [Quit: leaving]
x88x88x has quit [*.net *.split]
danchr_ has quit [*.net *.split]
indyZ has quit [*.net *.split]
hynek has quit [*.net *.split]
samth has quit [*.net *.split]
habnabit_ has quit [*.net *.split]
atomizer_ has quit [*.net *.split]
lastmikoi has quit [*.net *.split]
arkanoid has quit [*.net *.split]
iwkse_ has quit [*.net *.split]
mattip has quit [*.net *.split]
mgorny has quit [*.net *.split]
arigo has quit [*.net *.split]
energizer has quit [*.net *.split]
antocuni has quit [*.net *.split]
benjamin has quit [*.net *.split]
danchr_ has joined #pypy
indyZ has joined #pypy
arkanoid has joined #pypy
habnabit_ has joined #pypy
hynek has joined #pypy
antocuni has joined #pypy
energizer has joined #pypy
benjamin has joined #pypy
iwkse_ has joined #pypy
samth has joined #pypy
atomizer_ has joined #pypy
arigo has joined #pypy
mgorny has joined #pypy
mattip has joined #pypy
lastmikoi has joined #pypy
<cfbolz> mattip: it's a gigantic mess. it's my fault though
<cfbolz> mattip: fixed
Guest96 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mattip> thanks