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
rubdos_ has quit [Ping timeout: 240 seconds]
rubdos__ has joined #pypy
lritter has joined #pypy
oberstet has quit [Quit: Leaving]
Rhy0lite has quit [Quit: Leaving]
lritter has quit [Ping timeout: 260 seconds]
lritter has joined #pypy
todda7 has joined #pypy
todda7 has quit [Ping timeout: 264 seconds]
<bbot2> Started: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8271 [mattip: force build, py3.7]
<bbot2> Started: http://buildbot.pypy.org/builders/own-win-x86-32/builds/2393 [mattip: force build, py3.7]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/5425 [mattip: force build, py3.7]
<mattip> arigo: is there a better way to do a481a04de07c ? The bits from rsignal were missing from interp_time, translation failed
<mattip> would simply importing rsignal achieve the same effect?
<mattip> answering myself: no, it doesn't pass untranslated tests of pypy/module/time
jcea has quit [Quit: jcea]
<bbot2> Failure: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8271 [mattip: force build, py3.7]
dddddd has quit [Ping timeout: 240 seconds]
<bbot2> Failure: http://buildbot.pypy.org/builders/own-win-x86-32/builds/2393 [mattip: force build, py3.7]
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/5425 [mattip: force build, py3.7]
forgottenone has joined #pypy
dddddd has joined #pypy
_whitelogger has joined #pypy
<arigo> mattip: you're not supposed to mutate eci objects, in theory
<arigo> you have to use rsignal.eci somewhere in order for it to be enabled
<mattip> is there a comparable use pattern somewhere else?
<mattip> I couldn't find an "from x import eci"
<arigo> in this case the problem is really the variable pypy_sigint_interrupt_event I guess, but it's still messy
<arigo> mattip: like this maybe? (pushed)
<mattip> seems to work so far, thanks
rubdos__ has quit [Ping timeout: 272 seconds]
rubdos has joined #pypy
ccamel has joined #pypy
camelCaser has quit [Ping timeout: 260 seconds]
jerith has quit [Ping timeout: 256 seconds]
jerith has joined #pypy
oberstet has joined #pypy
<mattip> confirmed: pypy3.6 on win32 - >>>> time.sleep(100)
<mattip> hit ctrl-c
<mattip> get a KeyboardInterrupt
lritter has quit [Quit: Leaving]
<mattip> on the other hand, py3.7 is broken now that I started down the scandir-with-fd road, since
<mattip> "bytes paths are supported in os.scandir() on Windows since 3.6"
todda7 has joined #pypy
todda7 has quit [Ping timeout: 240 seconds]
dddddd_ has joined #pypy
dddddd has quit [Ping timeout: 264 seconds]
dddddd_ is now known as dddddd
todda7 has joined #pypy
_whitelogger has joined #pypy
todda7 has quit [Ping timeout: 240 seconds]
todda7 has joined #pypy
otisolsen70 has joined #pypy
dddddd has quit [Ping timeout: 240 seconds]
dddddd has joined #pypy
rindolf has joined #pypy
todda7 has quit [Ping timeout: 256 seconds]
<rindolf> Hi all! This C++ translation: https://paste.debian.net/1158434/ runs faster than pypy3 runs the original: https://paste.debian.net/1158432/ . Can I/we do anything about it? It also happened with a step of 1e6 iters
Rhy0lite has joined #pypy
todda7 has joined #pypy
BPL has joined #pypy
otisolsen70 has quit [Quit: Leaving]
forgottenone has quit [Quit: Konversation terminated!]
<arigo> rindolf: as far as I can tell, the two programs are very different: the Python one has to handle very large integers in recursive_a_sequence(), the C++ one blindly truncates to 32 bits
<arigo> ...right, the C++ one truncates to 128 bits actually
<rindolf> arigo: yes
<arigo> but the Python one handles it as large integers (more than 63 bits)
<arigo> we have no special logic to detect "ah but the integers always fit in 127 bits so let's use __int128"
<arigo> this makes an important difference, specially for operations like "%"
Rhy0lite has quit [Ping timeout: 240 seconds]
<arigo> that's one thing I can think about. the remaining difference is probably the expected fact that a C compiler generates better machine code than our JIT
<arigo> and also the extra overhead of managing "seq" as a generator
speeder39_ has joined #pypy
Rhy0lite has joined #pypy
marvin has quit [Remote host closed the connection]
marvin has joined #pypy
marvin has quit [Remote host closed the connection]
marvin has joined #pypy
todda7 has quit [Remote host closed the connection]
todda7 has joined #pypy
todda7 has quit [Read error: Connection reset by peer]
todda7 has joined #pypy
speeder39_ has quit [Quit: Connection closed for inactivity]
epsilonKNOT has quit [Quit: ZNC - https://znc.in]
epsilonKNOT has joined #pypy
forgottenone has joined #pypy
todda7 has quit [Remote host closed the connection]
todda7 has joined #pypy
todda7 has quit [Remote host closed the connection]
todda7 has joined #pypy
todda7 has quit [Remote host closed the connection]
todda7 has joined #pypy
todda7 has quit [Excess Flood]
todda7 has joined #pypy
forgottenone has quit [Quit: Konversation terminated!]
rindolf has quit [Ping timeout: 240 seconds]
BPL has quit [Quit: Leaving]