00:36:04 <esolangs> [[Yet Another Stack-Based Esoteric Programming Language]] https://esolangs.org/w/index.php?diff=176230&oldid=176226 * Hotcrystal0 * (+7) formatting fix
00:47:17 -!- amby has quit (Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement).
00:52:29 <esolangs> [[Brainfuck]] M https://esolangs.org/w/index.php?diff=176231&oldid=173481 * Lemonsandlimes * (+41) (made it more lighthearted)
00:55:09 <esolangs> [[Brainfuck]] M https://esolangs.org/w/index.php?diff=176232&oldid=176231 * Corbin * (-41) Undo revision [[Special:Diff/176231|176231]] by [[Special:Contributions/Lemonsandlimes|Lemonsandlimes]] ([[User talk:Lemonsandlimes|talk]]): Revert vandalism.
00:57:22 <esolangs> [[BitBitJump]] https://esolangs.org/w/index.php?diff=176233&oldid=165796 * Lemonsandlimes * (+6)
01:00:34 <esolangs> [[FlipJump]] https://esolangs.org/w/index.php?diff=176234&oldid=158975 * Lemonsandlimes * (+29)
01:06:28 <esolangs> [[Ook!]] https://esolangs.org/w/index.php?diff=176235&oldid=126808 * Lemonsandlimes * (+102)
01:10:32 <esolangs> [[Deadfish]] M https://esolangs.org/w/index.php?diff=176236&oldid=164304 * Lemonsandlimes * (+132)
01:13:02 <esolangs> [[BitBitJump]] M https://esolangs.org/w/index.php?diff=176237&oldid=176233 * Corbin * (-6) Undo revision [[Special:Diff/176233|176233]] by [[Special:Contributions/Lemonsandlimes|Lemonsandlimes]] ([[User talk:Lemonsandlimes|talk]]): revert vandalism.
01:13:15 <esolangs> [[Fish]] https://esolangs.org/w/index.php?diff=176238&oldid=173764 * Lemonsandlimes * (+65)
01:13:15 <esolangs> [[FlipJump]] M https://esolangs.org/w/index.php?diff=176239&oldid=176234 * Corbin * (-29) Undo revision [[Special:Diff/176234|176234]] by [[Special:Contributions/Lemonsandlimes|Lemonsandlimes]] ([[User talk:Lemonsandlimes|talk]]): revert vandalism.
01:13:27 <esolangs> [[Ook!]] M https://esolangs.org/w/index.php?diff=176240&oldid=176235 * Corbin * (-102) Undo revision [[Special:Diff/176235|176235]] by [[Special:Contributions/Lemonsandlimes|Lemonsandlimes]] ([[User talk:Lemonsandlimes|talk]]): revert vandalism.
01:13:38 <esolangs> [[Deadfish]] M https://esolangs.org/w/index.php?diff=176241&oldid=176236 * Corbin * (-132) Undo revision [[Special:Diff/176236|176236]] by [[Special:Contributions/Lemonsandlimes|Lemonsandlimes]] ([[User talk:Lemonsandlimes|talk]]): revert vandalism.
01:15:19 <esolangs> [[Fish]] M https://esolangs.org/w/index.php?diff=176242&oldid=176238 * Corbin * (-65) Undo revision [[Special:Diff/176238|176238]] by [[Special:Contributions/Lemonsandlimes|Lemonsandlimes]] ([[User talk:Lemonsandlimes|talk]]): revert vandalism.
01:15:36 <esolangs> [[User talk:Lemonsandlimes]] N https://esolangs.org/w/index.php?oldid=176243 * Corbin * (+383) Hi! Please stop vandalising for a moment and read the rules. Thanks!
02:10:12 <esolangs> [[User:Gilbert189/A way to golf Baba is You esolangs]] https://esolangs.org/w/index.php?diff=176244&oldid=150207 * Gilbert189 * (+50) added the new words
02:56:34 -!- impomatic has joined.
03:13:24 <esolangs> [[Befunge]] https://esolangs.org/w/index.php?diff=176245&oldid=170190 * JeffCalc84 * (+214) /* Calculator */
03:13:40 -!- impomatic has quit (Quit: Client closed).
03:35:09 <esolangs> [[Enn]] M https://esolangs.org/w/index.php?diff=176246&oldid=175929 * Las-r * (+32)
06:39:11 <esolangs> [[Output (WarzokERNST135)]] M https://esolangs.org/w/index.php?diff=176247&oldid=176196 * Dragoneater67 * (-7) /* Example programs */ SHORTEB
06:39:28 <esolangs> [[Output (WarzokERNST135)]] https://esolangs.org/w/index.php?diff=176248&oldid=176247 * Dragoneater67 * (+1) /* In Free2Edit */ casing
06:39:59 -!- ais523 has joined.
06:41:36 <ais523> int-e: my understanding is that CCC does have a 16-bit backend but the resulting code is very verbose, so it doesn't work to compile Linux because the code it's trying to compile doesn't fit into a single segment and thus doesn't work in the memory model they were using
06:42:18 <ais523> (remember memory models? apparently 64-bit processors have them too, but almost everyone uses the "the code fits into 4GiB and so does the data" memory model because it's rare to have more than 4GiB of code or static data)
06:43:48 <ais523> if you think about it, if your compiler doesn't do register allocation and is ignoring constraints on the size of the output, generating 16-bit asm or 32-bit asm or 64-bit asm are effectively equivalent (the only hard part would be arithmetic on values that are too wide for the processor)
06:49:40 <ais523> the «while self.pos < self.input.len() && self.input[self.pos].is_ascii_whitespace()» from korvo's link is also interesting – korvo was commenting on the "looks like generated code", but most notable to me is that it implies that the source code is being treated as a sequence of bytes (not unreasonable for a lexer), but interpreted as ASCII (which seems wrong nowadays)
06:50:43 <ais523> and it's very unidiomatic for a handwritten Rust lexer (which would likely be using an iterator over bytes or characters, together with Peekable to do lookahead)
06:54:47 <ais523> ooh… the comments talk about "GEP" (using an acronym directly without expanding it) and that language is clearly plagiarised from LLVM – in LLVM one of the most important operations is called "getelementptr", or "GEP" for short, but IIRC the LLVM devs consider it a bad idea and are trying to get rid od it
06:55:01 <ais523> and other compilers are unlikely to implement that operation in the same way
06:55:29 <ais523> of course, copying teminology from a widely-used compiler doesn't necessarily mean that you've copied code, but it's a bad sign
07:12:07 <b_jonas> ais523: what's the problem with ASCII whitespace only in this context?
07:13:15 <ais523> b_jonas: it's the «self.input[self.pos]» which implies that the lexer can't see multibyte characters at all, because it is reading the input a byte at a time and not using a state machine to recognise, e.g., UTF-8 leading bytes
07:14:00 <ais523> so the problem isn't so much that it's only matching ASCII whitespace, but that it's unable to match multibyte characters for any purpose (which is why it had to use is_ascii_whitespace – Rust has is_whitespace too but it doesn't work given the way that input was read)
07:14:58 <ais523> (there's also the side problem that "ASCII whitespace" isn't well-defined – Rust uses a definition that excludes \v)
07:15:24 <ais523> …and that includes \r, which I guess is inevitable so that \r\n parses, but \r isn't a whitespace character
07:15:58 <ais523> (except on MacOS classic)
07:16:18 <b_jonas> ais523: oh, you didn't say what type self.input is, and I assumed it's just a [u8] containing utf-8 encoded bytes read directly from the source code file, in which case that works fine even if there can be multi-byte characters
07:16:32 <ais523> b_jonas: I also assume it's just a [u8]
07:16:49 <ais523> I agree that this could technically be mixed with something that processes multibyte characters
07:17:01 <zzo38> Unless the multibyte characters are a part of the syntax, or if it uses Shift-JIS or something like that (where the ASCII characters that are in the range of the second byte of Shift-JIS are used), te lexer should just treat them as several bytes.
07:17:10 <b_jonas> and I think it's fine to accept bare \r as a whitespace character, though I don't know what the C or C++ standard specifically says
07:17:15 <ais523> but if so it would be weird to limit the whitespace handling to ASCII
07:17:33 <ais523> b_jonas: the C standard is flexible in the matter, it permits doing that but doesn't require it
07:17:35 <zzo38> (Although, Shift-JIS is not as good as other encodings such as EUC-JP)
07:17:35 <b_jonas> no, in source code I would accept only ascii whitespace
07:17:44 <b_jonas> like in C or rust source code
07:18:02 <ais523> does Rust really not accept non-ASCII whitespace (outside string literals / comments)?
07:18:44 <ais523> <Rust reference> Whitespace is any non-empty string containing only characters that have the Pattern_White_Space Unicode property.
07:18:53 <zzo38> I think it is reasonable to only parse ASCII, and non-ASCII can only be used in string literals and comments
07:19:02 <ais523> it explicitly lists U+2028 and U+2029 as being whitespace
07:19:31 <b_jonas> you're right, https://doc.rust-lang.org/nightly/reference/whitespace.html says it accepts some non-ASCII whitespace. I didn't know that.
07:19:35 <ais523> (although, in situations where it cares about the distinction between horizontal and vertical whitespace, it treats them as horizontal which leads to some weird consequences)
07:20:19 <ais523> zzo38: I think this depends on the context – there are definitely contexts where doing that is reasonable
07:21:15 <zzo38> (Non-ASCII could also be used in character literals, although in that case maybe you should need to declare the character encoding before that should work)
07:21:22 <ais523> for example Perl doesn't assume the source code's encoding unless you explicitly specify it within the source code itself – on systems that are expected to be ASCII- or UTF-8-based it assumes that bytes in the 0x00-0x7F range are ASCII but doesn't make assumptions about what bytes outside that range might mean
07:22:08 <zzo38> I think that is a reasonable way to do it; it is compatible with both ASCII and UTF-8, as well as many other things such as EUC-JP
07:23:27 <b_jonas> I was thinking about something like this for trying to design the syntax of the esoteric language Enchain, and I decided that it's best to say that LF is the only vertical whitespace for the purpose that in a double-quoted string you are allowed to have any bytes other than LF and double quotes for its literal meaning. a future extension could still accept other multi-byte characters as vertical
07:23:33 <b_jonas> whitespace in other context, but they have to accept those vertical whitespace in double-quoted strings.
07:24:17 <zzo38> Is there the document for the Enchain?
07:25:15 <zzo38> What you say can work (although depending on how the programming language works, it might or might not be reasonable to also disallow null characters)
07:25:23 <b_jonas> mind you, the first version of Enchain probably won't have double-quoted strings, but it WILL probably have an escape to output the rest of the line unchanged into the C source code output, and that will also output any whitespace other than LF literally, because I'm not parsing those C lines
07:26:10 <b_jonas> zzo38: I described some details of Enchain on IRC, but I don't have a full document, and I don't even have a full design in my head yet, because I have a lot of questions about how control flow and variables should work, there's part of the theory that I don't understand and might have to ask about it here
07:32:44 <b_jonas> so in the compiler I want to track the graph of all possible control flow to be able to check that any local variable is initialized before it's used, and run a very simple typechecking. this much is simple. but, possibly not in the first version of the language but later, I might want to allow nested functions that can access local variables from their surrounding function, and it's not clear to me yet
07:32:50 <b_jonas> how this combines with tracking the variables.
07:35:41 <b_jonas> the most likely situation is that the first version of the language will just forbid nested functions entirely, and I'll never make a later more advanced version
07:36:26 <b_jonas> so I'll only have local variables and compilation unit global variables
07:50:25 -!- laerling has quit (Server closed connection).
07:50:35 -!- laerling has joined.
07:57:54 -!- Sgeo has quit (Read error: Connection reset by peer).
08:01:41 -!- tromp has joined.
08:48:03 -!- ais523 has quit (Quit: quit).
09:09:50 <esolangs> [[A+B Problem]] https://esolangs.org/w/index.php?diff=176249&oldid=175073 * RikoMamaBala * (+34)
09:42:58 <esolangs> [[Tip]] https://esolangs.org/w/index.php?diff=176250&oldid=132738 * Yayimhere2(school) * (+13) /* Relationships to other languages / language families */
10:01:39 <esolangs> [[User:NoWhy]] M https://esolangs.org/w/index.php?diff=176251&oldid=166118 * NoWhy * (-21)
10:02:00 <esolangs> [[User:NoWhy]] M https://esolangs.org/w/index.php?diff=176252&oldid=176251 * NoWhy * (-106)
10:15:12 <esolangs> [[Talk:End]] https://esolangs.org/w/index.php?diff=176253&oldid=137513 * Blashyrkh * (+179)
10:58:17 -!- ais523 has joined.
11:24:25 -!- int-e has quit (Server closed connection).
11:24:35 -!- int-e has joined.
11:39:04 -!- amby has joined.
12:06:36 -!- lisbeths has joined.
12:39:59 <esolangs> [[User:PKMN Trainer/Sandbox]] N https://esolangs.org/w/index.php?oldid=176254 * PKMN Trainer * (+64) Created page with "Function is a programming language made by [[User:PKMN Trainer]]"
13:00:54 -!- impomatic has joined.
13:49:31 -!- ais523 has quit (Quit: quit).
14:28:04 -!- msv has quit (Remote host closed the connection).
14:28:28 -!- msv has joined.
14:31:19 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
14:58:11 <esolangs> [[M]] https://esolangs.org/w/index.php?diff=176255&oldid=172968 * Yayimhere2(school) * (+29) Undo revision [[Special:Diff/172968|172968]] by [[Special:Contributions/Yayimhere2(school)|Yayimhere2(school)]] ([[User talk:Yayimhere2(school)|talk]])
14:58:22 <esolangs> [[M]] https://esolangs.org/w/index.php?diff=176256&oldid=176255 * Yayimhere2(school) * (+152) Undo revision [[Special:Diff/172967|172967]] by [[Special:Contributions/Yayimhere2(school)|Yayimhere2(school)]] ([[User talk:Yayimhere2(school)|talk]])
14:59:11 <esolangs> [[M]] https://esolangs.org/w/index.php?diff=176257&oldid=176256 * Yayimhere2(school) * (-38)
15:07:47 -!- tromp has joined.
15:14:50 -!- ais523 has joined.
15:42:40 <esolangs> [[Yet Another Stack-Based Esoteric Programming Language]] https://esolangs.org/w/index.php?diff=176258&oldid=176230 * Fly * (+415)
15:43:17 <esolangs> [[Yet Another Stack-Based Esoteric Programming Language]] https://esolangs.org/w/index.php?diff=176259&oldid=176258 * Fly * (+32)
15:44:09 <esolangs> [[Yet Another Stack-Based Esoteric Programming Language]] https://esolangs.org/w/index.php?diff=176260&oldid=176259 * Fly * (-24)
15:47:49 <korvo> ais523: What I find interesting is what *wasn't* copied from LLVM. I'm very surprised that the backend isn't using NOLTIS and tiling.
15:48:16 <ais523> korvo: isn't that copied from the lecture notes of every compiler course ever? :-D
15:48:24 <korvo> It was kind of fun to see the exact same logic in my lexer and theirs.
15:48:53 <ais523> if you just want an instruction selection algorithm that's correct, and don't care about performance at all, there probably isn't a reason to use actual registers
15:49:16 <korvo> ais523: Yeah! Or nowadays, at least. It's like a 2008 algorithm, so it doesn't show up in some older compilers. It also doesn't show up in ad-hoc compilers like the older GL shader compilers.
15:49:32 <ais523> "let's create a stack allocation for every temporary and just use %rax to move them back and forth" is both simple and obviously correct, it's just horrifying performance-wise
15:50:19 <ais523> fwiw, I was reading up on NOLTIS and suspect that it isn't the last word in instruction selection – it's fast and near-optimal on its own, but doesn't interact well with register allocation algorithms
15:50:47 <ais523> so I think there might be space for a "near optimal, linear-time, instruction selection and register allocation" algorithm
15:50:52 <ais523> (but I don't know how it works)
15:52:14 <ais523> fwiw I have a suspicion that in code with large inner loops, a good register allocation (especially one that minimizes the number of registers used) is more important than a good instruction selection algorithm (ccc fails horribly at register allocation, to the extent that it's hard to tell how good the instruction selection algorihtm is)
15:53:07 <ais523> most compilers use a spilling algorithm in which everything starts off in spill slots, and then those get optimised to overlap each other and/or replaced by registers
15:53:29 <ais523> I think that's backwards – my approach would be to start with everything in (virtual) registers and force it into spill slots only when necessary
15:53:58 <ais523> although I suspect the two approaches might just end up equivalent when nontrivial amounts of optimisation are applied, it would make a big difference at -O0
16:02:41 <esolangs> [[Yet Another Stack-Based Esoteric Programming Language]] M https://esolangs.org/w/index.php?diff=176261&oldid=176260 * Dragoneater67mobile * (+5) /* Stack manipulation */ typo fix
16:03:37 <esolangs> [[Yet Another Stack-Based Esoteric Programming Language]] M https://esolangs.org/w/index.php?diff=176262&oldid=176261 * Dragoneater67mobile * (+13) formatting
16:04:24 <esolangs> [[Yet Another Stack-Based Esoteric Programming Language]] https://esolangs.org/w/index.php?diff=176263&oldid=176262 * Dragoneater67mobile * (+5)
16:06:52 <korvo> ais523: Yeah. I wonder whether we've been scared for too long due to the NP-hardness of register allocation. Folklore says that a greedy virtual-register algorithm, which first computes a program using hundreds of registers and then slowly pares it down by spilling, must miss some optimal solutions or else P=NP. But maybe optimal solutions aren't actually that big of a deal?
16:07:28 <korvo> Like, AFAIK there's usually not a performance impact from *using* a GPR on the typical architecture. So if you already have a solution that fits within your GPR budget then there's no need to push for an optimal solution.
16:07:29 <ais523> the real question is as to whether there's a good polynomial time approximation
16:07:58 <korvo> Instead the reason to avoid using registers is to avoid imposing spill or save/restore costs on *callers*.
16:08:05 <ais523> so I think there is a reason to try to push the GPR budget smaller
16:08:39 <ais523> and that's that it allows for better interprocedural optimisations, which both help beyond the point where you can't reasonably inline, and reduce the amount of inlining that's required for good performance
16:08:53 <ais523> right, you keep the GPR budget low so that the caller doesn't have to spill so mich
16:09:59 <ais523> looks like https://en.wikipedia.org/wiki/APX is the relevant computational class for this sort of thing
16:20:00 <korvo> I wonder whether this is another win for static linking. I could imagine that DLLs/DSOs could be separately optimized prior to release, or perhaps optimized on-device during installation, to reduce the cost of fastcalls. I don't remember which ABIs support that sort of dynamic fastcall though.
16:20:57 <korvo> ...Maybe I skipped ahead a little. I was imagining that whole-program compilation of an executable would use a different register-allocation strategy than compiling a reusable DSO.
16:30:02 <ais523> I can imagine the equivalent of a DLL import library stating how many registers each function uses, so that the importing code could optimise around that
16:30:18 <ais523> but it probably wouldn't be too useful because then you wouldn't necessarily be able to swap the DLL out with a newer version
16:30:57 <ais523> hmm, what's the generic term for "callable things provided by a DLL"? "symbol" is too general but "function" not general enough
16:32:21 <korvo> Same reasoning applies to GOT and PLT. We want the early binding, but we still hardcoded some of the names so it's already partially bound. A compromise between the early- and late-binding camps.
16:33:56 <ais523> oh, maybe "procedure" is the generic term, the acronym "PLT" uses it for that purpose
16:34:43 <ais523> (although when I was first learning programming, the terminology of the time was that a "procedure" was unable to return a value)
16:35:46 <korvo> (And then there's "routine" from the dinosaur years)
16:38:30 <ais523> hmm, is a subroutine like a smaller routine?
16:55:00 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
17:08:02 <fizzie> Maybe it's a static call stack depth thing. `main` is the (only) routine, the things it directly calls are sub-routines, the things called from there are sub-sub-routines, and so on.
17:11:01 -!- tromp has joined.
17:11:19 <ais523> hmm, does this make the shell a superroutine?
17:11:48 <ais523> or maybe the dynamic loader
17:20:33 <esolangs> [[User:PKMN Trainer/Sandbox]] https://esolangs.org/w/index.php?diff=176264&oldid=176254 * PKMN Trainer * (+1107)
17:26:26 <esolangs> [[Special:Log/move]] move * PKMN Trainer * moved [[User:PKMN Trainer/Sandbox]] to [[Functionable]]: moving to namespace
17:29:12 <esolangs> [[Functionable]] https://esolangs.org/w/index.php?diff=176267&oldid=176265 * PKMN Trainer * (+56)
17:39:20 -!- impomatic has quit (Quit: Client closed).
17:58:34 <b_jonas> ais523: what's the difference between a spill slot and a virtual register?
17:58:55 <ais523> spill slots have a memory address
17:59:32 <ais523> whereas virtual registers can be a single GPR, or repeatedly moved between GPRs, or spilled onto the stack into a spill slot
18:00:01 <b_jonas> ais523 “the terminology of the time was that a ‘procedure’ was unable to return a value” => because that's the Pascal terminology. now we use scheme terminology, where a procedure can return a value or even multiple values
18:01:01 -!- gAy_Dragon has quit (*.net *.split).
18:01:16 -!- A_Dragon has joined.
18:01:31 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
18:03:28 -!- tromp has joined.
18:06:31 <fizzie> I think canonical FORTRAN terminology is that you can have a FUNCTION (can return a value), or a SUBROUTINE (cannot return a value), but both of them are a type of procedure.
18:08:21 <fizzie> FORTRAN 77: "A subprogram is a program unit that has a FUNCTION, SUBROUTINE, or BLOCK DATA statement as its first statement. A subprogram whose first statement is a FUNCTION statement is called a function subprogram. A subprogram whose first statement is a SUBROUTINE statement is called a subroutine subprogram. Function subprograms and subroutine subprograms are called procedure subprograms."
18:08:34 <fizzie> I have to say, "subroutine subprogram" is a bit of a mouthful.
18:09:38 <int-e> Should be popular with streamers with all those subs.
18:10:04 <fizzie> I wonder if people discussing the FORTRAN 77 standard sometimes abbreviated them to "funsubs" and "subsubs".
18:12:39 <b_jonas> int-e: yeah, the terminology there is just as confusing. "subscribe" on Youtube and "follow" on Twitch are the free thing; "subscribe" on Twitch is and "join" on Youtube is where you pay money to the provider
18:13:18 <fizzie> Remeber to like and subscribe, and click the bell.
18:15:39 <HackEso> 51) <oklopol> actually just ate some of the dog food because i didn't have any human food... after a while they start tasting like porridge \ 82) <Gregor> Well yeah, but furthermore unlike, oh, say, an Apple product, you don't have to sign their "we own your sperm" license agreement to GET that SDK and the requisite libraries. [...] <Gregor> pikhq: Sure, but it's the only way Apple could get a first-born-son clause into a modern licensing agreement without
18:15:49 <HackEso> This is something people on the channel like to talk about. We're often unsure what this is, though. Nobody likes this.
18:15:58 * pikhq meows after a random ping
18:42:21 -!- impomatic has joined.
18:42:39 <fizzie> Oh, is there no anti-ping mechanism in HackEso quote listing? I guess there isn't.
18:47:51 <esolangs> [[Binary-encoded Minsky machine]] https://esolangs.org/w/index.php?diff=176268&oldid=144805 * RikoMamaBala * (+275) Corrected grammar errors
18:48:47 -!- ais523 has quit (Quit: quit).
18:51:48 <esolangs> [[1BNWL]] M https://esolangs.org/w/index.php?diff=176269&oldid=155592 * RikoMamaBala * (+0)
18:55:35 -!- lisbeths has quit (Quit: Connection closed for inactivity).
19:36:25 -!- iovoid has quit (Quit: iovoid has quit!).
19:40:31 -!- iovoid has joined.
19:45:42 -!- Lord_of_Life_ has joined.
19:46:41 -!- Lord_of_Life has quit (Ping timeout: 272 seconds).
19:48:35 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
19:53:49 <korvo> Ugh, had a good pun, now must resist the urge. Viola: a derivative of Cello which is capability-safe, mostly by omitting features of C. Like Vixen, compiles to execline. Could be practically used to make lightweight syscall wrappers.
19:57:26 -!- A_Dragon has changed nick to gAy_Dragon.
20:22:31 -!- ais523 has joined.
20:30:51 -!- JAA has quit (Server closed connection).
20:31:02 -!- JAA has joined.
20:33:02 -!- impomatic has quit (Quit: Client closed).
20:41:39 -!- pikhq has quit (Server closed connection).
20:41:50 -!- pikhq has joined.
20:46:36 -!- ais523 has quit (Quit: quit).
21:15:10 -!- int-e has quit (Quit: Reconnecting).
21:15:19 -!- int-e has joined.
22:10:51 -!- jix_ has quit (Server closed connection).
22:11:10 -!- jix has joined.
22:30:41 -!- Lord_of_Life has quit (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine).
22:31:34 -!- Lord_of_Life has joined.
23:04:42 -!- Sgeo has joined.
23:36:59 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
23:48:10 -!- pool has joined.