<njs>
fijal: the backtrace Ninpo posted seems to show tqdm doing something with a background thread that apparently works on cpython but deadlocks on pypy
<njs>
fijal: I don't imagine you can debug a deadlock via telepathy, and it's very unclera whether the bug is in pypy or not, but tqdm is super popular so maybe helpful to at least hear about
<njs>
(why a progress bar library has tricky threading code in it I don't know)
yaewa has joined #pypy
moei has quit [Ping timeout: 268 seconds]
<energizer>
njs: it has time-based options like `mininterval` "Minimum progress display update interval [default: 0.1] seconds."
<njs>
energizer: it does seem to be related to that somehow, but I don't understand why that needs a thread... when I've done stuff like this by hand, I just check when going to display whether the given amount of time has passed
<njs>
maybe it's some kind of optimization attempt, to avoid calliing time.monotonic() so often? seems poorly motivated to me, time.monotonic() is stupidly fast IME
<tos9>
njs: tqdm has an extremely odd / overcomplicated implementation overall (which I noticed for totally unrelated reasons while we tried to fix https://github.com/tqdm/tqdm/pull/598 )
<tumbleweed>
lazka: we intentionally use python3 dist-packages in Debian
<lazka>
oh, ok
<lazka>
I'll wait for 7.0 then. It's a bit of a mess right now, get_python_lib() gives /usr/lib/pypy3/dist-packages, get_paths("posix_prefix") gives /usr/lib/pypy3/lib/python3.5/site-packages
<mdash>
hi
<mdash>
my rpython program is segfaulting in GC, probably because of a mistake I made with rffi
<mdash>
what's a good way to tackle this? valgrind?
<cfbolz>
mdash: gdb, and building it with rpython --lldebug
<mdash>
aha, i was not aware of --lldebug
<cfbolz>
mdash: if it's really an rffi problem it might not help
<cfbolz>
but always the first thing to try
<mdash>
OK. Is there a way to keep the generated C source so gdb can see it?
<cfbolz>
mdash: not beyond just copying the dir somewhere
<mattip>
look at rpython.tool.udir, you can set PYPY_USESSION_DIR, then the sources are in PYPY_USESSION_DIR/usession*/test1
jcea has joined #pypy
<antocuni>
bah, lufthansa canceled my scheduled flight and put me on a later one tomorrow :(
<antocuni>
so I'll arrive latish in the evening; is there anyone who plans to go out somewhere tomorrow?
* mattip
arriving Mon afternoon, but check with arigato
lazka has quit [Remote host closed the connection]
<mdash>
mattip, cfbolz: thanks, this is most likely some double-free() stuff due to bugs in my rffi wrapper for libuv
<mjacob>
mdash: especially for these kinds of problems, i'm a big fan of using rr (reverse debugger based on gdb)
marky1991_2 has quit [Read error: Connection reset by peer]
Zaab1t has quit [Read error: Connection reset by peer]
marvin has quit [Remote host closed the connection]
marvin has joined #pypy
Zaab1t has joined #pypy
<tos9>
antocuni: me :) but I have no idea about actual pypy people plans
<tos9>
antocuni: I arrive tomorrow morning
kenaan has joined #pypy
<kenaan>
mattip unicode-utf8-py3 64938735299b /pypy/interpreter/error.py: invalid utf8 in error message should not crash the interpreter
<kenaan>
mattip unicode-utf8-py3 f165c244dfb4 /: remove more bytes.decode, assert on unused case in module.struct
Zaab1t has quit [Quit: bye bye friends]
<mdash>
mjacob: yes i never would have gotten this far without using rr :)
<mdash>
but right now it's looking like it's just a plain use-after-free due to misunderstanding libuv docs
irclogs_io_bot has quit [Remote host closed the connection]
<antocuni>
tos9: actually I realized that I'll arrive at my apartment at ~21:30/22, so probably too late for dinner
<tos9>
antocuni: ah ok
<tos9>
antocuni: the airport is very close to town from what I can tell FWIW
<tos9>
it looks like it's like a 15 minute train
<cfbolz>
yep, that's realistic
<cfbolz>
(antocuni and arigato (and me) have lived in düsseldorf at some point, fwiw ;-) )