--- Log for 05.04.120 Server: livingstone.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 3 days and 18 hours ago 00.09.33 Join dys [0] (~dys@tmo-112-52.customers.d1-online.com) 00.27.23 Quit lebellium (Quit: Leaving) 00.37.14 Quit ZincAlloy (Quit: Leaving.) 00.38.53 Quit petur (Quit: Leaving) 00.40.19 Quit krabador (Remote host closed the connection) 01.06.55 Join Loeb [0] (~urp@76.229.134.243) 01.08.31 Quit sakax (Read error: Connection reset by peer) 01.09.51 Join sakax [0] (~r0b0t@unaffiliated/r0b0t) 01.14.56 Quit sakax (Remote host closed the connection) 01.29.08 # oh sweet. 01.31.15 # __builtin, looks like SDL stuff works on hosted MIPS targets. wolf3d hangs, but doom launches and runs fine. 01.31.20 # no sound though. 01.32.17 # ah, it defaults off. ah, the sweet sounds of my impressionable youth. 01.46.47 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) 01.50.14 # <__builtin> Doom isn't sdl 01.50.17 # whoops, spoke too soon, doom doesn't use SDL. no matter, 01.50.24 # <__builtin> Hehe 01.50.25 # just barely beat me to it. :P 01.50.39 # trying to make a dent in the compiler warnings that SDL generates 01.50.53 # <__builtin> Any chance you can get a pc for the sdl hang? 01.51.02 # <__builtin> I.e 01.51.18 # <__builtin> I.e. on arm you can hack the piezo to buzz it out 01.51.39 # well, this is a hosted target, so it's linux under there. 01.52.35 # <__builtin> Ah, gdb maybe? 01.52.58 # maybe. It's a source-less android-ish mips environment 01.53.54 # can probably cross-compile gdb with a lot of elbow grease 01.54.15 # <__builtin> Or you can go the old-fashioned route and sprinkle a bunch of splashf() or logf()s everywhere 01.54.43 # <__builtin> And then bisect to find the offending lines 01.54.51 # yeah, that'll probably end up faster. 01.55.32 # <__builtin> It's remarkable how well that works, really 01.56.04 *** Saving seen data "./dancer.seen" 01.56.14 # <__builtin> I really should have cleaned up the sdl tree a lot more than I did... 02.03.18 # trying to clean up the really noisy warnings first. 02.06.02 # <__builtin> Most of the preprocessor ones are benign, I think 02.06.17 # yeah. 02.06.32 # <__builtin> Though gcc is finicky about -Wno-* for some reason 02.07.04 # <__builtin> I remember investigating it when I first did the port, but I was more focused on making it work than anything else 02.08.45 # but, for example, one I just fixed in SDL_Mixer was because of bad #include ordering 02.09.09 # causing warnings about endianness ordering and stuff like that 02.09.39 # <__builtin> rbendian.h? 02.10.07 # no.. caused by an include of an SDL header prior to incluing the config header. probably harmless ultimately, but it made for a lot of noise 02.11.19 # <__builtin> I did write some docs which might be of use: https://www.rockbox.org/wiki/SdlPluginPort 02.14.14 # <__builtin> would you mind pushing whatever WIP you've got? I should be able to lend a hand 02.16.38 # <__builtin> (to gerrit, of course) 02.19.13 # let me get through this chunk and I will do.. 02.22.50 # <__builtin> hopefully the MIPS misbehavior gives us some clue about the intermittent bugs on arm 02.27.38 # g#2324 02.27.44 # Gerrit review #2324 at http://gerrit.rockbox.org/r/2324 : SDL: Silence a large number of compile warnings (WIP) by Solomon Peachy 02.27.54 # it has everything but my ongoing changes to sdl.make 02.28.18 # I've been selectively mucking with that to make the warning pile manageable 02.29.00 # <__builtin> thanks :) 02.31.22 # okay, the reason the rocker target is blowing up so badly is it's stuck in a memory allocation failure loop 02.31.42 # AGPTek thoughfully left strace in the filesystem 02.35.45 # <__builtin> it only has 6 MB of memory, right? 02.36.01 # <__builtin> quake *definitely* isn't running on that, and duke is also marginal 02.36.07 # 6MB allocated to the application, but that can be boosted a little. 02.36.14 # I'm trying wolf3d 02.36.21 # <__builtin> how much is there physically? 02.36.27 # 32 02.36.46 # <__builtin> if we can wrangle about 16 from the kernel we should be good 02.36.50 # only 26.5 available to the OS... 02.37.21 # <__builtin> I vaguely recall quake needing about 10-12 MB of heap 02.37.34 # there's about 8.5 on top of that 6MB we can get 02.37.42 # but that leaves no room for caches. 02.37.51 # <__builtin> via sbrk or similar? 02.37.55 # I'll bump it to 10mb. 02.38.22 # IIRC we still use our internal malloc from a maximally-allocated heap on hosted targets 02.38.48 # rebuilding the world now 02.38.50 # <__builtin> buflib, you mean? 02.40.01 # basically strace is shoing that, during the wolf3d launch hang.. 02.40.26 # rt_sigprocmask(SIG_BLOCK, [USR1], [USR1], 16) = 0 02.40.28 # rt_sigaction(SIGUSR1, {0x8000000, [RT_69 RT_70 RT_71 RT_72 RT_74 RT_76 RT_78 RT_80 RT_81 RT_87 RT_88], SA_NOCLDWAIT|0x468d90}, {0x8000000, [RT_81 RT_82 RT_83 RT_84 RT_85 RT_86 RT_88], SA_NOCLDWAIT|0x468d90}, 16) = 0 02.40.30 # y 02.40.34 # this in a tight loop 02.40.52 # sigaltstack({ss_sp=0x753afe64, ss_flags=0, ss_size=0}, {ss_sp=0x460000, ss_flags=0, ss_size=12564028}) = -1 ENOMEM (Cannot allocate memory) 02.41.00 # <__builtin> aha! 02.41.01 # all three, looped 02.41.05 # <__builtin> I know what it is 02.41.14 # oh? 02.41.25 # <__builtin> yeah, I ran into that when building for the simulator 02.41.31 # <__builtin> you need to pass --sdl-threads to tools/configure 02.41.55 # gotcha 02.41.57 # give me a sec 02.42.22 # <__builtin> see the very bottom of the SdlPluginPort page 02.43.22 # * __builtin doesn't know if a hosted target will support SDL threads, though 02.43.40 # <__builtin> is the application build running on SDL? 02.43.45 # well, the hosted target is already configured to use SIGALSTACK_THREADS 02.44.03 # the application is native framebuffer etc. 02.45.02 # <__builtin> I never bothered to diagnose *why* sigaltstack threads were breaking 02.47.46 # so what we probably want is to, on hosted targets, tell SDL to use its own native threading. 02.48.56 # <__builtin> so do we actually link with SDL for the agptek build? 02.49.04 # no 02.49.59 # I mean we're building SDL within rockbox's confines, including mapping SDL_Thread -> rbthread 02.50.34 # we could just have SDL_Thread just compile to native linux threading. 02.50.57 # <__builtin> ah, I understand 02.51.38 # <__builtin> that's still a bit of a kludge, and I'd like to get at the root of the problem 02.51.43 # since when the sdl plugins are running, rockbox is effectively paused anyway. 02.52.19 # <__builtin> in what context are the sigaltstack errors occuring? 02.52.27 Quit atsampson (Ping timeout: 272 seconds) 02.53.07 # <__builtin> is it quake/wolf starting its SDL_audio thread? 02.53.31 # don't know. the rockbox background is still showing. 02.54.03 # <__builtin> can you pastebin the full strace dump? 02.54.59 # there's not a lot there 02.55.10 # http://www.shaftnet.org/~pizza/dump.txt 02.55.39 # <__builtin> that's 404ing 02.55.50 # if I had to guess this happens before (or due to) the first SDL thread that's started 02.56.10 # whoops, try again. forgot to save/create the file 02.56.17 # <__builtin> I should mention that there's really several threads in play here 02.56.32 # <__builtin> the main SDL application runs in a newly created rockbox thread (so it can have a larger stack) 02.57.21 # <__builtin> that application (or the SDL library itself) can then use SDL_thread (which is just a wrapper over rockbox threads) to create more for audio mixing, etc. 02.59.08 # <__builtin> hmm, it definitely looks to me that it's failing in the initial thread creatoin 03.00.10 # <__builtin> apps/plugins/sdl/main.c:227 03.00.32 # ...thread_unix:121 03.02.18 # The specified size of the new alternate signal stack ss.ss_size was less than MINSIGSTKSZ 03.03.14 # and there it is. 03.03.20 # main.c:76 03.03.43 # <__builtin> yeah, I've got it hardcoded to a megabyte 03.03.44 # fixed at 512K 03.04.11 # <__builtin> err, I'm working with a dirty tree 03.05.25 # <__builtin> that's 2MB, isn't it? 03.05.33 # <__builtin> long main_stack[1024 * 1024 / 2]; 03.05.42 # waiy, you're right. 03.05.47 # d'oh. 03.06.10 # <__builtin> that was determined completely empirically, btw 03.06.14 # * speachy really doesn't like raw buffers not specified in bytes. 03.06.45 # I'm chainging that definition to be the smaller of 2MB or DEFAULT_STACK_SIZE 03.06.57 # <__builtin> it needs to be pretty big, actually 03.07.11 # <__builtin> quake and duke will quickly crash with DEFAULT_STACK_SIZE 03.07.42 # on hosted platforms, DEFAULT_STACK_SIZE is defined as MINSIGSTKSZ + 12K 03.08.14 # <__builtin> what's MINSIGSTKSZ then? 03.08.35 # not sure. 03.10.05 # <__builtin> on ARM, DEFAULT_STACK_SIZE is only 1KB 03.10.26 # <__builtin> and there's no way quake is running with that little 03.11.46 # I think the problem is that rockbox's context->stack_size is being set to 0 03.12.06 # and 0 is WAY too low. :) 03.12.30 # <__builtin> heh 03.12.33 # <__builtin> no function calls! 03.14.24 Join atsampson [0] (~ats@cartman.offog.org) 03.14.30 # * __builtin dislikes the #include'ing of .c sources 03.16.35 # I think.. 03.16.53 # ..might have found it. 03.17.34 # <__builtin> aha, got it too 03.17.39 # <__builtin> ALIGN_BUFFER? 03.17.44 # no.. 03.18.14 # <__builtin> firmware/export/system.h:135: (size) = __a2 > __a1 ? __a2 - __a1 : 0; \ 03.19.34 # you're a bit ahead of me :) 03.19.45 # <__builtin> that macro is being used to initialize the stack size that's eventually going to sigaltstack 03.20.06 # <__builtin> see firmware/kernel/thread.c:351 03.20.18 # yeah, I see that 03.21.38 # but that shouldn't kick in unless we're overflowing 03.22.13 Quit atsampson (Ping timeout: 272 seconds) 03.22.51 # <__builtin> maybe throw in a panic to rule that out? 03.25.18 Join atsampson [0] (~ats@cartman.offog.org) 03.30.21 # okay, re-deploying.. 03.35.17 # no good. adding in another test. 03.37.05 # <__builtin> Maybe add a couple panics to check that the size is nonzero? 03.37.18 # I'm adding more panics 03.37.30 # didn't panic before or after tha ALIGN_BUFFER call 03.37.43 # <__builtin> Also it might be good to check that panic actually works 03.40.32 # it works. 03.40.38 # accidently put it in the wrong place 03.49.45 # <__builtin> So was it ALIGN_BUFFER? 03.50.36 # no 03.52.30 # tripped over the panic I put in thread-unix.c:make_context() 03.54.58 # adding more in a few other key places 03.56.07 *** Saving seen data "./dancer.seen" 04.02.31 Quit cockroach (Quit: leaving) 04.05.40 # ah, I think I found it 04.05.44 # ... 04.05.52 # it is ALIGN_BUFFER 04.07.10 # <__builtin> :) 04.07.23 # I take that back. 04.07.25 # <__builtin> overflow? 04.09.34 # it looks like it's goign wrong in new_thread_base_init(). *stack_sizep appears to be okay, but thread->stack_size seems to be screwed up. 04.10.06 # <__builtin> hmm... 04.10.32 # <__builtin> so the issue is in thread->stack_size = *stack_sizep;? 04.10.44 # so it appears. doing another run. 04.10.54 # <__builtin> huh 04.10.56 # takes longer to unzip the rockbox.zip than it does to compile it 04.11.22 # <__builtin> that's a good problem to have! 04.22.52 # now I'm crashig on startup 04.29.10 # <__builtin> on boot or plugin start? 04.29.31 # boot 04.30.12 # <__builtin> is it one of your panics? 04.30.27 # probably but it's prior to any of the output. 04.30.43 # I mean before the bootloader screen is painted over 04.30.49 # <__builtin> ah 04.30.56 # <__builtin> sounds like some early boot problem 04.31.15 # <__builtin> is it just freezing or do you get a trace? 04.31.19 # freezing 04.38.59 # two steps forward, three steps back 04.39.33 # <__builtin> are your panics on !stack_size? 04.39.57 # <__builtin> ("on" as in "taking place in case of") 04.49.03 # well, that's a new one 04.49.18 # segfault at startup.. 04.49.51 # <__builtin> always a fun time shaking the old kernel tree :) 04.53.13 # I think what's happening is that the sanity checks I keep putting in are getting tripped by the early startup code 04.55.52 # <__builtin> here's a hack: put in a flag (just a global int) to switch the panics on/off 04.56.04 # <__builtin> and set that flag once boot finishes 05.01.51 Quit mendelmunkis (Remote host closed the connection) 05.02.20 Join mendelmunkis [0] (~mendelmun@65-128-208-151.mpls.qwest.net) 05.11.57 # yep, definitely ALIGN_BUFFER. 05.12.14 # if I put in my panic after it, I fail to boot. 05.12.23 # damnit 05.12.30 # left the debug flag out of that test. 05.12.33 # sigh 05.14.46 Quit TheSeven (Ping timeout: 260 seconds) 05.15.16 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.15.51 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) 05.18.00 Quit mendelmunkis (Ping timeout: 265 seconds) 05.20.44 # okay, it's definietely thread->stack_size = *stack_sizep 05.21.06 # *stack_sizep is nonzero but post-assignment, thread->stack_size is zero. 05.21.56 # crap! 05.21.58 # found it. 05.22.04 # unsigned short stack_size; /* Size of stack in bytes */ 05.22.19 # changed that to size_t 05.22.37 # that would explain a _lot_ of SDL funkiness. 05.23.23 # <__builtin> shit... 05.23.31 # this is an _old_ bug. 05.23.35 # <__builtin> yep 05.23.53 # <__builtin> I think we've reached the bottom of the rabbit hole :) 05.24.36 # <__builtin> yeah, it looks like create_thread expects a size_t for stack size, so that's definitely a bug 05.24.49 # I'd put good odds that the SDL stack didn't need to be 2MB either 05.25.15 # * __builtin remembers sizing up til it ran, and then doing * 2 or * 4 to be safe 05.25.43 # godo news, wolf3d launches, then eventually blows up due to not being able to allocate wave buffer 05.25.55 # <__builtin> progress :) 05.26.05 # time to unwind all of this insane debug code. 05.27.01 # <__builtin> ah, that's the code that resamples all the wolf sounds 05.28.00 # <__builtin> could you just bump memorysize? 05.28.22 # one thing at a time. :D 05.33.18 # rebooting with the de-debuggified code.. 05.35.28 # rebuilding with 10MB memsize and 1MB SDL stack, for giggles. 05.37.50 # the thread fix is g#2326 05.37.52 # Gerrit review #2326 at http://gerrit.rockbox.org/r/2326 : Threading: Use 'size_t' for stack size in core threading code by Solomon Peachy 05.39.02 # wolf is running 05.39.33 # <__builtin> yay! 05.39.34 # <__builtin> sound works? 05.40.16 # <__builtin> and how about duke/quake? 05.40.28 # yes. music 05.41.05 # and digitized too 05.41.13 # it's kinda scratchy and choppy 05.41.28 # <__builtin> it's probably not realtime then 05.41.40 # duke3d 05.42.02 # works music and sound. 05.42.11 # <__builtin> that's a big win, actually :) 05.42.16 # and paniced when starting the game. 05.42.22 # might be due to my shrinking the stack 05.42.33 # abandon ship! sdl_main 05.43.00 Join mendelmunkis [0] (~mendelmun@65-128-208-151.mpls.qwest.net) 05.43.19 # <__builtin> "Only one bit in the mask should be set with a frequency on 1 which 05.43.20 # <__builtin> * represents the thread's own base priority otherwise threads are waiting 05.43.20 # <__builtin> * on an abandoned object" 05.47.14 # <__builtin> no idea what that means, though :p 05.47.39 # I'm loading a 2MB stack wolf3d in there now to see 05.50.42 # 2mb stack still goes boom with duke3d 05.50.51 # but hey, that's a separate problem. 05.53.03 # pushed the threading fix. you might want to redo your sdl stack experiments. :) 05.56.11 *** Saving seen data "./dancer.seen" 06.00.13 # <__builtin> wait, why? 06.01.52 # because any value you used over 64K might not have done much of anything.. 06.02.49 # the stack size was being truncated to 16 bits before the target-specific threading code was called to set up the thread contexts 06.04.12 # <__builtin> I don't think native targets actually care about that 06.04.34 # <__builtin> yeah, stack_size isn't used in arm's thread.c 06.05.01 # but the stack pointer is 06.05.13 # it is comptued as base + truncated_size 06.08.15 # so you'd never actually use that extra space you asked for. I think the only reason it even worked is because ALIGN_BUFFER pushed the value so the lower 16 bits were mostly set. 06.08.26 # <__builtin> it looks to me as the stack pointer uses the untruncated size (as a size_t) 06.09.09 # <__builtin> but I can test anyway, that's a pretty big bug regardless 06.09.11 # thread->context.sp = (typeof (thread->context.sp))(stack + stack_size); 06.09.27 # <__builtin> yeah, stack_size is a size_t 06.10.09 # okay, you're right 06.10.25 # ... I shouldn't be trying to do this on this little sleep 06.10.33 # <__builtin> that might not be behind the intermittent quake crashes on ipod6g, then 06.12.07 Quit massiveH (Quit: Leaving) 06.12.36 # it doesn't seem like that thread->stack_size variable is actually used for much of anything 06.13.02 # <__builtin> I think it's only any good on hosted 06.13.24 # hosted win32 and unix threading, and in the stack overflow check in switch_thread 06.14.09 # <__builtin> quake still hangs on exit with the stack size fix 06.14.23 # and the latter only checks for nonzero 06.14.45 # <__builtin> rebuilding to see if it's the same cause as before (errant overwriting of pointer) 06.22.00 # <__builtin> ... yep 06.22.02 # <__builtin> exact same corruption 06.37.54 # looks like I introduced some red on the build page. I'll deal with that in the morning. 06.38.04 # g'nite 06.39.21 # * __builtin waves 06.45.18 # <__builtin> I should've fixed the ibassos with that 06.45.32 # <__builtin> if bluebot will work 06.45.36 # * __builtin slaps fs-bluebot 06.45.36 # __builtin: ouch! 07.24.37 Quit Loeb (Ping timeout: 256 seconds) 07.56.12 *** Saving seen data "./dancer.seen" 08.45.16 Quit MrZeus_ (Ping timeout: 250 seconds) 08.50.21 Join johnb2 [0] (~johnb2@p4FDBFF03.dip0.t-ipconnect.de) 09.15.46 Join sakax [0] (~r0b0t@unaffiliated/r0b0t) 09.21.33 Quit johnb2 (Read error: Connection reset by peer) 09.22.23 Join johnb2 [0] (~johnb2@p4FDBFF03.dip0.t-ipconnect.de) 09.56.15 *** Saving seen data "./dancer.seen" 09.57.39 Join mendel_munkis_ [0] (~mendelmun@65-128-208-151.mpls.qwest.net) 09.57.40 Quit mendelmunkis (Read error: Connection reset by peer) 10.13.08 Quit johnb2 (Read error: Connection reset by peer) 10.14.22 Join johnb2 [0] (~johnb2@p4FDBFF03.dip0.t-ipconnect.de) 10.17.05 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) 10.50.51 Join lebellium [0] (~lebellium@89-92-253-148.hfc.dyn.abo.bbox.fr) 11.05.13 Join prof_wolfff [0] (~prof_wolf@37.120.199.204) 11.29.30 Quit dys (Ping timeout: 265 seconds) 11.48.12 Join PimpiN8 [0] (~PimpiN8@178.239.173.228) 11.54.20 Quit johnb2 (Ping timeout: 256 seconds) 11.56.19 *** Saving seen data "./dancer.seen" 11.57.11 Join dys [0] (~dys@tmo-114-230.customers.d1-online.com) 11.57.44 Quit prof_wolfff (Ping timeout: 256 seconds) 11.59.56 Quit mendel_munkis_ (Ping timeout: 265 seconds) 12.02.18 Join mendelmunkis [0] (~mendelmun@65-128-208-151.mpls.qwest.net) 12.03.11 Join johnb2 [0] (~johnb2@p4FDBFF03.dip0.t-ipconnect.de) 12.04.56 Quit mendelmunkis (Read error: Connection reset by peer) 12.05.17 Join mendelmunkis [0] (~mendelmun@65-128-208-151.mpls.qwest.net) 12.06.08 Join MrZeus_ [0] (~MrZeus@79-65-237-109.host.pobb.as13285.net) 12.18.29 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 12.50.00 Quit johnb2 (Ping timeout: 264 seconds) 12.57.05 Quit pamaury (Ping timeout: 256 seconds) 13.25.40 Quit mendelmunkis (Ping timeout: 265 seconds) 13.38.18 Join johnb2 [0] (~johnb2@p4FDBFF03.dip0.t-ipconnect.de) 13.53.28 Join prof_wolfff [0] (~prof_wolf@33.red-88-26-67.staticip.rima-tde.net) 13.56.20 *** Saving seen data "./dancer.seen" 14.10.14 Quit S|h|a|w|n (Read error: Connection reset by peer) 14.11.42 Join mendelmunkis [0] (~mendelmun@65-128-208-151.mpls.qwest.net) 14.34.00 Quit johnb2 (Quit: Quit) 14.43.13 Quit PimpiN8 (Remote host closed the connection) 14.49.17 Quit mendelmunkis (Ping timeout: 265 seconds) 14.54.58 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 15.19.57 # sweet, just need to fix the iAudio M5 IRAM overflow (caused by the thread size_t fix). 15.27.52 # and the x3ii port+bootloader is confirmed goog. 15.27.54 # good. 15.33.45 Quit prof_wolfff (Ping timeout: 265 seconds) 15.56.24 *** Saving seen data "./dancer.seen" 16.04.43 Join krabador [0] (~krabador@unaffiliated/krabador) 16.39.13 # __builtin, I found a potential source of problems with the quake input code 16.39.17 # http://gerrit.rockbox.org/r/#/c/2324/3/apps/plugins/sdl/progs/quake/cl_input.c 16.39.35 # compiler spewed a pile of "ambiguous parethensis" warnings. 16.39.56 # the quake code is absolutely riddled with warnings; I've barely scratched the surface. 16.43.10 Quit blackyus17 (Ping timeout: 265 seconds) 16.43.26 Join mendelmunkis [0] (~mendelmun@65-128-208-151.mpls.qwest.net) 16.51.12 Join blackyus17 [0] (~blackyus1@ip189.ip-144-217-213.net) 16.58.17 # <__builtin> speachy: that wouldn't be causing undefined behavior, would it? 16.59.21 # if the compiler decides the else belongs to the first rather than the second if in each block, then it could unconditionally apply a value 17.01.13 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) 17.17.49 # <__builtin> Ah, that would explain the input weirdness, then 17.18.17 # <__builtin> I'll test on ipod6g when I get a chance 17.32.47 Quit krabador (Remote host closed the connection) 17.52.43 # tweaked that code to make it even more explicit, as those successive if()s are mutually exclusive. 17.56.25 *** Saving seen data "./dancer.seen" 17.58.42 Quit mendelmunkis (Remote host closed the connection) 17.59.00 Join mendelmunkis [0] (~mendelmun@65-128-208-151.mpls.qwest.net) 18.02.35 Quit michaelni (Read error: Connection reset by peer) 18.06.30 Quit Ckat (Quit: this shouldn't be happening) 18.06.45 Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g) 18.10.01 Quit mendelmunkis (Ping timeout: 260 seconds) 18.11.08 Quit pamaury (Ping timeout: 265 seconds) 18.19.17 Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) 18.19.18 Join mendelmunkis [0] (~mendelmun@65-128-208-151.mpls.qwest.net) 18.19.20 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) 18.19.50 Quit MrZeus_ (Ping timeout: 265 seconds) 18.20.37 Join MrZeus_ [0] (~MrZeus@79-65-237-109.host.pobb.as13285.net) 18.52.46 Join krabador [0] (~krabador@unaffiliated/krabador) 19.02.14 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 19.30.19 Quit krabador (Remote host closed the connection) 19.45.32 Quit pamaury (Ping timeout: 240 seconds) 19.56.29 *** Saving seen data "./dancer.seen" 20.05.39 Quit cockroach (Quit: leaving) 20.06.13 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 20.58.19 Join mendel_munkis_ [0] (~mendelmun@65-128-208-151.mpls.qwest.net) 21.00.32 Quit mendelmunkis (Ping timeout: 240 seconds) 21.01.54 Join krabador [0] (~krabador@unaffiliated/krabador) 21.25.46 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 21.38.23 Quit krabador (Remote host closed the connection) 21.47.39 Quit koniu (Quit: WeeChat 2.3) 21.56.31 *** Saving seen data "./dancer.seen" 22.27.20 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 22.30.52 Quit pamaury (Ping timeout: 265 seconds) 23.09.35 Quit lebellium (Quit: Leaving) 23.14.05 Join krabador [0] (~krabador@unaffiliated/krabador) 23.19.54 Join ac_laptop [0] (~ac_laptop@lfbn-cay-1-91-237.w92-142.abo.wanadoo.fr) 23.29.21 Quit ac_laptop (Ping timeout: 265 seconds) 23.30.43 Join ac_laptop [0] (~ac_laptop@2a01:cb20:8000:4e00:e29d:31ff:fe2d:a258) 23.34.29 Quit dys (Ping timeout: 265 seconds) 23.35.30 Quit ac_laptop (Ping timeout: 260 seconds) 23.36.13 Join ac_laptop [0] (~ac_laptop@2a01:cb20:8000:4e00:e29d:31ff:fe2d:a258) 23.41.23 Quit ac_laptop (Ping timeout: 272 seconds) 23.56.34 *** Saving seen data "./dancer.seen"