Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-07-26

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:05 deep-book-gk_ joined #moarvm
00:07 deep-book-gk_ left #moarvm
01:52 ilbot3 joined #moarvm
01:52 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:16 geekosaur joined #moarvm
02:19 nwc10_ joined #moarvm
02:19 moritz_ joined #moarvm
03:05 AlexDani` joined #moarvm
03:27 AlexDani` joined #moarvm
04:56 deep-book-gk_ joined #moarvm
04:57 deep-book-gk_ left #moarvm
05:44 AlexDani` joined #moarvm
06:01 brrt joined #moarvm
06:06 brrt good * #moarvm
06:28 Ven joined #moarvm
06:39 brrt i've found a few bugs in the allocator still, but not the smoking gun
06:39 AlexDani` joined #moarvm
06:40 domidumont joined #moarvm
06:47 domidumont joined #moarvm
06:50 brrt also!
06:50 brrt http://www.evanmiller.org/why-im-learning-perl-6.html
06:50 brrt pretty high praise
06:52 brrt "The code base is well-written, well-organized, well-documented, and well-tested; little things, like functions having the right size and variables having good names, make it a pleasure to read."
06:52 brrt y'all++ :-D
06:53 Ven_ joined #moarvm
07:13 brrt joined #moarvm
07:18 samcv hey brrt
07:19 brrt hey, mac has decided to reset my computer
07:24 brrt joined #moarvm
07:25 brrt ohai samcv
07:25 samcv brrt, did they notify you first?
07:26 brrt the mac?
07:26 brrt like five seconds in advance
07:26 samcv :P
07:26 samcv rude
07:27 samcv brrt, glad to read that fine praise!
07:27 brrt :-D
07:38 brrt i'm going to copy that everywhere :-D
08:01 zakharyas joined #moarvm
08:22 AlexDaniel lizmat: ? something to mention in next p6weekly for sure :)
08:22 AlexDaniel ah, you've seen it already, nvm
08:48 jnthn morning o/
08:48 brrt morning jnthn
08:52 jnthn Nice article :)
08:53 * jnthn is usually so busy working on the things that need improving that he often forgets we have some good stuff too :P
08:59 robertle joined #moarvm
09:08 jnthn There's lots of stuff I'd like to work on based on the CORE.setting compile profile, but I think they're out of scope for my branch, so I figure I'll get it merged
09:08 jnthn Want to look into the --profile regression first
09:12 jnthn grr, valgrind makes it work o.O
09:21 evalable6 joined #moarvm
09:24 bisectable6 joined #moarvm
09:24 unicodable6 joined #moarvm
09:28 camelia joined #moarvm
09:41 nwc10 jnthn: ASAN? (as it has a multithreaded hammer)
09:48 dogbert17 perl6-gdb might be an alternative
09:50 dogbert17 that's what I used yesterday
09:52 dogbert17 jnthn was right again, valgrind does hide the problem
09:53 Geth ¦ MoarVM/spesh-worker: 836da8faf6 | (Jonathan Worthington)++ | src/profiler/instrument.c
09:53 Geth ¦ MoarVM/spesh-worker: Clear argument guards on starting profiling.
09:53 Geth ¦ MoarVM/spesh-worker:
09:53 Geth ¦ MoarVM/spesh-worker: Otherwise they'll end up pointing to bogus spesh candidates.
09:53 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/836da8faf6
09:53 Geth ¦ MoarVM/spesh-worker: 9a6b5d835e | (Jonathan Worthington)++ | 4 files
09:53 Geth ¦ MoarVM/spesh-worker: Update profiling to cope with spesh changes.
09:53 Geth ¦ MoarVM/spesh-worker:
09:53 Geth ¦ MoarVM/spesh-worker: It should wait for the spesh thread to finish its work, otherwise it
09:53 Geth ¦ MoarVM/spesh-worker: will end up with confusion (and segfualts) when instrumented code gets
09:53 Geth ¦ MoarVM/spesh-worker: installed underneath the spesh worker thread.
09:53 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/9a6b5d835e
09:53 jnthn That seems to make things better.
09:54 timotimo perl6-gdb-m or maybe even rr ;)
09:54 timotimo also, mornin'
09:54 dogbert17 morning timotimo
09:55 dogbert17 jnthn++, that was a quick fix
09:58 jnthn Righty, time for a blocking + nodelay run of things, then I think I'll get this merged
09:58 jnthn There's still a good amount of time before the next release
09:59 jnthn So the various huge changes this branch brings can get a good workout.
09:59 jnthn (The GC orchestration stuff I did yesterday is also a huge change.)
10:00 dogbert17 any ideas as to where the current performance loss might be hiding?
10:02 jnthn Various. We're collecting a good bit more info than we were but not really using it fully yet, would be one reason, though the profiles don't show that collection up as being much of a cost.
10:03 jnthn Another could be we always have multiple threads now, so the single-thread optimizations went away.
10:03 jnthn Again, hard to see that in the profiling data.
10:03 jnthn Though it could be there inside the FSA
10:04 jnthn Yet another is that perhaps we're doing less well on certain optimizations for some reason
10:05 dogbert17 you did fix some long standing bugs, perhaps they affected reliability positively but performance negatively ?
10:06 * dogbert17 tries to get ahead of nwc10 by doing a spectest with ASAN :)
10:07 jnthn That also possible, yes
10:08 jnthn Alright, looks OK
10:09 jnthn Will merge then continue hunting improvemnets
10:09 timotimo when the log buffer is full, we just stop logging, right?
10:09 jnthn Won't do an immediate bump of MOAR_REVISION so only those who choose to live right on the edge will get it
10:10 jnthn timotimo: We have a quota of buffers
10:10 jnthn timotimo: When we run out, we stop logging
10:10 jnthn timotimo: Until the spesh worker is done with one and lets us log some more
10:10 timotimo right
10:11 jnthn Otherwise we could end up nomming a lot of memory
10:11 timotimo it's not problematic to lose any logged data, right?
10:11 timotimo of course
10:11 AlexDani` joined #moarvm
10:11 jnthn Not really
10:12 jnthn If something's hot it'll get called and log stuff eventually
10:13 timotimo right
10:14 jnthn What you notice in CORE.setting is there are points where the spesh worker thread goes a whole second or two with no new data, which implies nearly everything we're running has been specialized :)
10:15 jnthn Or at least, everything hot
10:15 jnthn Since hot frames will be filling the buffer with entries and hot loops with OSR entries.
10:16 timotimo aye
10:16 timotimo do we now keep osrpoints that have not been used around in frames btw?
10:16 timotimo or is there still some design needed to make that work?
10:16 jnthn For now we kick them all out
10:17 timotimo right
10:17 jnthn There's no easy option on that, I don't think
10:17 jnthn Since a spesh'd frame doesn't log
10:17 timotimo hm, right
10:17 timotimo loop detection and all that
10:18 jnthn Wow, 193 commits in my branch o.O
10:19 jnthn Merge testeds and spectested
10:19 jnthn Geth?
10:20 jnthn :)
10:20 jnthn Pushed the merge, anyway :)
10:20 jnthn Odd it didn't report it
10:20 timotimo busy bee jnthn bringing us that very special optimization honey
10:21 brrt \o/
10:49 Geth ¦ MoarVM: 17e53807a7 | (Jonathan Worthington)++ | 2 files
10:49 Geth ¦ MoarVM: Avoid many array searches for SC code refs.
10:49 Geth ¦ MoarVM:
10:49 Geth ¦ MoarVM: This showed up hot in profiling. It turns out that we weren't even
10:49 Geth ¦ MoarVM: checking if the code ref had a cached SC index, and even if we had
10:49 Geth ¦ MoarVM: been we'd still get a miss because we didn't set the SC on the code
10:49 Geth ¦ MoarVM: object before adding it, meaning the index was never cached. Cuts the
10:49 Geth ¦ MoarVM: number of times we need to take the loop to just 40% of the cases it
10:49 Geth ¦ MoarVM: used to need to in CORE.setting compilation, which cuts about 5% off
10:49 Geth ¦ MoarVM: stage MAST.
10:49 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/17e53807a7
10:52 lizmat wee!  :-)
10:56 timotimo *neat*
10:57 ZofBot joined #moarvm
11:14 timotimo i think i'll install telemeh spots for "finished a log" which will tell both the thread object and the address of the log object, and also for the spesh worker when it grabs that log object
11:17 Geth ¦ MoarVM: 975a67ee28 | (Jonathan Worthington)++ | 3 files
11:17 Geth ¦ MoarVM: JIT param_sp and param_sn.
11:17 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/975a67ee28
11:18 jnthn Righty, lunch and another callgrind run to have fresher data
11:58 dogbert17 jnthn: unless I have done something wrong there's a spectest fail in t/spec/S04-declarations/constant.t. "Cannot invoke this object (REPR: Null; VMNull)"
11:59 timotimo there was just a commit about constants in rakudo
11:59 dogbert17 aha
11:59 dogbert17 ok 72 - Can match a exported constant regex
11:59 dogbert17 Cannot invoke this object (REPR: Null; VMNull)
11:59 dogbert17 in sub  at /home/dogbert/repos/rakudo/t/spec/packages/ExportConstant.pm6 (ExportConstant) line 3
11:59 dogbert17 in block <unit> at t/spec/S04-declarations/constant.rakudo.moar line 386
12:01 jnthn I suspect that was a revert done earlier today
12:01 jnthn Without reverting a test
12:02 jnthn fwiw, want a bit of a break from spesh work, so decided to work on shrinking MVMFrame some :)
12:04 brrt that is probably going to be worthwhile
12:06 timotimo i pushed two commits just now, geth seems unhappy
12:08 Geth ¦ MoarVM: f5d52c587f | (Timo Paulssen)++ | src/main.c
12:08 Geth ¦ MoarVM: inability to open telemeh log shall not be fatal
12:08 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f5d52c587f
12:08 Geth ¦ MoarVM: 30f92a01e6 | (Timo Paulssen)++ | src/spesh/worker.c
12:08 Geth ¦ MoarVM: output spesh worker info on telemetry channel
12:08 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/30f92a01e6
12:08 timotimo hey look
12:19 timotimo oh no
12:21 timotimo the cat is sitting between my keyboard and screens :D
12:23 jnthn They probably offer a nice warming service with the added bonus of distracting a human for attention.
12:24 timotimo actually, my desk is cluttered (fall-out from moving, still :( ) and she's sitting right in front of the keyboard, a good 30cm away from the screens
12:26 timotimo now the telemetry log shows when quota runs out and then when the worker thread re-enables logging for a thread
12:27 timotimo essentially letting you see how much time is spent non-logging
12:28 timotimo https://gist.github.com/timo/9fc680c461b0412688dfffc3a919e8b7 - looks like this
12:34 stmuk gcc 7.1 is noisy
12:37 Geth joined #moarvm
12:38 Geth ¦ MoarVM: 2f89bd12c5 | (Jonathan Worthington)++ | 2 files
12:38 Geth ¦ MoarVM: Eliminate all reads of frame effective_handlers.
12:38 Geth ¦ MoarVM:
12:38 Geth ¦ MoarVM: We can cheaply and easily determine what they are by checking if we
12:38 Geth ¦ MoarVM: have a spesh candidate or not. This will create a very small added
12:38 Geth ¦ MoarVM: cost where we need them, which is when an exception is thrown.
12:38 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2f89bd12c5
12:38 Geth ¦ MoarVM: c0ac26668d | (Jonathan Worthington)++ | 4 files
12:38 Geth ¦ MoarVM: Eliminate effective_handlers field in MVMFrame.
12:38 Geth ¦ MoarVM:
12:38 Geth ¦ MoarVM: All the writes to it can go away, some of which were on hot paths.
12:38 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c0ac26668d
12:38 Geth ¦ MoarVM: 3b6c397d97 | (Jonathan Worthington)++ | 2 files
12:39 Geth ¦ MoarVM: Move static inline to the only file using it.
12:39 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3b6c397d97
12:39 jnthn 8 (or 4 on 32-bit) bytes down
12:39 timotimo neat. we do have many frames.
12:43 Geth ¦ MoarVM: c969852553 | (Jonathan Worthington)++ | src/core/exceptions.c
12:43 Geth ¦ MoarVM: Correct pluralo.
12:43 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c969852553
12:49 zakharyas joined #moarvm
12:52 lucasb joined #moarvm
13:16 Geth ¦ MoarVM: b04678bc6d | (Jonathan Worthington)++ | 6 files
13:16 Geth ¦ MoarVM: Eliminate many readers of ->effective_bytecode.
13:16 Geth ¦ MoarVM:
13:16 Geth ¦ MoarVM: These are all easily handled by simply checking if we've a spesh
13:16 Geth ¦ MoarVM: candidate.
13:16 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b04678bc6d
13:16 Geth ¦ MoarVM: 992990345d | (Jonathan Worthington)++ | src/core/frame.c
13:16 Geth ¦ MoarVM: Remove an unrequired test.
13:16 Geth ¦ MoarVM:
13:16 Geth ¦ MoarVM: If we have JIT code, we'll be running JIT code.
13:17 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/992990345d
13:17 Geth ¦ MoarVM: 4357c00547 | (Jonathan Worthington)++ | 2 files
13:17 Geth ¦ MoarVM: Account for jitcode in effective bytecode check.
13:17 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4357c00547
13:20 Geth ¦ MoarVM: 3d5c545346 | (Jonathan Worthington)++ | src/core/frame.c
13:20 Geth ¦ MoarVM: Prepare invoke for eliminating effective_bytecode.
13:20 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3d5c545346
13:20 jnthn I "just" need to update deopt.c now in order to be able to eliminate effective_bytecode
13:21 jnthn But first, language class :)
13:22 jnthn bbiab
13:23 timotimo ... object oriented speaking ...
13:26 jsimonet joined #moarvm
13:28 jsimonet Hello, I think I saw a type on moarvm website (https://www.moarvm.org/) "Synchronous I/O reimplemented, lifting limtations".
13:28 jsimonet typo*
13:29 timotimo mhh lime-tations
13:29 timotimo probably some kind of târte?
13:32 brrt hey, thanks
14:03 AlexDaniel joined #moarvm
14:46 jnthn Ah, and I need to replace that with this 2017.07 release text anyway :)
14:46 jnthn jsimonet++ for noticing though :)
14:46 jsimonet :)
14:50 jnthn Well, now I know how to say "deopt je nejkomplikovan?jši"... :)
14:50 * jnthn tries to sort out the effective_bytecode removal there too
14:54 Geth ¦ MoarVM: paulsmith++ created pull request #618: Fix typo in comment
14:54 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/618
15:06 Geth ¦ MoarVM: 11f195d9f5 | (Paul Smith)++ (committed using GitHub Web editor) | src/core/oplist
15:06 Geth ¦ MoarVM: Fix typo in comment
15:06 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/11f195d9f5
15:06 Geth ¦ MoarVM: 49ed81f0a1 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/core/oplist
15:06 Geth ¦ MoarVM: Merge pull request #618 from paulsmith/patch-1
15:06 Geth ¦ MoarVM:
15:06 Geth ¦ MoarVM: Fix typo in comment
15:06 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/49ed81f0a1
15:10 Geth ¦ MoarVM: 7455420dbd | (Jonathan Worthington)++ | src/spesh/deopt.c
15:10 Geth ¦ MoarVM: Make deopt no longer require effective_bytecode.
15:10 Geth ¦ MoarVM:
15:10 Geth ¦ MoarVM: Which makes it rather clearer anyway.
15:10 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7455420dbd
15:10 jnthn Phew :)
15:22 Geth ¦ MoarVM: d6d7d5eb71 | (Jonathan Worthington)++ | 4 files
15:22 Geth ¦ MoarVM: Eliminate effective_bytecode.
15:22 Geth ¦ MoarVM:
15:22 Geth ¦ MoarVM: Saves another 8 (64-bit) or 4 (32-bit) bytes in MVMFrame, and some
15:22 Geth ¦ MoarVM: assignments on the invoke hot path.
15:22 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d6d7d5eb71
15:23 jnthn That's 16 (or 8 on 32-bit) bytes saved off every MVMFrame.
15:25 brrt joined #moarvm
15:26 timotimo the cache rejoices
15:32 nebuchadnezzar joined #moarvm
15:42 brrt joined #moarvm
15:58 Geth ¦ MoarVM/frame-extras: 9a33eeb8aa | (Jonathan Worthington)++ | 10 files
15:58 Geth ¦ MoarVM/frame-extras: Add function to encapsulate special return setup.
15:58 Geth ¦ MoarVM/frame-extras:
15:58 Geth ¦ MoarVM/frame-extras: Which will ease refactoring how it is handled/stored.
15:58 Geth ¦ MoarVM/frame-extras: review: https://github.com/MoarVM/MoarVM/commit/9a33eeb8aa
16:24 brrt joined #moarvm
16:26 robertle joined #moarvm
16:37 colomon joined #moarvm
16:54 Geth ¦ MoarVM/frame-extras: 3be41bc41c | (Jonathan Worthington)++ | 12 files
16:54 Geth ¦ MoarVM/frame-extras: Move special return into a frame extras.
16:54 Geth ¦ MoarVM/frame-extras:
16:54 Geth ¦ MoarVM/frame-extras: This is allocated and hung off a frame on-demand to store things that
16:54 Geth ¦ MoarVM/frame-extras: relatively few frames have. A couple of further items will move to
16:54 Geth ¦ MoarVM/frame-extras: this structure later; for now this saves 3 pointers per MVMFrame (so
16:54 Geth ¦ MoarVM/frame-extras: 24 bytes per frame on 64-bit platforms).
16:54 Geth ¦ MoarVM/frame-extras: review: https://github.com/MoarVM/MoarVM/commit/3be41bc41c
16:59 Ven joined #moarvm
17:03 jnthn Tomorrow, a couple more things move into there, saving another 16 bytes
17:03 jnthn Or 8 if you're on 32 bit
17:22 Ven joined #moarvm
17:29 timotimo hm, so reini's thread model is basically "the owner of an object doesn't have to lock if it wants to do changes to it, but it has to check for a work queue constantly"?
17:31 timotimo and on every access to any object you first have to check who the owner is, too
17:34 timotimo i'm not entirely convinced that's better than letting the user handle the locking based on what needs it and what doesn't
17:46 jnthn I suspect its properties also fall under the "false sense of security" I've mentioned before: effectively, that the atomicity is on smaller things than the transactions that you typically care for.
17:47 jnthn The start { while @a { process(@a.pop) } } for ^4 example being the classic example: a model that lets you safely ask how many elemnets you have and safely pop doesn't make that code safe
17:49 timotimo right
17:49 timotimo i imagine you'd still write lock-based code for that
17:50 timotimo where while a thread is waiting to acquire a lock would i guess block on its work queue?
17:50 timotimo and, er, when the lock gets freed all other threads get a wake-up for that?
17:50 timotimo there must be a way to make this efficient
17:50 timotimo anyway, will be AFK for a cinema evening with friends :)
17:53 domidumont joined #moarvm
18:08 domidumont joined #moarvm
18:19 FROGGS joined #moarvm
18:22 brrt joined #moarvm
18:27 nine timotimo: actually it's my thread model and it relies on writes being done only by the owning thread, i.e. you send it the task to execute the write. The effective lock is the one on the task queue. And yes, it doesn't actually give you guarantees about reading consistent states.
18:27 nine But hey, it was my first attempt :)
18:34 jnthn timotimo: You want something along the lines of what the concurrent queue uses
18:35 jnthn (condvar for the wake-up)
19:11 Geth_ ¦ moarvm.org: 4a6510293e | jnthn++ | 2 files
19:11 Geth_ ¦ moarvm.org: Update site for 2017.07 release.
19:11 Geth_ ¦ moarvm.org:
19:11 Geth_ ¦ moarvm.org: And some more general updates to the homepage text.
19:11 Geth_ ¦ moarvm.org: review: https://github.com/MoarVM/moarvm.org/commit/4a6510293e
19:15 Geth_ ¦ moarvm.org: 5904b51079 | jnthn++ | roadmap.html
19:15 Geth_ ¦ moarvm.org: Update roadmap also.
19:15 Geth_ ¦ moarvm.org:
19:15 Geth_ ¦ moarvm.org: We completed some things.
19:15 Geth_ ¦ moarvm.org: review: https://github.com/MoarVM/moarvm.org/commit/5904b51079
19:53 dogbert2 joined #moarvm
19:55 dogbert2 Profiled a program which runs 10-15 percent slower with spesh-worker and compared it with a profile where I used the Camelia version.
19:57 dogbert2 The only obvious difference I saw was the following, the Camelia version did 5 OSR while spesh-worker only did 3.
20:22 [Coke] COMPLEAT ALL THE THINGS
20:22 jnthn dogbert2: Any chance you could callgrind the two also?
20:23 jnthn How did the inlining rate and percentage specialized compare?
20:26 dogbert2 percentage specialized frames: Camelia 100%, spesh-worker 99.99%
20:27 dogbert2 no JIT compiled frames since I'm on a 32 bit VM
20:27 colomon_ joined #moarvm
20:28 dogbert2 also regarding the OSR's: camelia had 2 deopts while shesh-worker had 0
20:39 jnthn Yeah, in theory spesh-worker has more data to go on in most cases and so can do less deopting
20:41 jnthn Did you find the inlining rate? It's on the overview page
20:43 dogbert2 Camelia:  Inlining eliminated the need to create 25326140 call frames (that's 40.33%). spesh-worker Inlining eliminated the need to create 25325704 call frames (that's 40.33%).
20:47 jnthn Gosh, they're close
20:47 jnthn And top routines and their percentage times are similar?
20:49 colomon joined #moarvm
20:54 dogbert2 jnthn: here are the callgrind results: https://gist.github.com/dogbert17/6bb3eeb5fc07d809adf03ac7ab6f31a7
20:56 colomon joined #moarvm
21:04 dogbert2 the percentages (top ten in the --profile output) are more or less the same
21:05 jnthn Yeah, that's quite revealing. Thanks.
21:11 nine almost half a million get_attribute more?
21:14 jnthn Yeah, also a lot of multi-dispatch cache lookups
21:15 nine So either the stronger validation of code objects is too strong or some missing facts?
21:15 jnthn More like, we were playing waaay fast and loose with aliasing before
21:16 jnthn And now we're a lot tighter on it, so much so that it probably cuts out a bunch of useful opts
21:16 jnthn I expected to have to deal with that; we already do collect some data about it that now needs to be put to good use
21:16 jnthn In the longer run we'll want some more sophisticated alias analysis also
21:20 jnthn Which is also an escape analysis pre-req, which would allow for cutting out a ton of GC work.
21:38 colomon joined #moarvm
22:02 samcv someone i talk to on irc linked me that evanmiller article unprompted and asked if i'd seen it :) is perl 6 popular yet?
22:02 samcv :p
22:03 samcv heh
22:23 jnthn :)
22:31 jnthn sleep &
22:46 AlexDani` joined #moarvm
23:59 sivoais joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary