cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake https://pypy.org | IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end and https://libera.irclog.whitequark.org/pypy | hacking on TLS is fun, way more fun than arguing over petty shit, turns out
yizawa has quit [Ping timeout: 264 seconds]
fijal has quit [Ping timeout: 260 seconds]
graingert has quit [Ping timeout: 245 seconds]
idnar has quit [Ping timeout: 245 seconds]
eamanu has quit [Ping timeout: 260 seconds]
agronholm has quit [Ping timeout: 260 seconds]
cfbolz has quit [Ping timeout: 265 seconds]
phlebas_ has joined #pypy
phlebas has quit [Ping timeout: 260 seconds]
phlebas_ is now known as phlebas
ronan has quit [Ping timeout: 260 seconds]
samth has quit [Ping timeout: 260 seconds]
krono has quit [Ping timeout: 260 seconds]
fijal has joined #pypy
jerith_ has joined #pypy
jerith has quit [Ping timeout: 260 seconds]
jerith_ is now known as jerith
agronholm has joined #pypy
samth has joined #pypy
idnar has joined #pypy
eamanu has joined #pypy
ronan has joined #pypy
krono has joined #pypy
graingert has joined #pypy
yizawa has joined #pypy
cfbolz has joined #pypy
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
<Corbin> I know it's unlikely, but is there a portable way in RPython to customize NaN behavior? Every NaN check is generating a guard, and unrolled loops with NaN checks are causing an explosion of paths.
<Corbin> This is largely my fault for unrolling the loop in the first place, and I'm trying to fix that. But it would be nice if I could just get NaNs transformed to 0.0 or something like that.
<cfbolz> Corbin: nope, no such thing yet
<Corbin> Oh well. Maybe you'll find this funny: https://bpa.st/MZVQ
<Corbin> This takes about 4 seconds without NaN checks. It should run in realtime on a mid-class GPU, but emitting GPU code is such a headache and I'm not there yet.
greedom has joined #pypy
otisolsen70 has quit [Quit: Leaving]
greedom has quit [Remote host closed the connection]
Atque_ has joined #pypy
Atque has quit [Ping timeout: 276 seconds]
<mattip> I think I am stumbling across a CPython behaviour difference with signals
<mattip> deep inside OpenSSL, a SIGPIPE signal is triggered, which on CPython turns into a BrokenPipeError
<mattip> it seems PyPy does not do that conversion, in spite of a line in the PyPy ssl code that says "signals are checked frequently in the bytecode dispatch loop"
<mattip> at least at the point in the code where CPython catches the exception, PyPy does not stop
<mattip> maybe because of cffi?
<mattip> or because it is in a thread?
<cfbolz> mattip: who triggers the signal?
<cfbolz> ah, because the socket was closed
<mattip> openblas tries to read from a "file", which is closed
<mattip> I ran the test under gdb, which will stop on signals. Then I told it to ignore the stopping with "> handle SIGPIPE nostop"
<mattip> but it still prints the signals, as well as threads stopping and starting
<mattip> so I see the thread start, the signal emitted, and then the thread stops.
<mattip> I can even see the BrokenPipeError exception being caught, and can print there
<mattip> PyPy never raises the BrokenPipeError exception
<mattip> so the thread does not die, and the test hangs
<mattip> hmm, in CPython this is not automatic, it is part of the ssl.shutdown code?
<mattip> apparently the signal is a false flag. The problem is elsewhere
<cfbolz> sounds all complicated
<cfbolz> mattip: I am impressed you managed to do this advanced gdb stuff
<mattip> it really is only two threads, but I get confused going from python code to c code
<mattip> and trying to compare _ssl.c with our cffi code
<mattip> the "happy path" works fine, it is the tests checking the dark corners of the errors that is broken
<mattip> on openssl3
<cfbolz> right :-(
<cfbolz> mattip: is the signal getting delivered to a different thread on pypy?
<mattip> signals are only ever delivered to the main thread on both pypy and cpython
<mattip> now I am thinking that a read is returning -1 on PyPy and 0 on CPython, but maybe that is a false flag too
<mattip> hang on, mabe this is all due to the error codes changing between versions