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
jcea has quit [Ping timeout: 240 seconds]
mgedmin has quit [Quit: ZNC - https://wiki.znc.in/ZNC]
mgedmin has joined #pypy
forgottenone has joined #pypy
_whitelogger has joined #pypy
forgottenone has quit [Quit: Konversation terminated!]
proteusguy has joined #pypy
forgottenone has joined #pypy
<cfbolz> mattip: no, just "more of same" I think
<cfbolz> cpython has less copies, simply
<mattip> ahh
<cfbolz> they have four or five different replaces, we only have three 😂
<cfbolz> also, eventually we should look into the quadratic string search behaviour too: https://bugs.python.org/issue41972
<cfbolz> no I am wrong, cpython has seven
Dejan_ has quit [Read error: Connection reset by peer]
dmalcolm_ has quit [Ping timeout: 260 seconds]
todda7 has joined #pypy
<arigo> I'm not sure why they don't take that as a reason to drop the heuristic substring search and use a full linear-time regular-expression-based one
<cfbolz> arigo: what do you mean by that?
<cfbolz> arigo: one reason is definitely that the heuristic one is really fast in practice
<arigo> OK$
<cfbolz> arigo: the main work of that thread is to figure out the cutoffs :-(
<arigo> I can see that there are large constant factors in the guaranteed-linear-time algorithm
<cfbolz> yes
<cfbolz> arigo: it also needs quite a bit of extra memory
<cfbolz> arigo: for pypy we can cheat, and do the preprocessing once, if the search string is constant ;-)
dmalcolm has joined #pypy
<cfbolz> arigo: wow, annoying greenlet bugs 😬
antocuni_ has left #pypy [#pypy]
antocuni has joined #pypy
todda7 has quit [Quit: Konversation terminated!]
todda7 has joined #pypy
Lightsword has quit [Quit: ZNC]
Lightsword has joined #pypy
jcea has joined #pypy
Dejan has joined #pypy
Dejan has quit [Changing host]
Dejan has joined #pypy
oberstet has joined #pypy
otisolsen70 has joined #pypy
ronan_ is now known as ronan
muke has joined #pypy
<muke> There's a function in the LLVM API I'm calling through the rffi that causes rpython to hang on 'sys.stdin.readline()' (according to the traceback when interrupting), the function works fine in regular C and has the same behavior from rpython whether or not I'm calling the API directly or through a wrapper, anyone know what might cause this?
<muke> it's getting stuck in rpython/tool/runsubprocess.py
<simpson> Sounds familiar and IIRC the solution was to run with PyPy when running untranslated rather than CPython.
<muke> ah alright, I'll give that a try thanks
<muke> simpson took a while to build but just gave it a try and the problem persists - you just meant run pytest under pypy right?
<simpson> muke: Yeah, or however you're running untranslated. Sorry to make you spend time on something that didn't help.
<muke> oh no worries I'm on a fresh gentoo install and had to recompile pypy at some point either way :)
<cfbolz> muke: what function is that?
<muke> cfbolz LLVMOrcLLJITAddLLVMIRModule
<cfbolz> 🤔
<cfbolz> Bit weird. Did you try running the test with -s
<cfbolz> ?
<muke> will do now
<muke> oh, interesting
<muke> same behavior with regular python but under pypy it segfaults now instead
<cfbolz> That means something is wrong 😅
<muke> what's weird is the segfault is irregular, sometimes it does and sometimes it hangs
<muke> ahh, it was a mistake on my end, mixed up two similar variable names
<muke> thanks for the advice though
asmeurer has joined #pypy
asmeurer has quit [Quit: asmeurer]
kipras has joined #pypy
kipras has quit [Read error: Connection reset by peer]
oberstet has quit [Quit: Leaving]
forgottenone has quit [Quit: Konversation terminated!]
marky1991 has joined #pypy
marky1991 has quit [Ping timeout: 246 seconds]
muke has quit [Quit: Leaving]