Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2020-04-05

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:00
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:08speachyoh sweet.
01:31:15speachy__builtin, looks like SDL stuff works on hosted MIPS targets. wolf3d hangs, but doom launches and runs fine.
01:31:20speachyno sound though.
01:32:17speachyah, 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__builtinDoom isn't sdl
01:50:17speachywhoops, spoke too soon, doom doesn't use SDL. no matter,
01:50:24__builtinHehe
01:50:25speachyjust barely beat me to it. :P
01:50:39speachytrying to make a dent in the compiler warnings that SDL generates
01:50:53__builtinAny chance you can get a pc for the sdl hang?
01:51:02__builtinI.e
01:51:18__builtinI.e. on arm you can hack the piezo to buzz it out
01:51:39speachywell, this is a hosted target, so it's linux under there.
01:52:35__builtinAh, gdb maybe?
01:52:58speachymaybe. It's a source-less android-ish mips environment
01:53:54speachycan probably cross-compile gdb with a lot of elbow grease
01:54:15__builtinOr you can go the old-fashioned route and sprinkle a bunch of splashf() or logf()s everywhere
01:54:43__builtinAnd then bisect to find the offending lines
01:54:51speachyyeah, that'll probably end up faster.
01:55:32__builtinIt's remarkable how well that works, really
01:56:04***Saving seen data "./dancer.seen"
01:56:14__builtinI really should have cleaned up the sdl tree a lot more than I did...
02:00
02:03:18speachytrying to clean up the really noisy warnings first.
02:06:02__builtinMost of the preprocessor ones are benign, I think
02:06:17speachyyeah.
02:06:32__builtinThough gcc is finicky about -Wno-* for some reason
02:07:04__builtinI remember investigating it when I first did the port, but I was more focused on making it work than anything else
02:08:45speachybut, for example, one I just fixed in SDL_Mixer was because of bad #include ordering
02:09:09speachycausing warnings about endianness ordering and stuff like that
02:09:39__builtinrbendian.h?
02:10:07speachyno.. 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__builtinI did write some docs which might be of use: https://www.rockbox.org/wiki/SdlPluginPort
02:14:14__builtinwould 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:13speachylet me get through this chunk and I will do..
02:22:50__builtinhopefully the MIPS misbehavior gives us some clue about the intermittent bugs on arm
02:27:38speachyg#2324
02:27:44fs-bluebotGerrit review #2324 at http://gerrit.rockbox.org/r/2324 : SDL: Silence a large number of compile warnings (WIP) by Solomon Peachy
02:27:54speachyit has everything but my ongoing changes to sdl.make
02:28:18speachyI've been selectively mucking with that to make the warning pile manageable
02:29:00__builtinthanks :)
02:31:22speachyokay, the reason the rocker target is blowing up so badly is it's stuck in a memory allocation failure loop
02:31:42speachyAGPTek thoughfully left strace in the filesystem
02:35:45__builtinit only has 6 MB of memory, right?
02:36:01__builtinquake *definitely* isn't running on that, and duke is also marginal
02:36:07speachy6MB allocated to the application, but that can be boosted a little.
02:36:14speachyI'm trying wolf3d
02:36:21__builtinhow much is there physically?
02:36:27speachy32
02:36:46__builtinif we can wrangle about 16 from the kernel we should be good
02:36:50speachyonly 26.5 available to the OS...
02:37:21__builtinI vaguely recall quake needing about 10-12 MB of heap
02:37:34speachythere's about 8.5 on top of that 6MB we can get
02:37:42speachybut that leaves no room for caches.
02:37:51__builtinvia sbrk or similar?
02:37:55speachyI'll bump it to 10mb.
02:38:22speachyIIRC we still use our internal malloc from a maximally-allocated heap on hosted targets
02:38:48speachyrebuilding the world now
02:38:50__builtinbuflib, you mean?
02:40:01speachybasically strace is shoing that, during the wolf3d launch hang..
02:40:26speachyrt_sigprocmask(SIG_BLOCK, [USR1], [USR1], 16) = 0
02:40:28speachyrt_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:30speachyy
02:40:34speachythis in a tight loop
02:40:52speachysigaltstack({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__builtinaha!
02:41:01speachyall three, looped
02:41:05__builtinI know what it is
02:41:14speachyoh?
02:41:25__builtinyeah, I ran into that when building for the simulator
02:41:31__builtinyou need to pass −−sdl-threads to tools/configure
02:41:55speachygotcha
02:41:57speachygive me a sec
02:42:22__builtinsee 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__builtinis the application build running on SDL?
02:43:45speachywell, the hosted target is already configured to use SIGALSTACK_THREADS
02:44:03speachythe application is native framebuffer etc.
02:45:02__builtinI never bothered to diagnose *why* sigaltstack threads were breaking
02:47:46speachyso what we probably want is to, on hosted targets, tell SDL to use its own native threading.
02:48:56__builtinso do we actually link with SDL for the agptek build?
02:49:04speachyno
02:49:59speachyI mean we're building SDL within rockbox's confines, including mapping SDL_Thread -> rbthread
02:50:34speachywe could just have SDL_Thread just compile to native linux threading.
02:50:57__builtinah, I understand
02:51:38__builtinthat's still a bit of a kludge, and I'd like to get at the root of the problem
02:51:43speachysince when the sdl plugins are running, rockbox is effectively paused anyway.
02:52:19__builtinin what context are the sigaltstack errors occuring?
02:52:27 Quit atsampson (Ping timeout: 272 seconds)
02:53:07__builtinis it quake/wolf starting its SDL_audio thread?
02:53:31speachydon't know. the rockbox background is still showing.
02:54:03__builtincan you pastebin the full strace dump?
02:54:59speachythere's not a lot there
02:55:10speachyhttp://www.shaftnet.org/~pizza/dump.txt
02:55:39__builtinthat's 404ing
02:55:50speachyif I had to guess this happens before (or due to) the first SDL thread that's started
02:56:10speachywhoops, try again. forgot to save/create the file
02:56:17__builtinI should mention that there's really several threads in play here
02:56:32__builtinthe main SDL application runs in a newly created rockbox thread (so it can have a larger stack)
02:57:21__builtinthat 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__builtinhmm, it definitely looks to me that it's failing in the initial thread creatoin
03:00
03:00:10__builtinapps/plugins/sdl/main.c:227
03:00:32speachy...thread_unix:121
03:02:18speachyThe specified size of the new alternate signal stack ss.ss_size was less than MINSIGSTKSZ
03:03:14speachyand there it is.
03:03:20speachymain.c:76
03:03:43__builtinyeah, I've got it hardcoded to a megabyte
03:03:44speachyfixed at 512K
03:04:11__builtinerr, I'm working with a dirty tree
03:05:25__builtinthat's 2MB, isn't it?
03:05:33__builtinlong main_stack[1024 * 1024 / 2];
03:05:42speachywaiy, you're right.
03:05:47speachyd'oh.
03:06:10__builtinthat was determined completely empirically, btw
03:06:14*speachy really doesn't like raw buffers not specified in bytes.
03:06:45speachyI'm chainging that definition to be the smaller of 2MB or DEFAULT_STACK_SIZE
03:06:57__builtinit needs to be pretty big, actually
03:07:11__builtinquake and duke will quickly crash with DEFAULT_STACK_SIZE
03:07:42speachyon hosted platforms, DEFAULT_STACK_SIZE is defined as MINSIGSTKSZ + 12K
03:08:14__builtinwhat's MINSIGSTKSZ then?
03:08:35speachynot sure.
03:10:05__builtinon ARM, DEFAULT_STACK_SIZE is only 1KB
03:10:26__builtinand there's no way quake is running with that little
03:11:46speachyI think the problem is that rockbox's context->stack_size is being set to 0
03:12:06speachyand 0 is WAY too low. :)
03:12:30__builtinheh
03:12:33__builtinno 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:35speachyI think..
03:16:53speachy..might have found it.
03:17:34__builtinaha, got it too
03:17:39__builtinALIGN_BUFFER?
03:17:44speachyno..
03:18:14__builtinfirmware/export/system.h:135: (size) = __a2 > __a1 ? __a2 - __a1 : 0; \
03:19:34speachyyou're a bit ahead of me :)
03:19:45__builtinthat macro is being used to initialize the stack size that's eventually going to sigaltstack
03:20:06__builtinsee firmware/kernel/thread.c:351
03:20:18speachyyeah, I see that
03:21:38speachybut that shouldn't kick in unless we're overflowing
03:22:13 Quit atsampson (Ping timeout: 272 seconds)
03:22:51__builtinmaybe throw in a panic to rule that out?
03:25:18 Join atsampson [0] (~ats@cartman.offog.org)
03:30:21speachyokay, re-deploying..
03:35:17speachyno good. adding in another test.
03:37:05__builtinMaybe add a couple panics to check that the size is nonzero?
03:37:18speachyI'm adding more panics
03:37:30speachydidn't panic before or after tha ALIGN_BUFFER call
03:37:43__builtinAlso it might be good to check that panic actually works
03:40:32speachyit works.
03:40:38speachyaccidently put it in the wrong place
03:49:45__builtinSo was it ALIGN_BUFFER?
03:50:36speachyno
03:52:30speachytripped over the panic I put in thread-unix.c:make_context()
03:54:58speachyadding more in a few other key places
03:56:07***Saving seen data "./dancer.seen"
04:00
04:02:31 Quit cockroach (Quit: leaving)
04:05:40speachyah, I think I found it
04:05:44speachy...
04:05:52speachyit is ALIGN_BUFFER
04:07:10__builtin:)
04:07:23speachyI take that back.
04:07:25__builtinoverflow?
04:09:34speachyit 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__builtinhmm...
04:10:32__builtinso the issue is in thread->stack_size = *stack_sizep;?
04:10:44speachyso it appears. doing another run.
04:10:54__builtinhuh
04:10:56speachytakes longer to unzip the rockbox.zip than it does to compile it
04:11:22__builtinthat's a good problem to have!
04:22:52speachynow I'm crashig on startup
04:29:10__builtinon boot or plugin start?
04:29:31speachyboot
04:30:12__builtinis it one of your panics?
04:30:27speachyprobably but it's prior to any of the output.
04:30:43speachyI mean before the bootloader screen is painted over
04:30:49__builtinah
04:30:56__builtinsounds like some early boot problem
04:31:15__builtinis it just freezing or do you get a trace?
04:31:19speachyfreezing
04:38:59speachytwo steps forward, three steps back
04:39:33__builtinare your panics on !stack_size?
04:39:57__builtin("on" as in "taking place in case of")
04:49:03speachywell, that's a new one
04:49:18speachysegfault at startup..
04:49:51__builtinalways a fun time shaking the old kernel tree :)
04:53:13speachyI think what's happening is that the sanity checks I keep putting in are getting tripped by the early startup code
04:55:52__builtinhere's a hack: put in a flag (just a global int) to switch the panics on/off
04:56:04__builtinand set that flag once boot finishes
05:00
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:57speachyyep, definitely ALIGN_BUFFER.
05:12:14speachyif I put in my panic after it, I fail to boot.
05:12:23speachydamnit
05:12:30speachyleft the debug flag out of that test.
05:12:33speachysigh
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:44speachyokay, it's definietely thread->stack_size = *stack_sizep
05:21:06speachy*stack_sizep is nonzero but post-assignment, thread->stack_size is zero.
05:21:56speachycrap!
05:21:58speachyfound it.
05:22:04speachy unsigned short stack_size; /* Size of stack in bytes */
05:22:19speachychanged that to size_t
05:22:37speachythat would explain a _lot_ of SDL funkiness.
05:23:23__builtinshit...
05:23:31speachythis is an _old_ bug.
05:23:35__builtinyep
05:23:53__builtinI think we've reached the bottom of the rabbit hole :)
05:24:36__builtinyeah, it looks like create_thread expects a size_t for stack size, so that's definitely a bug
05:24:49speachyI'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:43speachygodo news, wolf3d launches, then eventually blows up due to not being able to allocate wave buffer
05:25:55__builtinprogress :)
05:26:05speachytime to unwind all of this insane debug code.
05:27:01__builtinah, that's the code that resamples all the wolf sounds
05:28:00__builtincould you just bump memorysize?
05:28:22speachyone thing at a time. :D
05:33:18speachyrebooting with the de-debuggified code..
05:35:28speachyrebuilding with 10MB memsize and 1MB SDL stack, for giggles.
05:37:50speachythe thread fix isg#2326
05:37:52fs-bluebotGerrit 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:02speachywolf is running
05:39:33__builtinyay!
05:39:34__builtinsound works?
05:40:16__builtinand how about duke/quake?
05:40:28speachyyes. music
05:41:05speachyand digitized too
05:41:13speachyit's kinda scratchy and choppy
05:41:28__builtinit's probably not realtime then
05:41:40speachyduke3d
05:42:02speachyworks music and sound.
05:42:11__builtinthat's a big win, actually :)
05:42:16speachyand paniced when starting the game.
05:42:22speachymight be due to my shrinking the stack
05:42:33speachyabandon 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__builtinno idea what that means, though :p
05:47:39speachyI'm loading a 2MB stack wolf3d in there now to see
05:50:42speachy2mb stack still goes boom with duke3d
05:50:51speachybut hey, that's a separate problem.
05:53:03speachypushed the threading fix. you might want to redo your sdl stack experiments. :)
05:56:11***Saving seen data "./dancer.seen"
06:00
06:00:13__builtinwait, why?
06:01:52speachybecause any value you used over 64K might not have done much of anything..
06:02:49speachythe 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__builtinI don't think native targets actually care about that
06:04:34__builtinyeah, stack_size isn't used in arm's thread.c
06:05:01speachybut the stack pointer is
06:05:13speachyit is comptued as base + truncated_size
06:08:15speachyso 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__builtinit looks to me as the stack pointer uses the untruncated size (as a size_t)
06:09:09__builtinbut I can test anyway, that's a pretty big bug regardless
06:09:11speachythread->context.sp = (typeof (thread->context.sp))(stack + stack_size);
06:09:27__builtinyeah, stack_size is a size_t
06:10:09speachyokay, you're right
06:10:25speachy... I shouldn't be trying to do this on this little sleep
06:10:33__builtinthat might not be behind the intermittent quake crashes on ipod6g, then
06:12:07 Quit massiveH (Quit: Leaving)
06:12:36speachyit doesn't seem like that thread->stack_size variable is actually used for much of anything
06:13:02__builtinI think it's only any good on hosted
06:13:24speachyhosted win32 and unix threading, and in the stack overflow check in switch_thread
06:14:09__builtinquake still hangs on exit with the stack size fix
06:14:23speachyand the latter only checks for nonzero
06:14:45__builtinrebuilding to see if it's the same cause as before (errant overwriting of pointer)
06:22:00__builtin... yep
06:22:02__builtinexact same corruption
06:37:54speachylooks like I introduced some red on the build page. I'll deal with that in the morning.
06:38:04speachyg'nite
06:39:21*__builtin waves
06:45:18__builtinI should've fixed the ibassos with that
06:45:32__builtinif bluebot will work
06:45:36*__builtin slaps fs-bluebot
06:45:36fs-bluebot__builtin: ouch!
07:00
07:24:37 Quit Loeb (Ping timeout: 256 seconds)
07:56:12***Saving seen data "./dancer.seen"
08:00
08:45:16 Quit MrZeus_ (Ping timeout: 250 seconds)
08:50:21 Join johnb2 [0] (~johnb2@p4FDBFF03.dip0.t-ipconnect.de)
09:00
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:00
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:00
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:00
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:00
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:00
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:00
15:19:57speachysweet, just need to fix the iAudio M5 IRAM overflow (caused by the thread size_t fix).
15:27:52speachyand the x3ii port+bootloader is confirmed goog.
15:27:54speachygood.
15:33:45 Quit prof_wolfff (Ping timeout: 265 seconds)
15:56:24***Saving seen data "./dancer.seen"
16:00
16:04:43 Join krabador [0] (~krabador@unaffiliated/krabador)
16:39:13speachy__builtin, I found a potential source of problems with the quake input code
16:39:17speachyhttp://gerrit.rockbox.org/r/#/c/2324/3/apps/plugins/sdl/progs/quake/cl_input.c
16:39:35speachycompiler spewed a pile of "ambiguous parethensis" warnings.
16:39:56speachythe 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__builtinspeachy: that wouldn't be causing undefined behavior, would it?
16:59:21speachyif 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:00
17:01:13 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
17:17:49__builtinAh, that would explain the input weirdness, then
17:18:17__builtinI'll test on ipod6g when I get a chance
17:32:47 Quit krabador (Remote host closed the connection)
17:52:43speachytweaked 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:00
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:00
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:00
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
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:00
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:00
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"

Previous day | Next day