| 00:00:04 | federico3 | PMunch: have you red the original Reflections on trusting trust? The point is not about developing paranoia but encouraging healty security practices around traceability and avoiding unnecessary risks |
| 00:00:47 | Araq | I wonder if you guys actually read the article. You cannot read the source code, because the attack is not in the source code anymore. |
| 00:01:30 | Araq | what you can do is to develop your own disassembler and use it to look at the compiler binary |
| 00:01:45 | PMunch | Of course it is (haven't read it unfortunately, link appreciated) but you still can't bar these things, not like anyone has a clean sheet when it comes to this... |
| 00:01:58 | Araq | that's lots of work because the compiler is a large program. |
| 00:03:06 | PMunch | Araq, I read the article (the Rust one, not the one federico3 mentioned). The problem is that compilers in general are vulnerable to these kinds of attack. |
| 00:03:46 | federico3 | PMunch: http://dl.acm.org/citation.cfm?id=358210 |
| 00:04:08 | PMunch | Sneak something into GCC, TinyCC, VCC etc. and suddenly you can put backdoors in anything, even the most scrutinized source code. |
| 00:04:23 | federico3 | PMunch: also some thoughs are on the famous c2 wiki http://wiki.c2.com/?TheKenThompsonHack |
| 00:04:27 | Guest94556 | good night! |
| 00:04:32 | * | Guest94556 is now known as wuehlmaus |
| 00:04:39 | PMunch | Thanks federico3 |
| 00:05:14 | PMunch | I'll read it once I'm back at my university and have access to ACM stuff |
| 00:07:15 | PMunch | You don't even have to have your sources looked at. One bad redirect from a site like Sourceforge and your compiler is out there making more bad compilers |
| 00:08:53 | PMunch | In fact it all boils down to open source people basically having to trust something which should be considered closed source. |
| 00:08:57 | * | yglukhov_ quit (Remote host closed the connection) |
| 00:09:36 | PMunch | If your already in a closed source environment you already need to have these trusts in place |
| 00:10:07 | PMunch | After all there is nothing stopping a closed source file manager to change a recognized inary for something else |
| 00:10:20 | PMunch | s/inary/binary |
| 00:10:37 | PMunch | Or any other program for that matter |
| 00:11:47 | PMunch | Not saying that it has happened, or even ever will happen, just saying that it's theoretically possible |
| 00:12:31 | federico3 | PMunch: not happened to have one process infecting another one? It happens all the time :-/ |
| 00:12:36 | PMunch | And I'll stop spamming the Nim channel now, after all this is hardly related to anything Nim specific |
| 00:13:57 | PMunch | federico3, I meant not having a closed source program that is generally trusted (think OS stuff like explorer.exe) modifying open source binaries to apply backdoors to open source stuff |
| 00:14:29 | federico3 | PMunch: #nim-offtopic :) |
| 00:31:29 | * | PMunch quit (Quit: leaving) |
| 00:32:45 | * | yglukhov joined #nim |
| 00:38:19 | Varriount|Mobile | http://wiki.c2.com/?HyperBug |
| 00:40:37 | * | yglukhov quit (Ping timeout: 248 seconds) |
| 00:42:18 | * | byte512 quit (Ping timeout: 246 seconds) |
| 00:52:22 | Varriount|Mobile | Araq: So what's currently in the works? |
| 01:11:31 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 01:19:18 | * | yglukhov joined #nim |
| 01:20:00 | Araq | "'I've never been able to understand why simply doing some programmatic transformation of your compiler first isn't considered a good defense. Basically just obfuscating the code. For such a backdoor to work the injection point needs to be recognized by the injector. So if one ... Started with a corrupted compiler and then obfuscated it's source. Then compiled the obfuscated but "clean" source with the corrupted compiler. One should end up with a clean |
| 01:20:00 | Araq | and uncorrupted compiler." |
| 01:20:15 | Araq | -- finally somebody who gets it :P |
| 01:23:36 | * | yglukhov quit (Ping timeout: 246 seconds) |
| 01:26:37 | * | rynsin joined #nim |
| 01:34:39 | * | krux02 joined #nim |
| 01:50:51 | * | vlad1777d quit (Remote host closed the connection) |
| 02:21:25 | * | yglukhov joined #nim |
| 02:25:39 | * | yglukhov quit (Ping timeout: 244 seconds) |
| 02:31:21 | * | rynsin quit (Quit: rynsin) |
| 02:40:04 | * | arnetheduck quit (Remote host closed the connection) |
| 02:41:36 | * | arnetheduck joined #nim |
| 02:59:46 | * | chemist69 quit (Ping timeout: 250 seconds) |
| 03:02:31 | * | yglukhov joined #nim |
| 03:06:43 | * | yglukhov quit (Ping timeout: 245 seconds) |
| 03:09:08 | * | bjz joined #nim |
| 03:10:39 | * | bjz_ quit (Ping timeout: 260 seconds) |
| 03:13:48 | * | chemist69 joined #nim |
| 03:44:55 | * | yglukhov joined #nim |
| 03:49:43 | * | yglukhov quit (Ping timeout: 268 seconds) |
| 04:00:57 | * | arnetheduck quit (Ping timeout: 240 seconds) |
| 04:04:37 | * | krux02 quit (Quit: Leaving) |
| 04:07:50 | * | dddddd quit (Remote host closed the connection) |
| 04:27:32 | * | yglukhov joined #nim |
| 04:29:51 | ftsf | does nim have a tmpfile or mk(s)temp equivalent? |
| 04:31:24 | * | kunev quit (Ping timeout: 256 seconds) |
| 04:32:23 | * | yglukhov quit (Ping timeout: 265 seconds) |
| 04:33:44 | * | kunev joined #nim |
| 04:35:24 | * | [CBR]Unspoken quit (Ping timeout: 246 seconds) |
| 04:37:30 | * | [CBR]Unspoken joined #nim |
| 04:42:41 | ftsf | hmm there's mkstemp in posix.nim, but it returns a cint, how can i turn a cint into a File? |
| 05:00:57 | * | chemist69 quit (Ping timeout: 246 seconds) |
| 05:03:30 | * | chemist69 joined #nim |
| 05:10:07 | * | yglukhov joined #nim |
| 05:14:52 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 05:19:44 | * | couven92 quit (Read error: Connection reset by peer) |
| 05:27:35 | * | [ui] joined #nim |
| 05:34:44 | * | wuehlmaus quit (Ping timeout: 265 seconds) |
| 05:49:46 | * | wuehlmaus joined #nim |
| 05:50:08 | * | wuehlmaus is now known as Guest47601 |
| 05:52:43 | * | yglukhov joined #nim |
| 05:57:11 | * | yglukhov quit (Ping timeout: 258 seconds) |
| 06:13:41 | * | yglukhov joined #nim |
| 06:18:09 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 06:22:49 | * | brson joined #nim |
| 06:23:16 | * | brson quit (Client Quit) |
| 06:53:14 | * | ftsf quit (Quit: Leaving) |
| 06:56:24 | * | yglukhov joined #nim |
| 07:00:37 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 07:01:42 | * | space-wizard quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 07:16:52 | * | space-wizard joined #nim |
| 07:16:52 | * | space-wizard quit (Client Quit) |
| 07:38:39 | * | yglukhov joined #nim |
| 07:39:16 | * | MightyJoe joined #nim |
| 07:39:37 | * | cyraxjoe quit (Ping timeout: 240 seconds) |
| 07:42:56 | * | yglukhov quit (Ping timeout: 256 seconds) |
| 07:46:09 | * | rokups joined #nim |
| 07:58:15 | * | yglukhov joined #nim |
| 08:14:57 | * | Trustable joined #nim |
| 08:16:22 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 08:18:00 | * | bjz joined #nim |
| 08:26:51 | * | yglukhov quit (Remote host closed the connection) |
| 08:34:21 | * | yglukhov joined #nim |
| 08:40:14 | * | yglukhov quit (Remote host closed the connection) |
| 08:49:15 | * | yglukhov joined #nim |
| 08:53:04 | Araq | ok, got significantly better timings here |
| 08:53:14 | Araq | will write about it soonish |
| 08:54:26 | dom96 | Awesome |
| 08:55:02 | dom96 | Unfortunately I doubt Pusher will adopt Nim. The reason for their choice was the existence of a certain library in the Go ecosystem. |
| 08:57:14 | dom96 | Some interesting discussion on HN about this too: https://news.ycombinator.com/item?id=13086059 |
| 09:00:18 | * | Trustable quit (Remote host closed the connection) |
| 09:04:08 | * | Matthias247 joined #nim |
| 09:06:18 | * | [ui] quit (Quit: Connection closed for inactivity) |
| 09:07:37 | * | yglukhov quit (Remote host closed the connection) |
| 09:15:13 | * | yglukhov joined #nim |
| 09:16:11 | yglukhov | Is there any way to work with processes in async manner? E.g. read from pipe with timeout? or peek from pipe? |
| 09:23:49 | yglukhov | dom96, Araq: also are there any plans on reworking streams to make them more feature rich? |
| 10:11:05 | * | themagician joined #nim |
| 10:11:30 | Guest47601 | how mature is async, i think, that is the question |
| 10:11:37 | * | Guest47601 is now known as wuehlmaus |
| 10:20:14 | * | byte512 joined #nim |
| 10:57:27 | Araq | yglukhov: cheatfate has async processes in the works |
| 11:00:57 | * | chemist69 quit (Ping timeout: 260 seconds) |
| 11:03:29 | * | chemist69 joined #nim |
| 11:05:54 | Araq | dom96: http://forum.nim-lang.org/t/2646/1#16351 |
| 11:07:32 | dom96 | lol, I think this shows that these benchmarks are mostly meaningless, it's just a case of spending the time optimising these things to death |
| 11:08:41 | * | kier quit (Quit: No Ping reply in 180 seconds.) |
| 11:10:15 | Araq | I didn't optimize anything. |
| 11:10:24 | Araq | just used different GC API calls |
| 11:10:39 | Araq | with GC_disable() we restrict the GC too much |
| 11:10:46 | Araq | when it handles its ZCT |
| 11:12:01 | Araq | this is an interesting result. :P |
| 11:12:51 | Araq | GC_setMaxPause(...) is the better API for this program. |
| 11:13:49 | dom96 | You don't call adding 'shallowCopy' optimisation? |
| 11:13:59 | * | kier joined #nim |
| 11:14:10 | dom96 | what about warming up Nim's memory allocator? |
| 11:14:55 | Araq | shallowCopy was in my first version already |
| 11:15:16 | Araq | the original used 'ref array' which doesn't need it. |
| 11:15:30 | Araq | I only removed your pessimization. |
| 11:15:56 | Araq | warming up Nim's allocator is an interesting observation that should *lead* to an optimization in Nim's runtime |
| 11:16:24 | Araq | benefitting every Nim program that deals with large-ish quantities of memory |
| 11:17:19 | dom96 | My point is that this is no longer an idiomatic test |
| 11:17:51 | dom96 | Well, it is, but what I mean is that it's not something someone would write initially. |
| 11:17:59 | dom96 | Whether that matters or not I don't know |
| 11:18:15 | dom96 | But surely the designer of Go will be able to optimise that benchmark too. |
| 11:20:45 | Araq | sure, and he will get it from 10ms down to 0.3ms in roughly 2 hours of work. |
| 11:20:47 | dom96 | Perhaps what we should be measuring is how easy these optimisations are, but doing so is difficult. |
| 11:22:42 | * | nsf joined #nim |
| 11:22:46 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 11:23:55 | Araq | 1. we beat Go by a wide margin without sweating. |
| 11:24:13 | Araq | 2. we then used the benchmark to see where we can improve further. |
| 11:25:38 | Araq | 3. warm ups are annoying, but commonly done for benchmarking all kinds of systems. |
| 11:26:13 | Araq | 4. in a server setup you can assume the warm up happened. |
| 11:26:41 | Araq | 5. I haven't touched the GC to obtain these results. |
| 11:26:58 | Araq | but ok, I'm not playing fair, got it. |
| 11:31:17 | dom96 | nah, i'm glad you improved it |
| 11:31:40 | dom96 | Like you said, it didn't take long to optimise |
| 11:31:44 | * | space-wizard joined #nim |
| 11:33:02 | * | space-wizard quit (Client Quit) |
| 11:33:33 | dom96 | I'm getting a maximum of 0.9ms btw |
| 11:37:29 | Araq | is your machine plugged? |
| 11:39:16 | * | vlad1777d joined #nim |
| 11:43:40 | * | elrood joined #nim |
| 11:43:45 | jh32 | hi |
| 11:45:17 | jh32 | i think the linux version of waitForExit() with timeout has a problem |
| 11:45:56 | jh32 | after blocking the signals it needs to check if the process already died before waiting for SIGCHLD |
| 11:46:35 | jh32 | i'll try to come up with a fix but this stuff is rather tricky :-) |
| 11:47:34 | jh32 | the kqueue based version for *bsd is much nicer |
| 11:49:34 | * | jh32 quit (Remote host closed the connection) |
| 11:53:53 | * | jh32 joined #nim |
| 12:07:48 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 12:12:56 | * | nsf quit (Quit: WeeChat 1.6) |
| 12:22:18 | jh32 | oh, running() has a problem. if waitpid() returns the pid of the process and it actually exited it returns true - which is false |
| 12:23:48 | jh32 | i wonder why this isn't causing a lot of problems, am i missing something? |
| 12:25:48 | * | jh32 quit (Remote host closed the connection) |
| 12:28:38 | * | jh32 joined #nim |
| 12:33:50 | jh32 | probabely it is mostly called in a loop and the next call then catches it |
| 13:33:18 | cheatfate | jh32, nobody used it yet... |
| 13:35:25 | * | Sentreen quit (Quit: WeeChat 1.4) |
| 13:37:52 | * | Sentreen joined #nim |
| 13:44:04 | * | vlad1777d quit (Remote host closed the connection) |
| 13:47:17 | * | vlad1777d joined #nim |
| 13:56:20 | * | brechtm joined #nim |
| 14:02:10 | Araq | what? running is used by the tester itself iirc |
| 14:04:50 | jh32 | i pushed a fix and test case to my posix_running branch |
| 14:05:10 | dom96 | indeed, running() is used widely |
| 14:05:49 | cheatfate | i'm not about running, im about waitForExit with timeout value |
| 14:06:39 | * | brechtm quit (Remote host closed the connection) |
| 14:08:38 | corecode | hi |
| 14:08:54 | cheatfate | poor osproc.nim, every time somebody comes with very rare OS it got modifications not supported by other rare OSes :) |
| 14:10:14 | jh32 | true :-), but the waitForExit() thing is on linux, *bsd is fine because it uses kqueue |
| 14:14:23 | cheatfate | jh32, how you propose to modify linux version? |
| 14:15:47 | * | nsf joined #nim |
| 14:15:52 | jh32 | i plan to call running() before actually waiting for sigchld - that's why i hit the running() bug |
| 14:17:23 | jh32 | i'll make a PR once it works for me |
| 14:18:58 | cheatfate | jh32, so you will call for waitpid before sigblock or after sigblock? |
| 14:19:37 | * | chemist69 quit (Ping timeout: 240 seconds) |
| 14:19:52 | jh32 | after sigblock but before sigwait |
| 14:20:49 | cheatfate | i think waitpid becomes useless after sigblock |
| 14:21:35 | jh32 | ah, but we need some check after sigblock otherwise there is a race |
| 14:23:18 | cheatfate | i dont think we can fix this |
| 14:23:32 | cheatfate | its better to remove waitPid with timeout |
| 14:23:55 | cheatfate | signals must be blocked before fork/clone |
| 14:24:03 | cheatfate | so there will be no race |
| 14:25:21 | jh32 | are you sure waitpid() with WNOHANG can't be called after sigblock()? |
| 14:26:03 | jh32 | it seems to work for me |
| 14:26:08 | cheatfate | i'm not sure and have not tested it |
| 14:26:32 | cheatfate | so you have example with race? |
| 14:26:55 | jh32 | yes, i have a testcase |
| 14:27:41 | jh32 | i'll push it to a branch, but i need some minutes |
| 14:29:00 | jh32 | basically call waitForExit with timeout on a process that already died |
| 14:29:19 | jh32 | it will then hang until the timeout expires |
| 14:34:27 | * | azur_kind joined #nim |
| 14:34:44 | * | arnetheduck joined #nim |
| 14:42:49 | * | libman joined #nim |
| 14:46:41 | * | chemist69 joined #nim |
| 14:50:25 | Varriount|Mobile | Trouble with signals? |
| 14:51:19 | libman | Hope someone posts some competitive Go-vs-Nim GC numbers / graphs on http://forum.nim-lang.org/t/2646 for my social media Nim advocacy. ;) |
| 15:07:19 | elrood | hope you include some throughput-vs-latency aspects and point out there are tradeoff decisions in gc implementations, otherwise any advocacy is pretty much moot and may even be detrimental |
| 15:35:10 | * | couven92 joined #nim |
| 15:43:43 | * | Matthias247 joined #nim |
| 15:45:07 | * | nsf quit (Quit: WeeChat 1.6) |
| 15:46:39 | jh32 | cheatfate: https://github.com/jfhg/Nim/tree/posix_process_handling has a test case and proposed fix |
| 15:48:34 | * | arnetheduck quit (Ping timeout: 265 seconds) |
| 16:14:22 | * | saml_ joined #nim |
| 16:15:08 | * | azur_kind quit (Remote host closed the connection) |
| 16:22:45 | * | chemist69 quit (Ping timeout: 250 seconds) |
| 16:25:15 | * | chemist69 joined #nim |
| 16:27:10 | * | [ui] joined #nim |
| 16:51:17 | * | vlad1777d_ joined #nim |
| 16:52:17 | * | vlad1777d quit (Ping timeout: 240 seconds) |
| 17:08:34 | * | PMunch joined #nim |
| 17:48:17 | * | vlad1777d__ joined #nim |
| 17:49:02 | * | vlad1777d_ quit (Ping timeout: 258 seconds) |
| 17:54:06 | * | PMunch quit (Ping timeout: 244 seconds) |
| 18:29:27 | * | chemist69 quit (Ping timeout: 246 seconds) |
| 18:32:00 | * | chemist69 joined #nim |
| 18:33:20 | * | abeaumont quit (Ping timeout: 250 seconds) |
| 18:36:17 | * | [ui] quit (Quit: Connection closed for inactivity) |
| 18:36:28 | * | nsf joined #nim |
| 18:43:17 | * | rokups quit (Quit: Connection closed for inactivity) |
| 19:02:03 | * | brechtm joined #nim |
| 19:07:53 | cheatfate | jh32, i dont like it |
| 19:09:26 | cheatfate | 1. your test uses os.sleep(1000) on VMs this is not working, so your test will fail all the time |
| 19:10:06 | cheatfate | 2. you cleared most of code which checks for specific SIGCHILD, what happens if you are running for 5 processes and you need to wait for particular? |
| 19:10:21 | cheatfate | 3. your test also not spawning more processes to check 2. |
| 19:15:07 | * | nsf quit (Quit: WeeChat 1.6) |
| 19:21:56 | * | Trustable joined #nim |
| 19:31:19 | jh32 | cheatfate: any idea what to use instead of sleep for 1. ? |
| 19:32:38 | jh32 | cheatfate: regarding 2. the idea is that it breaks out of sigwait (as it did before, running() see's it still running, it adjusts the timeout and waits again |
| 19:32:57 | jh32 | cheatfate: 3. is certainly a good idea |
| 19:41:53 | Varriount|Mobile | So what's the problem you two are working on? |
| 19:49:40 | jh32 | Varriount|Mobile: waitForExit() with timeout on linux when process exited before starting to wait |
| 19:50:19 | * | Jesin joined #nim |
| 19:50:28 | Varriount|Mobile | jh32: have you looked at what implementations in other languages do? |
| 19:51:39 | jh32 | i looked at how make is handling subprocesses |
| 19:52:16 | * | Jesin quit (Client Quit) |
| 19:55:50 | * | dddddd joined #nim |
| 19:56:28 | jh32 | i have no problem at all if you decide not to merge it, but i would also be happy to improve my fix based on your feedback |
| 20:01:29 | * | Jesin joined #nim |
| 20:14:04 | * | djellemah_ joined #nim |
| 20:30:57 | dyce[m] | Out of curiosity which functional programming language complements Nim / do Nim programmers prefer? |
| 20:32:29 | * | PMunch joined #nim |
| 20:33:05 | vktec | dyce[m]: What's wrong with Nim? |
| 20:33:12 | vktec | Nim can do functional programming |
| 20:36:21 | * | PMunch quit (Read error: Connection reset by peer) |
| 20:39:28 | * | PMunch joined #nim |
| 20:39:35 | cheatfate | i have no idea how to help you with os.sleep() but i have already troubles with timeouts on CI |
| 20:40:00 | cheatfate | jh32, you removed checks of SIGCHILD |
| 20:40:04 | cheatfate | pid |
| 20:40:24 | cheatfate | so if program not waiting for particular pid we just need to miss it |
| 20:40:28 | * | tinAndi joined #nim |
| 20:46:04 | dyce[m] | vktec nothing, but I am interested in learning a functional language to expand my knowledge |
| 20:46:20 | jh32 | cheatfate: i removed the explicit SIGCHILD case because the handling turned out to be the same as for e.g. EINTR - check if process is still running, adapt timeout and then wait again |
| 20:46:31 | vktec | dyce[m]: I like Lisp, so Scheme or Clojure perhaps? |
| 20:46:59 | jh32 | maybe i should try to make the change a little less invasive |
| 20:48:21 | * | djellemah_ quit (Quit: Leaving) |
| 20:49:17 | * | Jesin quit (Quit: Leaving) |
| 20:58:46 | * | wuehlmaus quit (Quit: Lost terminal) |
| 21:07:01 | Varriount|Mobile | dyce[m]: If you're looking for a purely functional language, you could try Haskell |
| 21:08:22 | Varriount|Mobile | Nim has functional-programming constructs such as lambdas/closures, object variants, and side-effect taking |
| 21:08:29 | Varriount|Mobile | *tracking |
| 21:08:34 | * | PMunch quit (Quit: leaving) |
| 21:11:50 | dom96 | dyce[m]: Scala is somewhat similar to Nim |
| 21:13:13 | * | chemist69 quit (Ping timeout: 260 seconds) |
| 21:15:05 | dyce[m] | I'll take a look at those |
| 21:15:12 | dyce[m] | Thanks |
| 21:17:08 | * | jh32 quit (Ping timeout: 260 seconds) |
| 21:17:53 | * | chemist69 joined #nim |
| 21:38:36 | * | tinAndi quit (Quit: ChatZilla 0.9.93 [Firefox 50.0.2/20161129173726]) |
| 21:39:23 | * | jh32 joined #nim |
| 21:40:56 | * | nsf joined #nim |
| 21:54:15 | dom96 | Araq: https://twitter.com/brianhatfield/status/804355831080751104 |
| 21:54:25 | dom96 | Can we do that? :) |
| 21:54:39 | dom96 | (Discussion on HN as well: https://news.ycombinator.com/item?id=13097092) |
| 21:55:26 | * | libman quit (Remote host closed the connection) |
| 21:59:07 | Varriount|Mobile | Doesn't a small pause time become meaningless at some point, due to other OS factors (like context switching)? |
| 22:00:12 | federico3 | do they do rollouts at their hosts in the same minute? odd |
| 22:06:49 | dyce[m] | For functional programming I thought this was interesting https://people.eecs.berkeley.edu/~bodik/cs294fa12 |
| 22:07:23 | dyce[m] | Seems like you might need a PhD though? |
| 22:10:38 | dyce[m] | Some sort of bridge between genetic programming and machine learning? |
| 22:19:38 | * | Trustable quit (Remote host closed the connection) |
| 22:36:12 | * | saml_ quit (Remote host closed the connection) |
| 22:45:14 | * | vlad1777d_ joined #nim |
| 22:46:21 | * | vlad1777d__ quit (Ping timeout: 246 seconds) |
| 22:53:53 | * | space-wizard joined #nim |
| 22:58:12 | * | nsf quit (Quit: WeeChat 1.6) |
| 23:06:17 | * | brechtm quit (Ping timeout: 240 seconds) |
| 23:12:54 | * | brechtm joined #nim |
| 23:20:02 | * | chemist69 quit (Ping timeout: 250 seconds) |
| 23:22:35 | * | chemist69 joined #nim |
| 23:37:42 | * | themagician quit () |
| 23:39:45 | * | bjz_ joined #nim |