| --- Log opened Fri May 05 00:00:54 2017 |
| 00:01 | | Jessikat` is now known as Jessikat |
| 00:07 | <&McMartin> | A highly aggressive approach to arena allocation |
| 00:35 | < RchrdB> | That's, like, the precise opposite of a compacting collector. |
| 00:35 | < RchrdB> | More of a garbage dispersal algorithm than a garbage collection algorithm. |
| 00:38 | <&McMartin> | I admit to a certain alarm that the system in question uses dynamic allocation at all. |
| 00:46 | < RchrdB> | Quite. |
| 00:46 | | RchrdB [RchrdB@Nightstar-qe9.aug.187.81.IP] has quit [[NS] Quit: Leaving] |
| 00:47 | | RchrdB [RchrdB@Nightstar-qe9.aug.187.81.IP] has joined #code |
| 00:48 | <&McMartin> | RchrdB: That said, many uses of static memory, like building a graph by storing indexes into that array out of an array of nodes, end up basically being half-assed dynamic allocation anyway. |
| 00:48 | < RchrdB> | Y'know what's a really hilarious prank to play on yourself by accident? Having both .bash_profile and .profile and they do subtly different things. |
| 00:48 | < RchrdB> | a.k.a. so THAT'S why stuff wasn't always reliably on my friggin' $PATH! |
| 00:49 | <&McMartin> | One of the old tutorials I've been working through actually manages to implement a procedure call stack in BASIC independent of the actual call stack. |
| 00:49 | <&McMartin> | Starting with "give me 1K of bytes plz" |
| 00:49 | <&McMartin> | It's kind of unnerving - my main goal with this tutorial is ultimately to translate the useful bits from BASIC into C |
| 00:50 | < RchrdB> | Go far enough down that rabbit hole and you find you've simply implemented a virtual machine inside BASIC with its own bytecode that has proper CALL instructions and so on. :) |
| 00:50 | <&McMartin> | Oh, this BASIC has real procedures, local variables, etc |
| 00:50 | <&McMartin> | This is for temporary allocations when interoperating with syscalls. |
| 00:50 | <&McMartin> | And it doesn't have a single GOTO or GOSUB in it |
| 00:50 | < RchrdB> | Does it? Can you recurse? |
| 00:50 | <&McMartin> | Yep! |
| 00:50 | <&McMartin> | And despite all that |
| 00:51 | <&McMartin> | Translating from BASIC into C will *increase* the amount of structure in the program |
| 00:51 | <&McMartin> | (Mainly because I'll be replacing some of the byte buffers with structs and relying more heavily on the machine stack for RAII-like stuff) |
| 00:51 | < RchrdB> | I didn't know that. I thought old fashioned BASIC interpreters had static lifetimes for all variables, including those local to functions, making reentrancy completely impossible. |
| 00:51 | <&McMartin> | When are you ending "old-fashioned" as an era |
| 00:52 | <&McMartin> | What you describe is certainly true for, say, GW-BASIC, which persisted into the 1990s |
| 00:52 | <&McMartin> | But it does not hold for later DOS Basics introduced in the late 1980s |
| 00:53 | <&McMartin> | QBASIC in particular is Basically Just Another Algoloid though it doesn't go out of its way to advertise this the way Visual Basic did. |
| 00:53 | < RchrdB> | Aha. |
| 00:53 | <&McMartin> | This is more of that BBC-Basic stuff, specifically BBC BASIC V which I think is again 90s era |
| 00:53 | <&McMartin> | And is in a weird midway point in terms of program abstraction compared to QBasic |
| 00:53 | < RchrdB> | so |
| 00:53 | <&McMartin> | It has *much* tighter hardware and OS integration, sufficiently so that much of the translation will be from commands to C compiler intrinsics that turn directly into syscalls |
| 00:54 | <&McMartin> | But it keeps line numbers everywhere, which QBASIC dropped in the mid 1980s |
| 00:54 | < RchrdB> | BBC BASIC: yes all lifetimes are static, reentrancy is impossible. QBASIC: it's actually secretly okay? |
| 00:54 | <&McMartin> | ... but unlike QBASIC it makes a huge issue out of it to the point that using line numbers is deprecated and makes your text editors yell att you |
| 00:54 | <&McMartin> | QBASIC: It's secretly OK |
| 00:54 | <&McMartin> | BBC BASIC: You're still typing 10 PRINT "ZOMGWTFBBQ" but it's blatantly OK |
| 00:55 | <&McMartin> | As someone whose experience with BASICs was strictly Microsoft descendants with an aside of Sinclair basic as a hilarious failparade |
| 00:55 | | Derakon[AFK] is now known as Derakon |
| 00:55 | <&McMartin> | BBC BASIC is in a real weird place |
| 00:56 | <&McMartin> | To the point that I would expect it to have a noticable impact on programming idioms from hackers about my age if they grew up in the UK vs not |
| 00:57 | <&McMartin> | I'm finding a lot of it very ugly, but it's ugly in ways I associate with slapdash asm. |
| 00:58 | < RchrdB> | well AFAIK there was the whole generation (in their early 40s now I think?) of programmers in the UK who grew up on BBC BASIC |
| 00:58 | < Jessikat> | some asshole taught me how to make an infinite loop in BBC BASIC then told me I knew secret hacking things and was likely to go to jail for it |
| 00:58 | <&McMartin> | Yep, checks out |
| 00:58 | <&McMartin> | Basically you could have probably gone a least an extra five years before BBC BASIC felt confining enough that you'd want to shift to C or similar |
| 00:58 | < RchrdB> | like AFAIK the whole of Bullfrog and studios like it came from that generation |
| 00:59 | <&McMartin> | And the thing that would finally get you to move would be not functions but structs |
| 00:59 | < RchrdB> | Haha yeah. |
| 00:59 | <&McMartin> | You'd already go in knowing pointers and functions |
| 00:59 | <&McMartin> | But you'd want structures more aggressive than "bag of bytes you can individually cast to ints" |
| 00:59 | < RchrdB> | Would it, though? The ability to just put in inline asm can keep people in for a long time. |
| 00:59 | <&McMartin> | You know what asm doesn't thave |
| 01:00 | <&McMartin> | structs |
| 01:00 | | Jessikat` [Jessikat@Nightstar-f4rt18.dab.02.net] has joined #code |
| 01:00 | <&McMartin> | (If the BBC BASIC assembler less you do symbolic offsets and such I haven't learned about that yet~) |
| 01:00 | < RchrdB> | Yar. |
| 01:00 | <&McMartin> | But yeah, you get kicked out of BASIC in the US because it's too slow and it doesn't let you talk to the hardware or OS in any meaningful ways that aren't pre-circumscribed |
| 01:00 | < RchrdB> | Structs are a thing that I think one could plausibly not notice that they're missing. |
| 01:01 | <&McMartin> | In DOS you can't even reliably do POKEs to get results, and while it turns out you do get access to the I/O bus, this was not widely advertised |
| 01:01 | <&McMartin> | Segmented architectures yey, etc |
| 01:01 | < RchrdB> | I mean if you come from a modern PL and try to use BASIC, you'll notice the lack of structs. |
| 01:01 | <&McMartin> | Mmm. Yes. That's where the OS binding comes in |
| 01:01 | <&McMartin> | Like, a bunch of the things this code I'm working through does |
| 01:02 | < RchrdB> | but if you start on BASIC and don't move off, it might not occur to you for years that your productivity is being gated by how hard it is to look up fields. |
| 01:02 | <&McMartin> | You do a syscall and one of the arguments is "a 256 byte block of workspace data to be filled in with stuff" |
| 01:02 | <&McMartin> | And the documentation for that will also totally mention C as a thing that exists, and also, uh, OSLib, which defines all the structs and typechecks the arguments and such |
| 01:02 | <&McMartin> | ... and which, ANAICT, is, autogenerated from documentation |
| 01:03 | <&McMartin> | And extremely bloated, distributed only as a binary, and difficult to link against reliably in the modern world once you're using more than one project, so I may have a go at the Radical Byte Array Anarchy method first, which requires two include files and one function call |
| 01:03 | <&McMartin> | (The second include file being the one that gives symbolic names to the constants you pass to the syscalls~) |
| 01:03 | < Jessikat> | my productivity at work today was being gated by the fact that types aren't first class objects in C++, or, indeed, any language I know of |
| 01:04 | <&McMartin> | Hrm. Aren't there, um, philosophical issues with that? |
| 01:04 | <&McMartin> | ISTR that types had to be abstracted into kinds for reasons besides implementation laziness |
| 01:05 | < Jessikat> | when I want to perform boolean tests on the capabilities of types, I shouldn't have to use a calling convention that uses angle brackets and colons when they're clearly just functions |
| 01:05 | < RchrdB> | "Radical Byte Array Anarchy" |
| 01:05 | < Jessikat> | if I had a built-in type type that was accessible at compile time, I could write much more succinct code |
| 01:06 | < Jessikat> | kinds feel like such a weird hack |
| 01:06 | < RchrdB> | it is now undeniable that the sandwich chart has been added to the set of things which your brain uses to describe the world |
| 01:06 | <&McMartin> | Jessikat: Set theory when you start getting sets of sets seems to go Hard Lovecraft really fast |
| 01:06 | < Vornotron> | interesting conversations everywhere aaaaaaaaaa |
| 01:07 | < RchrdB> | when you implement "types as first-class objects", you get Russel's paradox |
| 01:07 | < Vornotron> | Very, very fast. |
| 01:07 | < Jessikat> | McMartin: I can believe it, but god dammit why can't I write IsConst(Foo) && IsPrimitive(Foo) ? |
| 01:07 | < RchrdB> | there are 2 ways out that I know of |
| 01:07 | < Jessikat> | I'm effectively doing that by writing IsConst<Foo>() |
| 01:07 | < RchrdB> | 1 is the way python uses, which is just to not worry about it, the language is dynamic. in Python (type(type) is type) == True, and that's just not something that matters to anything. |
| 01:07 | < Jessikat> | well, std::type_traits::is_const_v<Foo>() or something like it |
| 01:07 | < RchrdB> | the second way I know of is the way that Coq uses |
| 01:08 | < Jessikat> | see, if you stop being anal about the types of things that aren't lvalues, life gets easier |
| 01:08 | < Jessikat> | :D |
| 01:08 | < Jessikat> | I'm convinced that Haskell is bonkers for abstracting the machine away almost entirely, but I understand why it tries to |
| 01:09 | < Jessikat> | it is a language concerned with Absolute Truth, except that there's virtually nothing in the world that works that way |
| 01:09 | < RchrdB> | (I might have details wrong because this is from memory), in Coq, the type of '1' is 'Natural', the type of 'Natural' is 'Set', the type of 'Set' is 'Set1', the type of 'Set1' is 'Set2' and so on |
| 01:09 | < RchrdB> | so there's an endless hierarchy of Set-N (types of types of types of typesâ¦) |
| 01:09 | < Jessikat> | the type of a type is just 'Type', which I suppose in Haskell is spelt *? |
| 01:10 | < RchrdB> | so you never get a term whose type is itself, so you never run into Russell's paradox |
| 01:10 | < Jessikat> | I don't care about statements beyond the first level (she says fully knowing that given access to said first level she'll care) |
| 01:10 | < RchrdB> | and in any given Coq program, you only ever happen to use a finite depth of Set-ness nesting |
| 01:10 | < Jessikat> | although honestly, what I *want* to be able to do is make statements about how things compile |
| 01:11 | < Jessikat> | which means that I likely don't care about type-types |
| 01:11 | < Jessikat> | I just think it's really foolish that there's so much syntax in C++ which is effectively functions that return types |
| 01:11 | < RchrdB> | Jessikat, in Haskell, values have types, types have kinds, and type-level programming is pretty much untyped. |
| 01:11 | < Jessikat> | std::vector<Foo> is a constructor for a type |
| 01:11 | < Jessikat> | I find Haskell weird in that way |
| 01:12 | < Jessikat> | values don't have types, representations have types |
| 01:12 | < Jessikat> | values are just symbols. types are sets of valid symbols with interpretations |
| 01:12 | < Jessikat> | this is a really frustrating thing in C++ |
| 01:12 | < RchrdB> | er⦠yes |
| 01:13 | < Jessikat> | a literal should be of 'literal' type and interpreted, but instead they get typed to machine types |
| 01:13 | < Jessikat> | which means you get stupid signed/unsigned conversions and coercions meaning that you get constructs like 1337u |
| 01:13 | < RchrdB> | s/values have types/names have types/ |
| 01:14 | < Jessikat> | perhaps |
| 01:14 | < RchrdB> | Haskell's way of dealing with that is that they use typeclasses for literals. |
| 01:14 | < Jessikat> | Haskell is in my bad books for teaching people that you need to know deep voodoo to go take a piss |
| 01:14 | < RchrdB> | â:t 1â in ghci will tell you that the type of the expression (1) is (Num a) => a. |
| 01:14 | < Jessikat> | I shouldn't need to know the mechanics of the flushing toilet to evacuate my bladder into it and pull the handle :< |
| 01:15 | < Jessikat> | I... may have gone off the deep end a bit tonight |
| 01:15 | < Jessikat> | I probably ought to go to bed |
| 01:19 | < Jessikat> | I think part of the problem I have with Haskell is that everyone treats it as deeply magical, when in reality it's not, it's just another language and it'd be easier to learn if it wasn't seen as some mystery |
| 01:20 | < Jessikat> | like, there's no 'you must have at least this IQ' bar to entry, but some people treat it that way |
| 01:21 | < RchrdB> | Yeah to Hell with those kids. |
| 01:21 | < Jessikat> | kids? |
| 01:22 | < Jessikat> | I still think 'side effects are a thing that Haskell achieves via the IO type, which is a placeholder for 'the world' in your functions', 'you can use 'do', which is a macro for sequencing your function calls in a nice way and scoping names' is a decent introduction to actually achieving anything in the language |
| 01:24 | < Jessikat> | (yes, yes, I know Haskell practitioners are convinced that there are no side effects in Haskell, but given that IO functions when evaluated produce effects you cannot specify symbolically, I argue there's no real difference except that it manages to abstract them efficiently) |
| 01:24 | < Jessikat> | (and using familiar names means people can grok things more easily) |
| 01:25 | <&McMartin> | That's merely an internal implementation detail in The World >_> |
| 01:26 | < Jessikat> | IO stands for Interactive Omnipotence? |
| 01:26 | < Jessikat> | one day I might try Haskell again |
| 01:27 | < Jessikat> | amusingly, I realised that a common component system architecture used by game engines effectively amounts to a runtime dynamic implementation of Haskell/Rust style typeclasses |
| 01:27 | < Jessikat> | tickled me slightly |
| 01:28 | < Jessikat> | (this assertion may fall down under scrutiny) |
| 01:28 | | Jessikat [Jessica@Nightstar-bt5k4h.81.in-addr.arpa] has quit [[NS] Quit: Leaving] |
| 01:39 | <&McMartin> | Entity-action frameworks often provide a neat solution to the issues introduced by multiple inheritance. |
| 01:39 | <&McMartin> | I haven't tried to map them to typeclasses, but it does pass the initial sniff test |
| 01:40 | < Jessikat`> | Inheritance is just shitty one dimensional composition |
| 01:40 | | Jessikat` is now known as Jessikat |
| 01:41 | < Jessikat> | I guess you can have multiple supersets, but classes conflate type with behavior |
| 01:41 | < Jessikat> | There's so much that C++ ought to answer for |
| 01:42 | <&McMartin> | I remember throwing together a cheap-ass Entity system in Scheme on a page or so of code just to put paid to one of the old "tricky problems" |
| 01:42 | <&McMartin> | MI's wackiness can't be laid solely at C++'s feet |
| 01:43 | <&McMartin> | If you ever want to feel the whistle of a bullet dodged, check out CLOS's resolution mechanism some time |
| 01:43 | < Jessikat> | I think most of what programmers think of as hard problems are caused by the fact that C++ never lets you abstract away from machine types |
| 01:44 | < Jessikat> | And yet there are many subsets of features in the language that would benefit greatly from never needing to worry what a pointer is |
| 01:45 | < Jessikat> | You can write remarkably quick code in C++ but it's amazingly easy to escape the thin veils of certainty it sometimes lets you define |
| 01:54 | <&McMartin> | "In an announcement on May 2, the director of NASA's Transformative Aeronautics Concepts Program (TACP) launched the High Performance Fast Computing Challenge, an effort to accelerate NASA's Modern Fortran-based computational fluid dynamics (CFD) software, FUN3D." |
| 01:55 | <&McMartin> | FUN3D |
| 01:57 | < Vornotron> | is that like love2d? |
| 01:58 | <&McMartin> | If it were in fortran and involved computational fluid dynamics |
| 02:19 | < RchrdB> | okay so typescript |
| 02:19 | < RchrdB> | is going on my "doesn't suck" list |
| 02:19 | | * Vornotron should look at typescript |
| 02:20 | < RchrdB> | I'm using it with VS Code on Linux |
| 02:20 | <&McMartin> | Hilariously, I've had better luck running VS Code on Linux than on Windows |
| 02:20 | < RchrdB> | there was a little fiddling with the installation, it makes my laptop fans spin up a little often |
| 02:20 | < RchrdB> | (specifically |
| 02:20 | <&McMartin> | Because of its interactions with the git/ssh plugins |
| 02:21 | < RchrdB> | (specifically, the manner in which the provided rpms install the 'tsc' binary appears to be impossible to ever work? I just installed the matching version of tsc myself with 'yarn' into some subdirectory and put it on my PATH) |
| 02:22 | < Vornotron> | I find myself increasingly tired of using systems that blow up on runtime instead of warning me about it as I'm programming |
| 02:22 | < RchrdB> | Vornotron, this far it seems to be working quite nicely for me, partly as "even without bothering to learn very much of it, I now have autocomplete for all the standard DOM functions and names) |
| 02:22 | < RchrdB> | ...I don't know how I managed to mismatch that punctuation so badly. |
| 02:22 | < RchrdB> | anyway |
| 02:22 | < RchrdB> | ALSO it does some other really nice things like compiling modern ES2015 javascript syntax into old ES3 shit. |
| 02:24 | < RchrdB> | e.g. let [first, second] = [1, 2]; // works in JS in Firefox, is a syntax error in JS in IE6, but works just fine in either after `tsc` turns it into plain old comprehensible-by-IE6 es3 era javascript |
| 02:25 | < RchrdB> | also also also |
| 02:25 | < RchrdB> | async/await |
| 02:25 | < RchrdB> | fuck vanilla JS right in the ear for not having that from day zero |
| 02:27 | <&McMartin> | > GODDAMN PUNK KIDS, EXIT LAWN |
| 02:27 | <&McMartin> | And man, over here in C++ land |
| 02:27 | <&McMartin> | I'm still champing at the bit for thenable futures :( |
| 02:28 | <&McMartin> | Also, a correction to various statements I've made over the past month or so |
| 02:28 | <&McMartin> | The stuff I've been messing with isn't really properly from the BBC Micro |
| 02:28 | < Vornotron> | i don't even know what a thenable future is |
| 02:28 | <&McMartin> | Though it is descended from it in at least the same way Apple II and Commodore machines were MS-descended |
| 02:28 | <&McMartin> | But the obvious patriarch machine here is the Archie by way of the RISC PC. |
| 02:29 | <&McMartin> | Vornotron: It's an asynchronous result that you hang further processing off of by use of a function named "then" |
| 02:29 | <&McMartin> | I think JS calls them "promises"? |
| 02:31 | < RchrdB> | afaik there's a distinction between promises and futures but i'm not super clear |
| 02:31 | <&McMartin> | My experience is that every communitty agrees there is a distinction but does not agree as to what the distinction is |
| 02:31 | < RchrdB> | when you construct a Promise in JS, you get passed a callback 'accept' and a callback 'reject'; you're to call the first if your thing succeeds or the second upon any kind of error. |
| 02:34 | <&McMartin> | Yep |
| 02:34 | <&McMartin> | C# has a similar construct with a name that's something like TaskCompletionSource, and then Java has CompletableFuture which was deprecated in favor of something like ProcessingStage |
| 02:35 | <&McMartin> | But they're all pretty obviously The Same Philosophical Construct. |
| 02:35 | <&McMartin> | Anyway, C++ has std::promise and it looks a lot like this |
| 02:35 | <&McMartin> | But the only things you can do with it are extract the value if it's there or block your thread until a value is placed there. |
| 02:36 | <&McMartin> | That makes them next to useless for actual asynchronous work without a supporting library like boost::asio |
| 02:36 | <&McMartin> | (And in order to do that, you have to call get_future() on the promise, so, heyo) |
| 02:44 | < RchrdB> | TBH the more I think about this stuff, the more I'd rather have Erlang's spawn_link() and green threads in most contexts instead. |
| 02:54 | <&McMartin> | ISTR Clojure admits that Erlang solved the Hardest Version of this problem :) |
| 02:55 | | Turaiel is now known as Turaiel[Offline] |
| 03:04 | | Turaiel[Offline] is now known as Turaiel |
| 03:18 | | Derakon [Derakon@Nightstar-5mvs4e.ca.comcast.net] has quit [[NS] Quit: Leaving] |
| 03:21 | | I [Derakon@Nightstar-5mvs4e.ca.comcast.net] has joined #code |
| 03:30 | | I is now known as Derakon |
| 03:30 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 04:19 | | Turaiel is now known as Turaiel[Offline] |
| 04:22 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 04:24 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 04:24 | | mode/#code [+o macdjord] by ChanServ |
| 05:03 | | Derakon is now known as Derakon[AFK] |
| 05:06 | | Kindamoody[zZz] is now known as Kindamoody |
| 05:15 | | Kindamoody is now known as Kindamoody|out |
| 06:19 | | celticminstrel is now known as celmin-of-nod |
| 07:13 | | Jessikat` [Jessica@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
| 07:29 | | Jessikat` [Jessica@Nightstar-bt5k4h.81.in-addr.arpa] has quit [[NS] Quit: Leaving] |
| 07:30 | | Jessikat` [Jessikat@Nightstar-e10s2k.dab.02.net] has joined #code |
| 07:33 | | Jessikat [Jessikat@Nightstar-f4rt18.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 07:35 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Connection closed] |
| 07:35 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 07:35 | | mode/#code [+o macdjord] by ChanServ |
| 08:41 | | Jessikat` [Jessikat@Nightstar-e10s2k.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 08:43 | | Jessikat [Jessikat@Nightstar-e10s2k.dab.02.net] has joined #code |
| 11:08 | | ion [Owner@Nightstar-gmbj85.vs.shawcable.net] has quit [Ping timeout: 121 seconds] |
| 11:10 | | ion [Owner@Nightstar-gmbj85.vs.shawcable.net] has joined #code |
| 11:47 | | RchrdB [RchrdB@Nightstar-qe9.aug.187.81.IP] has quit [Ping timeout: 121 seconds] |
| 11:48 | | RchrdB [RchrdB@Nightstar-qe9.aug.187.81.IP] has joined #code |
| 12:36 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Connection closed] |
| 12:36 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 12:37 | | mode/#code [+o macdjord] by ChanServ |
| 14:00 | | Jessikat` [Jessikat@Nightstar-ng7.klt.132.82.IP] has joined #code |
| 14:02 | | Jessikat [Jessikat@Nightstar-e10s2k.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 15:13 | | Jessikat` is now known as Jessikat |
| 15:20 | | mac [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 15:20 | | mode/#code [+o mac] by ChanServ |
| 15:22 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 16:19 | | celmin-of-nod is now known as celticminstrel |
| 16:43 | | Vornotron [Vorn@ServerAdministrator.Nightstar.Net] has quit [Operation timed out] |
| 18:00 | | Jessikat [Jessikat@Nightstar-ng7.klt.132.82.IP] has quit [Ping timeout: 121 seconds] |
| 18:05 | | mac [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [[NS] Quit: Subject 10: Developed dental hypertrophy, ocular luminescence, & extreme behavioural changes. Killed & partially consumed 2 graduate students. Euthanized with sustained automatic weapons fire.] |
| 18:31 | | Jessikat [Jessica@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
| 19:12 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 19:12 | | mode/#code [+o macdjord] by ChanServ |
| 19:12 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Connection closed] |
| 19:17 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 19:17 | | mode/#code [+o macdjord] by ChanServ |
| 19:17 | | mac [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 19:17 | | mode/#code [+o mac] by ChanServ |
| 19:18 | | mac [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [A TLS packet with unexpected length was received.] |
| 19:22 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [[NS] Quit: Subject 10: Developed dental hypertrophy, ocular luminescence, & extreme behavioural changes. Killed & partially consumed 2 graduate students. Euthanized with sustained automatic weapons fire.] |
| 19:22 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 19:23 | | mode/#code [+o macdjord] by ChanServ |
| 19:23 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Connection closed] |
| 19:23 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 19:23 | | mode/#code [+o macdjord] by ChanServ |
| 19:24 | | celticminstrel [celticminst@Nightstar-mb6eve.dsl.bell.ca] has quit [Ping timeout: 121 seconds] |
| 19:34 | | celticminstrel [celticminst@Nightstar-mb6eve.dsl.bell.ca] has joined #code |
| 19:34 | | mode/#code [+o celticminstrel] by ChanServ |
| 20:27 | | Vornotron [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 20:35 | | Vornotron [Vorn@ServerAdministrator.Nightstar.Net] has quit [Operation timed out] |
| 21:05 | | Madchen [Madchen@Nightstar-tn6m5r.com] has quit [[NS] Quit: Awoked] |
| 21:30 | | Vornotron [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 21:37 | | Vornotron [Vorn@ServerAdministrator.Nightstar.Net] has quit [Operation timed out] |
| 21:53 | | Kindamoody|out is now known as Kindamoody |
| 22:31 | | Vornotron [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 22:40 | | Vornotron [Vorn@ServerAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 23:04 | | Vornotron [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| --- Log closed Sat May 06 00:00:56 2017 |