00:01:01 -!- tromp has joined.
00:05:15 -!- tromp has quit (Ping timeout: 246 seconds).
00:06:59 -!- tromp has joined.
00:07:47 -!- tromp has quit (Read error: Connection reset by peer).
00:08:19 -!- tromp has joined.
00:14:05 -!- tromp has quit (Ping timeout: 240 seconds).
01:06:17 <zzo38> These are my ideas so far of the mirror protocol: http://sprunge.us/GZT9QV
01:06:50 <zzo38> Please make a comment of it.
01:08:02 -!- oerjan has joined.
01:08:25 -!- arseniiv has quit (Ping timeout: 256 seconds).
01:12:08 -!- privateger has quit (Quit: Leaving.).
01:14:17 -!- clog has joined.
01:18:38 -!- ais523 has joined.
01:18:49 <ais523> hey, I have a ridiculous question, so this seemed like a good channel to ask it
01:19:12 <ais523> I'm trying to mmap over NULL to make my process's virtual address 0 a valid address; it seems that by default you can do this as root, but not as a regular user
01:19:39 <ais523> I vaguely remember there's a kernel setting that makes doing that legal even for regular users; does anyone here happen to know/remember what it is, or should I go hunting for it? it's hard to search for
01:21:16 <oerjan> i vaguely remember that was a possible security hole?
01:21:21 <zzo38> I don't know what it is; I have not heard of that before, though.
01:21:28 <ais523> yes, it's the vmsplice security hole from 2008, now patched
01:21:41 <ais523> (the context is a code-golfing-like situation, I'm wondering how many bytes / uops it's theoretically possible to save in a hot loop, and it crosses my mind that you can simplify things by having the loop end at address 0 so that the check for the loop end is simpler)
01:22:13 * oerjan doesn't know the answer, anyway
01:22:21 <fizzie> Yeah, there was a sysctl for it, right?
01:22:39 <ais523> I already found the solution where you just add a SIB byte to every memory access containing a nonzero value, and use that as a "virtual zero"
01:22:43 <ais523> also the solution using segment registers
01:22:49 <ais523> but both of those add at least one additional byte
01:23:09 -!- hendursa1 has joined.
01:23:17 <fizzie> `` cat /proc/sys/vm/mmap_min_addr
01:23:29 <fizzie> Sounds plausible to me.
01:23:30 -!- hendursaga has quit (Ping timeout: 268 seconds).
01:23:57 <ais523> thanks, I wasn't 100% sure that someone would know it off the top of their head, but this place seemed as likely as any
01:24:26 <fizzie> I had a faint recollection you had to change that to make dosemu work right.
01:24:57 <ais523> the funny thing is, this is the sort of code that a) wants to map over NULL, *and* b) wants to use vmsplice
01:25:05 <ais523> I bet at the time of the fix, nobody thought that was a legitimate combination
01:27:17 <ais523> this isn't documented in either proc(5) nor mmap(2) (and the return value is EPERM which isn't supposed to be caused by this)
01:27:34 <ais523> actually, Linux's userspace/kernel-interface documentation is rather more lacking than I'd hoped
01:27:49 <ais523> I had to read about four files of kernel source code to figure out what vmsplice actually does
01:28:46 <ais523> (what it does is to take a page of memory from your process, flag it as copy-on-write, then mmap it directly into a pipe buffer so that reads from the pipe will read from your process's memory if you don't change it before the read, or from a copy of the memory if you do)
01:29:46 <ais523> so vmsplice to the write end of a pipe, followed by another process reading from the read end, only copies the data once (in read); if you write rather than vmsplice, the data gets copied twice (on both write and read)
01:30:12 <ais523> but the caveat is that if you modify the page in question at all before the pipe gets read, the kernel has to copy the entire page containing the data you wrote, rather than just the data itself (and also adjust page tables, which is slow)
01:30:40 -!- ais523 has quit (Quit: sorry for my connection).
01:30:52 -!- ais523 has joined.
01:31:28 <ais523> the kernel devs were hoping to implement vmsplice for the read end of a pipe, too, but couldn't think of a good way to handle the mapping *into* user space, so right now it's effectively just an alias for readv that only works on pipes
01:33:45 <ais523> maybe I should just use a %fs: prefix, although there's little documentation as to how expensive those are; my guess would be that they're cheap due to the need to support backwards compatibility for 32-bit programs, but I may be wrong
01:35:03 <zzo38> Actually, I also found the documentation for some Linux features (including stuff in /proc) to be incomplete
01:35:39 <ais523> I don't even think there's an official piece of documentation anywhere for how you make a system call from userspace
01:35:48 <ais523> in terms of calling convention and ABI
01:36:21 <ais523> (although there seems to be a consensus that all registers are call-preserved, including the flags and argument registers, with the exception of %rcx and %r11, and the return value %rax)
01:36:32 <shachaf> Isn't it used for thread-local storage on Linux nowadays? Or is that gs?
01:36:52 <ais523> shachaf: so the idea is that you have a loop with a pointer that points to useful memory, but also doubles as the loop counter
01:37:00 <ais523> and the loop ends when the pointer hits 0
01:38:01 <ais523> in order to use this pointer usefully, you can either a) make it an index rather than a pointer (requiring a base register and a SIB byte); b) mmap over NULL so that 0 is a valid address; or c) use a segment override so that the pointer with value 0 actually points to some part of virtual memory other than the bottom
01:38:18 <ais523> segment overrides used to be much more complex in 16-bit and 32-bit x86
01:38:48 <ais523> but in x86-64, there are only two segment overrides that do anything (%fs: and %gs:), and their effect is unrelated to the actual value in the %fs or %gs registers
01:39:52 <ais523> each of them just adds a constant offset to the address it modifies; there are a few different ways to specify the constant (but typically, you tell the kernel what constant you want and it sets up the processor according to the offsets you requested during context switches)
01:40:59 <ais523> thread-local storage takes advantage of the fact that each thread is context-switched to separately by the kernel, so each thread is given its own %fs base by the threading library, which points to the start of the thread's thread-local storage
01:41:23 <shachaf> Isn't the constant offset the value in the %fs register?
01:41:27 <ais523> which means that at the assembly level, accessing (say) the 33rd byte of TLS is as simple as %fs:(32)
01:41:39 <ais523> that would be the logical thing to do, but they're actually unrelated
01:41:43 <ais523> in most cases, the value in the register is 0
01:42:37 <ais523> (the exception is that writing to the register will write the offset, too; but the relationship between the value you write and the offset that is loaded is not the identity function, it's actually calculated using a lookup table that on Linux, you can specify using the modify_ldt system call)
01:42:52 <ais523> only the values in the lookup table are only 32 bits long for some reason
01:43:24 -!- tromp has joined.
01:43:26 <ais523> so in general, you don't ever write to %fs or %gs directly
01:43:40 <ais523> you can write to the offset registers, %fsbase and %gsbase, directly on some recent Intel processors
01:43:46 <ais523> which is what you probably actually wanted to do
01:43:49 <shachaf> I see, fsbase and fs are different things?
01:44:33 <shachaf> And these are set by some MSR.
01:44:48 <fizzie> I learned the other day that both Linux and Windows swapped the segment override they're using for TLS when going from x86-32 to x86-64; since they started out using the opposite registers, they still do.
01:45:05 <ais523> right, if you don't have wrfsbase/wrgsbase instructions, you need to use an MSR to set them (which is why you need a system call to set them in Linux, because only the kernel can write MSRs)
01:45:33 <ais523> fizzie: I have no idea why you'd pick %fs or %gs in particular for this
01:45:36 <shachaf> If I remember correctly it's also impossible to even get the fsbase/gsbase value directly.
01:45:50 <fizzie> ais523: There's a SWAPGS instruction, but no SWAPFS counterpart, that's what I was given as the reason.
01:45:59 <shachaf> And so Linux stores the value of gsbase at %gs:0 or something like that.
01:46:03 <ais523> shachaf: it *was*, but Intel added RDFSBASE recently
01:46:24 <ais523> I think there are still lots of processors that don't have it, though, it's fairly new
01:46:47 <zzo38> Will the instruction be emulated on computers that don't have it?
01:46:59 <ais523> fizzie: I realise that, but it's unclear what the performance properties are
01:47:00 <shachaf> You might hope that nowadays something like lea %fs:0, %rax would be valid.
01:47:21 <HackEso> 0: 64 48 8b 14 25 00 00 00 00 mov %fs:0x0,%rdx
01:47:36 <HackEso> 0: 48 8d 14 25 00 00 00 00 lea 0x0,%rdx
01:47:45 -!- tromp has quit (Ping timeout: 240 seconds).
01:47:54 <ais523> shachaf: lea ignores segment registers
01:48:01 <ais523> I was curious about this myself, so decided to test it
01:48:09 <ais523> and gas actually produced a warning telling me that it doesn't work
01:48:27 <HackEso> 0: f3 48 0f ae c2 rdfsbase %rdx
01:48:29 <shachaf> Yes, but you might hope otherwise, in long mode.
01:48:58 <ais523> wow, the "f3 48 0f" prefix seems so dirty
01:49:01 -!- tromp has joined.
01:49:06 <ais523> even though that is the only legal ordering for the prefixes
01:49:34 <shachaf> `asm .byte 0x64, 0x48, 0x14, 0x25, 0, 0, 0, 0
01:49:35 <HackEso> 0: 64 48 14 25 fs rex.W adc $0x25,%al \ 4: 00 00 add %al,(%rax) \ ...
01:49:49 <shachaf> `asm .byte 0x64, 0x48, 0x8d, 0x14, 0x25, 0, 0, 0, 0
01:49:50 <HackEso> 0: 64 48 8d 14 25 00 00 00 00 lea %fs:0x0,%rdx
01:50:14 <shachaf> So it is encodable, it just ignores it.
01:50:22 <ais523> that's a totally valid instruction, but its actual effect is to write 0 to %rdx
01:50:43 <ais523> `asm lea 0, %fs:0(%rdx)
01:50:44 <HackEso> /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: too many memory references for `lea' \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: junk `:0(%rdx)' after expression
01:50:51 -!- hendursaga has joined.
01:50:54 <ais523> `asm lea %fs:(0), %rdx
01:50:55 <HackEso> 0: 64 48 8d 14 25 00 00 00 00 lea %fs:0x0,%rdx
01:51:01 <fizzie> Well, it's named after "load effective address", and the effective address is by definition before segments.
01:51:15 <fizzie> That's what distinguishes it from the linear address.
01:51:17 <ais523> you'd need a "load linear address" to get the post-segmentation value
01:51:35 <ais523> maybe even a "load physical address" to get a complete set
01:52:28 <shachaf> Well, I wouldn't expect to get physical addresses in userspace.
01:52:29 -!- hendursa1 has quit (Ping timeout: 268 seconds).
01:52:44 <ais523> it doesn't seem that ridiculous of a thing to be able to do at CPL 0
01:53:10 <ais523> the implementation of vmsplice needs to get physical addresses, for example
01:53:29 <ais523> the kernel has to do a page walk in order to figure it out, duplicating the work that the processor does in hardware
01:53:47 -!- tromp has quit (Ping timeout: 272 seconds).
01:53:51 <ais523> (a side effect of this is that vmsplice runs faster if you're using hugepages)
01:55:08 <ais523> so basically, what I'm saying is that LPA should probably be restricted to kernel space, but there are plenty of processor instructions that are restricted to kernel space
01:59:07 <zzo38> Does x86-64 have emulation of invalid instructions (either not implemented or not allowed)?
01:59:55 <ais523> zzo38: indirectly; an invalid instruction causes a #UD trap, which the kernel gets an opportunity to react to
02:00:25 <ais523> on physical hardware, most kernels will react to this by causing a SIGILL instruction; however, a kernel could if it wanted to emulate the instruction then return (there is sufficient information in the trap for this)
02:00:56 <zzo38> It can help then, if a program uses instructions that your computer doesn't have, the kernnel can emulate it, or if it uses a privileged instruction that the user program has sufficient privilege to use
02:01:03 <shachaf> I remember reading that Windows used to use illegal instructions to do system calls, because they were faster than a regular interrupt for some reason.
02:01:26 <ais523> the "canonical illegal instruction" that you're supposed to use for intentional SIGILLs is ud2, and I vaguely remember that the reason for the name is that there was once also a ud1 instruction, intended to "soft extent" the instruction set by having the kernel handle the #UD trap
02:01:44 <ais523> but I can't find documentation for ud1 in either the Intel or AMD guides, so maybe it was removed
02:02:11 <ais523> (that said, if the kernel is going to be assigning a meaning to ud1 combinations, maybe they aren't a good suggestion for intentionally illegal instructions)
02:02:38 <shachaf> https://www.felixcloutier.com/x86/ud also talks about ud0
02:03:21 <shachaf> I remember this subtlety about decoding ud0 without the modrm byte.
02:06:04 <ais523> `asm .byte 0x0f, 0xff, 0x00
02:06:07 <HackEso> 0: 0f ff 00 ud0 (%rax),%eax
02:06:17 <ais523> `asm .byte 0x0f, 0xb9, 0x00
02:06:18 <HackEso> 0: 0f b9 00 ud1 (%rax),%eax
02:06:22 <ais523> `asm .byte 0x0f, 0xf1, 0x00
02:06:23 <HackEso> 0: 0f f1 00 psllw (%rax),%mm0
02:06:34 <ais523> `asm .byte 0x0f, 0x1f, 0x00
02:06:48 <ais523> so it seems that ud0 and ud1 take two arguments each
02:07:23 <ais523> incidentally, I recently realised that it's possible to at least encode a vectorized NOP, by following the normal rules for vectorising other instructions
02:07:27 <ais523> but I got a SIGILL when I tried
02:07:48 <ais523> along similar lines you can write a vectorized ud0 or ud1 or ud2
02:08:14 <ais523> these will presumably also give a SIGILL, and there may be some debate about whether they're real instructions or not because a SIGILL is the expected effect :-)
02:13:10 <kmc> isn't there at least one OS that uses ud2 as its syscall instruction?
02:13:40 <ais523> I actually had a crazy idea of using pagefaults as a system call instruction
02:13:46 <ais523> this would allow for things like memory-mapped pipes
02:14:20 <ais523> the advantage is that you could remove a lot of loop logic from the userspace side, whereas the kernel side may well not be any slower
02:14:39 <ais523> (although, I think `syscall` is meant to be faster than all the other ways of doing system calls)
02:15:07 <kmc> hmm, if a store causes a pagefault, can the handler get access to the value which was to be written?
02:15:13 <kmc> on x86 i don't think it can :/
02:16:09 <kmc> can you get the exact bytes of the instruction which faulted in order to emulate it? of course you can get %rip and read the program memory but that might have a race condition in some crazy circumstance
02:17:01 <ais523> I think you're supposed to just read %rip, although I can imagine the crazy circumstance in which the race condition occurs
02:17:49 <ais523> at least the plus side is that the race condition can be handled by looking at the bytes to see if they're an instruction that could have produced the sort of fault you see, emulating if so, and just returning and rerunning the instruction otherwise
02:18:03 <kmc> yeah it's not that crazy really. just multithreading + self modifying code
02:18:17 <ais523> because that won't produce any results that you couldn't have seen with a slightly different method
02:18:23 <ais523> err, a slightly different timing
02:18:36 <ais523> this isn't self-modifying code, but other-modifying code
02:19:32 <ais523> from the processor's point of view, it would show up as an RFO for L1c data, which is not a path that's going to be used pretty much ever
02:19:40 <kmc> wtf is rdfsbase?
02:19:44 <kmc> i thought the long mode fs base was in a msr
02:19:55 <ais523> it returns the "value of the msr"
02:20:14 <kmc> so why not use rdmsr
02:20:18 <ais523> although, from various discussion of MSRs, I have the strong suspicion that they don't actually exist as separate entities within the processor
02:20:25 <ais523> rdmsr is privileged, and possibly slower?
02:20:34 <kmc> what do you mean by "separate entities"
02:20:51 <ais523> rdmsr and wrmsr seem to be processor-level system calls, they're basically just function calls
02:20:59 <kmc> are you saying that they're microcoded
02:21:09 <ais523> yes, and they can apparently be microcoded to do anything
02:21:27 <kmc> that's fair
02:21:34 <ais523> one of the workarounds for one of the spectre vulnerabilities was to add a new MSR that emptied the branch target buffer when written
02:21:38 <kmc> wrmsr is to opcodes as ioctl is to syscalls :P
02:21:42 <ais523> and which returns 0 when read
02:22:30 <ais523> it strikes me as very unlikely that Intel would have added a physical register with that specific behaviour to the processors they'd actually released and not told anyone out of it, so it's probably some sort of virtual register that exists only in microcode
02:22:41 <ais523> * not told anyone about it
02:23:28 <ais523> anyway, if rdmsr is microcoded, I can easily imagine that a hardwired rdfsbase would be faster
02:23:50 <kmc> fair enough
02:24:03 <kmc> and the fs base does pretty much have to be in a hardware register
02:24:31 <kmc> i mean also all the user visible registers are virtual in some sense
02:24:58 <kmc> there's not an actual specific set of 64 flip flops corresponding to RAX, not anymore
02:25:14 <kmc> with out of order and speculative execution the ISA registers are assigned to physical registers on the fly
02:25:28 <kmc> but that's still different from executing arbitrary microcode of course
02:25:54 <ais523> yes, there are tens or hundreds of actual physical registers, and the only purpose register names like rax is to let the processor know which outputs of which instructions should be connected to which inputs of which other instructions
02:26:50 <ais523> although, there *is* an actual register rax, but it isn't used most of the time (its purpose is to remember what data is in the register the programmer thinks of as "rax" in the case that rax isn't mentioned for a very long time but its value becomes relevant again in some later code, without being overwritten)
02:27:34 <ais523> if a register isn't used for so long that it falls out of the register allocation table, the processor needs some way to remember where it's storing the value of the register in question, that's why there's a permanent register file
02:28:27 <ais523> apparently old Intel processors had a bandwidth limitation on the permanent register file, and the processor would stall if you suddenly accessed three registers simultaneously that hadn't been accessed for ages, although that's been fixed in more recent processors
02:29:59 <kmc> does the VT-x VMCS contain MSRs? it must have some
02:30:01 <kmc> like the FS base
02:30:18 <kmc> so those are sort of promoted to ISA registers and are not really "model specific" in the same way
02:30:26 <ais523> I don't know, I haven't looked into how virtualisation is implemented
02:30:30 -!- oerjan has quit (Quit: Later).
02:30:37 <ais523> arguably, the virtualisation is itself a model
02:30:42 <ais523> I wonder if it can define its own MSRs
02:31:05 -!- Lord_of_Life has quit (Ping timeout: 240 seconds).
02:31:13 <kmc> I think you can set it to trap to the hypervisor on all MSR access
02:31:19 <ais523> oh, something else aggravating that I discovered recently is that Intel and AMD encode their cache information differently in the CPUID output
02:31:21 <kmc> probably intended so that you can emulate MSRs that don't exist on your physical CPU
02:31:52 -!- Lord_of_Life has joined.
02:32:19 <ais523> fortunately, the value you care most about in code is normally the size of the L2 cache, and although you get almost entirely zeroes if you use AMD's method for accessing cache information on an Intel processor, the value for the L2 cache size specifically is filled in in the same format that you get on an AMD processor
02:32:30 <ais523> so you just get a few random L2 cache parameters in a sea of zeroes
02:32:42 <ais523> presumably, Intel had to implement that to avoid breaking existing software
02:33:01 <ais523> (this is documented, too, as a guarantee that you can find the L2 cache information there)
02:34:21 <ais523> looks like it's L2 cache line size, L2 cache size, L2 cache associativity, and the other 29 values that the cpuid call is meant to return are all zeroes, and this is documented behaviour
02:34:40 <ais523> at least this makes it easy to write L2-cache-aware programs that function on both Intel and AMD processors
02:36:24 <kmc> cpuid is another wastebasket taxon of an instruction
02:36:30 <kmc> wasn't it used as a memory fence on some CPUs??
02:37:03 <ais523> not memory fence, though
02:37:06 <ais523> instruction ordering fence
02:37:21 <ais523> all the instructions before the cpuid are guaranteed to run before any instruction after the cpuid does
02:37:32 <ais523> there are a few other instructions with that property, cpuid might be the fastest though?
02:37:40 <ais523> it's vaguely useful for things like cycle-accurate benchmarking
02:38:02 <ais523> if you want a proper memory fence you need mfence, not cpuid, because I don't think cpuid guarantees things like stores having reached memory
02:39:47 <ais523> oh, it's also worth noting that most stores on x86 have an implicit sfence on them (you need to jump through hoops to get an un-sfenced store)
02:39:56 <ais523> so mfence and lfence are useful, but sfence is virtually useless
02:43:20 -!- tromp has joined.
02:47:36 -!- tromp has quit (Ping timeout: 240 seconds).
02:51:04 -!- tromp has joined.
02:55:25 -!- tromp has quit (Ping timeout: 240 seconds).
03:13:03 <ais523> oh wow, browsing instruction lists, I just discovered why LDDQU exists (when MOVDQU also exists)
03:13:31 <kmc> x86 is so stupidly complicated :(
03:13:39 <ais523> it's a different-performance-properties variant: LDDQU is designed to have high throughput for unaligned data which isn't being written at the time
03:14:01 <ais523> whereas MOVDQU is designed to have low latency, especially when the data has been written recently or is about to be written back
03:14:09 <kmc> interesting
03:14:17 <kmc> does that mean lddqu bypasses some caches?
03:14:37 <ais523> also LDDQU can over-read on either side and is explicitly allowed to read the same memory twice
03:14:44 <ais523> my guess is that LDDQU is bypassing the store-forwarding buffer
03:15:24 <ais523> (which you can think of as the "L0 cache")
03:15:39 <ais523> but it only caches writes, not reads
03:45:12 -!- tromp has joined.
03:49:58 -!- tromp has quit (Ping timeout: 256 seconds).
04:10:49 -!- tromp has joined.
04:14:26 -!- spruit11 has quit (Read error: No route to host).
04:15:05 -!- tromp has quit (Ping timeout: 240 seconds).
04:40:09 -!- craigo has joined.
04:58:11 -!- mich181189 has quit (Read error: Connection reset by peer).
04:58:26 -!- mich181189 has joined.
04:59:34 -!- sftp has quit (Quit: leaving).
04:59:51 -!- sftp has joined.
05:04:44 -!- tromp has joined.
05:05:26 <zzo38> Did you read the document I linked? Maybe you have some idea for improvement, too.
05:09:03 -!- tromp has quit (Ping timeout: 246 seconds).
05:28:01 -!- tromp has joined.
05:31:08 -!- delta23 has quit (Ping timeout: 272 seconds).
05:35:21 -!- tromp has quit (Ping timeout: 264 seconds).
05:44:24 -!- tromp has joined.
05:48:25 -!- tromp has quit (Ping timeout: 240 seconds).
06:15:15 <esowiki> [[PRINTASKSWITCHINPUTCASEXGOTOACASEYGOTOBELSEGOTOC]] https://esolangs.org/w/index.php?diff=80736&oldid=80723 * Quintopia * (+2019) Add implementation
06:18:26 <esowiki> [[User:Quintopia]] M https://esolangs.org/w/index.php?diff=80737&oldid=80090 * Quintopia * (+55) python impls
06:22:50 -!- tromp has joined.
06:27:06 -!- tromp has quit (Ping timeout: 246 seconds).
06:33:19 -!- tromp has joined.
06:34:39 -!- tromp_ has joined.
06:34:39 -!- tromp has quit (Read error: Connection reset by peer).
06:38:56 -!- tromp_ has quit (Ping timeout: 240 seconds).
06:41:26 -!- sprock has quit (Ping timeout: 272 seconds).
06:41:51 -!- sprock has joined.
06:52:13 -!- tromp has joined.
06:52:56 -!- ais523 has quit (Quit: quit).
06:55:32 -!- spruit11 has joined.
07:08:45 -!- sprock has quit (Ping timeout: 240 seconds).
07:52:46 -!- Sgeo has quit (Read error: Connection reset by peer).
08:21:36 -!- Arcorann has joined.
09:03:50 -!- LKoen has joined.
09:05:55 -!- hendursa1 has joined.
09:06:37 -!- hendursaga has quit (Ping timeout: 268 seconds).
09:09:03 -!- hendursaga has joined.
09:10:56 -!- hendursa1 has quit (Ping timeout: 268 seconds).
09:16:59 -!- imode has quit (Quit: Sleepy sheepy..).
09:20:30 -!- Lord_of_Life has quit (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine).
09:21:50 -!- Lord_of_Life has joined.
09:35:46 -!- tromp has quit (Remote host closed the connection).
09:56:05 -!- tromp has joined.
09:59:27 -!- metcalf has quit (Ping timeout: 265 seconds).
10:48:54 -!- x201 has joined.
10:50:02 -!- x201 has left.
11:04:44 -!- craigo has quit (Quit: Leaving).
11:25:36 -!- arseniiv has joined.
12:30:45 -!- Arcorann has quit (Ping timeout: 246 seconds).
12:31:33 -!- sftp has quit (Ping timeout: 272 seconds).
12:32:36 -!- sftp has joined.
13:03:18 -!- LKoen_ has joined.
13:05:18 -!- LKoen has quit (Ping timeout: 256 seconds).
13:19:31 <esowiki> [[Assignless]] M https://esolangs.org/w/index.php?diff=80738&oldid=52732 * PythonshellDebugwindow * (+60) Cats, stub
13:33:54 -!- rain1 has joined.
13:34:27 -!- tromp has quit (Remote host closed the connection).
13:52:15 -!- tromp has joined.
14:04:11 -!- Sgeo has joined.
14:21:06 -!- xelxebar_ has joined.
14:21:07 -!- xelxebar has quit (Ping timeout: 268 seconds).
14:25:36 -!- arseniiv has quit (Ping timeout: 240 seconds).
14:25:43 -!- rain1 has quit (Quit: Leaving).
14:42:08 -!- arseniiv has joined.
14:42:26 -!- hendursaga has quit (Quit: hendursaga).
14:43:10 -!- hendursaga has joined.
15:48:51 -!- Sgeo has quit (Ping timeout: 246 seconds).
16:41:35 -!- LKoen_ has quit (Remote host closed the connection).
16:44:07 <esowiki> [[Parse this sic]] https://esolangs.org/w/index.php?diff=80739&oldid=80692 * Digital Hunter * (+829) /* Example programs */ added a pi calculator program
16:45:08 <esowiki> [[Parse this sic]] M https://esolangs.org/w/index.php?diff=80740&oldid=80739 * Digital Hunter * (+53) /* Deadfish interpreter */
16:46:22 -!- LKoen has joined.
16:50:02 -!- Sgeo has joined.
17:06:43 <b_jonas> fungot: in English, do people really pronounce "chassis" with the final "s" silent? if so, why?
17:06:44 <fungot> b_jonas: madam president, i should just like to say that this problem cannot be available. mr bolkestein, i should like to take this stand because of certain wordings such as " the farmer's privilege'. i also think it is very important that this trend must now be incorporated into the constitution in its entirety to the whole of africa is dramatic. i am an optimist: this situation also has benefits. for in the final analysis, t
17:08:16 <b_jonas> I don't think that answers my question
17:10:13 <int-e> . o O ( faux francaise )
17:12:11 -!- metcalf has joined.
17:15:40 -!- metcalf has quit (Client Quit).
17:15:59 -!- metcalf has joined.
17:30:53 -!- metcalf has quit (Remote host closed the connection).
17:31:06 -!- metcalf has joined.
17:42:33 -!- metcalf has quit (Ping timeout: 264 seconds).
17:43:43 -!- metcalf has joined.
17:46:30 -!- tromp has quit (Remote host closed the connection).
17:50:41 -!- tromp has joined.
18:01:51 -!- ocharles has quit (Read error: Connection reset by peer).
18:02:02 -!- tromp has quit (Remote host closed the connection).
18:02:05 -!- ocharles has joined.
18:04:16 -!- metcalf has quit (Ping timeout: 240 seconds).
18:05:38 -!- metcalf has joined.
18:09:32 -!- tromp has joined.
18:14:08 -!- tromp has quit (Ping timeout: 256 seconds).
18:39:52 -!- tromp has joined.
18:45:15 -!- Lord_of_Life has quit (Ping timeout: 246 seconds).
18:46:20 -!- sprock has joined.
18:53:10 -!- tromp has quit (Remote host closed the connection).
19:00:47 -!- Lord_of_Life has joined.
19:08:28 -!- tromp has joined.
19:14:04 -!- LKoen has quit (Read error: Connection reset by peer).
19:14:32 -!- LKoen has joined.
19:22:12 -!- tromp has quit (Remote host closed the connection).
19:28:55 -!- tromp has joined.
19:37:18 -!- naivesheep has quit (Remote host closed the connection).
19:38:02 -!- naivesheep has joined.
19:58:37 <b_jonas> I called the customer service of a fast-food restaurant because they put fewer food into my delivery than I payed for. They gave me a coupon for my next order. The customer service rep on the phone told me that he'd talk to the restaurant and then call me back. fungot, do you think he really talked to the restaurant before calling me back, or is this just something they say?
19:58:37 <fungot> b_jonas: mr president, presidents of parliament pass by, honourable members, who will not, in the case of these condemned women. speaking fnord, the indiscriminate use of force and that is perhaps even more significant than others and it has the resources. the rapporteur has had to do was to protest about the electronics here. i am therefore favourable to these amendments on board, but they are some of the discussions on intern
19:59:06 <b_jonas> this euparl or brexit style isn't really suitable for these sorts of questions
19:59:08 <fungot> Available: agora alice c64 ct darwin discworld enron europarl* ff7 fisher fungot homestuck ic irc iwcs jargon lovecraft nethack oots pa qwantz sms speeches ss wp ukparl youtube
20:14:16 -!- tromp has quit (Remote host closed the connection).
20:15:00 <fungot> Selected style: qwantz (Dinosaur Comics transcriptions 2003-2011)
20:15:04 <b_jonas> I called the customer service of a fast-food restaurant because they put fewer food into my delivery than I payed for. They gave me a coupon for my next order. The customer service rep on the phone told me that he'd talk to the restaurant and then call me back. fungot, do you think he really talked to the restaurant before calling me back, or is this just something they say?
20:15:05 <fungot> b_jonas: here, i'll prove it, too, will take what i can get a little of that back with them, dromiceiomimus what's up, champ! here, have some lego. if people wanted traditional! they want new and sexy
20:22:38 <esowiki> [[Divrac]] M https://esolangs.org/w/index.php?diff=80741&oldid=80710 * Quintopia * (+0) fix truth-machine
20:26:11 <esowiki> [[Divrac]] https://esolangs.org/w/index.php?diff=80742&oldid=80741 * Quintopia * (+2207) impl
20:26:24 <esowiki> [[Divrac]] M https://esolangs.org/w/index.php?diff=80743&oldid=80742 * Quintopia * (-1) /* Python 3 */
20:26:51 <esowiki> [[Divrac]] M https://esolangs.org/w/index.php?diff=80744&oldid=80743 * Quintopia * (+0) /* Python 3 */
20:27:36 <esowiki> [[User:Quintopia]] https://esolangs.org/w/index.php?diff=80745&oldid=80737 * Quintopia * (+13)
20:43:38 -!- tromp has joined.
20:44:13 <esowiki> [[Divrac]] M https://esolangs.org/w/index.php?diff=80746&oldid=80744 * PythonshellDebugwindow * (+57) /* Semantics */ Fix typo; "clarify" n<2
20:46:21 -!- scoofy has quit (Ping timeout: 246 seconds).
20:51:55 <arseniiv> I’m reading “DSP tutorial for the braindead”. Some lore there
20:52:44 <arseniiv> I cornered myself up in trying to generate a sine wave most effectively, using nothing more than numpy
20:55:44 <arseniiv> also I want to experiment with noisy tonal oscillators and try to use convolution with a fake gaussian for that (piecewise quadratic for large sigmas and binomial for small ones, which I hasn’t implemented yet, and both I haven’t yet tested)
20:57:24 <arseniiv> the end goal is to mess with timbres with harmonics with various irrational rations between them, like golden ratio or sqrt(2). I’m a tad slow and lazy with all that though
21:04:41 -!- scoofy has joined.
21:15:11 <esowiki> [[Divrac]] M https://esolangs.org/w/index.php?diff=80747&oldid=80746 * PythonshellDebugwindow * (+40) /* Implementations */ See resources
21:15:51 <esowiki> [[Divrac]] M https://esolangs.org/w/index.php?diff=80748&oldid=80747 * PythonshellDebugwindow * (+121) /* External resources */ GitHub
21:25:33 -!- scoofy has quit (Ping timeout: 246 seconds).
21:33:07 -!- aloril has quit (Ping timeout: 260 seconds).
21:42:43 <arseniiv> kmc: I thought you might like this topic yeah :)
21:47:57 -!- arseniiv has quit (Ping timeout: 264 seconds).
21:55:46 -!- aloril has joined.
23:21:20 -!- tromp has quit (Remote host closed the connection).
23:31:35 <esowiki> [[Parse this sic]] https://esolangs.org/w/index.php?diff=80749&oldid=80740 * Digital Hunter * (-15) /* Fibonacci numbers */ shorter one ..
23:33:40 -!- mmmattyx has joined.
23:40:23 <esowiki> [[C = theNextIntegerThatComesAfterAnotherIntegerWithTheValueOf(c)]] N https://esolangs.org/w/index.php?oldid=80750 * CatCatDeluxe * (+4256) Created page with "C = theNextIntegerThatComesAfterAnotherIntegerWithTheValueOf(C) is a C-like programming language created to be very hard and annoying to read and write. It has the same langua..."
23:41:16 <esowiki> [[C = theNextIntegerThatComesAfterAnotherIntegerWithTheValueOf(c)]] https://esolangs.org/w/index.php?diff=80751&oldid=80750 * CatCatDeluxe * (+8)
23:45:15 <esowiki> [[C = theNextIntegerThatComesAfterAnotherIntegerWithTheValueOf(c)]] https://esolangs.org/w/index.php?diff=80752&oldid=80751 * CatCatDeluxe * (+66)
23:48:17 <esowiki> [[User:CatCatDeluxe]] https://esolangs.org/w/index.php?diff=80753&oldid=79923 * CatCatDeluxe * (+162)
23:48:41 <esowiki> [[User:CatCatDeluxe]] M https://esolangs.org/w/index.php?diff=80754&oldid=80753 * CatCatDeluxe * (+66)
23:49:20 <esowiki> [[C = theNextIntegerThatComesAfterAnotherIntegerWithTheValueOf(c)]] https://esolangs.org/w/index.php?diff=80755&oldid=80752 * CatCatDeluxe * (+64)
23:50:37 <esowiki> [[C = theNextIntegerThatComesAfterAnotherIntegerWithTheValueOf(c)]] https://esolangs.org/w/index.php?diff=80756&oldid=80755 * CatCatDeluxe * (+67)
23:50:49 -!- LKoen has quit (Quit: “It’s only logical. First you learn to talk, then you learn to think. Too bad it’s not the other way round.”).
23:56:52 -!- tromp has joined.