00:05:10 <Soni> imagine being the first programming language to provide signal-safety while still having fully-featured signal handling
00:05:20 -!- Thelie has quit (Quit: Leaving.).
00:05:31 <Soni> (and being a pain to use, but we digress)
00:09:20 -!- X-Scale has quit (Quit: Client closed).
00:09:25 <korvo> I don't want to handle signals. I want to politely ignore their existence.
00:09:44 <korvo> Or, if I have an event loop, then I want signals to politely wait their turn.
00:18:18 <Soni> oh okay so you're not into challenges, got it
00:19:35 -!- X-Scale has joined.
00:28:57 <korvo> Indeed, I think that secure distributed computing should not be difficult. As a special case, I think that single-user single-machine computing should not be difficult.
00:29:51 -!- 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:36:13 -!- X-Scale has quit (Ping timeout: 256 seconds).
00:38:24 <Soni> why not make signal handling secure?
00:44:01 <ais523> korvo: I realised a while back that asynchronous signals are, in effect, a form of user input
00:44:54 <ais523> which is why handling them in the event loop makes sense
00:45:17 <korvo> Soni: Signals create "stale stack frames", so to speak; they interrupt a computation in a way that leaves cleanup unspecified.
00:45:22 <ais523> I can see potential exceptions for things like lease breaks in noninteractive code, though
00:45:42 <Soni> korvo: stack frames aren't real
00:46:08 <Soni> it's all global state
00:46:15 <ais523> like, say you're reading and processing a really large file, and then the OS tells you that some process is about to change the file while you're reading it, and if you don't stop reading it in 2 seconds you will get undefined behaviour
00:46:16 <korvo> Soni: How is an object supposed to preserve internal invariants if it can be interrupted at any moment and possibly never restored?
00:46:58 <ais523> I can see wanting to handle that without a full event loop
00:47:17 <Soni> korvo: there's an easy answer to that actually! how do you pre-poop your pants?
00:48:11 <ais523> <korvo> Soni: How is an object supposed to preserve internal invariants if it can be interrupted at any moment and possibly never restored? ← clearly by using only atomic changes
00:48:13 <Soni> you could make said object completely inaccessible ("leaking is safe")
00:49:15 <ais523> ah yes, "anything that is interrupted leaks" can also be a reasonable way to make things work sometimes, although if that rule is applied too blindly you end up leaking the entire computer
00:49:23 <ais523> which is safe but not particularly useful, or even particularly easy to define
00:49:33 <Soni> (and you should. the allocator? yeah, can't touch that anymore. you're welcome!)
00:50:13 <korvo> I know that event loops just came up, but we're not talking about politely pausing computation on an isolated actor and synchronizing its state using some sort of global orthogonal persistence. We were talking about UNIX-style signals.
00:50:46 <ais523> korvo: asynchronous UNIX-style signals can and should be handled in an event loop as long as you can make sure it runs often enough
00:50:49 <Soni> how do processes manage preempting-safety
00:51:11 <korvo> ais523: Yes, that's the right answer.
00:51:50 <korvo> But at that point they're not signals, but some sort of magic FD or magic syscall.
00:51:51 <Soni> okay, give us an event loop that can handle SIGSEGV :v
00:52:10 <ais523> the main exception is for noninteractive processes, where the correct behaviour is a little harder to define – you may need a "signal pump" specifically for interacting with signals, when the program doesn't take input normally
00:52:16 <ais523> Soni: SIGSEGV is a synchronous signal
00:52:35 <ais523> normally, at least (it is possible to send a process a synthetic SIGSEGV but doing so is very rare)
00:52:41 <int-e> and not one that you'd ordinarily handle
00:52:58 <Soni> SIGSEGV is the main reason to use signals
00:53:00 <ais523> int-e: handling synchronous SIGSEGV isn't a totally weird thing to do, there are libraries for it
00:53:11 <korvo> e.g. https://www.gnu.org/software/libsigsegv/
00:53:27 * int-e finds it ironic that the person who wants to eliminate globals is now asking to tackle a mechanism that's objectively worse cleanly.
00:53:32 <ais523> but at that point, it is happening in known locations of your code so it doesn't act at all like an asynchronous signal any more, just a weird sort of if statmenet
00:53:46 <korvo> Event loops really should be run on top of GC, but I can imagine wanting to handle them in the underlying runtime, and this sort of library
00:54:06 <Soni> most high-performance language VMs use it
00:54:08 <int-e> ais523: I still think it's not something you'd usually do.
00:54:09 <ais523> korvo: what do you mean by "on top of" here?
00:54:32 <int-e> But maybe I'm naive to think that.
00:55:14 <ais523> int-e: it's not something I'd normally do because I prefer the technique of allocating huge amounts of address space, in such a way that the physical memory backing it is allocated lazily
00:55:22 <Soni> (luajit, JVM, V8, wasm2c, ...)
00:55:23 <ais523> that way there are fewer calls into the kernel
00:55:35 <ais523> but I'm not sure how many OSes support that
00:56:20 <Soni> int-e: sometimes we shouldn't ask if we should, but if we can. and we think we can.]
00:56:22 <korvo> ais523: Like, the actual message-handling actions should not have to do any manual allocation. Google's Native Client is a good historic example of how it just can't be made secure.
00:56:27 <int-e> Soni: VMs aren't your usual application code.
00:56:30 <ais523> it is very useful to have some way to allocate memory lazily, though, and making use of the page fault if you access a paged-out page of memory is one of the better ways to do it
00:57:07 <ais523> korvo: are you talking about allocating memory in signal handlers?
00:57:20 <Soni> int-e: unless you're in #esolangs :p
00:57:32 <ais523> that was a huge problem for me in NH4 – malloc traditionally doesn't work in signal handlers and it took a while to figure out how to work around the issue
00:57:44 <int-e> Eh I'd rather piggy-back on an existing VM than write my own. YMMV.
00:57:56 <korvo> ais523: Huh, effectively, I guess yeah. I wasn't thinking of it that way.
00:58:26 <ais523> I'm pretty sure that it is possible to write an async-signal-safe malloc, at least in some programming languages (I think it might not be possible in Rust, though)
00:58:37 <ais523> (at least, not without inline asm)
00:59:32 <Soni> ais523: we don't want it
00:59:55 <ais523> I want an async-signal-safe malloc, at least
01:00:11 <int-e> Soni's pluralizing themselves all the time.
01:00:34 <Soni> we want this more than anything https://docs.rs/stdworld/0.1.1/src/std/lib.rs.html#1-156
01:01:05 <Soni> because why should a signal handler be able to use the allocator when the allocator isn't signal-safe
01:02:37 <Soni> why solve a problem when you can just avoid it instead
01:02:39 <ais523> this is easily fixed using capabilities, I think? being able to allocate memory is a type of capability
01:02:49 <ais523> you can make it available to most code, but not to signal handlers
01:03:08 <Soni> being able to allocate memory implies access to a &mut GlobalAllocator
01:03:40 <Soni> just gotta tie that &mut to regular code and forbid it from crossing into a signal handler
01:03:50 <ais523> the GlobalAllocator object is a type of capability, in that ase
01:03:58 <Soni> (just like Send and Sync prevent crossing into threads)
01:04:06 <ais523> code that has it can allocate, code that doesn't have it can't
01:04:36 <Soni> and unsafe code can make their own :v
01:04:54 <Soni> but why stop at allocators
01:05:25 <Soni> what happens if we move the entire global context and state into an object you carry around and pass into stuff
01:05:41 <ais523> Soni: I've been meaning to write a blog post on how to make doing that ergonomic
01:05:42 <Soni> that is to say, what if global state were a type(state)
01:06:18 <ais523> it is clearly an improvement, if you can find good syntax for it
01:06:42 <ais523> it's not just global *state*, though, also things like global permissions
01:06:49 <Soni> how do you find good syntax for it without experimenting with it
01:06:51 <ais523> "ability to send messages to the printer", for example
01:07:04 <Soni> we don't need permissions
01:07:06 <ais523> this is not a state, it contains no bits of information
01:07:15 <ais523> but it is something that should be guarded the same way
01:07:36 <ais523> especially because sometimes these things can't be done re-entrantly
01:07:38 <Soni> did you read the comments in stdworld?
01:07:45 <ais523> I skimmed some of htem
01:08:02 <ais523> it seems like it's still in its early stages
01:08:24 <Soni> is this useful extra context? https://users.rust-lang.org/t/new-signal-safe-std-replacement-looking-for-contributors-to-help-reimplement-all-of-std/117063
01:09:22 <Soni> (also yes we propose just making <W: World> implicit)
01:10:07 <korvo> Indeed, thinking of the computer as a robot, all of the ways that the CPU can signal the robot to act in the outside world are each their own capability. Discovering and wrapping these is known as *taming*.
01:10:16 <ais523> anyway, I think it is important that global state and permissions and capabilities are all managed by a system like this – it is pointless reimplementing all of std to just get working unloading and signal-safety, when capability-safety is probably more important in practice and also requires implementing all of std
01:10:58 <ais523> I have considered going further, making things like loops that can't be proven finite require a capability to do
01:11:05 <zzo38> I think that permissions and capabilities should be handled by the operating system, though
01:11:06 <Soni> if we have this we effectively have capabilities, even if we don't use them ourselves
01:11:10 <ais523> although you can't do that within most existing langauges
01:11:24 <Soni> ah yes solving the halting problem lol
01:11:37 <ais523> "can't be proven finite" doesn't require solving the halting problem
01:11:51 <ais523> or, well, I meant "haven't been proven finite", you don't have to prove that there's no proof
01:12:27 <Soni> we don't wanna go anywhere near halting problem stuff tbh
01:13:08 <korvo> zzo38: They are, kind of. In seL4, allocators and arenas are OS-managed handles, like file descriptors. It's something the OS has to be built around, though.
01:13:18 <ais523> the problem with what you're doing is that you have a project that a) will take a lot of work to complete and b) has a precisely limited scope that makes it useful only for a few applications and not for otheres
01:13:29 <int-e> Soni: have you tried woodcarving
01:13:31 <korvo> I hear Fuschia is cool, although I didn't take it seriously due to the Googliness.
01:13:42 <ais523> it would be a more useful project if the scope were larger, especially given how much work it would take, because it would then be useful to more peopel
01:13:58 <Soni> the useful thing about worlds is preventing mistakes, while everyone who says the word capabilities is thinking about control
01:14:01 <ais523> zzo38: I feel like permissions and capabilities kind-of need the programming language and OS to cooperate
01:14:30 <ais523> capabilities can also prevent mistakes (e.g. simultaneous overwrites of the same file)
01:14:53 <ais523> but they're also very useful when, e.g. using untrusted dependencies
01:14:57 <zzo38> I think that the OS has to be built around, yes. And, I had some idea of making such operating system, and all I/O uses a "capability" object.
01:15:00 <b_jonas> also that it'll push you to artificially limit some loops to 2**128 iterations long instead of potentially infinite, so that you have a proof that they're finite
01:15:01 <Soni> unsafe code can make their own worlds
01:15:04 <ais523> that could be untrusted in the sense of "I think this might do something malicious", and you use the capabilities to sandbox it
01:15:13 <korvo> Soni: The computer doesn't know what a mistake is. It can't make that sort of moral judgement computationally.
01:15:20 <ais523> but it could also be untrusted in the sense of "I think this might be buggy", and you use the capabilities to limit the damage if it is
01:15:24 <zzo38> I had seen some stuff about Fuschia. I do not agree with all of the design, but a few of my ideas are similar
01:15:25 <Soni> (and we make a point of supporting that)
01:15:58 <korvo> zzo38: Have you seen Capsicum? It's supported on one of the BSDs still, I think. All I/O happens through FDs and a single syscall.
01:16:01 <ais523> b_jonas: yes; I'm aware of the problem and suspect it's fixable but I don't yet know how
01:16:26 <zzo38> I had seen Capsicum too.
01:17:15 <Soni> we're here trying to fix the hexchat-plugin crate and nobody cares, everyone thinks we should just leave it unsound forever
01:17:19 <b_jonas> I mean sometimes that's a good thing, though for smaller numbers. sometimes I deliberately put a limit, much smaller than 2**128, that I think the loop shouldn't reach, to catch infinite loop bugs earlier
01:18:00 <ais523> anyway, my view of things is a) the type system in statically typed programming languages is a really good way to model capabilities/permissions and ensure that mistakes in using them are caught at compile-time; b) the OS generally doesn't have a way to confirm that programs perform only operations allowed by a language type system, so it needs to redo the checks itself in such a way that it could catch a program doing malicious things outside the bounds of
01:18:02 <ais523> the language it's allegedly written in
01:18:04 <zzo38> My idea involves that messages consists of bytes and/or capabilities, and a program receives an initial message when it starts; a program that discards all of its capabilities will terminate (a program that waits for any single capability from an empty set also terminates, and is the usual way to do so)
01:18:17 <int-e> b_jonas: there's work on tracking resource bounds in types but I'm not sure any of that is practical.
01:18:29 <ais523> int-e: I did a PhD on this stuff
01:18:44 <ais523> but mostly it was proving that the standard approach for doing it couldn't possibly work
01:19:06 <Soni> we wanna move on, this topic is too frustrating
01:19:10 <korvo> Soni: No worries. It's easy to get overwhelmed with personal infrastructure when also trying to build big libraries for everybody else. Take it slow; there's no rush.
01:19:57 <Soni> not exactly a programming language but still cursed: do you know the difference between editing text in bash, writing a text editor in bash, and turning bash into a text editor?
01:19:57 <zzo38> A program can also create its own capabilities (proxy capabilities), and programs cannot tell the difference of a proxy capability from any other one. Furthermore, such things as date/time and random numbers is also considered to be I/O, therefore programs can be made deterministic.
01:20:00 <int-e> most of what I've seen is struggling to establish bounds for small things... like sorting algorithms, up to relatively simple Okasaki style amortized cost things.
01:20:30 <ais523> zzo38: I agree that something like that would be beneficial – I don't know whether or not you have the details right, but the general approach is fine
01:21:05 <zzo38> ais523: Yes, that is a valid point, some of the details might be better to do differently; they are completely decided yet
01:21:28 <korvo> zzo38: Yes! And that's why actors end up getting reinvented; capabilities are essentially endpoints where messages are delivered, and also where messages are emitted, with some sort of partial order s.t. no observers disagree about ordering.
01:21:51 <ais523> actually, it strike me that in all the discussions about operating systems we've had over the years in #esolangs / (and previously #esoteric)
01:21:59 <zzo38> I have read about actor systems as well, and my idea is also similar than that too
01:22:02 <ais523> all the ideas I can remember are consistent with each other and look towards a similar approach for implementing it
01:22:16 <korvo> And yeah, you have to tame the system's ambient authority, including timers and entropy. Nix does this too, as do some other build systems.
01:22:46 <ais523> this is quite amazing, given what the channel is about, and especially given that OSes typically *don't* work like that
01:22:54 <Soni> sigh we're gonna get dragged back into this
01:23:02 <int-e> . o O ( shouldn't they be called re-actors )
01:23:04 <ais523> it's like everyone has independently decided "this approach is better"
01:23:07 <Soni> how do you use capabilities on a bare metal microcontroller in asm
01:23:28 <ais523> well, those don't have an OS
01:23:52 <ais523> but the answer is probably "they exist in the language you're compiing into the asm from, and the compiler ensures there are no incorrect uses of capabilities"
01:23:55 <korvo> I should go look for an seL4/Genode hardware compatibility list. I have a couple old Raspberry Pis...
01:24:03 <ais523> so that if the compiler is correct, you know the program doesn't have capability violations
01:24:23 <korvo> Soni: Machine code usually *isn't* capability-safe.
01:24:27 <ais523> what do you mean by "use capabilities" here
01:24:31 <Soni> machine code isn't asm
01:24:37 <zzo38> My idea would be that it would also define how the system call interface in the machine code is working in each computer type, so you can use them in assembly language as well, and it will be capability-safe too
01:24:53 <ais523> hmm, statically typed asm should in theory be possible, you could add ZSTs to that
01:25:11 <ais523> but, lots of it would compile down to nothing and you wouldn't be able to see it upon disassembling the machien code
01:25:25 <zzo38> However, the portable API would be defined mainly for C, and for the "Command, Automation, and Query Language" as well
01:25:43 <Soni> yes the entire point of typed asm is that it erases the types when assembling
01:26:01 <Soni> but it can still check constraints and other stuff
01:26:09 <Soni> invariants and whatnot
01:26:15 <korvo> There is a history of capability-safe machines. AIUI the oldest is the Burroughs B5000: https://en.wikipedia.org/wiki/Burroughs_Large_Systems
01:26:30 <zzo38> Yes, I suppose you could make static typed assembly but some things you might want to do in assembly language you might not always want it
01:26:47 <ais523> x86-64 has different commands to operate on SSE registers as floats and as integers, which is notable because it has different commands even when you're performing an operation like a copy that works the same way on both data types
01:26:49 <Soni> not with that attitude
01:26:52 <korvo> These basically embed file-descriptor indirections ("capability tables" or "cap tables" in cap lore) into the CPU's way of looking at memory. The CPU can tell whether you're allowed to do what you're trying to do.
01:27:11 <ais523> and apparently, some processors have a slowdown if you use an integer operation on a register that was most recently read/written as a float, or vice versa
01:27:27 <Soni> why can't types be aware of such things as self-modifying code?
01:27:34 <korvo> Today, look for CHERI for examples of this. Also The Mill would have similar tables, but complicated.
01:27:46 <ais523> self-modifying code doesn't work very well on modern processors
01:27:56 <ais523> they like to read ahead a long way and run lots of pieces of code in parallel
01:28:02 <zzo38> I think there is a program in uxn for doing something similar than static typed assembly, although I do not use it (and even if you do use it, you can use square brackets to suppress warnings about such things)
01:28:09 <ais523> if code self-modifies, then either they ignore the modification or they have to discard a lot of work to incorporate the modification
01:28:13 <Soni> we're not talking about modern processors
01:28:45 <Soni> well you'd still want unsafe blocks probably, like in rust
01:29:17 <Soni> (unsafe blocks in an assembler...)
01:29:29 <zzo38> I would also have that the kernel doesn't have "typed capabilities", although the rest of the system implements such things as typed capabilities.
01:29:44 <ais523> b_jonas: on the subject of loop limits, it may be possible to use run time as a way to prevent variables overflowing
01:29:59 <shachaf> ais523: It's even odder than that -- Packed 32-bit integer and 64-bit integer xor are different instructions, I think.
01:30:04 <ais523> say you have 64-bit reference counts, and they are only ever increased and decreased by small integers
01:30:30 <ais523> now a reference count cannot overflow, you cannot run 2**64/(small integer) incref instructions to overflow it, the program does not run for that long
01:30:39 <ais523> so you can optimise out the overflow checks
01:31:00 <shachaf> `asm vpxord %ymm0, %ymm1, %ymm2
01:31:02 <HackEso> 0: 62 f1 75 28 ef d0 vpxord %ymm0,%ymm1,%ymm2
01:31:05 <shachaf> `asm vpxorq %ymm0, %ymm1, %ymm2
01:31:07 <HackEso> 0: 62 f1 f5 28 ef d0 vpxorq %ymm0,%ymm1,%ymm2
01:31:41 <shachaf> Is that just because the instruction encoding is regular, or is there a reason to stick with the same number of lanes across operations or something?
01:31:59 <ais523> shachaf: a quick check of the docs implies that this only happens with AVX512 encodings specifically
01:32:03 <ais523> which makes it probably a case of regular encoding
01:32:20 <ais523> `asm vpxor %ymm0, %ymm1, %ymm2
01:32:21 <HackEso> 0: c5 f5 ef d0 vpxor %ymm0,%ymm1,%ymm2
01:32:52 <ais523> oh, no, the operations are acutally different
01:33:00 <zzo38> I had not used modern x86-64 assembly language, although I had examined the assembly code output from compilers
01:33:01 <ais523> AVX512 supports masks to operate only on a subset of the inputs
01:33:11 <ais523> or, well, to only write a subset of the values to the output register
01:33:23 <shachaf> Ah, interesting, these packed 32-bit/64-bit xor instructions are AVX512.
01:33:30 <ais523> the D versus Q would affect the meaning of the mask, even though it doesn't affect the meaning of the XOR
01:33:53 <ais523> `asm vpxord {k1} %ymm0, %ymm1, %ymm2
01:33:54 <HackEso> /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: invalid char '{' beginning operand 1 `{k1} %ymm0' \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: junk `} %ymm0' after expression
01:34:04 <ais523> `asm vpxord %ymm0, {k1} %ymm1, %ymm2
01:34:05 <HackEso> /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: invalid char '{' beginning operand 2 `{k1} %ymm1' \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: junk `} %ymm1' after expression
01:34:09 <ais523> `asm vpxord %ymm0 {k1}, %ymm1, %ymm2
01:34:10 <HackEso> 0: 62 f1 75 29 ef c2 vpxord ymm0{k1},ymm1,ymm2
01:34:26 <ais523> so the meaning of k1 is affected by the d
01:34:47 <shachaf> It's still kind of funny that the unmasked instructions are different.
01:35:18 <shachaf> I haven't looked at the AVX512 encodings very closely. Maybe the unmasked instructions are just a special case of the masked instructions or something, so this happens naturally.
01:35:25 <ais523> right, but given how there are 15 times as many masked as unmasked variants, it doesn't really make sense to remove one of the unmasked versions, it'd hardly save any encoding space
01:36:15 <shachaf> Why 15 times? Is it 15 mask registers or something, and unmasked is just encoded as another mask register?
01:36:41 <ais523> oh, no, I misremembered, it is 8
01:36:48 <ais523> I thought there were 16, one of which indicated unmasked
01:37:18 <ais523> <Intel> Note that from this set of 8 architectural registers, only k1 through k7 can be addressed as predicate oper- ands. k0 can be used as a regular source or destination but cannot be encoded as a predicate operand.
01:38:09 <ais523> so there are 8, in theory, but only 7 of them can be encoded into an instruction whose purpose is anything other than manipulating mask registers
01:38:52 <shachaf> If you actually want fast unmasked xor on AVX512, you'd use vpternlog.
01:40:03 <shachaf> Well, if you're xoring more than two things, which is presumably pretty common.
01:40:14 <ais523> `asm vpxord %ymm0 {k1}, %ymm1, %ymm2
01:40:15 <HackEso> 0: 62 f1 75 29 ef c2 vpxord ymm0{k1},ymm1,ymm2
01:40:18 <ais523> `asm vpxord %ymm0 {k0}, %ymm1, %ymm2
01:40:19 <HackEso> /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: unknown vector operation: `{k0}' \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: `%k0' can't be used for write mask
01:40:35 <ais523> `asm vpxord %ymm0 {k1}{z}, %ymm1, %ymm2
01:40:36 <HackEso> 0: 62 f1 75 a9 ef c2 vpxord ymm0{k1}{z},ymm1,ymm2
01:40:57 <ais523> I still haven't found the part of the documentation which says that 000 encodes no mask
01:41:26 <ais523> `asm .byte 0x62,0xf1,0x75,0x28,0xef,0xd2
01:41:27 <HackEso> 0: 62 f1 75 28 ef d2 vpxord %ymm2,%ymm1,%ymm2
01:41:45 <shachaf> `asm vpternlogd $0x96, %ymm0, %ymm1, %ymm2
01:41:47 <HackEso> 0: 62 f3 75 28 25 d0 96 vpternlogd $0x96,%ymm0,%ymm1,%ymm2
01:41:53 <ais523> `asm vpxord %ymm0, %ymm1, %ymm2{k0}
01:41:54 <HackEso> /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: unknown vector operation: `{k0}' \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: `%k0' can't be used for write mask
01:41:57 <ais523> `asm vpxord %ymm0, %ymm1, %ymm2{k1}
01:41:58 <HackEso> /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: unknown vector operation: `{k1}' \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: mask not on destination operand for `vpxord'
01:42:19 <ais523> I hate how long these instructions are
01:42:50 <shachaf> I've only written a small amount of AVX512 code. I didn't use the masking at all there.
01:42:56 <int-e> `asm .byte 0x62,0xf1,0x75,0xa8,0xef,0xd2
01:42:57 <HackEso> 0: 62 f1 75 a8 ef d2 vpxord %ymm2,%ymm1,%ymm2{z}
01:44:01 <shachaf> `asm vgf2p8affineqb $0, %zmm0, %zmm1, %zmm2 # the other great instruction in AVX512
01:44:03 <HackEso> 0: 62 f3 f5 48 ce d0 00 vgf2p8affineqb $0x0,%zmm0,%zmm1,%zmm2
01:44:09 <shachaf> termlog and gf2p8affineqb are where it's at.
01:44:34 <ais523> I use Intel syntax when writing SSEish/AVXish code, because with AT&T syntax I find it too hard to figure out which order the arguments are supposed to be in
01:44:55 <shachaf> I'm used to AT&T syntax but I think I should just switch to Intel syntax everywhere for this reason.
01:45:12 <ais523> I do like the % signs on registers to stop them clashing with variables, though
01:45:24 <ais523> if someone adds a new register that has the same name as a variable you're using…
01:45:27 <shachaf> Or maybe I should switch to ARM or RISC-V syntaxes.
01:45:47 <ais523> but people get angry with me when I use Intel argument order with % on registers, even though gas supports it
01:46:12 <int-e> `asm vpxord %ymm2,%ymm1,%ymm2{z}
01:46:13 <HackEso> /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: zeroing-masking only allowed with write mask \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: zeroing-masking only allowed with write mask
01:47:17 <ais523> PCLMULQDQ is a fun instruction, that I may even have used as VPCLMULQDQ
01:47:24 <ais523> I am not quite sure why it has an SSE encoding, I think it's newer than SSE is
01:47:43 <int-e> (But what happens if you execute that 0x62,0xf1,0x75,0xa8,0xef,0xd2 on real hardware? Will it fault or execute as an unmasked vpxord?
01:48:03 <ais523> `asm vpclmullqlqdq %xmm1, %xmm2
01:48:05 <HackEso> /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: number of operands mismatch for `vpclmullqlqdq' \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: number of operands mismatch for `vpclmullqlqdq'
01:48:16 <ais523> `asm vpclmullqlqdq %xmm1, %xmm2, %xmm3
01:48:18 <HackEso> 0: c4 e3 69 44 d9 00 vpclmullqlqdq %xmm1,%xmm2,%xmm3
01:49:19 <ais523> `asm vpclmullqlqdq %zmm1, %zmm2, %zmm3
01:49:20 <HackEso> /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: operand size mismatch for `vpclmullqlqdq' \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: operand size mismatch for `vpclmullqlqdq'
01:49:32 <ais523> `asm vpclmullqlqdq %ymm1, %ymm2, %ymm3
01:49:34 <HackEso> /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: operand size mismatch for `vpclmullqlqdq' \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: operand size mismatch for `vpclmullqlqdq'
01:50:08 <int-e> how does that mnemonic work... low quad, low quad, double quad.
01:50:09 <ais523> huh, that should be encodeable with ymm registers
01:50:37 <int-e> sorry, I have this habit of starting a question... and then looking up the answer and reporting it along with it :P
01:50:41 <ais523> it is an abbreviation/shortcut mnemonic which is somehow harder to remember and longer than the instruction it abbreviates
01:50:56 <ais523> `asm vpclmulqdq %xmm1, %xmm2, %xmm3, 0x00
01:50:58 <HackEso> 0: c4 e3 69 44 cb 00 vpclmullqlqdq xmm1,xmm2,xmm3
01:51:39 <int-e> `asm vpclmulqdq %xmm1, %xmm2, %xmm3, 0x11
01:51:41 <HackEso> 0: c4 e3 69 44 cb 11 vpclmulhqhqdq xmm1,xmm2,xmm3
01:52:15 <ais523> `asm vpclmulqdq %xmm1, %xmm2, %xmm3, 0x23
01:52:17 <HackEso> 0: c4 e3 69 44 cb 23 vpclmulqdq xmm1,xmm2,xmm3,0x23
01:52:40 <ais523> the disassembler is scared to abbreviate when you set some of the ignored bits in the immediate :-)
01:53:33 <HackEso> /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: too many memory references for `pext' \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: operand size mismatch for `pext'
01:53:41 <int-e> *reading* yeah apparently that's legal
01:53:43 <ais523> `asm pext eax, ebx, ecx
01:53:45 <HackEso> 0: c4 e2 62 f5 c1 pext eax,ebx,ecx
01:54:19 <shachaf> Hmm, I might need to do a spot of the carryless multiplication soon to speed up a CRC thing.
01:54:23 <ais523> (that's the INTERCAL select instruction)
01:54:42 <ais523> fun to see a three-operand instruction that operates on the general-purpose integer registers
01:54:50 <ais523> `asm pext eax, ebx, esp
01:54:51 <HackEso> 0: c4 e2 62 f5 c4 pext eax,ebx,esp
01:55:14 <ais523> `asm pext eax, ebx, eip
01:55:15 <HackEso> /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: too many memory references for `pext' \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: operand type mismatch for `pext'
01:55:28 <ais523> I didn't think you'd be able to do that one, but it was worth trying
01:55:46 <shachaf> Interesting, it uses a VEX prefix and puts the third operand there, I guess.
01:57:24 <ais523> C-INTERCAL compiles ~ into PEXT in some circumstances which I can't remember, it was too good an opportunity
01:57:25 <shachaf> You can't use eip anywhere except as a memory offset, right?
01:57:33 <HackEso> 0: c4 e2 e2 f5 05 00 00 00 00 pext rax,rbx,QWORD PTR [rip+0x0] # 0x9
01:57:37 <int-e> hehe that reminds me of "pop cs" that apparently worked on 8089 and 8086.
01:58:02 <ais523> a return statement is actually just a pop of the IP
01:58:03 <int-e> before it was stolen as a prefix for encoding more instructions (0x0F)
01:58:06 <ais523> but it is given a different name
01:58:28 <ais523> but yes, usually you can't use RIP except for IP-relative addressing
01:58:36 <ais523> `asm pext rax, rbx, [0x0]
01:58:39 <HackEso> 0: c4 e2 e2 f5 04 25 00 00 00 00 pext rax,rbx,QWORD PTR ds:0x0
01:59:05 <int-e> `asm lea rax, [rip]
01:59:06 <HackEso> 0: 48 8d 05 00 00 00 00 lea rax,[rip+0x0] # 0x7
01:59:23 <shachaf> I was going to say lea is another three-operand instruction, but that's not true for rip, I guess.
01:59:38 <ais523> absolute-memory-address addressing (with no register) had two equivalent encodings in x86-32, one of them (the shorter one) was repurposed to mean rip-relative
01:59:55 <ais523> `asm lea rax, [rbx + rcx + 0x4]
01:59:56 <HackEso> 0: 48 8d 44 0b 04 lea rax,[rbx+rcx*1+0x4]
02:00:04 <ais523> `asm lea rax, [rip + rcx + 0x4]
02:00:06 <HackEso> /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: invalid char '[' beginning operand 2 `[rip+rcx+0x4]' \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: `[rip+rcx+0x4]' is not a valid base/index expression
02:00:40 <ais523> but you can't put RIP into anything other than "[RIP + constant]" because of that
02:01:42 <ais523> the longer encoding was a consequence of encoding consistency:
02:01:56 <ais523> `asm lea rax, [rbx + 0x4]
02:01:58 <HackEso> 0: 48 8d 43 04 lea rax,[rbx+0x4]
02:02:10 <ais523> `asm lea rax, [rbp + 0x4]
02:02:12 <HackEso> 0: 48 8d 45 04 lea rax,[rbp+0x4]
02:02:16 <ais523> `asm lea rax, [rsp + 0x4]
02:02:17 <HackEso> 0: 48 8d 44 24 04 lea rax,[rsp+0x4]
02:02:25 <shachaf> I wrote an encoder for all this ModRM/SIB business once.
02:02:28 <ais523> `asm lea rax, [rbx*2 + 0x4]
02:02:30 <HackEso> 0: 48 8d 04 5d 04 00 00 00 lea rax,[rbx*2+0x4]
02:02:50 <shachaf> But I've mostly forgotten it already.
02:04:48 <shachaf> We should have `asm for ARM.
02:04:58 <HackEso> #!/bin/sh \ echo "$1" > /tmp/asm.s; for o in ',' '-msyntax=intel -mnaked-reg,-M intel'; do if as ${o%,*} /tmp/asm.s -o /tmp/asm.o 2>>/tmp/asm.err; then objdump ${o#*,} -d --insn-width=20 /tmp/asm.o | sed -e "1,/0000000000000000/d" | perl -pe 'if (/^\s*(\w+:)\s*((?:\w\w )+)\s*(\S.*)$/) { ($a,$b,$c) = ($1,$2,$3); $_ = "$a $b ".($c =~ s/\s+/ /rg)."\n"; }'; exit; fi; done; cat /tmp/asm.err
02:06:52 <int-e> shachaf: but that's less confusing :P
02:07:09 <int-e> TBH `arm was my first thought
02:07:18 <int-e> I'd rather avoid ars*
02:08:58 <int-e> (there could also be a `amd64 alias for `asm to make `arm feel more systematic)
02:09:03 <shachaf> Can GNU as cross-assemble by default?
02:09:40 <int-e> I don't know. I guess not.
02:10:23 <shachaf> I think llvm-as can? But it doesn't seem to be installed.
02:12:33 <shachaf> I was recently thinking about how LDAPR works, and I was confused at first, but now I think it makes sense and is kind of elegant.
02:13:42 <shachaf> (Or rather about how LDAR works, I guess.)
02:14:09 -!- X-Scale has joined.
02:17:36 <int-e> `` echo $(as --help | awk '/=CPU/ { x++ } (x == 1) { print }' | sed 's= *= =g') # full output at https://hack.esolangs.org/tmp/paste/paste.28966
02:17:38 <HackEso> -march=CPU[,+EXTENSION...] generate code for CPU and EXTENSION, CPU is one of: generic32, generic64, i386, i486, i586, i686, pentium, pentiumpro, pentiumii, pentiumiii, pentium4, prescott, nocona, core, core2, corei7, l1om, k1om, iamcu, k6, k6_2, athlon, opteron, k8, amdfam10, bdver1, bdver2, bdver3, bdver4, znver1, znver2, btver1, btver2 EXTENSION is combination of: 8087, 287, 387, 687, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, sse4, avx, avx2, avx5
02:18:27 <int-e> so just x86 things
02:19:17 <int-e> and I guess the `sed` isn't needed
02:21:55 <shachaf> Interesting, GNU as has a -mfence-as-lock-add option.
02:22:10 <shachaf> "encode lfence, mfence and sfence as lock addl $0x0, (%{re}sp)"
02:22:26 <shachaf> I ask because mfence is significantly slower than a locked instruction like that.
02:25:06 <shachaf> `fetch /hackenv/tmp/fence.c https://shachaf.net/tmp/fence.c
02:25:09 <HackEso> 2024-11-04 02:25:08 URL:https://shachaf.net/tmp/fence.c [1589/1589] -> "/hackenv/tmp/fence.c" [1]
02:26:09 <shachaf> Ah, can't do perf in HackEso.
02:28:29 <shachaf> Also, generating lock addl $0, (%rsp) generates a false dependency on (%rsp)
02:28:53 <shachaf> I recently read a post suggesting doing it on an address in the red zone below (%rsp) instead, to avoid that.
02:29:14 <shachaf> ais523: Do you know the specific differences?
02:29:37 <shachaf> I like this Intel pseudocode for mfence: "Wait_On_Following_Loads_And_Stores_Until(preceding_loads_and_stores_globally_visible);"
03:05:02 <b_jonas> "64-bit reference counts, only ever increased and decreased by small integers, cannot overflow" => yes, I am aware of that trick
03:05:59 <b_jonas> it can be useful for things other than reference counts too
03:22:13 <b_jonas> "I still haven't found the part of the documentation which says that 000 encodes no mask" => try to find the part in the Intel 64 and IA-32 Architecture Software Developer's Manual that defines how the REX prefix modifies the registers encoded by ModR/M bytes as described in vol 2 ch 2.1.5 and B.1.4.
03:25:11 -!- baldibacak has joined.
03:27:31 <ais523> shachaf: at a guess, write-combining memory probably works differently
03:27:47 <ais523> I don't know the actual answer though
03:33:07 <b_jonas> this is why we have both the Intel and AMD manual, gnu binutils, yasm, Agner's objdump, and qemu. if some information about instruction encoding is unclear or missing in one manual, you can look them up in the other five.
03:34:23 <b_jonas> that's six independent sources of information, each of which should completely specify the instruction encodings
03:34:51 <b_jonas> (binutils has both an assembler and a disassembler, but I don't think the two count as independent)
03:36:12 <b_jonas> plus of course there are real CPUs to test with
03:36:59 <baldibacak> there was so much garbage file in my home dir so i rm -rf homedir now i erased every single config
03:53:17 -!- baldibacak has quit (Quit: Client closed).
03:53:49 -!- babakarazaqo has joined.
03:54:15 -!- babakarazaqo has left.
04:22:54 -!- craigo has quit (Ping timeout: 260 seconds).
05:50:43 <zzo38> Is it possible in Linux to disable address space randomization for a specific program (without affecting other programs)?
06:01:57 <ais523> zzo38: yes, call personality(ADDR_NO_RANDOMIZE) from the process that spawns it, between the fork and exec
06:04:43 <ais523> I am not sure if that affects randomization done by the dynamic linker too, or just by the kernel
06:05:13 <zzo38> OK. The man page for "personality" on my computer does not mention what argument is expected by that function
06:06:03 <zzo38> Is it usable together with other stuff in order to be able to save/restore the program's memory (if it is not necessary to save/restore file descriptors, signals, etc, and the program does not use multiple threads)?
06:07:18 <ais523> zzo38: yes, but there's a better way to do it; see PR_SET_MM in prctl(2)
06:07:58 <ais523> there's actually quite a lot of kernel support for checkpointing and restoring a program's memory
06:08:21 <ais523> and existing programs to do it for you, so you don't need to rewrite it from scratch; I think CRIU is one of the better-known ones
06:09:42 <ais523> turning off ASLR is still useful if you need the program to run reproducibly
06:12:48 <zzo38> I do not seem to have PR_SET_MM on my computer
06:12:55 <zzo38> (maybe I need a newer version of Linux)
06:14:43 <zzo38> (Also, the program that should be saved/restored would be one that is meant to be able to do this, so it not just any arbitrary program. If this requires special linker options it is OK too)
06:30:04 -!- Sgeo has quit (Read error: Connection reset by peer).
06:31:20 <esolangs> [[JS-CODE]] https://esolangs.org/w/index.php?diff=144889&oldid=144875 * Ractangle * (+1) /* Some things i found */
07:07:31 <shachaf> You can also do it in the ELF file, can't you?
07:31:19 -!- tromp has joined.
07:45:28 -!- Lord_of_Life has quit (Ping timeout: 252 seconds).
07:46:37 -!- Lord_of_Life has joined.
08:33:44 <esolangs> [[User talk:Superstitionfreeblog]] https://esolangs.org/w/index.php?diff=144890&oldid=143607 * ZCX islptng * (+435)
09:07:22 -!- X-Scale has quit (Quit: Client closed).
09:19:11 -!- ais523 has quit (Quit: quit).
09:43:53 <esolangs> [[RECT4n=GLE]] https://esolangs.org/w/index.php?diff=144891&oldid=139113 * JJRubes * (+690) interpretation explanation rewrite
09:45:25 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
09:50:41 -!- tromp has joined.
10:00:47 -!- amby has joined.
11:28:07 -!- chiselfuse has quit (*.net *.split).
11:35:50 -!- chiselfuse has joined.
11:49:56 -!- X-Scale has joined.
11:55:18 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144892&oldid=144869 * Ractangle * (-44) /* Syntax */
11:55:54 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144893&oldid=144892 * Ractangle * (+12) /* Hello, world! */
11:58:25 -!- Everything has joined.
12:00:45 -!- X-Scale has quit (Ping timeout: 256 seconds).
12:35:41 <Soni> ais523: compile-time virtual memory
12:43:51 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
12:52:37 -!- Guest60 has joined.
13:02:43 <Soni> oh wait, not around
13:04:10 -!- Everything has quit (Quit: leaving).
13:05:53 <esolangs> [[SML]] https://esolangs.org/w/index.php?diff=144894&oldid=143587 * Froginstarch * (+19) /* Hello, world! */
13:07:24 <esolangs> [[User:EvyLah/public stack]] https://esolangs.org/w/index.php?diff=144895&oldid=131013 * Gggfr * (+469) /* commands */
13:08:06 <Guest60> give me spmething to turn into an esolang
13:08:59 <esolangs> [[User:EvyLah/public stack]] https://esolangs.org/w/index.php?diff=144896&oldid=144895 * Gggfr * (+71) /* commands */
13:15:32 -!- baldibacak has joined.
13:17:04 <baldibacak> btw how do we setup password on liberal chat
13:17:06 -!- Guest60 has quit (Quit: Client closed).
13:18:04 -!- Guest60 has joined.
13:22:25 <Guest60> cuz i have smth for you to read!
13:24:59 <Guest60> baldibacsk this is for you
13:25:04 -!- wib_jonas has joined.
13:28:03 <wib_jonas> ais523: apparently the Turing-complete computation in M:tG is making rounds on the internet, though here it appears with a very deceptive wording, both because it's missing the parenthesis in "deck can be used to (deal damage iff mathematical conjecture is true)": https://www.astralcodexten.com/p/links-for-november-2024 (search for "Isochron
13:29:05 -!- Guest60 has quit (Quit: Client closed).
13:29:58 -!- wWwwW has joined.
13:33:00 <wWwwW> ais523: ik its a loong time but somebody made an interpreter for RECT4n=GLE and explained it better is if you where interestd then you can see it now
13:43:02 <wWwwW> i was going to if you said yyes show you this:
13:43:23 <wWwwW> https://esolangs.org/wiki/Bring_to_another
13:47:44 -!- amby has quit (Ping timeout: 244 seconds).
13:58:14 <wWwwW> have you red/are readingf th hackMD doc?
13:59:10 <baldibacak> i am gonna make an end to end encrypted chat app
14:03:43 <baldibacak> just for fun i am gonna make an chatapp includesend to end encrypted meaning i cant read messages
14:09:27 -!- tromp has joined.
14:10:02 -!- wWwwW has quit (Quit: Client closed).
14:14:09 -!- baldibacak has quit (Quit: Client closed).
14:17:23 -!- wWwwW has joined.
14:34:58 <esolangs> [[Extended Brainfuck]] https://esolangs.org/w/index.php?diff=144897&oldid=139240 * None1 * (+38)
14:44:34 <esolangs> [[Brainfuck extended]] https://esolangs.org/w/index.php?diff=144898&oldid=140254 * None1 * (+124)
14:45:32 <esolangs> [[Brainfuck extended]] https://esolangs.org/w/index.php?diff=144899&oldid=144898 * None1 * (+45)
14:45:52 <esolangs> [[Extended Brainfuck]] M https://esolangs.org/w/index.php?diff=144900&oldid=144897 * None1 * (-1)
14:47:34 <esolangs> [[Brainfuck extended]] M https://esolangs.org/w/index.php?diff=144901&oldid=144899 * None1 * (+131)
14:50:24 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
14:58:00 <wib_jonas> huh ... apparently that uses a card https://scryfall.com/card/dsk/241/zimone-all-questioning that refers to prime numbers explicitly in its rules text. that's cheating!
15:06:37 -!- wWwwW has quit (Ping timeout: 256 seconds).
15:12:13 -!- tromp has joined.
15:59:11 -!- wWwwW has joined.
16:07:26 -!- X-Scale has joined.
16:11:10 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
16:31:01 -!- tromp has joined.
16:32:54 <esolangs> [[Son of a BitCh]] N https://esolangs.org/w/index.php?oldid=144902 * ZCX islptng * (+613) Created page with "Son of a [[BitChanger|BitCh]] is an esolang with 2 instructions, created by islptng. As the title says, it is heavily inspired and based on BitChanger. The program itself, has not only a tape, but a state storage, which the value is always one of <code>diojn<
16:44:21 <esolangs> [[Son of a BitCh]] M https://esolangs.org/w/index.php?diff=144903&oldid=144902 * ZCX islptng * (+140) Examples
16:46:58 <esolangs> [[Deadfish with gotos and input]] M https://esolangs.org/w/index.php?diff=144904&oldid=144853 * ZCX islptng * (+21) Added my AHF to this page because it has the same idea as mine.
17:02:29 <esolangs> [[User:EvyLah/public stack]] https://esolangs.org/w/index.php?diff=144905&oldid=144896 * Ractangle * (+25) /* program */
17:02:39 <esolangs> [[User:EvyLah/public stack]] https://esolangs.org/w/index.php?diff=144906&oldid=144905 * Ractangle * (-9) /* program */
17:03:43 -!- baldibacak has joined.
17:20:27 -!- wib_jonas has quit (Quit: Client closed).
17:25:52 -!- amby has joined.
17:26:31 -!- baldibacak has quit (Quit: Client closed).
17:59:51 <esolangs> [[MarkupL]] https://esolangs.org/w/index.php?diff=144907&oldid=144888 * Ractangle * (-181) /* MarkupL syntax */
18:06:38 <esolangs> [[Bake]] https://esolangs.org/w/index.php?diff=144908&oldid=143158 * Ractangle * (-14) /* Syntax */
18:06:47 <esolangs> [[Bake]] https://esolangs.org/w/index.php?diff=144909&oldid=144908 * Ractangle * (-2) /* Cat program */
18:26:13 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
18:35:09 -!- wWwwW has quit (Ping timeout: 256 seconds).
18:38:24 <esolangs> [[Special:Log/newusers]] create * QOALO * New user account
18:38:32 -!- tromp has joined.
18:44:27 <esolangs> [[Special:Log/newusers]] create * AES256-Always secure Encrypeter * New user account
19:06:19 -!- X-Scale has quit (Ping timeout: 256 seconds).
19:12:30 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144910&oldid=144893 * Ractangle * (-436)
19:12:46 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144911&oldid=144910 * Ractangle * (+0) /* Syntax */
19:12:50 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144912&oldid=144911 * Ractangle * (+1) /* Hello, world! */
19:13:40 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144913&oldid=144912 * Ractangle * (-25) /* Implementation */
19:35:49 -!- zzo38 has quit (Ping timeout: 260 seconds).
19:38:40 <esolangs> [[User:EvyLah/public stack]] https://esolangs.org/w/index.php?diff=144914&oldid=144906 * EvyLah * (-2) /* current stack */ ya gotta change the stack when you change the program
19:51:05 -!- X-Scale has joined.
19:53:38 -!- zzo38 has joined.
20:00:35 -!- craigo has joined.
20:07:57 -!- X-Scale has quit (Quit: Ping timeout (120 seconds)).
20:21:26 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144915&oldid=144913 * Ractangle * (+37) /* Syntax */
20:50:51 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144916&oldid=144915 * Ractangle * (+21) /* Examples */
21:19:38 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144917&oldid=144916 * Ractangle * (+9) /* Quine */
21:19:55 -!- ais523 has joined.
21:21:32 <esolangs> [[List of quines]] https://esolangs.org/w/index.php?diff=144918&oldid=139630 * Ractangle * (+44) /* $_$ */
21:22:50 <esolangs> [[List of quines]] https://esolangs.org/w/index.php?diff=144919&oldid=144918 * Ractangle * (+64) /* /// */
21:52:34 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
21:56:40 -!- tromp has joined.
21:58:30 -!- Everything has joined.
22:29:04 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
22:42:15 -!- Everything has quit (Quit: leaving).
23:26:53 <esolangs> [[lang]] https://esolangs.org/w/index.php?diff=144920&oldid=143523 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (+45) /* Java Interpreter */
23:27:33 <esolangs> [[Txet]] https://esolangs.org/w/index.php?diff=144921&oldid=140918 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (+4) /* Cat program */
23:30:50 <esolangs> [[Nope.]] https://esolangs.org/w/index.php?diff=144922&oldid=144512 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (+48) /* Tile */
23:41:48 <esolangs> [[Talk:Text]] https://esolangs.org/w/index.php?diff=144923&oldid=132832 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (+12012) /* txeT */
23:42:11 <esolangs> [[Talk:Text]] https://esolangs.org/w/index.php?diff=144924&oldid=144923 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (-71) /* 99 bottles of beer on the wall */
23:42:18 <esolangs> [[Talk:Text]] https://esolangs.org/w/index.php?diff=144925&oldid=144924 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (+69) /* txeT */
23:47:42 -!- Sgeo has joined.
23:48:00 <esolangs> [[9]] https://esolangs.org/w/index.php?diff=144926&oldid=144719 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (-5) /* Operators */