<njs>
anyone know why getsockopt(tsocket.IPPROTO_TCP, tsocket.TCP_NODELAY) on pypy3 nightlies would return b""? (it should be 1 or 0)
<njs>
err, s/tsocket/socket/
tilgovi has quit [Ping timeout: 240 seconds]
mattip has joined #pypy
<mattip>
ronan: there is a test failure on own tests, in test_strbufobject.py::AppTestStringObject::()::test_buffer
<njs>
ahhhh it's because pypy doesn't know that passing buffersize=0 to getsockopt is supposed to be a special case that's equivalent to not passing buffersize at all
tilgovi has joined #pypy
<mattip>
ronan: it "grew" sometime in PyBuffer-backport, and is because W_StringBufferObject blindly takes the typedef of W_BytesObject,
<mattip>
where W_BytesObject's __buffer__ is specific to that class, not from W_AbstractBytesObject
<mattip>
well, at least that is the first problem :)
<realitix>
Hello arigato, congratulation for europython !
<danchr>
arigato: you could use the original name of the OS — Mac OS X — which has the nice advantage of being both old school and unambiguous ;)
<arigato>
danchr: yes, that's done
<arigato>
realitix: thanks!
<kenaan>
antocuni faster-rstruct-2 acd0aa896e2d /rpython/rlib/rstruct/nativefmttable.py: rpython fix for 32 bit
commandoline has quit [Quit: Bye!]
commandoline has joined #pypy
girish946 has quit [Ping timeout: 240 seconds]
<kenaan>
antocuni faster-rstruct-2 1a6ceca7adce /pypy/module/pypyjit/test_pypy_c/test_struct.py: fix the expected JIT ops after the recent W_BytearrayObject changes
<palecsan>
Hello, I have a question regarding the Multiprocessing issue (https://bitbucket.org/pypy/pypy/issues/1538). Do you have any clues how can I investigate the usage of locks and semaphores in PyPy? I am curios why it hangs for random periods of time in sem_wait() system call, inside RPyThreadAcquireLockTimed() function. I tried the same code in my own
<palecsan>
C application and no freeze happens, even for a very large number of concurrent threads
<arigato>
well, then you have to figure out what the difference is
<arigato>
thanks for helping with this old issue, btw
<palecsan>
you are welcome! I was wondering if there is any other place I should be paying attention, or something particular that is implemented in PyPy
<arigato>
the GIL is done in a different way than CPython
<arigato>
but that's also as C files, in thread_gil.c
<arigato>
and I think it should not matter for multiprocessing in the default, multiple-processes mode, because it doesn't start threads, I think
<arigato>
(I may be wrong)
<palecsan>
In multiprocessing, besides the processes that are forked, you have 3 threads
<arigato>
ah, ok
<palecsan>
one for monitoring the processes, one for task sending and one for result retrieval
<arigato>
so the way the GIL works is by a combination of a semaphore and polling
<palecsan>
and an interesting observation is that if I switch from "import multiprocessing" to "import multiprocessing.dummy as multiprocessing" and use the pure thread version of this, everything works flawless
<palecsan>
with multiprocessing.dummy it's even faster than CPython
<arigato>
so what's the CPU usage?
<arigato>
does it seem that the CPU is mostly idle (when it should not be)?
<palecsan>
with my script it does not stress the CPU, it's a rather small workload, with a single process
<palecsan>
it's just enough for me to see that from time to time it freezes
<arigato>
well, the issue is that something is slow
<arigato>
so the question is, is it slow (or freezing) while burning CPU time, or it is slow/freezing while being idle
<cfbolz>
antocuni: are you ok with killing the fastpath in ctypes, given that it produces bugs to have it?
<cfbolz>
ahm sorry
<cfbolz>
didn't see that you just commented ;-)
jacob22_ has joined #pypy
<antocuni>
cfbolz: sure :)
<cfbolz>
cool, so I'll merge
<cfbolz>
(mihai just fixed your complaints)
* antocuni
looking
Guest38760 has quit [Remote host closed the connection]
<cfbolz>
off-topic: this is pretty cool: telnet mapscii.me
<antocuni>
cfbolz: ok please merge :)
<kenaan>
Dodan pypy_ctypes_nosegfault_nofastpath 96435a57d046 /: fixed ctypes segfault by removing fastpath. Test in test_segfault.py
<kenaan>
Dodan pypy_ctypes_nosegfault_nofastpath a0c92b42599a /pypy/module/test_lib_pypy/ctypes_tests/test_segfault.py: Test_segfault.py now throws ctypes.ArgumentError
<kenaan>
Dodan pypy_ctypes_nosegfault_nofastpath 5823134aebb6 /pypy/module/test_lib_pypy/ctypes_tests/: Removed test_segfault.py. The test was in test_functions.py in test_argument_conversion_a...
<kenaan>
cfbolz default 8b4ebb4d87c8 /: Merged in Dodan/pypy_ctypes/pypy_ctypes_nosegfault_nofastpath (pull request #547) fixed ctypes segfault by removi...
Guest81763 has quit [Remote host closed the connection]
yuyichao_ has quit [Ping timeout: 272 seconds]
<realitix>
Is pypy taking advantage of mypy notation instead of guessing types when available ?
<LarstiQ>
no
<dash>
realitix: pypy doesn't have to guess, it knows :)
<realitix>
^^ !
marr has quit [Read error: Connection reset by peer]
<kenaan>
antocuni faster-rstruct-2 ca5fc3f48609 /rpython/translator/c/test/test_llop.py: bah, the two tests shared the same cache, which means that they worked if invoked separately but broke ...
inad922 has joined #pypy
arigato has quit [Quit: Leaving]
marky1991 has joined #pypy
vkirilic_ has joined #pypy
vkirilichev has quit [Ping timeout: 260 seconds]
marky1991 has quit [Remote host closed the connection]
<cfbolz>
antocuni: there are other ways to end up in 18:50:17 <antocuni> I am a bit confused. I am in gdb after I got the RPython assertion error, inside pypy_g__opimpl_getfield_gc_any_pureornot___153_f
<cfbolz>
But I am not seeing any of the other ones in the jitcode either
<antocuni>
plus, the pc looks wrong
<antocuni>
cfbolz: the jitcode opcode is 102, which corresponds to pypy_g_handler_getfield_gc_f_pure_1
<antocuni>
the most likely thing is that jc_inst_name is wrong?
<cfbolz>
antocuni: what are the two different values m
<antocuni>
cfbolz: the ones which cause the assertion error?
<cfbolz>
Yes
<antocuni>
they are stored as long long, 4134304457926115328 and 4885473209836634112
<cfbolz>
So not particularly similar
<antocuni>
which, according to longlong2float, correspond to 2.465190328815662e-32 and 4.1343044579261153e+18
<antocuni>
which are a bit suspicious as values
<cfbolz>
Indeed
<antocuni>
I got there by running test_cmath.py btw
<cfbolz>
Anyway, I would fix writeanalyze as the first step. Because atm the effect Infos are just wrong
<antocuni>
yes, makes sense
<antocuni>
I'll do that and hope that it's enough to solve
* antocuni
off for now
<antocuni>
cfbolz: thanks!
<cfbolz>
antocuni: I am sure there are other such problems somewhere
<antocuni>
yes, I suppose I need to fix heapcache as well
<cfbolz>
antocuni: maybe, yes. Or at least test that the new op invalidates the heapcache