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
xcm has quit [Killed (card.freenode.net (Nickname regained by services))]
xcm has joined #pypy
jcea has joined #pypy
dmalcolm has quit [Remote host closed the connection]
dmalcolm has joined #pypy
ekaologik has joined #pypy
jvesely has joined #pypy
lritter has quit [Ping timeout: 264 seconds]
dddddd_ has joined #pypy
lritter has joined #pypy
dddddd has quit [Ping timeout: 246 seconds]
dddddd_ is now known as dddddd
i9zO5AP has quit [Quit: WeeChat 2.7.1]
jacob22 has quit [Quit: Konversation terminated!]
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
<arigato>
mattip: so, test_semlock works fine on windows with --jit off, provided I increase the timeout of 5 seconds in the test
<arigato>
with the jit, though, it gives an error "release unlocked lock" at the end of a "with lock:" block, which makes little sense
<mattip>
ok
<mattip>
pyusr: you may want to ping some async people to see if there are other benchmark frameworks
<arigato>
...mmh, maybe it's not related to the jit but crashes if it's "too fast" somehow
<mattip>
arigato: doesn't the JIT do something different with the GIL ?
<arigato>
yes
<arigato>
logs seem to say that at some point, a thread.lock.acquire() succeeds in two threads at once
<arigato>
so I suspect that lock.acquire() sometimes fails (and errors are eaten), which gives this result
<arigato>
but I have a lack of motivation to actually try to debug the C source, which usually takes me more than one hour plus a translation to get started
<mattip>
fair
<mattip>
I plan on working on windows a bit this week: we should really merge the winconsoleio branch, since many tests need it
<arigato>
(and that's the good case; now I've upgraded stuff like the version of visual studio, so I bet it would be more one afternoon to get started)
<arigato>
...ah no, it seems that translation still works for a simple example and starts for the full pypy, so I'll try anyway
<mattip>
+1
<mattip>
don't forget to do python2 get_externals.py to update the hg repo of the external libraries
<mattip>
for your version of visual studio
<mattip>
fwiw, the build is using visual 2019 now
<mattip>
if it can
<arigato>
I didn't, but also I got painfully installed stuff from long ago and that seems to be enough (provided I use --withoutmod-bz2) so I'll first try like this
<mattip>
cool
<arigato>
still with VC 2008 (I don't have VC 2019, I have only VC 2017 here)
<arigato>
(at some point I tried to upgrade to VC 2019 and I lost an afternoon at the end of which I had VC 2017 again)
<mattip>
hmm, It should have preferred 2017 over vc 2008
<mattip>
but the detection code is flaky
<mattip>
anyhow, thanks for diving in
<arigato>
well I'm running with tons of env vars, as required long ago, so I guess they still force vc2008
<arigato>
we'll see
<mattip>
whatever works. I admit it took me a few reinstalls and restarts to get the pieces in place
<mattip>
I would document it but I have no idea what the correct configuration of all the tools is
<arigato>
right
<arigato>
is there some Docker support for Windows images?
<mattip>
I keep hearing about it, but have never seen it
<arigato>
I managed once to reproduce on Linux, so I guess I'll continue to dig there
<arigato>
OK, maybe not
<arigato>
...OK, give up again. The compilation fails at the end in yet another funny way I've never seen before
<mattip>
the problem might not be in the semaphore code at all, rather in the threading code
<mattip>
wasn't there some threading problem on win32 that we never got to the bottom of so we just skipped the test?
<pyusr>
windows has in the task manager if you right click on a process in details "Analize wait chain" which can find locks that have not been released by dead threads
<mattip>
+1
<mattip>
pyusr: the process is hung but nothing shows in that window