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 | insert pithy quote here
fotis has joined #pypy
lritter has quit [Ping timeout: 276 seconds]
lritter_ has joined #pypy
fotis has quit [Ping timeout: 256 seconds]
fotis has joined #pypy
fotis has quit [Ping timeout: 255 seconds]
lritter_ has quit [Quit: Leaving]
fotis has joined #pypy
fotis has quit [Ping timeout: 272 seconds]
kor1 has quit [Read error: Connection reset by peer]
kor1 has joined #pypy
kor1 has quit [Client Quit]
<bbot2> Started: http://buildbot.pypy.org/builders/rpython-win-x86-64/builds/25 [mattip: test latest pypy as buildbot runner]
<bbot2> Exception: http://buildbot.pypy.org/builders/rpython-win-x86-64/builds/25 [mattip: test latest pypy as buildbot runner]
<bbot2> Started: http://buildbot.pypy.org/builders/rpython-win-x86-64/builds/26 [mattip: test latest pypy as buildbot runner]
smarr has quit [Quit: Connection closed for inactivity]
stkrdknmibalz has quit [Remote host closed the connection]
fotis has joined #pypy
fotis has quit [Ping timeout: 256 seconds]
<bbot2> Failure: http://buildbot.pypy.org/builders/rpython-win-x86-64/builds/26 [mattip: test latest pypy as buildbot runner]
fotis has joined #pypy
Julian has joined #pypy
gef has joined #pypy
fotis has quit [Ping timeout: 276 seconds]
Eclipse2212 has joined #pypy
gef_ has joined #pypy
gef has quit [Ping timeout: 276 seconds]
<mattip> rpython tests on win64 finished with "failure" instead of "exception", maybe a fluke but maybe due to updating libffi
gef has joined #pypy
arigo_ is now known as arigato
gef_ has quit [Quit: No Ping reply in 240 seconds.]
gef_ has joined #pypy
<mattip> arigato: any idea why the rpython test_rgil test of test_after_thread_switch fails on win64 with double the number of thread switches
<mattip> is the test flaky or the windows rgil switch flaky?
<mattip> (not double, it is actually 4x)
<arigato> only on win64? no, we should look at the C code produced
otisolsen70 has joined #pypy
<arigato> looks like it could bring down performance
* mattip trying to debug it
greedom has joined #pypy
fotis has joined #pypy
fotis has quit [Ping timeout: 256 seconds]
Julian has quit [Ping timeout: 272 seconds]
tazle has quit [Ping timeout: 272 seconds]
<mattip> in rpython/rlib/rposix.py there is a context manager so that a call with an invalid fd will not crash the windows app
<mattip> pre-visual2015 it used a tricky _PyVerify_fd() call, which was turned into a empty function when we moved to visual2015+
<mattip> but the function still was called with the gil, so that is 1 of the 4 rgil acquisitions
<mattip> that was all replaced with a call to a new API to replace the "crash on invalid fd" handler with one to do nothing
<mattip> and another call to restore the old behaviour
<mattip> so that is another 2 rgil acquisitions
<mattip> the construct now looks like "with rposix.SuppressIPH(): <do something with fd>"
<mattip> I guess we could do better if we do all that in one C call
<arigato> :-(
Julian has joined #pypy
fotis has joined #pypy
fotis has quit [Ping timeout: 255 seconds]
<mattip> 80-20 rule: it seems read() and write() would be the first functions to wrap in C since they are probably the most-used ones
smarr has joined #pypy
<mattip> there is also fread, fwrite in cpyext/api.py, but those could be replaced with os.read/os.write
gef_ has quit [Ping timeout: 256 seconds]
gef has quit [Ping timeout: 272 seconds]
gef has joined #pypy
<mattip> heh, and just like that virtualenv released a version with a fix for the recent libffi win64 changes
gef has quit [Ping timeout: 256 seconds]
antocuni_ is now known as antocuni
gef has joined #pypy
gef_ has joined #pypy
gef has quit [Read error: Connection reset by peer]
greedom has quit [Remote host closed the connection]
fotis has joined #pypy
fotis has quit [Ping timeout: 272 seconds]
otisolsen70 has quit [Quit: Leaving]
Eclipse2212 has quit [Quit: WeeChat 3.1]
kor1 has joined #pypy
gef_ has quit [Ping timeout: 272 seconds]
gef has joined #pypy
fotis has joined #pypy
fotis has quit [Ping timeout: 255 seconds]
gef has quit [Ping timeout: 252 seconds]
stkrdknmibalz has joined #pypy
<mattip> rpython on win64 is hanging in rpython/jit/backend/llsupport/test/test_codemap.py when it calls into unpack_traceback (in codemap.py)
<mattip> there is a "while True" loop there, I don't see what is changing between iterations of the loop
<mattip> it looks to me like once the first iteration fails, it will continue forever
stkrdknmibalz has quit [Quit: WeeChat 3.0.1]
<mattip> ahh, it is getting stuck in the loop in yield_bytecode_at_address
stkrdknmibalz has joined #pypy
gef has joined #pypy
<mattip> the codemap source in llsupport/src/codemap.c seems to assume pointers are long, where on win64 they are long long
<mattip> arigato: does that look OK to you?
gef has quit [Ping timeout: 272 seconds]
gef_ has joined #pypy
gef has joined #pypy
gef_ has quit [Ping timeout: 245 seconds]
gef has quit [Ping timeout: 245 seconds]
gef has joined #pypy
gef has quit [Ping timeout: 265 seconds]
stkrdknmibalz has quit [Remote host closed the connection]
gef has joined #pypy
gef has quit [Ping timeout: 258 seconds]
ambv has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gef has joined #pypy
gef_ has joined #pypy
gef_ has quit [Ping timeout: 255 seconds]
gef has quit [Ping timeout: 255 seconds]
Dejan has joined #pypy
fotis has joined #pypy
Dejan has quit [Quit: Leaving]
gef has joined #pypy
fotis has quit [Ping timeout: 252 seconds]
gef has quit [Ping timeout: 276 seconds]
kor1 has quit [Quit: Leaving.]
Julian has quit [Quit: leaving]
gef has joined #pypy
gef has quit [Ping timeout: 272 seconds]
gef has joined #pypy
gef_ has joined #pypy
gef_ has quit [Ping timeout: 256 seconds]
gef has quit [Ping timeout: 256 seconds]
lritter has joined #pypy
gef has joined #pypy
gef has quit [Ping timeout: 265 seconds]
<mattip> ahh, they are not really pointers, they are bytecode addresses
gef has joined #pypy
jryans has quit [Read error: Connection reset by peer]
daubers has quit [Remote host closed the connection]
<mattip> looking in another direction
<mattip> The spec for win64 calls is that the callee is expected to restore RBX, RBP, RDI, RSI, RSP, R12, R13, R14, R15, and XMM6-XMM15
<mattip> in jit/backend/x86/runner.py I see only ebx, esi, edi, r12, r14, r15
fotis has joined #pypy
fotis has quit [Ping timeout: 245 seconds]
gef has quit [Ping timeout: 272 seconds]
gef_ has joined #pypy
gef has joined #pypy
greedom has joined #pypy
gef_ has quit [Ping timeout: 250 seconds]
gef has quit [Ping timeout: 268 seconds]
greedom has quit [Remote host closed the connection]
kor1 has joined #pypy
gef has joined #pypy
jryans has joined #pypy
gef has quit [Ping timeout: 246 seconds]
daubers has joined #pypy
raek has joined #pypy
fotis has joined #pypy
tazle has joined #pypy
fotis has quit [Ping timeout: 245 seconds]
fotis has joined #pypy
gef has joined #pypy
fotis has quit [Ping timeout: 252 seconds]
<smarr> hmmm, so, I assumed the following would result in the lookup call being elided, but it doesn't work (there's a call in the trace)
<smarr> @elidable_promote("0,1")
<smarr> ```
<smarr> ```
<smarr> def _lookup(self, layout, obj):
<smarr> reading the documentation of `@elidable` I guess all arguments need to be constants/promoted values. Is there any way to ignore a specific argument?
<smarr> I need the object in the lookup, there's a fallback case (transitioning objects with outdated shapes), but it doesn't influence the lookup results in the normal case.
<smarr> Ideally, I'd just do the following in the interpreter:
<smarr> ```
<smarr> location = self._lookup(layout, self_obj)
<smarr> layout = self_obj.get_object_layout()
<smarr> return location.read_fn(location, self_obj)
<smarr> ```