|
01:30
deep-book-gk joined,
deep-book-gk left
01:52
ilbot3 joined
01:56
stmuk joined
03:24
geekosaur joined
03:25
geekosaur joined
03:29
geekosaur joined
05:46
brrt joined
05:53
GK1wmSU joined
05:54
GK1wmSU left
|
|||
| brrt | good * #moarvm | 05:57 | |
|
06:06
_GK1wmSU joined
06:09
_GK1wmSU left
06:42
brrt joined
|
|||
| brrt | one advantage of merging this week; i can start working on a stack-walker branch, without woryying about merging it in both | 07:17 | |
|
07:45
zakharyas joined
|
|||
| brrt | the dolphin folks have apparently written a JIT: bwiegmans-emkapp.dev.booking.com | 08:04 | |
| eh | |||
| wrong paste | |||
| dolphin-emu.org/blog/2017/07/30/ubershaders/ | |||
|
08:18
vendethiel- joined
|
|||
| jnthn | Moarning, #moarvm | 08:44 | |
| brrt | moarning jnthn | 08:45 | |
|
08:52
robertle joined
|
|||
| ilmari | brrt: they always had the JIT shader compiler, AIUI. they wrote a whole GPU emulator as a shader as well because the JIT latency was unacceptable | 09:11 | |
| brrt | well, that's what makes it a JIT compiler, otherwise it's just a compiler, innit | 09:13 | |
| :-) | |||
| but it is really really cool work nevertheless | |||
|
09:14
robertle joined
|
|||
| brrt | it's completely irrelevant to me since i own a wii and wii u | 09:14 | |
| but really cool | |||
|
09:21
vendethiel joined
|
|||
| Geth | MoarVM: 68031489de | (Jonathan Worthington)++ | src/6model/reprs/P6opaque.c Spesh matches on exact types, so MI is no problem. With slots it is because they are unpredictable in the face of subclasses given MI. But when matching on an exact type and getting the offset for it, as spesh does, then it's safe. |
09:25 | |
| timotimo | it's only the jit latency if you consider the code on the gpu to be the target, which i'd claim it isn't | 09:49 | |
| because it's the gpu driver that takes ages to turn the glsl (or hlsl on directx) into whatever internal machine-code-like stuff the gpu uses | 09:51 | ||
| ilmari | they have to JIT the TEV config to glsl first | 09:53 | |
| timotimo | right, but that's probably the faster step; i might have to re-read | ||
| hm, looks like you're right, the wording is a tiny bit misunderstandable | 09:54 | ||
|
10:01
vendethiel- joined
|
|||
| dogbert17 | jnthn: dunno if it ties in with your current work, but of the two MoarVM related bugs found during the weekend, I reported one as a MoarVM issue and the other might have already been solved by timotimo :) | 10:06 | |
| jnthn | This one: github.com/MoarVM/MoarVM/issues/620 ? | 10:07 | |
| dogbert17 | yes, that's the reported one :) | 10:09 | |
| the other is hidden here, gist.github.com/dogbert17/e23c3340...da3feb18f, but can be turned into a report should you so desire | 10:10 | ||
| jnthn | Yeah, that's worth a MoarVM issue also | 10:14 | |
| dogbert17 | jnthn: done github.com/MoarVM/MoarVM/issues/622 | 10:18 | |
| jnthn | m: say 220 / 225 | 10:34 | |
| camelia | 0.977778? | ||
|
10:34
vendethiel joined
|
|||
| Geth | MoarVM: 682b8c8694 | (Jonathan Worthington)++ | 5 files Speed up attribute reads during invocation. By caching the offsets when it's a P6opaque (in reality, it pretty much always is) so we don't have to call get_attribute. Profiling showed that about 3% of CORE.setting instructions during compilation go on the get_attribute calls in these functions; a profile after the change shows a drop of around 5 billion instructions when compiling CORE.setting, or about 2.2%. |
10:47 | |
| MoarVM: e3c44fc042 | (Jonathan Worthington)++ | src/core/oplist Document the various op adverbs. |
|||
| MoarVM: 099764bd92 | (Jonathan Worthington)++ | 3 files Avoid spesh log function call when not logging. The static inline does the check quickly, saving the overhead of the function call in the case we aren't doing spesh logging at this point. |
11:04 | ||
| lizmat | jnthn: possibly related to this, do you have a clue why "is default()" is not honoured on attributes ? | 11:05 | |
| jnthn | lizmat: No, no idea why that'd be | 11:06 | |
| lizmat | m: class A { has $.a is default(42) }; use nqp; dd nqp::getattr(nqp::create(A),A,q/$!a/) | ||
| camelia | Any $!a = Any? | ||
| lizmat | it's happening at a very low level | 11:07 | |
| m: class A { has $.a is default(42) }; use nqp; dd nqp::getattr(nqp::create(A),A,q/$!a/).VAR.default | |||
| camelia | 42? | ||
| jnthn | Probably that it isn't setting the value into the container that then later gets cloned | 11:09 | |
| Just updating the container descriptor won't suffice | |||
| Note that the variable one does an assignment into the container | |||
| lizmat | I've lost you | 11:10 | |
| I just wanted to show that the descriptor *is* set up correctly | 11:11 | ||
| jnthn | Yes, it is, my point was that this isn't actually very important. | ||
| lizmat | but something is stoking an Any into it | ||
| jnthn | Because that's only for introspection by runtime | ||
| lizmat | I think it's *very* important | ||
| jnthn | You can think what you want, but I know how it works :P | ||
| The mechanism in both cases is that we clone a "prototype" Scalar | 11:12 | ||
| In Variable.pm where the var default trait is, we have this line: | |||
| # make sure we start with the default if a scalar | |||
| $var = $default if nqp::istype($what, Scalar); | |||
| That is not, however, taking place in the is default trait for Attribute | 11:13 | ||
| lizmat | hmmmm | ||
| ok, | |||
| jnthn | The question being, how we do it :) | ||
| Ah, right | |||
| Attribute has a $!auto_viv_container | |||
| So we need to make sure it ends up assigned into that | 11:14 | ||
| Ah, and it can be done in the Attribute default trait in traits.pm | |||
| lizmat | ok, I will take it from there then :-) | ||
| jnthn | The solution will be something like adding: | 11:15 | |
| my \cont := $attr.container; | |||
| nqp::assign(cont, $defualt) if nqp::istype(cont, Scalar) | 11:16 | ||
| or | |||
| my $cont := $attr.container; | |||
| $cont = $defualt if nqp::istype(cont, Scalar) | |||
| Saves an nqp op and should be equally good code :) | |||
| (Saves using one, I mean; it'll generate nqp::assign underneath) | |||
| lizmat | ack, lemme try :-) | 11:17 | |
| Geth | MoarVM: 9720819b96 | (Jonathan Worthington)++ | src/core/frame.c Reduce duplication and simplify logic in invoke. By making the codepaths where we have a specialization already and where we don't have a specialization share most of their code. This also gets rid of the found_spesh flag. |
11:20 | |
| jnthn | Meanwhile, lunch :) | ||
| bbiab | |||
| nine | ssh cmsfrontend-public.atikon.io | 11:32 | |
| timotimo | nine: wrong channel again? | 11:34 | |
| nine | Yeah, brane didn't register, that this doesn't really look like normal shell output. | 11:35 | |
| Woke up at 5 in the morning because the roller shutters didn't close and I can't sleep when it's too much light. Turns out my WiFi router which hosts the controller software has got a broken flash or something. Rebooted into an openWRT version that shouldn't have been on that thing for half a year. | 11:36 | ||
| timotimo | whoops | 11:37 | |
| i, too, can't sleep when there's light; even a little will prevent me from falling asleep, and a bit more than that will easily wake me up | 11:38 | ||
| stmuk | we are using a cheap car sunshade to block summer light from the window | 11:46 | |
| timotimo | my shutters are human-powered | 11:47 | |
| nine | Well sometimes that is an advantage indeed :) | 11:54 | |
| jnthn back | 12:04 | ||
| brrt | \o | 12:05 | |
| jnthn | Darn it. Some update seems to have screwed things up such that when the auto-logout-because-you-were-inactive thing happens, you just get a black screen and, mouse cursor moving aside, a totally unresponsive system :/ | 12:06 | |
| Occasionally get hangs coming out of hibernate mode too. | 12:07 | ||
| Don't miss the Windows dev expereince at all but I miss the stability :P :P | |||
| brrt | are you on linux now? | ||
| timotimo | auto-logout, you mean suspend to ram or just a screen locker? | ||
| jnthn | brrt: yeah | 12:08 | |
| timotimo: Just screen locker :/ | |||
| timotimo | that's not nice | ||
| brrt | part of 'stability' is dealing with the bugs you know rather than the bugs that you don't though :-P | ||
| timotimo | though there's a variety of screen lockers to choose from :D | ||
| what kind of DE are you running? | |||
| jnthn | timotimo: Whatever Ubuntu comes without of the box :) | 12:09 | |
| timotimo | oh | ||
| brrt | i always feel like windows is less stable (in my hands) than windows is, but i think i'm ignoring a lot of things that you'd notice :-) | ||
| eh, second windows should be linux :-P | |||
| jnthn | tbh I don't even care what it is, in so far as I use the command line + chromium and that's about it :P | ||
| timotimo | the ubuntu devs have been brewing their own X replacement for a while that's not gotten any traction outside of ubuntu where you're basically forced to use it :P | ||
| ilmari | did they actually switch to it by default? | 12:10 | |
| timotimo | i think they very recently dropped mir development | ||
| brrt | ymmv, but you might find fedora to be more polished. | ||
| adn then agian, you might not care | |||
| ilmari | has fedora switched to wayland yet? | 12:12 | |
| jnthn | Wow, another 3 billion instructions off as a result of the previous two commits :) | ||
| timotimo | i'm still running xorg, but i believe if you install fedora regularly you'll get a gnome3 on wayland now | 12:14 | |
| i started out with the xfce4 spin | |||
| brrt wonders how many bitcoin can be mined with all the instructions jnthn has saved | |||
| yeah, wayland is standard by now | |||
| i notice a very occasional bug in Qt integration, but other than that | |||
| jnthn | Current project: trying to heap-allocate frames that'll obviously get promoted there anyway | 12:16 | |
| nine | jnthn: so you're already outdating the blog post you just wrote? | ||
| brrt | and how will you know how obvious that is? | ||
| jnthn | Yeah :P | ||
| brrt: Well, my Plan A is to mark ops that force it (done) and have the bytecode validation note if it seems such an op (done), and then use that flag (doing it now) | 12:17 | ||
| I think spesh can in the future try to be more accurate | |||
| Boom, sigsegv | 12:29 | ||
| lizmat misses RabidGravy | 12:33 | ||
| [Coke] | soooo much burnout since y2k. | 12:35 | |
| jnthn | Hm, nearly got it to work, just some SEGV in a few spectests | 12:43 | |
| timotimo | you must know how much it costs to promote frames during core setting compile? | 12:48 | |
| jnthn | About 2.15% of CPU cycles | ||
| ho, interesting | 12:49 | ||
| Was hyper.t flappy? | |||
| Just tracked down the SEGV in it and...it wasn't anything new | |||
| Just uncovered | |||
| Zoffix | wasn't a flopper for me | 12:51 | |
| timotimo | curious | 12:53 | |
| i'm going to look closer at the high occurence of memset during Terminal::Print thing | 12:54 | ||
| jnthn | I guess it coulda shown up in various places | 12:57 | |
| Plus a second one I just found | 12:58 | ||
| Geth | MoarVM: ae86ef0620 | (Jonathan Worthington)++ | src/core/frame.c Ensure allocd_work and allocd_env are zeroed. Otherwise they may be junk which will break OSR by causing it to try and free a bogus pointer. |
13:00 | |
| MoarVM: a539212457 | (Jonathan Worthington)++ | src/spesh/log.c Handle log getting full between making entries. This could occasionally lead to a NULL pointer dereference. |
|||
|
13:04
ggoebel joined
|
|||
| jnthn | Seems I've a working patch to allocate on the heap straight off in some cases | 13:05 | |
| callgrind is measuring its worthiness | |||
| Seems to knock some seconds off spectest though | |||
|
13:10
zakharyas joined
|
|||
| timotimo | nice | 13:13 | |
| jnthn | The callgrind takes ages but at least it takes less ages than it used to :) | 13:15 | |
| timotimo | fewer ages* | 13:16 | |
| :P | |||
| jnthn | *groan* | ||
| So I realized over the weekend that there's actually a much simpler solution to getting most of our Perl 6 pass-a-thing-in-a-container dispatches and inlines back | 13:21 | ||
| Than the super-clever alias analysis | |||
| Which we'll want some of anyway for doing EA but still | 13:22 | ||
| We know the type tuples, including deconts, of our callees | |||
| We can also stash those away at the callsite too | 13:23 | ||
| Then, provided it's stable, we can trace back from the args to where there's something that fetches the arg and, provided it's a deopt-able instruction, insert a decont + guard there | |||
| The decont would then be subject to the fetch lowering | 13:24 | ||
| And the guard a normal STable one | |||
| jnthn sets about figuring out the details of that | 13:25 | ||
| Also, going to make decont a deoptonepoint so we get guards on it | 13:27 | ||
| Which will also get us some Perl 6 spesh mojo back | |||
| I like how this guard splitting also naturally means we only enforce the content of the container when we care, whereas before we always did it | |||
| Oh dear. Things get *worse* after my patch. Hmm. | 13:43 | ||
| Oh, hmm | 13:47 | ||
| Of course, since I marked exception | |||
| But there's loads of code like | |||
| nqp::die(...blah...) unless $foo | |||
| hm, though I forgot to mark die | 13:48 | ||
| lizmat | .oO( I always use die to mark ) |
13:49 | |
| or dye rather :-) | 13:50 | ||
| dogbert17 | jnthn: yes hyper.t was flappy | 13:52 | |
| jnthn | dogbert17: OK, hopefully no longer on HEAD :) | ||
| dogbert17 | :) | 13:55 | |
| TBH, I've only had it flop once or twice | 13:58 | ||
| lizmat | news.perlfoundation.org/2017/07/gra...perl-.html # jnthn++ | 14:04 | |
| Zoffix | w00t \o/ jnthn++ | ||
| timotimo | cool | 14:05 | |
| jnthn is quite relieved by this | 14:07 | ||
| Some weeks back I got told it was approved. So I didn't take on $other-work so I could focus on Perl 6 for the summer and dug in. Then got a mail some days later saying some legal process needed to be completed first before the approval could be posted. I figured eh, I'll just get on with stuff, guess it's just a couple more days. Took some weeks in the end. TPF++ for sorting it out, anyways. | 14:09 | ||
| Geth | MoarVM: c7be0ee7f5 | (Jonathan Worthington)++ | src/spesh/stats.c Fix a typo. |
14:12 | |
| MoarVM: c5be4dd59a | (Jonathan Worthington)++ | 3 files Move checking part of force_to_heap into an inline Since quite often - increasingly so if we allocate directly on the heap - the answer will be that it's already promoted. |
|||
| jnthn | I think more checks were part of the added cycles, but there's no getting away from the other numbers: we really are causing a lot more GC | ||
| So a static approach isn't going to fly, I don't think | 14:13 | ||
| I guess takeclosure must happen more conditionally in NQP than I expected | |||
| I guess it makes sense given it can flatten more aggressively | |||
| Guess I'll try a dynamic approach :) | 14:14 | ||
| brrt | that smells like it's going to want a counter | 14:15 | |
| jnthn | Yeah | ||
| Nice thing is, we already have one | |||
| An invocations counter | |||
| So if I also count in the heap promotion code | 14:16 | ||
| I guess we can stop counting once the frame is specialized also | |||
| oh, even easier, just latch once it's promoted | 14:22 | ||
| Mmmm...fresh watermelon jice | 14:27 | ||
| *juice | |||
| timotimo | so ... water? :) | 14:32 | |
| dogbert17 | tried to check out MoarVM master and rebuild it. It worked but when running 'perl Configure.pl --gen-moar --gen-nqp --backends=moar' I get SEGV's | 14:33 | |
|
14:33
travis-ci joined
|
|||
| travis-ci | MoarVM build failed. Jonathan Worthington 'Move checking part of force_to_heap into an inline | 14:33 | |
| travis-ci.org/MoarVM/MoarVM/builds/259383987 github.com/MoarVM/MoarVM/compare/a...be4dd59a61 | |||
|
14:33
travis-ci left
|
|||
| jnthn | Hm, maybe my pulling apart of stuff into commits didn't quite go to plan :) | 14:33 | |
| dogbert17 | :) | 14:34 | |
| jnthn | Not sure why htough | ||
| dogbert17 | perhaps one important change didn't make it through | 14:35 | |
| jnthn | Dunno. After latest round of changes I also see segv | 14:36 | |
| dogbert17 tries ASAN | 14:38 | ||
| jnthn | oh duh duh duh | ||
| dogbert17 | ASAN:SIGSEGV | 14:39 | |
| ================================================================= | |||
| ==9221== ERROR: AddressSanitizer: SEGV on unknown address 0x00000006 (pc 0xb566b9a0 sp 0xbfdf2070 bp 0xbfdf6328 T0) | |||
| AddressSanitizer can not provide additional info. | |||
| #0 0xb566b99f in MVM_interp_run /home/dogbert/repos/rakudo/nqp/MoarVM/src/core/interp.c:304 | |||
| #1 0xb59d2d3a in MVM_vm_run_file /home/dogbert/repos/rakudo/nqp/MoarVM/src/moar.c:331 | |||
| jnthn | I somehow got the conditional totally backwards | ||
|
14:40
ilmari[m] joined
|
|||
| dogbert17 has done that more times than I want to admit | 14:40 | ||
| Geth | MoarVM: 4a92691268 | (Jonathan Worthington)++ | src/core/frame.h Correct inverted conditional. |
||
| jnthn | timotimo: It turns out the juice is a pink/red color and quite sweet :) | 14:43 | |
| dogbert17 | and .... the SEGV has mysteriously disappeared :) | 14:44 | |
| nine | Amazon++ # sending a replacement for my faulty router without making a fuzz about me running openWRT on it. | 14:47 | |
| jnthn | Hm, wallclock numbers aren't immediately encouraging after my change, but could be noise. Also, increasing heat in the office thanks to heatwave outside. :/ | 14:48 | |
| nine | Though I had some funny 10 minutes on the phone with the helpdesk lady how faught with their system which needed confirmation of my payment data but did not accept the correct one (despite amazon.com showing the exact same numbers) | ||
| lizmat | which is why I run my spectest bench at 5am in the morning or so :-) | 14:49 | |
| ilmari | as opposedt to 5am in the afternoon or 5pm in the morning? | 14:50 | |
| jnthn | Well, callgrind can give me better numbers | 14:51 | |
| Much of what I'm doing is within noise so far as wallclock goes | |||
| ah, a chrome tab was hungry | 14:55 | ||
| jnthn offers his latest to callgrind | |||
| lizmat | ilmari: ah, indeed 5 in the morning :-) | ||
| ilmari | lizmat: am/pm sucks, just use 24h time :) | 14:56 | |
| lizmat | ok, I run my spectests at 0500 :-) | ||
| ilmari | I remember seeing "02:30 pm" somewhere recently, which is just weird | 14:57 | |
| who the hell uses leading zeros with 12h time? | |||
|
15:10
brrt joined
15:12
travis-ci joined
|
|||
| travis-ci | MoarVM build passed. Jonathan Worthington 'Correct inverted conditional.' | 15:12 | |
| travis-ci.org/MoarVM/MoarVM/builds/259395289 github.com/MoarVM/MoarVM/compare/c...9269126861 | |||
|
15:12
travis-ci left
|
|||
| jnthn | yay :) | 15:13 | |
| dogbert17 | callgrind? | ||
| jnthn | No, the travis report agreeing with the earlier fix | ||
| callgrind still grinding | |||
| I'm already working on the next thing while it does so :) | |||
| dogbert17 | saving even more cycles? | 15:16 | |
| jnthn | Well, that's the eventual goal, for now just getting spesh to propagate information about type tuples seen in callees back to their caller's callsite, so we can do better optimization | 15:19 | |
| This is more for Rakudo than NQP, though, so will be looking less at CORE.setting compilation during it | 15:21 | ||
|
15:31
MasterDuke joined
|
|||
| japhb | timotimo: What is "the high occurence of memset during Terminal::Print thing"? | 15:32 | |
| jnthn++ # Memory use and performance hacking | 15:33 | ||
| jnthn | Gahhh. :( Latest version of the frame promotion changes are even worse. | 15:34 | |
| lizmat knows that feeling | 15:35 | ||
| :-( | |||
| MasterDuke | i've been experimenting with making MVMString.num_graphs an MVMuint64 (instead of MVMuint32) | 15:40 | |
| yoleaux | 27 Jul 2017 18:37Z <AlexDaniel> MasterDuke: I'm going to take a nap now, but… bots are broken :) Feel free to investigate: github.com/perl6/whateverable/issu...-318444466 | ||
| 27 Jul 2017 18:38Z <AlexDaniel> MasterDuke: well, not completely broken, but a chance of getting MoarVM panic when you do something is really high. | |||
| MasterDuke | however, there are lots of places where some MVMint64 value is compared against num_graphs (or something similar, like a substring length) | ||
| i supposing introducing an MVMint128 would not be the preferred solution | 15:41 | ||
| jnthn | No. | 15:45 | |
| Ok, with thresholds tweaked the wallclocks look better | 15:49 | ||
| MasterDuke | right, i'm thinking that a bunch of checks will get/have to go away at the moar level (e.g., if (length < 0) { MVM_exception_throw_adhoc() } else { }) | ||
| and such a check would have to be moved up to the nqp/rakudo level | 15:50 | ||
| jnthn | Uh | ||
| No | |||
| I mean, we have to do checks at VM level to make sure we don't go writing over the ends of buffers and stuff | |||
| MasterDuke | well, i mean convert the MVMint64 parameter to an MVMuint64 | 15:51 | |
| jnthn | Oh | ||
| Yeah, that we can do | |||
| Though | |||
| A lot of the reason we have MVMint64 is because we receive the value in an i64 register | 15:52 | ||
| And so it's passed that way from the interp 'cus that's how the interp sees it | |||
| MasterDuke | yeah, and uints aren't handled well | ||
| which was also something i had tried to start on a fix for, but didn't make much progress | |||
| but Zoffix has also mentioned he might work on it | 15:53 | ||
| anyway, afk for probably until tomorrow, but will backlog if there are any further thoughts/comments | 15:54 | ||
|
16:08
brrt joined
|
|||
| jnthn | Urgh, no, things are even worse. Doesn't make much sense. :/ | 16:29 | |
| nwc10 | step away from the keyboard and check the stock level in the beer fridge? | ||
| jnthn | Either the predictor is really wrong, or we must have frames that start out getting promoted a lot and then cease to be | ||
| nwc10 | any test cases that the rest of us can play with? | ||
| Geth | MoarVM/frame-heap-prediction: 2184a05861 | (Jonathan Worthington)++ | 3 files Allocate frames on heap that will need promotion. By trying to use existing promotions as an indicator. This somehow seems to end up doing *worse* for the CORE.setting build, however it looks like it helps `make spectest` wallclock time a bit (though it's all within noise). |
16:34 | |
| jnthn | There's waht I tried | ||
| Off home now | |||
|
17:06
robertle joined
18:40
praisethemoon joined
|
|||
| timotimo | japhb: profiling moarvm while running the examples from that library gives a surprising amount of time spent in memset | 18:41 | |
| nwc10 | jnthn: frustratingly ASAN makes no comment | 18:46 | |
| but I'm guessing that wasn't the problem. It was "why is this slower?" | 18:47 | ||
| timotimo | yeah, it was | ||
| we might want to debug-printf stats about what exact frames used to get promoted (how often) and which frames are now being pre-promoted and post-promoted | 18:48 | ||
| nwc10 | oh gosh it's fast when you build O2 rather than ASAN :-) | 18:49 | |
| japhb | timotimo: Interesting. Maybe because of all the 2D-array slinging or the string joinging or the I/O? There's a lot of copying between backing buffers and the screen grid, and then outputting massive strings of grid updates to the TTY. | 20:04 | |
| (Terminal::Print::Grid should show a fair number of low-level and high-use actions.) | 20:05 | ||
| If you're seeing it in the particle-rendering code, that gets even more interesting, because there's a particle-to-grid-cell collation pass. | |||
|
21:04
mtj_ joined
|
|||
| lizmat | and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/07/31/...r-smaller/ | 21:22 | |
| timotimo | cool. fprinting the numbers that take part in the "if" for resolving annotations makes the "use of uninitialized value" messages go away | 22:35 | |
|
23:29
bisectable6 joined,
quotable6 joined,
committable6 joined,
evalable6 joined,
coverable6 joined,
greppable6 joined,
unicodable6 joined,
bloatable6 joined,
benchable6 joined,
statisfiable6 joined
23:51
sivoais joined
23:52
https_GK1wmSU joined
23:55
https_GK1wmSU left
|
|||