| --- Log opened Fri Dec 22 00:00:52 2017 |
| 00:08 | | Degi [Degi@Nightstar-hn99vf.dyn.telefonica.de] has joined #code |
| 01:01 | | Derakon[AFK] is now known as Derakon |
| 01:08 | | Jessikat [Jessikat@Nightstar-bt5k4h.81.in-addr.arpa] has quit [Connection closed] |
| 01:16 | | Kindamoody is now known as Kindamoody[zZz] |
| 02:12 | | ender948 [NSkiwiirc@Nightstar-uuul2b.lbvlil.sbcglobal.net] has joined #code |
| 02:12 | < ender948> | hi |
| 02:13 | <&McMartin> | 'lo |
| 02:38 | | ender948 [NSkiwiirc@Nightstar-uuul2b.lbvlil.sbcglobal.net] has quit [[NS] Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] |
| 04:00 | | Degi [Degi@Nightstar-hn99vf.dyn.telefonica.de] has quit [Connection closed] |
| 04:27 | | Derakon is now known as Derakon[AFK] |
| 05:36 | | celmin|away [celticminst@Nightstar-red7c7.dsl.bell.ca] has quit [[NS] Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.] |
| 07:21 | | Vornicus [Vorn@Nightstar-1l3nul.res.rr.com] has joined #code |
| 07:21 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 07:25 | | * McMartin manages to assemble, link, and run a GB ROM that displays some text. |
| 07:37 | <~Vornicus> | \o/ |
| 09:04 | <@abudhabi> | "Klingon software isn't released. It escapes." |
| 09:05 | <&McMartin> | Klingon chairs do not recline. They fall gloriously in battle. |
| 09:30 | | Kindamoody[zZz] is now known as Kindamoody |
| 09:52 | | * TheWatcher throttles the idiots responsible for the trainwreck that is this css |
| 10:01 | <~Vornicus> | what'd css do today |
| 10:43 | | Degi [Degi@Nightstar-hn99vf.dyn.telefonica.de] has joined #code |
| 10:54 | | gnolam [quassel@Nightstar-hsn6u0.cust.bahnhof.se] has joined #code |
| 10:54 | | mode/#code [+o gnolam] by ChanServ |
| 11:12 | | Jessikat [Jessikat@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
| 11:14 | <@TheWatcher> | Vornicus: I'm trying to use slick for a carousel. Works decently enough, except that the arrow buttons and dots are being screwed up by hilariously over-enthusiastic bullshit in the Must-Be-User-By-Order-Of-Manglement-Common-Look-And-Feel css from the uni web team. |
| 11:14 | <~Vornicus> | aha |
| 11:15 | < Jessikat> | try a multi web team instead |
| 11:26 | <@TheWatcher> | :P |
| 11:46 | <&jerith> | "Must-Be-User" -- that's one hell of an order for some CSS... |
| 11:49 | <@TheWatcher> | Blegh |
| 11:49 | <@TheWatcher> | Must-Be-Used :P |
| 11:54 | <&jerith> | So far I've only run into one adventofcode puzzle that really broke me, and that was because I misunderstood the question. |
| 11:55 | <&jerith> | But there are still three days to go. |
| 12:21 | | * TheWatcher HAIRPULLS |
| 12:23 | <&[R]> | Do they still pointlessly require you to do up a login? |
| 12:25 | <&jerith> | [R]: AoC? |
| 12:25 | <&jerith> | You need to log in with github, google, twitter, or reddit. |
| 12:26 | <~Vornicus> | registration/logging in generates your unique puzzle data |
| 12:26 | <&[R]> | So yes |
| 12:26 | <&jerith> | And it's not pointless, because puzzle input is personalised and you need to unlock part two of each day. |
| 12:26 | <~Vornicus> | This makes it so you get a slightly different problem from others, so you can't simply copy someone else's answer |
| 12:27 | <&jerith> | You can look at part one of each day without logging in, though. |
| 12:27 | <&[R]> | Ah, okay I guess that's fair |
| 12:27 | <&[R]> | IIRC last year you couldn't. All I saw was scoreboard and "please log in now" |
| 12:28 | <&jerith> | I can look at last year's without logging in, but if it changed since then it probably changed for all the years. |
| 12:29 | <&jerith> | The personalised input and unlocking of part two has been around since the beginning. |
| 12:35 | <@TheWatcher> | .mainContentContainer ul li:before { ... content: "\00BB"; font-size: 1em; } |
| 12:35 | <@TheWatcher> | Why would you do that, ffs |
| 12:43 | <~Vornicus> | can be, fortunately, beaten with a single id-based specification. which gets annoying when you're doing animation or transitions because you have to respecify the whole damn thing |
| 12:45 | <&[R]> | ? |
| 12:45 | <@TheWatcher> | Yeah, I just... seriously, I am having to resist the urge to find whoever did this and do very un-festive things to them with a fire extinguishr. |
| 12:47 | | * Vornicus adds glitter and snowflake confetti to the fire extinguisher contents |
| 12:56 | <~Vornicus> | now it is much more festive. |
| 13:05 | | VirusJTG [VirusJTG@Nightstar-42s.jso.104.208.IP] has quit [Connection reset by peer] |
| 13:05 | | VirusJTG [VirusJTG@Nightstar-42s.jso.104.208.IP] has joined #code |
| 13:05 | | mode/#code [+ao VirusJTG VirusJTG] by ChanServ |
| 13:14 | <~Vornicus> | (for those playing the home game: animation and transitions are done by using a 'transition' style rule, but you only get one, and so all transitions are overruled by a more specific one - even if the particular transition type you care about isn't being manipulated. have one type of thing you want to change color on hover, and another thing you want to grow in size? If something is both, you must include a style for the "both" type object |
| 13:14 | <~Vornicus> | that has both transitions, or you'll only get the transition for the one that wins the priority fight) |
| 13:45 | | Kindamoody [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has quit [Connection reset by peer] |
| 13:46 | | Kindamoody [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has joined #code |
| 13:46 | | mode/#code [+o Kindamoody] by ChanServ |
| 14:05 | | * simon_ shrugs |
| 14:10 | < simon_> | in the testing framework at work, you can test that an HTTP route works in two ways: you either make a request to '${servicename}_${actionname}' or you make a request to a literal URL, e.g. '/service/action'. those rarely correspond exactly. e.g. the actionname is always 'root' for the front page, but is typically '' in the URL. |
| 14:12 | < simon_> | when you're making an HTML form or a button point at some location, it's very convenient to use the '${servicename}_${actionname}' way, because in generating the URL, the framework can tell you if that thing doesn't exist any more, whereas if you're going for direct URLs, not so easy. |
| 14:13 | < simon_> | and when testing, I'd figure the same argument applies. e.g. you might want to rename the actual URL, but preserve the controller action. |
| 14:14 | <&jerith> | There are times when you want to know if the URL changed, though. |
| 14:14 | < simon_> | this one guy, though, keeps converting routes into URLs and tests on them instead. he says it's smart because he'll also test that the actual URLs that he determined when he add items to the routing table actually work. which is right. but I feel like it's a little half-hearted. |
| 14:16 | < simon_> | in specific, this helper method in the test framework is called 'require_user_login_ok', and it indirectly tests that the route is translated into whatever fixed string he placed. |
| 14:17 | < simon_> | and I think: if you really want to have a test that keeps the routing table in check, it should probably be a test like: route_is('someservice_someaction', '/service/welcome') |
| 14:18 | < simon_> | otherwise the test will fail with not being able to log in, not because authentication is broken, but because the URL is broken. i.e., when testing one thing, I want to sort of isolate that I'm testing *that* for no cascading effects. |
| 14:18 | < simon_> | doesn't that seem reasonable? |
| 14:19 | <&jerith> | That does seem reasonable. |
| 14:20 | < simon_> | just before starting at this job, I was correcting a lot of exam assignments, and it occurred to me that writing unit tests for assignments is not the same as writing unit tests for production code: in production, you assume that everything is right, and you want the odd case where it's wrong. in exams, you have to assume that they did things wrong in all the possible ways you can, otherwise when testing an A |
| 14:20 | < simon_> | PI and one thing is spat out slightly broken and it doesn't go into the next thing, you kind of evolve a list of broken ways to transform it back to something nice. |
| 14:21 | <&jerith> | For "internal" tests, you probably want to use route names only. For "external" (or "integration" or whatever) tests, you probably want to use URLs only. |
| 14:22 | <&jerith> | Heh. My tests for production code focus very much on all the things I can think of going wrong. |
| 14:22 | <&jerith> | This is why I like property-based tests where feasible. |
| 14:22 | < simon_> | I like them, too. I just wish people weren't so resistant to them. |
| 14:23 | <&jerith> | Why are people resistant to them? |
| 14:23 | < simon_> | I think because it messes with the structure of their existing unit tests. |
| 14:23 | < simon_> | I tried adding property-based tests at my former job and was told: but they're not deterministic! |
| 14:24 | < simon_> | and I said: but every time you run the entire test suite, you're actually generating new test cases for old things, too. and if anything ever breaks, it prints the seed value! |
| 14:25 | < simon_> | but I think the whole re-running a test with a specific seed has to be well-supported in the toolchain for it to be nice. |
| 14:28 | <&jerith> | Yeah. |
| 14:28 | <&jerith> | In the places where I have property-based tests, I typically also have example-based tests. |
| 14:29 | <&jerith> | Good tools (such as Hypothesis) allow you to pass a bunch of example input to your properties. |
| 14:29 | < simon_> | unit tests are just property-based tests with really boring properties. >:) |
| 14:29 | < simon_> | neat. |
| 14:30 | < simon_> | I've only used Erlang and Haskell's QC. |
| 14:30 | <&jerith> | What language(s) are you using for this stuff? |
| 14:30 | < simon_> | umm, my stuff at work? Perl. |
| 14:30 | < simon_> | using Test::More, Test::Mojo and some custom stuff on top. |
| 14:30 | <&jerith> | I've used property tools in scala, clojure, python, and a few others. |
| 14:30 | < simon_> | there's a pretty neat code coverage tool, too. |
| 14:31 | <&jerith> | Hypothesis is by far the nicest of all of them. |
| 14:31 | < simon_> | hm. |
| 14:31 | < simon_> | I think Haskell's has been the nicest for me. the Arbitrary type class is really just sweet. |
| 14:35 | < simon_> | okay, Hypothesis is also quite nice looking. |
| 14:36 | < simon_> | what they do with that @given decorator makes it look quite convenient. |
| 14:37 | <&jerith> | The thing I like about Hypothesis over the others is the flexibility with which I can define "strategies". |
| 14:38 | <&jerith> | A bunch of them, especially for languages with static typing, assume that "integer" is sufficient and don't make it easy to get "integer in the range [-5, 27]" or whatever. |
| 14:40 | < Jessikat> | whenever I see people talking about automated testing I find it bizarre that people seem to have forgotten how to test the behaviour of their functions is correct |
| 14:42 | <&jerith> | Jessikat: Do you include us in that? :-) |
| 14:43 | < Jessikat> | I don't know, I'm not awake enough to care x) |
| 14:43 | < Jessikat> | I just find it fascinating that when people talk about tests they only seem interested in whether the input space can be handled not the output result it produces |
| 14:43 | <&jerith> | I'm really terrible at testing. I find it quite depressing that most other people are even worse. |
| 14:44 | < Jessikat> | testing seems simple to me |
| 14:44 | < Jessikat> | you test a number of simple cases, you enumerate the edge cases and test those, you add regression tests as you find issues |
| 14:45 | < Jessikat> | a lot of people do this informally in debuggers when they're writing them then don't leave tests around to help them fix things in future |
| 14:45 | < Jessikat> | then they talk about unit testing like it's this mythical thing you can solve by using types |
| 14:45 | < Jessikat> | which is a secondary consideration at best ._o |
| 14:47 | < Jessikat> | there's only so much it makes sense to write unit tests for I guess |
| 14:47 | | * Jessikat shrugs |
| 14:47 | <&jerith> | Hrm. |
| 14:48 | <&jerith> | I'd say that viewpoint is "a good start", but not the whole story. |
| 14:48 | < Jessikat> | more complex systems require state, require setup and teardown, require good architectural underpinnings to even try to test in automated fashion |
| 14:48 | <&jerith> | It also depends very much on the kind of software you're working with. |
| 14:50 | < Jessikat> | regardless, types are not behaviour |
| 14:50 | <&jerith> | Indeed. |
| 14:50 | <@TheWatcher> | But mah strong typing!!one1~ |
| 14:51 | < Jessikat> | strong types are really important, they let you create guarantees |
| 14:51 | <&jerith> | But input space is important. Hypothesis regularly breaks all my code by deliberately feeding it NaNs and infinities. |
| 14:51 | < Jessikat> | sure, but it's not the most important thing about your code |
| 14:52 | < Jessikat> | and if you don't have any tests of the form that f(1) => 27 or whatever you failed despite the fancy automation |
| 14:52 | < Jessikat> | no-one seems to talk about the simplest kinds of tests like they're obvious |
| 14:52 | < Jessikat> | or worse, that you don't need to write them |
| 14:53 | < Jessikat> | but I'm mostly ranting about shit rn |
| 14:53 | < Jessikat> | and it *is* cool to automate discovering failure states in your implementation |
| 14:53 | < Jessikat> | but I think you can avoid those by writing code systemically better |
| 14:54 | <&jerith> | The great thing about a good property test system is that it automates the generation of your simple tests and feeds in all sorts of crap most people would never think to test. |
| 14:55 | <&jerith> | But as I said earlier, I like to toss in a few handcrafted examples as well just to make sure. :-) |
| 14:56 | < Jessikat> | but you aren't testing that your function is logically correct as a first step and that bugs me XD |
| 14:56 | <&jerith> | Almost all my work stuff (and most of the personal stuff I bother testing at all) has 100% branch coverage (modulo a few things that are explicitly excluded). |
| 14:56 | < Jessikat> | I can't write code without tests now |
| 14:56 | <&jerith> | I am testing that my function is logically correct. |
| 14:57 | < Jessikat> | how can you generate a function that tests your output is correct without hand-crafting it? |
| 14:57 | <&jerith> | In fact, properties (when done right) do that far better than any other mechanism I've seen. |
| 14:59 | < Jessikat> | don't get me wrong, I think automated test coverage is really cool so long as someone's actually written the basic tests for logical correctness first |
| 15:00 | <&jerith> | The canonical example (which isn't necessarily the best, but it makes the point reasonably well) is to test an implementation of addition by writing assertions for the basic properties of the mathematical operation and then generating piles of input to throw at those. |
| 15:00 | < Jessikat> | I just find it really strange that Haskell in particular seems obsessed with testing that input/output pairs are in the right range but not that they're a correct implementation of the function |
| 15:01 | <&jerith> | Actually, another not-particularly-good example that's easier to talk about is properties for a sorting function. |
| 15:02 | <&jerith> | You'd have properties that check things like "every item in the input is also in the output", "the size of the input and output are the same", "every item in the output is less than or equal to the item that comes after it", etc. |
| 15:04 | < Jessikat> | That sounds more like it |
| 15:04 | < Jessikat> | For sorting a more abstract functional approach makes complete sense actually |
| 15:05 | <&jerith> | You're not explicitly testing that "sort([1, 3, 2]) == [1, 2, 3]", but you're testing that all the things the make something "sorted" apply to the output no matter what (valid) input is given. |
| 15:06 | < Jessikat> | right, that may have flipped me on the idea for some spaces |
| 15:06 | <&jerith> | Designing good properties is significantly harder than writing a screenful of example tests, though. |
| 15:07 | < Jessikat> | aye |
| 15:07 | <&jerith> | A really common trap is to basically reimplement the thing you're testing in the test, which means it'll likely have the same bugs. |
| 15:07 | < Jessikat> | :D |
| 15:07 | < Jessikat> | this is one of the reasons I love raw data input/output handcrafted pairs |
| 15:07 | < Jessikat> | then you can't do that |
| 15:08 | <&jerith> | Although "oracle" tests (I can't remember where I got that name from) are useful if the behaviour is trivial but the implementation is not. |
| 15:08 | | * Jessikat nods |
| 15:08 | <&jerith> | A distributed key-value store is an example of that. |
| 15:09 | <&jerith> | "Do the same sequence of operations on my complex distributed system and this in-memory dict, fail if the results aren't identical." |
| 15:10 | <@TheWatcher> | I had great fun while trying to work out tests while modifying one of the twitter API modules. That sort of shit is my nightmare -_- |
| 15:11 | <~Vornicus> | I had "fun" trying to unit test payment processor interactions |
| 15:11 | <~Vornicus> | They had a sandbox, yes |
| 15:11 | <&jerith> | The problem I have with heavy reliance on example-based testing is that the examples aren't always representative. |
| 15:11 | <&jerith> | Vornicus: But the sandbox is different from production? |
| 15:11 | <@TheWatcher> | Vornicus: ouch. |
| 15:11 | <~Vornicus> | In this case the sandbox was *too accurate* |
| 15:11 | <~Vornicus> | In particular, in the real world, it usually takes several hours for payments to finish processing |
| 15:12 | <~Vornicus> | ...and so it was on the sandbox as well |
| 15:12 | <&jerith> | I had all sorts of fun testing my domain reselling codebase... |
| 15:12 | < Jessikat> | I just want people who write tests to acknowledge that handcrafted examples aren't pointless |
| 15:14 | <&jerith> | Jessikat: You're right, they're absolutely not pointless. :-) |
| 15:16 | <&jerith> | Quite a lot of the tests I've written recently have been "example" tests for stateful systems. |
| 15:18 | <&jerith> | https://github.com/praekeltfoundation/marathon_event_exporter/blob/develop/test/marathon_client_test.exs is a particularly annoying example of that. :-/ |
| 15:19 | <&jerith> | I really wish I knew a better way to that kind of thing. |
| 15:21 | <&jerith> | A lot of the testing stuff I like to talk about is kind of orthogonal to the sorts of tests being written. |
| 15:21 | <&jerith> | The idea of a "verified fake", for example. |
| 15:23 | <&jerith> | (It's sort of the opposite of the "oracle" thing I mentioned earlier - a simplified and malleable implementation of a thing your code needs to interact with. The "verified" bit is because you run the same set of tests against both the fake and the real implementation to guarantee that their behaviour is identical.) |
| 15:25 | <&jerith> | (Particularly useful with "microservices", because each service thing can ships its own verified fake for everyone else to use. Your tests become far lighter (no more managing twelve different external things in your tests) but you still keep the confidence you have that what you're testing is actually what you'll see in production.) |
| 15:28 | <&jerith> | Anyway, thanks for your input. It's definitely something I'll consider next time I'm talking about general testing stuff. :-) |
| 15:31 | < Jessikat> | I'm also massively biased towards soft realtime local, simple information transformationg systems |
| 15:31 | < Jessikat> | -g |
| 15:31 | < Jessikat> | thanks for showing me cases where it makes more sense XD |
| 15:33 | <&jerith> | The one place property-based testing has *really* saved me a whole lot time and energy has been serialisation logic. |
| 15:34 | <&jerith> | Write a property "assert input == unpack(pack(input))", write a moderately comprehensive strategy for generating representative input, write code until the tests pass. |
| 15:36 | < Jessikat> | that sounds pretty lush |
| 15:36 | <&jerith> | Because Hypothesis has such a fantastic "shrinking" mechanism, it's really good at spitting out close-to-minimal failing cases. |
| 15:37 | <~Vornicus> | Which you can then incorporate into your regular tests if you like 'em |
| 15:37 | <@TheWatcher> | Just idly: https://mobile.twitter.com/chrisalbon/status/943342608742604801 |
| 15:37 | <&jerith> | Yup. |
| 15:38 | < Jessikat> | I have literally no long-term projects at work on me right now |
| 15:38 | < Jessikat> | it's kind of weird |
| 15:38 | <&jerith> | I know that feeling. |
| 15:39 | < Jessikat> | my favourite quote from last week from one of the lighting guys working using tech that evolved from my rewrite of our tools and changing the culture around them - "I just did a day's work in ten minutes" |
| 15:40 | <&jerith> | In my case it's usually a pile of terrifying long-term projects that I can't start on now, but that's kind of similar. |
| 15:40 | <&jerith> | Jessikat: \o/ \o/ \o/ |
| 15:41 | < Jessikat> | my favourite part is that there's now a team of 4-5 coders working on this stuff and I moved onto other things |
| 15:42 | <&jerith> | So they replaced you on that project with medium sized team? ;-) |
| 15:43 | < Jessikat> | I encouraged the existing team to work in ways I wanted them to (which they bought into and added to) and now it's self-sustaining |
| 15:43 | <&jerith> | That's even better. |
| 15:43 | < Jessikat> | it's not my doing but it was my vision |
| 15:43 | < Jessikat> | not all my doing* |
| 15:43 | < Jessikat> | maybe not mostly my doing? |
| 15:43 | | * Jessikat shrugs |
| 15:45 | < Jessikat> | I replaced myself on the team because I wanted to work on making some other systems better in similar fashion, and because I'm going to be off work recovering from medical nonsense for a couple months in the new year |
| 15:47 | <&jerith> | I've found that having a positive impact on the culture and productivity of a team is more satisfying than building even the most elegant systems. |
| 15:48 | < Jessikat> | "You're the reason we have AAA standard tools" is another favourite quote of mine |
| 15:48 | < Jessikat> | well, that I've heard about me |
| 15:51 | <&jerith> | "You're the reason we can have nice things." |
| 15:51 | <&jerith> | Toolsmithing is a vastly underappreciated activity. |
| 16:05 | < Jessikat> | there's more than enough folk who appreciate it :) |
| 16:05 | < Jessikat> | they're the ones using it |
| 16:08 | <&jerith> | Yeah, but almost all the toolsmithing I've done has been on a "don't tell management about it until it's done" basis. |
| 16:16 | <&jerith> | One of the things I love most about my current role is that I answer only the the rest of the team (well, mostly) and nobody really cares as long as stuff keeps working. |
| 16:30 | < Jessikat> | :) to be fair the initial tools I built were done in a skunkworks fashion with the blessing of the tools lead, but then we made a game with them we could not have done otherwise |
| 16:30 | < Jessikat> | and it changed from "that's impossible" to "let's do more of this" |
| 16:32 | <&[R]> | A video game, or a contest? If the latter could you expand on that? |
| 16:33 | <&jerith> | My guess is the former, knowing some very vague things about the industry Jessikat works in. |
| 16:34 | < Jessikat> | heh yeah, a game :) |
| 16:34 | <&jerith> | Jessikat: Is this a game available to mortals who don't have Windows computers? :-) |
| 16:34 | <&jerith> | I don't think I've ever played anything you were involved in creating, and I'm vaguely curious. |
| 16:36 | <&jerith> | Relatedly, I humbly offer https://suspended-sentence.org/ which is the game I like most out of the ones I've been involved in creating. |
| 16:39 | <~Vornicus> | Checking Steam, I've played one of the four games listed for Jessikat's company, which I played on Wii. |
| 16:39 | < Jessikat> | heh, that one was made before I worked there |
| 16:52 | | Jessikat [Jessikat@Nightstar-bt5k4h.81.in-addr.arpa] has quit [[NS] Quit: Leaving] |
| 18:50 | | Vornlicious [Vorn@Nightstar-65jmrv.sub-174-210-16.myvzw.com] has joined #code |
| 18:52 | | Vorntastic [Vorn@Nightstar-1l3nul.res.rr.com] has quit [Ping timeout: 121 seconds] |
| 18:59 | | Kindamoody is now known as Kindamoody|afk |
| 19:05 | | Vornlicious [Vorn@Nightstar-65jmrv.sub-174-210-16.myvzw.com] has quit [Connection closed] |
| 19:05 | | Vorntastic [Vorn@Nightstar-60o.3mj.149.47.IP] has joined #code |
| 19:36 | | Vornlicious [Vorn@Nightstar-65jmrv.sub-174-210-16.myvzw.com] has joined #code |
| 19:38 | | Vorntastic [Vorn@Nightstar-60o.3mj.149.47.IP] has quit [Ping timeout: 121 seconds] |
| 19:52 | | Vornlicious [Vorn@Nightstar-65jmrv.sub-174-210-16.myvzw.com] has quit [[NS] Quit: Bye] |
| 19:52 | | Vorntastic [Vorn@Nightstar-1l3nul.res.rr.com] has joined #code |
| 20:56 | | Kindamoody|afk is now known as Kindamoody |
| 21:18 | | Vornotron [Vorn@Nightstar-1l3nul.res.rr.com] has joined #code |
| 21:18 | | mode/#code [+qo Vornotron Vornotron] by ChanServ |
| 21:21 | | Vornicus [Vorn@Nightstar-1l3nul.res.rr.com] has quit [Ping timeout: 121 seconds] |
| 22:30 | | Jessikat [Jessikat@Nightstar-i8fd39.skybroadband.com] has joined #code |
| 23:51 | | Kindamoody [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has quit [[NS] Quit: reboot] |
| 23:54 | | Kindamoody|autojoin [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has joined #code |
| 23:54 | | mode/#code [+o Kindamoody|autojoin] by ChanServ |
| --- Log closed Sat Dec 23 00:00:53 2017 |