cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | the secret reason for us trying to get PyPy users: to test the JIT well enough that we're somewhat confident about it
nimaje has quit [Read error: Connection reset by peer]
nimaje has joined #pypy
<kenaan>
cfbolz pyparser-improvements-3 1065b72e0409 /pypy/interpreter/pyparser/: introduce a Token class instead of passing 5 values around all the time
<kenaan>
cfbolz pyparser-improvements-3 d965ef8c054e /pypy/interpreter/pyparser/: use Token class in pytokenizer too
<kenaan>
cfbolz pyparser-improvements-3 d14ff1f951e6 /pypy/interpreter/pyparser/parser.py: move classify method to Grammar where it makes more sense
<kenaan>
cfbolz pyparser-improvements-3 2b67feca9fbd /pypy/interpreter/pyparser/pyparse.py: less code in except block
dddddd has joined #pypy
energizer has quit [Ping timeout: 260 seconds]
<kenaan>
cfbolz pyparser-improvements-3 2b4152c6c930 /pypy/interpreter/pyparser/test/test_automata.py: add at least a very minimal recognize test
jacob22__ has quit [Quit: Konversation terminated!]
jacob22__ has joined #pypy
jacob22__ has quit [Ping timeout: 240 seconds]
antocuni has quit [Ping timeout: 256 seconds]
lazka has quit [Quit: Leaving]
illume has joined #pypy
<kenaan>
cfbolz pyparser-improvements-3 5c8a5d8bb882 /pypy/interpreter/pyparser/: manually transplant 1e634f696054 to python2 pyparser: (antocuni, romain): use a better way to reg...
forgottenone has joined #pypy
forgottenone has quit [Read error: Connection reset by peer]
forgottenone has joined #pypy
pf_moore has joined #pypy
jacob22__ has joined #pypy
antocuni has joined #pypy
lritter has joined #pypy
raynold has quit [Quit: Connection closed for inactivity]
inhahe has joined #pypy
inhahe_ has quit [Ping timeout: 240 seconds]
TheAdversary has quit [Ping timeout: 240 seconds]
Hasimir has quit [Ping timeout: 240 seconds]
Hasimir has joined #pypy
TheAdversary has joined #pypy
antocuni has quit [Ping timeout: 240 seconds]
jacob22__ has quit [Quit: Konversation terminated!]
marky1991 has quit [Read error: Connection reset by peer]
marky1991 has joined #pypy
marky1991 has quit [Client Quit]
energizer has joined #pypy
<kenaan>
mattip default 1bdd44279495 /pypy/doc/: reset whatsnew-head for release
<kenaan>
mattip release-pypy2.7-6.x 46a3d2b1b0ee /: merge default into release
<kenaan>
mattip py3.5 1be242f4be56 /: merge default into py3.5
<mattip>
__pv: fix for #2797 merged, and cython has release 0.28.2 which silences a warning on newer Pypy
<mattip>
just waiting for some more pyparser improvements and we can release
nunatak has joined #pypy
ronan has joined #pypy
<arigato>
mattip: I'm digging into issue #2752 (cpyext: PyObject_GetBuffer() returns NUL-filled buffer (instead of data) when called intensively)
<mattip>
cool, is the test clear enough?
<arigato>
yes
<arigato>
it fails with the JIT only (when run directly, not via py.test because that starts a subprocess)
<arigato>
but still no clue
<mattip>
does it matter that the W_BytesObject._value is a `str` and not some lltypes CArray, does that confuse rffi.get_raw_address()
<mattip>
?
<arigato>
no, that's expected
<arigato>
rffi.get_raw_address() will sometimes return a raw pointer inside the rpython 'str', if it can't move any more
<arigato>
like now
<arigato>
but the 'str' really starts with null bytes here
<arigato>
I suspect it's a problem created earlier by the JIT
<arigato>
unrelated to cpyext
<mattip>
it is strange to me that PyString_AsString works even when the PyObject_GetBuffer doesn't
<antocuni>
arigato: unrelated to this discussion but I recently stumbled upon this: why do we use rdtsc to implement READ_TIMESTAMP instead of using rdtscp?
<antocuni>
by looking online, everyone seems to suggest to use either cpuid+rdtsc or rdtscp, but never rdtsc alone
<arigato>
mattip: PyString_AsString returns a pointer to the data in the PyStringObject, which is usually another copy
<arigato>
antocuni: cpuid+rdtsc is not safe in all cases, and rdtscp is not always available
<arigato>
instead I *think* we try to force the process on a given cpu
<arigato>
but I'm not sure
<antocuni>
according to what I read, rdtsc is "non serializing", which means that the CPU could reorder it and read the timestamp before or after some other instructions, with the effect of measuring the wrong interval
<antocuni>
maybe it's not too important anyway, because our log sections tend to be relatively long anyway
<arigato>
yes, it's a trade-off, it's probably more important to avoid skewing results too much by inserting a "serializing" instruction
<antocuni>
about forcing the process on a given cpu: IIRC, in the past we had the problem of having the time going backwards if the process migrated between cpus; but I think that nowadays almost all CPUs have the "constant_tsc" flag (grep in /proc/cpuinfo), which means that the tsc is shared among all cores
<arigato>
ok
<antocuni>
also, they have the "nonstop_tsc", which means that it ticks at a fixed frequency, regardless of power management
<antocuni>
anyway, I am fine keeping rdtsc; I just wanted to be sure that it's something that we know of, instead of using it "just by chance"
<arigato>
yes
ronan has quit [Remote host closed the connection]
<antocuni>
(for context: I digged into it because my gc hooks measure the duration of gc sections by using READ_TIMESTAMP)
<antocuni>
and of course there seems to be no standard/portable way to know what is the frequency, although in practice it seems to be the maximum frequency of the CPU
<antocuni>
the linux kernel seems to know it somehow, but it's not exposed
ronan has joined #pypy
<arigato>
...the bogus rpython str starts as a gc "shadow", which means it's a str in the nursery and we take the identityhash() of it; then there is a minor collection and the shadow becomes the object, but apparently not correctly filled
<arigato>
the link with the JIT may be only that the JIT tracing uses identityhash() a lot
<arigato>
Why Doesn't It Explode Ridiculously All The Time, and related questions
<arigato>
ah, found it
<arigato>
it's really get_raw_address_of_string(), which calls rgc.move_out_of_nursery(string)
<arigato>
there is a particular case in which rgc.move_out_of_nursery() will return a non-filled object, by mistake
<arigato>
it's if the object has already got a shadow copy, but the shadow copy is not filled
<antocuni>
for the series "how is it possible that nobody noticed so far"?
<arigato>
yes, it's a 2016-12-20 commit that adds this bug in the GC, which like all GC issues is rather subtle