< 1767830413 814852 :somefan!~somefan@208.58.192.69 QUIT :Remote host closed the connection < 1767830421 361154 :somefan!~somefan@208.58.192.69 JOIN #esolangs * :[https://web.libera.chat] somefan < 1767830572 108667 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I just came to a sudden realisation about Rust, and wanted to write it down somewhere before I forgot it, and I guess #esoteric will do: an aligned/nonnull raw pointer to T is basically just an &UnsafeCell whose lifetime isn't tracked < 1767830619 747637 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there's already a special-case rule that says an &UnsafeCell can exist even if the inside of the cell doesn't contain valid data, and I think this is where it comes from < 1767830777 591552 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this fits in with an observation I had a while ago (but didn't post), that when working with raw pointers in Rust they seem to want to be created by doing something to a mutable reference – &mut T and &mut UnsafeCell are equivalent (safely interconvertable either way using UnsafeCell::from_mut and UnsafeCell::get_mut), then you pirate the &mut UnsafeCell to get an &UnsafeCell < 1767830866 740701 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :actually, you can create raw pointers to uninitalized memory too, so maybe an aligned/nonnull raw pointer is &'unsafe UnsafeCell> < 1767830909 224189 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :('unsafe isn't actual Rust syntax but it's a fairly well-known proposal at this point) < 1767830939 51156 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, I guess this is the exact opposite of rubber-ducking, instead of asking questions into the void to help me understand something, I'm making statements into the void to help me express something < 1767831174 535799 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: you aren't allowed to have an &UnsafeCell point to the same address as an &mut UnsafeCell unless you reborrowed from the latter, but you can have a raw pointer point to the same address as the &mut UnsafeCell, so I don't think they're the same < 1767831234 710429 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: so the trick here is: if your raw pointers can only be created by pirating the &mut UnsafeCell, they're all derived from a share of that mutable borrow and so they're allowed < 1767831259 130839 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in fact, I think the original &mut UnsafeCell is what a provenance is < 1767831316 831298 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if you offset them out of bounds you can't read or write through them until they're back in bounds < 1767831338 543888 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :this seems to me kind of a narrow view of raw pointers < 1767831350 128946 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so even if they're matching the address of some other &mut it's OK, as you need the read or write to break the rules < 1767831353 903134 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :it's certainly one thing you can use raw pointers too, but surely there are others > 1767831425 892156 PRIVMSG #esolangs :14[[07GTPS14]]4 10 02https://esolangs.org/w/index.php?diff=172493&oldid=172489 5* 03A() 5* (-32) 10 < 1767831428 990370 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :under the current rules there are "raw pointers to memory outside the Rust virtual machine", but that's one of the special cases I've been actively working on trying to combine into the general case < 1767831469 202993 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and there are raw pointers without provenance, too, but you can't actually read or write through them so they don't cause any aliasing conflicts < 1767831594 991003 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the situation with aliasing is a little complicated because the rules that safe Rust implies (that an &mut T is never allowed to alias an &T not derived from it) is different from the rules that unsafe Rust is allowed to use (unsafe Rust currently allows them to alias unless both of them are accessed through – if one of them is unused it's OK – but it's unsafe because using a reference is a safe operation) < 1767831637 477958 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I thought that's still forbidden in unsafe rust in general. < 1767831707 751706 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so there is a model of unsafe Rust called Stacked Borrows, which is the de-facto standard at the moment – most unsafe Rust programmers are willing to do anything that's legal in Stacked Borrows and the compiler avoids doing optimisations that conflict with it < 1767831735 480757 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but, it is not necessarily the final model – but it's considered much more likely for parts of it to be relaxed than parts of it to be made stricter < 1767831762 898799 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :that's why rust added the &raw syntax recently, because you're only allowed to have a reference if it always points to a readable object with a valid representation. I know you work that around above with MaybeUninit, but still. < 1767831788 834319 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Stacked Borrows doesn't look at lifetimes at all when considering whether code is valid or not, just for the first/last use of each given reference (although there is a somewhat confusing "protectors" rule which means that some rules apply for the rest of a function body, even past the last use) < 1767831827 440697 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the reason &raw exists is partly because of that, and partly because if you go via a reference you narrow the provenance < 1767831855 424832 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :sure, lifetimes belong to safe rust, that's how safe rust proves at compile time that it doesn't do anything that would be forbidden in unsafe rust, and unsafe rust is allowed to ignore lifetimes using an unsafe cast of pointer to reference < 1767831875 769944 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah right, so the problem isn't "I convert this to a reference and then to a pointer, and the reference aliases something so it's UB" < 1767831890 768307 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :but typed references and typed mut references still have strict rules in unsafe rust < 1767831916 111472 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the problem is "I convert this to a reference and then to a pointer, and the reference aliased something, so *when I use the pointer* it is trying to use the reference's provenance and so the fact that the reference aliased something then causes UB now" > 1767831975 438833 PRIVMSG #esolangs :14[[07User talk:FluixMakesEsolangs14]]4 10 02https://esolangs.org/w/index.php?diff=172494&oldid=172471 5* 03 5* (+35) 10 < 1767831992 630674 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess the way to look at it is that a reference that illegally aliases something isn't insta-UB, but it screws up the reference's provenance, so anything that you subsequently try to do with pointers derived from it is UB < 1767832049 729544 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and you might as well express this rule as "references aren't allowed to illegally alias things" < 1767832100 536882 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :hmm > 1767832178 361348 PRIVMSG #esolangs :14[[07Esolang talk:Categorization14]]4 10 02https://esolangs.org/w/index.php?diff=172495&oldid=172491 5* 03A() 5* (+206) 10/* Groups */ < 1767832251 983902 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I guess you are allowed to point an UnsafeCell anywhere, but I don't think that's an informative way to think of all raw pointers, simply because you aren't guaranteed to be able to do anything with an UnsafeCell > 1767832431 669503 PRIVMSG #esolangs :14[[07User:A()14]]4 10 02https://esolangs.org/w/index.php?diff=172496&oldid=172252 5* 03A() 5* (+10) 10 > 1767832496 759000 PRIVMSG #esolangs :14[[07ASTLang (Fast Lookup)14]]4 10 02https://esolangs.org/w/index.php?diff=172497&oldid=172315 5* 03NTMDev 5* (-169) 10Blanked the page > 1767832522 142129 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=172498&oldid=172317 5* 03NTMDev 5* (-281) 10 > 1767832698 242534 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=172499&oldid=172498 5* 03NTMDev 5* (+307) 10/* PrimitiveWrapper (DEPRECATED) */ > 1767832717 2766 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=172500&oldid=172499 5* 03NTMDev 5* (-133) 10/* Types */ > 1767832951 587353 PRIVMSG #esolangs :14[[07GTPS14]]4 10 02https://esolangs.org/w/index.php?diff=172501&oldid=172493 5* 03A() 5* (+30) 10 > 1767832987 991626 PRIVMSG #esolangs :14[[07GTPS14]]4 10 02https://esolangs.org/w/index.php?diff=172502&oldid=172501 5* 03A() 5* (+0) 10 > 1767833004 7904 PRIVMSG #esolangs :14[[07GTPS14]]4 10 02https://esolangs.org/w/index.php?diff=172503&oldid=172502 5* 03A() 5* (+0) 10 < 1767833033 697460 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :a raw pointer could have arithmetic done on it to store extra info, or it could point to a function or to an atomic. I think you're still allowed to make an &UnsafeCell from it in those cases, but you can't use that &UnsafeCell for anything, so I don't think UnsafeCell helps imagine what raw pointers can do. > 1767833035 520245 PRIVMSG #esolangs :14[[07GTPS14]]4 10 02https://esolangs.org/w/index.php?diff=172504&oldid=172503 5* 03A() 5* (+0) 10 < 1767833054 321511 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :(other than casting that &UnsafeCell back into a raw pointer) < 1767833176 805602 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :(well no, technically you can also pass it as an &UnsafeCell to a foreign function, but it would be strange to declare the function that way rather than with a raw pointer) < 1767833206 748239 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :(or you can reinterpret the bits of the reference as a pointer, they're represented the same) < 1767833269 528268 :somefan!~somefan@208.58.192.69 QUIT :Remote host closed the connection < 1767833277 340501 :somefan!~somefan@208.58.192.69 JOIN #esolangs * :[https://web.libera.chat] somefan < 1767833352 838396 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :are atomics something different from non-atomics? i thought that was a property of the access, not the object < 1767833390 351862 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :is "raw pointer pointing to a function" something different from the general case of "raw pointer to the wrong type"? < 1767833431 903464 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :sorear: it's technically a property of the access, but you can cast a raw pointer to a raw pointer of any other type so *anything* is a property of the access at that point. < 1767833501 189976 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :as for raw pointer pointing to a function, only in as much that I think some C APIs use a C pointer to void instead of a pointer to a function whose type isn't known until runtime, which is odd but not really wrong < 1767833566 810025 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :that's allowed by POSIX as an extension but not in general legal C, e.g. x86-16 MEDIUM model < 1767833623 162421 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :no, C specifically allows that for void pointers < 1767833670 102575 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :C says that void pointers can represent pointers to functions or pointers to any type of object, it's safe to cast any of those to void pointer as long as you cast back before use < 1767833746 274714 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :(also any pointer to a struct/union can represent a pointer to any other struct/union, but that's mostly so that pointers to not incomplete structs can work sanely with a specific representation, which you use if the struct will either be delcared later or only in other compilation units) < 1767833779 567838 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :other pointer types can be more restricted, but void pointers are magic in C < 1767833802 817392 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ok, not really magic, just have strong guarantees < 1767833901 172711 :int-e!~noone@int-e.eu PRIVMSG #esolangs :AFAICS &UnsafeCell must be properly aligned because it had to point to valid memory when it was constructed: "whenever a &UnsafeCell is constructed or dereferenced, it must still point to live memory" < 1767834012 592754 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :if you want something that needn't be able to point to a function the you can use a pointer to struct, kind of. I think the C standard allows that all structs are 4-byte aligned even when you have 1-byte and 2-byte integer types, and pointers to struct could be such that they can only represent 4-aligned addresses, so if you want to do this you'll have to wrap anything you want to point to into a < 1767834018 589498 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :struct. But I don't think C behaves like that on any real architecture. < 1767834026 461302 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :int-e: yes, but ais523 did say aligned and non-null < 1767834112 873820 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : are atomics something different from non-atomics? i thought that was a property of the access, not the object ← it's a property of the access *but* there's no useful way to correctly mix atomic and non-atomic accesses, so it makes sense for the type system to dictate what sort of access you're using < 1767834145 774192 :int-e!~noone@int-e.eu PRIVMSG #esolangs :b_jonas: Maybe I read something into https://logs.esolangs.org/libera-esolangs/2026-01-08.html#lR that you didn't intend to say, but to me it sounded like you were suggesting that you could, say, put a tagged pointer into a &UnsafeCell < 1767834157 20382 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : no, C specifically allows that for void pointers ← I also thought function pointers were an exception to this, ahs something changed? < 1767834212 810453 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: you can't do that specifically due to representation validity reasons (the compiler is allowed to assume that references haven't been tagged, even if you don't read through them, and uses this allowance to collapse enum size) – I don't think there are any provenance reasons why you couldn't do it though < 1767834232 740975 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: that's what I said just before? < 1767834245 632840 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: sorry, pings are confusing < 1767834257 390316 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I was mostly replying to b_jonas but trying to quote your comment by reference < 1767834274 296360 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ah. relatable. < 1767834276 431424 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I have realised recently that my use of pings on IRC is more to do with whether I am replying to a previous comment specifically than with who I am replying to < 1767834352 821525 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :recently someone posted two comments, I replied to the second one with no ping, then replied to the first one with a ping, I think that's another example of the same sort of phenomenon (I think I subconsciously decided to gave the ping because the referent wouldn't be obvious otherwise) < 1767834392 750066 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :…and now I'm realising that I have somehow managed to subconsciously create a new language convention that uses existing communication mechanisms for a purpose entirely different from the recommended or generally understood one < 1767834420 736939 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :languages aren't real, it's idiolects all the way down < 1767834448 629374 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: I think of it as like when I'm doing dishes and talking to somebody. Pinging is like looking up, making eye contact, and ensuring that I've gotten a point across. More practically, I use pings to indicate that I think that the recipient might want to read what I'm saying. < 1767834536 946679 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :int-e: I can understand if you read it that way, but yes, you may still need the pointer to be aligned and it definitely needs to be non-null if you want to make an UnsafeCell there, and since ais523 mentioned that I didn't repeat. < 1767834594 150154 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :references being aligned and non-null is a validity thing, otherwise type like Option<&T> wouldn't work properly (it relies on references always being non-null, even if they're never used, to be able to distinguish Some(null) from None) < 1767834642 790312 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if not for that rule an &UnsafeCell to null would actually work, as long as you never read or wrote it (there's a specific rule saying that you can free/unmap the memory behind an &UnsafeCell) < 1767834677 929196 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and because the compiler has to allow for the possibility that the memory is unmapped, it won't do anything that wouldn't work with null, because null is also just unmapped memory from the processor's point of view < 1767834921 549209 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :you're right. sorear: sorry, I was wrong about function pointers, C doesn't claim that you can convert them to void * and back. I don't know why I thought it did. < 1767835280 501212 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :Rust rules have been relaxed to allow some limited mixing of atomic with non-atomic, though I hvaen't processed the details of whether this is useful. In particular, I don't understand if you can just zero memory and transmute it instead of initializing a rust atomic. < 1767835347 253484 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: an &mut can be reborrowed as an &Atomic < 1767835375 439553 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the basic way to think about it is that all the cell-like types can be switched between if you have a mutable reference, but not if you don't have a mutable reference < 1767835445 290943 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: ok, but if you reborrow that way, will it give a definite value if you atomic read it, and the same as if you had read it as an integer instead before reborrowing as an atomic? < 1767835455 155403 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: yes < 1767835468 60331 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :good < 1767835485 64555 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can think of the Atomic types as basically being thread-safe versions of Cell < 1767835490 408369 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that are limited to primitive types < 1767835656 942033 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :sure, that's how they're implemented, but I want to know what's actually guaranteed about them in a future-proof way. this is relevant eg. if you want to atomic access the same atomic objects from rust and some other language concurrently < 1767835701 492951 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :memory in Rust is not typed – the only type-like thing about it is whether it carries provenance < 1767835733 131278 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the rules about atomics are basically that accesses that *aren't* atomic can't race with each other, but accesses that are atomic can < 1767835747 972905 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(if there is a race, both accesses need to be atomic) < 1767835750 520415 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :good < 1767835788 265691 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so if you have any reason to use atomics in the first place (i.e. races exist), you then have to somehow prove that the races have stopped existing before you can do non-atomic accesses on the same memory < 1767835813 721730 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(prove to the compiler in safe Rust, or prove to yourself in unsafe Rust) < 1767836082 44582 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: so one weird thing that I could imagine is this. Say you have an ARM-like CPU that has arithmetic only between registers, but has both little-endian and big-endian 16-bit and 32-bit integer load and store instructions. So the C ABI has to pick one of big-endian or little-endian, it picked one of them and that spread. Then a later extension of the CPU adds an atomic compare and exchange < 1767836088 59644 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :instruction, but only one endianness. Then you could end up with a C ABI where integers have the opposite endianness from atomic integers, and then the Rust ABI will match that too. < 1767836108 673793 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :Or the same but it's only 128 byte sized atomic compare an exchange instructions that are in one endianness only. < 1767836136 448844 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :You could still manipulate atomics of any endianness, the other endianness just takes an extra instruction or two to byteswap your registers. < 1767836175 690590 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: AtomicUsize::from_mut / AtomicUsize::get_mut (unstable) would probably deal with the conversion, although it seems unlikely that such a situation would end up happening < 1767836221 81137 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in practice I would expect all modern processors to use the same endianness for integers as they do for pointers, and normally pointers have to be pushed to the stack automatically by the hardware sometimes < 1767836235 471130 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but I can just about imagine having a link register and an interrupt link register to avoid that < 1767836278 507835 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :that's how pretty much all of the RISCs work except SuperH < 1767836321 211030 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :arm1 exceptions store the PC into a general register, but R14/R15 are banked in all modes so it works out the same < 1767836365 309585 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in any case, most processors that can't do arithmetic on memory use LL/SC as their atomic primitive rather than CAS < 1767836383 361466 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although I guess it's possible that LL/SC would only work on one endianness but MOV would work on both < 1767836392 449240 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :what is LL/SC? < 1767836402 794431 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :load-linked/store-conditional < 1767836415 212851 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :if you think of registers as being a sequence of bytes LL/SC and CAS are both endian agnostic < 1767836423 327589 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :what does that mean? < 1767836440 270085 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the way it works on most processors is that LL loads a value from memory and also marks some amount of surrounding memory as busy < 1767836455 463579 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and SC stores to memory, but only if none of the memory busied by the most recent LL instruction has been touched since < 1767836493 470339 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :otherwise it does some sort of error return instead < 1767836530 407785 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: so that's like compare and swap but it's allowed to spuriously fail? < 1767836551 920999 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(ideally LL would busy only the specific value you loaded, but normally it has to busy at least a cache line) < 1767836563 770422 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: can indeed spuriously fail, but also it doesn't have the ABA problem < 1767836565 808213 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I think that's https://doc.rust-lang.org/nightly/std/sync/atomic/struct.AtomicI32.html#method.compare_exchange_weak < 1767836576 508699 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :what's "ABA problem"? < 1767836585 834783 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :you can emulate "wrong endian" xadd/amoadd/ldadd using a LL/SC or CAS loop but the emulation has different lock-free/wait-free properties than native xadd/amoadd/ldadd < 1767836594 205341 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I mean at the CPU level it would have somehwat stronger guarantees on when exactly it can spuriously fail < 1767836608 218430 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: memory gets written to twice during an atomic sequence and ends up with its old value, so when you do the compare-and-swap at the end you think it hasn't chagned < 1767836629 950914 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :the ABA thing is an urban legend, LL/SC is stronger than CAS if you can do unrelated memory operations in the middle but this is not actually allowed by any ISA specification < 1767836649 257709 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this can be problematic if, e.g., the atomic value is a pointer and you are relying on the pointer not having changed to indicate that the value it points to hasn't changed (e.g. because it doesn't change for as long as it's in the variable) < 1767836685 710062 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because if in the middle of your compare-exchange loop, someone took out the pointer, changed the memory it points to, and put it back again, it'll look like nothing happened but now your information is stale < 1767836690 286795 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :LL immediately followed by SC is observably equivalent to CAS because you can postdate the successful LL and pretend it happened at the same time as the SC < 1767836708 438771 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ok, I think this doesn't change much in how I imagine atomics could represent numbers differently than integers < 1767836729 446855 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :but it's still interesting < 1767836732 812651 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: LL immediately followed by SC is a swap, isn't it? (rather than a compare-and-swap) < 1767836744 760365 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if you want a compare-and-swap you need to actually do the compare in between < 1767836763 969265 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :"immediately" in the sense of the local memory order < 1767836767 478789 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah, I see < 1767836771 763636 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :it explains why so many functions that are generic between CPUs are defined to allow spurious fails where you have to retry < 1767836775 703293 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, in that case it doesn't give you any extra power I think < 1767836777 760796 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :well, explains some of it < 1767836786 57742 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :some of the spurious failures may be introduced at a higher levle < 1767836798 994414 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one thing that surprised me about this is just how much memory typically gets busied by the LL in practice < 1767836816 947533 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :realistically it has to be at least a cache line, but often it's somewhere around a kilobyte, which is surprisingly large to me < 1767836830 429990 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :of course, usually you get away with it because the LL and SC are so close together < 1767836923 100628 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :it's mostly unobservable outside performance because the SC is allowed to fail spuriously < 1767836953 552683 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: oh! there's a subtlety I forgot about converting between atomics and nonatomics – atomics have bigger alignment on some platforms < 1767836987 481974 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :e.g. u64 sometimes has 4-byte alignment on 32-bit platforms, but AtomicU64 has 8-byte alignment basically everywhere because it's hard to stop it straddling a cache line otherwise < 1767837014 19505 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :the Rocket implementation starts a ~16 cycle timer when it sees a LL, refuses remote invalidations while the timer is active, and succeeds SC if the timer is active and the address matches < 1767837020 550727 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that said, IIRC misaligned atomics actually work on x86(-64) except for the double-register ones < 1767837031 346812 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :that's reasonable. cache lines are small because the data actually has to be moved, and there are physical limits to how many bits fit through the wires quickly, but synchronization between CPU threads could be less fine-grained. < 1767837036 134310 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and the processor has to be able to lock two cache lines because of that < 1767837083 790515 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(this still doesn't mean that any sensible compiler/language will let you define misaligned atomics, though) < 1767837185 969273 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: yeah, x86_64 mostly tolerates unaligned accesses surprisingly well. there are some cases when they don't work, but it's mostly (1) the MOVDQA instruction that exists for historical reasons because it used to be faster in old CPUs but these days has no advantage over MOVDQU, (2) one flag that you can specifically set to disallow certain unaligned vector accesses, probably to catch code that < 1767837191 987892 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :mistakenly does unaligned access, and (3) system-related stuff like page tables. < 1767837206 463401 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: and the alignment check flag! < 1767837215 14128 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :that's (2) isn't it? < 1767837229 51791 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :no, it controls non-vector accesses specifically < 1767837236 683259 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :riscv has misaligned atomics within an aligned 16byte region as a feature "intended to be mandatory in a future profile", nobody will say what the actual use case for this is < 1767837252 159825 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :only 16-, 32- and 64-bit accesses cause alignment traps, anything larger (or smaller) can't < 1767837314 409921 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :AVX and later allow misaligned vectors unless you are using a specifically aligned instruction like MOVDQA, but SSE instructions fault on misaligned vectors, so that's one way to custom alignment behaviour on vector instructions (as long as they're old enough) < 1767837328 688349 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :I think AC mostly exists as a migration aid from when they weren't quite sure what the IA-32 successor was and whether it would support misalignment < 1767837329 884030 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I think originally the unaligned was because the 8088 got popular and people wrote code for it that did unaligned access, and some of the supposedly undocumented IBM PC BIOS variables at unaligned addresses ascended to de facto public API that every clone had to support. But I don't know why it got continued so far. < 1767837372 550714 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :AVX encodings should in theory be faster due to zeroing the top of the register rather than leaving it alone (and causing a false dependency) < 1767837373 72994 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :debian's current m68k ABI has sizeof int = 4, _Alignof int = 2 < 1767837414 779098 :int-e!~noone@int-e.eu PRIVMSG #esolangs :b_jonas: disassembling network packets and concatenated files and the like may just be useful enough < 1767837419 470539 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but it turns out that recent Intel has a sticky "some of the vector registers have data beyond the bottom 16 bytes" flag that isn't vector-specific, meaning that you get the false dependency even with AVX instructions < 1767837428 383822 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the only ways to clear it are VZEROUPPER/VZEROALL) < 1767837437 453003 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* that isn't specific to a particular vector register < 1767837467 124026 :int-e!~noone@int-e.eu PRIVMSG #esolangs :b_jonas: plus the fact that within the same cache line you can do this "for free" < 1767837478 460758 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this strikes me as a terrible idea, but Intel probably think they can get away with it because compilers do VZEROUPPER anyway to support linking against SSE libraries (and depressingly, they may be right) < 1767837491 79407 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :alignment check => I see < 1767837520 910120 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in any case this means that on recent Intel, SSE encodings have no actual downside over the AVX equivalent < 1767837525 243248 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :int-e: yes, that can be a good reason < 1767837551 256543 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :useful in string functions too < 1767837553 80200 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because both of them have to write both halves of the register if the second-16-dirty flag is set, and neither of them do if it's clear < 1767837589 11017 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but it also means you can't use different widths of vector at the same time < 1767837590 568591 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :or say you have a struct (necessarily with several fields) with size 8, align <8. wouldn't it be nice to copy it with one instruction? < 1767837605 575551 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(you *can* but you will get all operations acting at the speed of the largest vector you're using) < 1767837629 593312 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: why does that need to be atomic, though? < 1767837631 326951 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :do they still have the scratchpad? < 1767837635 565166 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I kind of wish compilers just had four first-class variants for their integer types according to whether they are aligned and their endianness. You can implement this as just library types, and it has been implemented in C++ a few times, but I feel like compilers could implement it easier. < 1767837646 633276 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :ais523: it needs to not fault < 1767837647 890722 :scoofy_!~scoofy@254C1327.nat.pool.telekom.hu JOIN #esolangs * :realname < 1767837697 288952 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :(Possibly six types if native endianness is considered different from both big and little endianness in the same way as C int and long and long long are three different types even if they're just two different representations.) < 1767837707 800411 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: right, but couldn't the feature just say "you need to be able to read/write misaligned data nonatomically within a cache line", rather than supporting atomics too? < 1767837758 315201 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: this goes back to the whole distinction between storage representations and register representations < 1767837767 317481 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :those weren't connected, I thought the conversation had moved to "why is unaligned access allowed at all" < 1767837772 730707 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: ah, I see < 1767837792 830220 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : riscv has misaligned atomics within an aligned 16byte region as a feature "intended to be mandatory in a future profile", nobody will say what the actual use case for this is < 1767837802 294631 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and then you started justifying it in the non-atomic case, which I agree iwth < 1767837813 498874 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I guess a hypothetical new CPU architecture could even have unaligned reads just work like x86, but unaligned writes raise a fault. < 1767837835 550800 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the best use I can think of in the atomic case is to somehow store more data in an atomic-safe way by using overlapping atomics < 1767837853 556475 :scoofy!~scoofy@254C2329.nat.pool.telekom.hu QUIT :Ping timeout: 264 seconds < 1767837882 910580 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: if it's doing that, it would be great if it faulted only on entirely unmapped memory and just returned zeroes for partially unmapped memory < 1767837896 825891 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :misaligned load/store *without* atomicity guarantees is already required in all application profiles < 1767837899 638345 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although the problem there is that hardware normally can't distinguish between memory being unmapped and paged out < 1767837955 130533 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: like for strlen? I dunno, it could make sense < 1767837971 44245 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: right < 1767837994 828942 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :troll option: byte level NaT < 1767838014 37966 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I have considered a mode in my C interpreter where any read from invalid memory silently reads 0, while writes fail, but you're right that at a hardware level this would be much harder < 1767838028 410076 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: that's not quite a troll option if it applies at the byte level in registers but the page level in memory < 1767838063 553985 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :also it's basically how LLVM's virtual machine works > 1767839098 597607 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03MtPenguinMonster 5* 10New user account > 1767839197 549203 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=172505&oldid=172451 5* 03MtPenguinMonster 5* (+202) 10/* Introductions */ < 1767839300 155046 :amby!~ambylastn@host-81-178-158-35.as13285.net 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 < 1767842078 350758 :impomatic!~impomatic@2a00:23c7:5fc6:3201:3cc5:8e33:3808:f449 JOIN #esolangs * :[https://web.libera.chat] impomatic < 1767843112 631124 :impomatic!~impomatic@2a00:23c7:5fc6:3201:3cc5:8e33:3808:f449 QUIT :Quit: Client closed < 1767850042 878716 :ais523!~ais523@user/ais523 QUIT :Quit: quit < 1767854265 118 :molson__!~molson@24-124-54-137-dynamic.midco.net QUIT :Remote host closed the connection > 1767856323 228873 PRIVMSG #esolangs :14[[07Gur yvsr14]]4 10 02https://esolangs.org/w/index.php?diff=172506&oldid=172492 5* 03Placeholding 5* (+93) 10clarified how a conditional and a conditional destination correspond < 1767856647 355577 :somefan!~somefan@208.58.192.69 QUIT :Remote host closed the connection < 1767857142 297625 :tromp!~textual@2001:1c00:3487:1b00:a460:d351:8685:d1f0 JOIN #esolangs * :Textual User > 1767859624 713465 PRIVMSG #esolangs :14[[07Brainpocalypse II14]]4 10 02https://esolangs.org/w/index.php?diff=172507&oldid=164875 5* 03Yayimhere2(school) 5* (+17) 10/* See also */ add goto start, very similair languages! < 1767859805 959919 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer < 1767862189 25422 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu QUIT :Quit: leaving > 1767863012 639685 PRIVMSG #esolangs :14[[07USI14]]4 N10 02https://esolangs.org/w/index.php?oldid=172508 5* 03Yayimhere2(school) 5* (+2643) 10Created page with "'''USI''', short for Unknown Source of Intervention, is a language based on the method of implementing of compiling one language to another, in which a counter is used as the program counter, and then when it has a certain value, a certain effect takes place. It < 1767863179 341031 :Yayimhere!~Yayimhere@2a02:aa7:464e:d550:a4b7:63fe:5700:f91d JOIN #esolangs * :[https://web.libera.chat] Yayimhere < 1767863510 946751 :tromp!~textual@2001:1c00:3487:1b00:a460:d351:8685:d1f0 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1767864995 340416 :Yayimhere!~Yayimhere@2a02:aa7:464e:d550:a4b7:63fe:5700:f91d QUIT :Ping timeout: 272 seconds > 1767866747 641692 PRIVMSG #esolangs :14[[07User:Yayimhere14]]4 10 02https://esolangs.org/w/index.php?diff=172509&oldid=172452 5* 03Yayimhere2(school) 5* (+64) 10/* esolangs */ < 1767868022 833452 :scoofy_!~scoofy@254C1327.nat.pool.telekom.hu NICK :scoofy < 1767868033 669970 :scoofy!~scoofy@254C1327.nat.pool.telekom.hu CHGHOST ~scoofy :user/scoofy < 1767868594 318554 :tromp!~textual@2001:1c00:3487:1b00:a460:d351:8685:d1f0 JOIN #esolangs * :Textual User < 1767873951 154869 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu JOIN #esolangs b_jonas :b_jonas < 1767874043 340960 :somefan!~somefan@208.58.192.69 JOIN #esolangs * :[https://web.libera.chat] somefan > 1767874534 447217 PRIVMSG #esolangs :14[[07DeltaLang14]]4 N10 02https://esolangs.org/w/index.php?oldid=172510 5* 03PrySigneToFry 5* (+5909) 10Created page with "DeltaLang is designed by PSTF. It is a formal programming language, roughly designed in [https://funcode.miraheze.org/wiki/Gdel's_Incompleteness_Theorems_vs_Programming_Languages Gdel's Incompleteness Theorems vs Programming Languages]. Note, the DeltaLang reco < 1767875025 914530 :APic!apic@apic.name PRIVMSG #esolangs :Hi > 1767875255 201757 PRIVMSG #esolangs :14[[07User:Hotcrystal0/Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=172511&oldid=172480 5* 03Hotcrystal0 5* (-2) 10 > 1767878200 284593 PRIVMSG #esolangs :14[[07User:Blashyrkh/Crazy J14]]4 10 02https://esolangs.org/w/index.php?diff=172512&oldid=172199 5* 03Blashyrkh 5* (+17476) 10Sequential tag system implementation < 1767879763 231520 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer < 1767879790 341734 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan < 1767883606 349857 :impomatic!~impomatic@2a00:23c7:5fc6:3201:3cc5:8e33:3808:f449 JOIN #esolangs * :[https://web.libera.chat] impomatic > 1767883663 531543 PRIVMSG #esolangs :14[[07BrainTrix14]]4 10 02https://esolangs.org/w/index.php?diff=172513&oldid=170948 5* 03JIT 5* (+10) 10 > 1767883693 993995 PRIVMSG #esolangs :14[[07Hata hata hata ton14]]4 10 02https://esolangs.org/w/index.php?diff=172514&oldid=171054 5* 03JIT 5* (+24) 10 > 1767883754 136988 PRIVMSG #esolangs :14[[07AddByteNegJump14]]4 10 02https://esolangs.org/w/index.php?diff=172515&oldid=171056 5* 03JIT 5* (+42) 10 > 1767883772 634087 PRIVMSG #esolangs :14[[07AddSys14]]4 10 02https://esolangs.org/w/index.php?diff=172516&oldid=171083 5* 03JIT 5* (+23) 10 > 1767883787 404236 PRIVMSG #esolangs :14[[07AddByte14]]4 10 02https://esolangs.org/w/index.php?diff=172517&oldid=171194 5* 03JIT 5* (+23) 10 > 1767883810 237459 PRIVMSG #esolangs :14[[07Memory14]]4 10 02https://esolangs.org/w/index.php?diff=172518&oldid=171288 5* 03JIT 5* (+23) 10TIM > 1767883864 240017 PRIVMSG #esolangs :14[[07AddByteJump14]]4 10 02https://esolangs.org/w/index.php?diff=172519&oldid=172462 5* 03JIT 5* (+23) 10its not THAT hard, TIM! just add a category:languages and tHATS it > 1767884107 910329 PRIVMSG #esolangs :14[[07Talk:USI14]]4 N10 02https://esolangs.org/w/index.php?oldid=172520 5* 03Aadenboy 5* (+349) 10noticed > 1767884209 512665 PRIVMSG #esolangs :14[[07Talk:USI14]]4 10 02https://esolangs.org/w/index.php?diff=172521&oldid=172520 5* 03Yayimhere2(school) 5* (+237) 10 < 1767884441 389001 :DOS_User_webchat!~DOS_User_@user/DOS-User:11249 JOIN #esolangs DOS_User :[https://web.libera.chat] DOS_User_webchat > 1767884553 553352 PRIVMSG #esolangs :14[[07USI14]]4 10 02https://esolangs.org/w/index.php?diff=172522&oldid=172508 5* 03Yayimhere2(school) 5* (+17) 10 < 1767884901 207017 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname < 1767885020 181390 :DOS_User_webchat!~DOS_User_@user/DOS-User:11249 QUIT :Quit: Client closed < 1767885414 955744 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1767885421 867738 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`olist 1338 < 1767885426 627118 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :olist : shachaf oerjan Sgeo boily nortti b_jonas Noisytoot < 1767885500 401798 :int-e!~noone@int-e.eu PRIVMSG #esolangs :. o O ( the wall of text comic is still going I see ) > 1767885813 664227 PRIVMSG #esolangs :14[[07User talk:Blashyrkh14]]4 N10 02https://esolangs.org/w/index.php?oldid=172523 5* 03Yayimhere2(school) 5* (+202) 10Created page with "Hey, you make some cool stuff!!! Would you perhaps collaborate with me on an esolang? --~~~~" > 1767886067 538940 PRIVMSG #esolangs :14[[07User:Blashyrkh/Crazy J14]]4 10 02https://esolangs.org/w/index.php?diff=172524&oldid=172512 5* 03Blashyrkh 5* (+1209) 10Cyclic tag system implementation > 1767886592 883968 PRIVMSG #esolangs :14[[07User talk:Blashyrkh14]]4 M10 02https://esolangs.org/w/index.php?diff=172525&oldid=172523 5* 03Blashyrkh 5* (+134) 10 > 1767886688 841737 PRIVMSG #esolangs :14[[07User talk:Blashyrkh14]]4 10 02https://esolangs.org/w/index.php?diff=172526&oldid=172525 5* 03Yayimhere2(school) 5* (+165) 10 < 1767886710 569690 :amby!~ambylastn@host-81-178-158-35.as13285.net JOIN #esolangs amby :realname < 1767887116 466825 :ehmry!~quassel@217.155.30.169 QUIT :Quit: https://quassel-irc.org - Chat comfortably. Anywhere. < 1767887123 743966 :tromp!~textual@2001:1c00:3487:1b00:a460:d351:8685:d1f0 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… > 1767887616 211007 PRIVMSG #esolangs :14[[07User talk:Blashyrkh14]]4 M10 02https://esolangs.org/w/index.php?diff=172527&oldid=172526 5* 03Blashyrkh 5* (+372) 10 > 1767887681 862653 PRIVMSG #esolangs :14[[07User talk:Blashyrkh14]]4 10 02https://esolangs.org/w/index.php?diff=172528&oldid=172527 5* 03Yayimhere2(school) 5* (+189) 10 > 1767888101 133789 PRIVMSG #esolangs :14[[07User talk:Blashyrkh14]]4 M10 02https://esolangs.org/w/index.php?diff=172529&oldid=172528 5* 03Blashyrkh 5* (+402) 10 > 1767888267 606291 PRIVMSG #esolangs :14[[07User talk:Blashyrkh14]]4 10 02https://esolangs.org/w/index.php?diff=172530&oldid=172529 5* 03Yayimhere2(school) 5* (+136) 10 < 1767888275 725722 :tromp!~textual@2001:1c00:3487:1b00:a460:d351:8685:d1f0 JOIN #esolangs * :Textual User > 1767888421 489578 PRIVMSG #esolangs :14[[07User:Blashyrkh14]]4 M10 02https://esolangs.org/w/index.php?diff=172531&oldid=171679 5* 03Blashyrkh 5* (+145) 10Link to UnnamedEsolang draft page < 1767889428 491513 :ehmry!~quassel@217.155.30.169 JOIN #esolangs ehmry :Emery < 1767889439 224364 :somefan!~somefan@208.58.192.69 QUIT :Remote host closed the connection < 1767889449 339971 :somefan!~somefan@208.58.192.69 JOIN #esolangs * :[https://web.libera.chat] somefan < 1767889952 619580 :somefan!~somefan@208.58.192.69 QUIT :Remote host closed the connection < 1767889963 339537 :somefan!~somefan@208.58.192.69 JOIN #esolangs * :[https://web.libera.chat] somefan > 1767890379 61194 PRIVMSG #esolangs :14[[07User:Blashyrkh/UnnamedEsolang14]]4 N10 02https://esolangs.org/w/index.php?oldid=172532 5* 03Blashyrkh 5* (+1544) 10Just an idea of a language < 1767890391 150528 :impomatic!~impomatic@2a00:23c7:5fc6:3201:3cc5:8e33:3808:f449 QUIT :Quit: Client closed > 1767890419 788661 PRIVMSG #esolangs :14[[07User talk:Blashyrkh14]]4 M10 02https://esolangs.org/w/index.php?diff=172533&oldid=172530 5* 03Blashyrkh 5* (+131) 10 > 1767890583 755967 PRIVMSG #esolangs :14[[07User:Blashyrkh/UnnamedEsolang14]]4 M10 02https://esolangs.org/w/index.php?diff=172534&oldid=172532 5* 03Blashyrkh 5* (-1) 10typo > 1767890778 274877 PRIVMSG #esolangs :14[[07User talk:Blashyrkh14]]4 10 02https://esolangs.org/w/index.php?diff=172535&oldid=172533 5* 03Yayimhere2(school) 5* (+321) 10 > 1767890916 425192 PRIVMSG #esolangs :14[[07User talk:Blashyrkh14]]4 10 02https://esolangs.org/w/index.php?diff=172536&oldid=172535 5* 03Yayimhere2(school) 5* (+31) 10 > 1767891317 782145 PRIVMSG #esolangs :14[[07User talk:Blashyrkh14]]4 M10 02https://esolangs.org/w/index.php?diff=172537&oldid=172536 5* 03Blashyrkh 5* (+431) 10 > 1767891524 208469 PRIVMSG #esolangs :14[[07User talk:Blashyrkh14]]4 10 02https://esolangs.org/w/index.php?diff=172538&oldid=172537 5* 03Yayimhere2(school) 5* (+213) 10 > 1767891721 923595 PRIVMSG #esolangs :14[[07User talk:Blashyrkh14]]4 M10 02https://esolangs.org/w/index.php?diff=172539&oldid=172538 5* 03Blashyrkh 5* (+168) 10 > 1767891755 441739 PRIVMSG #esolangs :14[[07User talk:Blashyrkh14]]4 10 02https://esolangs.org/w/index.php?diff=172540&oldid=172539 5* 03Yayimhere2(school) 5* (+182) 10 < 1767891898 609629 :somefan!~somefan@208.58.192.69 QUIT :Remote host closed the connection < 1767891914 340140 :somefan!~somefan@208.58.192.69 JOIN #esolangs * :[https://web.libera.chat] somefan > 1767891919 732585 PRIVMSG #esolangs :14[[07User:Blashyrkh/UnnamedEsolang14]]4 M10 02https://esolangs.org/w/index.php?diff=172541&oldid=172534 5* 03Blashyrkh 5* (+41) 10some clarification > 1767891959 602092 PRIVMSG #esolangs :14[[07User:Blashyrkh/UnnamedEsolang14]]4 10 02https://esolangs.org/w/index.php?diff=172542&oldid=172541 5* 03Yayimhere2(school) 5* (+12) 10 < 1767892452 345477 :impomatic!~impomatic@2a00:23c7:5fc6:3201:3cc5:8e33:3808:f449 JOIN #esolangs * :[https://web.libera.chat] impomatic < 1767892753 9231 :ais523!~ais523@user/ais523 QUIT :Quit: quit < 1767892989 210401 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1767895517 798712 :svm!~msv@user/msv JOIN #esolangs msv :msv < 1767895655 249954 :msv!~msv@user/msv QUIT :Ping timeout: 240 seconds > 1767896265 686746 PRIVMSG #esolangs :14[[07Countable14]]4 10 02https://esolangs.org/w/index.php?diff=172543&oldid=172436 5* 03Aadenboy 5* (+843) 10implement the [[Kolakoski sequence]] < 1767896281 652311 :tromp!~textual@2001:1c00:3487:1b00:a460:d351:8685:d1f0 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… > 1767896324 41225 PRIVMSG #esolangs :14[[07Kolakoski sequence14]]4 10 02https://esolangs.org/w/index.php?diff=172544&oldid=168755 5* 03Aadenboy 5* (+834) 10add [[Countable]] > 1767896326 350880 PRIVMSG #esolangs :14[[07User:Blashyrkh/Crazy J14]]4 10 02https://esolangs.org/w/index.php?diff=172545&oldid=172524 5* 03Blashyrkh 5* (+4765) 10/* Cyclic tag system */ Compiled form of cts-sts adapter < 1767896402 331468 :svm!~msv@user/msv NICK :msv < 1767896926 940607 :tromp!~textual@2001:1c00:3487:1b00:a460:d351:8685:d1f0 JOIN #esolangs * :Textual User > 1767897677 283623 PRIVMSG #esolangs :14[[07Kolakoski sequence14]]4 10 02https://esolangs.org/w/index.php?diff=172546&oldid=172544 5* 03Yayimhere2(school) 5* (+2) 10/* Countable */ == -> === < 1767897910 969381 :Everything!~Everythin@172-232-54-192.ip.linodeusercontent.com QUIT :Quit: leaving > 1767897951 302918 PRIVMSG #esolangs :14[[07User:Blashyrkh/Crazy J14]]4 10 02https://esolangs.org/w/index.php?diff=172547&oldid=172545 5* 03Blashyrkh 5* (+289) 10New rule with S combinator, update table, remove some todos < 1767898279 466502 :impomatic!~impomatic@2a00:23c7:5fc6:3201:3cc5:8e33:3808:f449 QUIT :Quit: Client closed < 1767898574 436236 :tromp!~textual@2001:1c00:3487:1b00:a460:d351:8685:d1f0 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1767898940 889807 :tromp!~textual@2001:1c00:3487:1b00:a460:d351:8685:d1f0 JOIN #esolangs * :Textual User > 1767898971 632931 PRIVMSG #esolangs :14[[07Countable14]]4 10 02https://esolangs.org/w/index.php?diff=172548&oldid=172543 5* 03Yayimhere2(school) 5* (+8) 10make example programs have === === titles > 1767899209 554164 PRIVMSG #esolangs :14[[07USI14]]4 10 02https://esolangs.org/w/index.php?diff=172549&oldid=172522 5* 03Yayimhere2(school) 5* (+208) 10/* Syntax */ > 1767899337 439218 PRIVMSG #esolangs :14[[07Pythong14]]4 N10 02https://esolangs.org/w/index.php?oldid=172550 5* 03FluixMakesEsolangs 5* (+1827) 10Initial Creation of Page > 1767899339 233012 PRIVMSG #esolangs :14[[07USI14]]4 10 02https://esolangs.org/w/index.php?diff=172551&oldid=172549 5* 03Yayimhere2(school) 5* (+2) 10/* Constructs */ > 1767899422 809425 PRIVMSG #esolangs :14[[07USI14]]4 10 02https://esolangs.org/w/index.php?diff=172552&oldid=172551 5* 03Yayimhere2(school) 5* (+23) 10/* Semantics */ < 1767899670 261470 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :@metar EGBB < 1767899670 606066 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esolangs :METAR EGBB 081850Z 08010KT 1500 SN OVC004 01/00 Q0986 RESN RERA > 1767899953 287320 PRIVMSG #esolangs :14[[07Apraxia14]]4 10 02https://esolangs.org/w/index.php?diff=172553&oldid=172381 5* 03Yayimhere2(school) 5* (+8) 10/* Combinators */ > 1767900200 434146 PRIVMSG #esolangs :14[[07USI14]]4 10 02https://esolangs.org/w/index.php?diff=172554&oldid=172552 5* 03Yayimhere2(school) 5* (+34) 10/* Semantics */ > 1767900216 522929 PRIVMSG #esolangs :14[[07USI14]]4 10 02https://esolangs.org/w/index.php?diff=172555&oldid=172554 5* 03Yayimhere2(school) 5* (+47) 10/* Memory */ > 1767900244 683741 PRIVMSG #esolangs :14[[07USI14]]4 10 02https://esolangs.org/w/index.php?diff=172556&oldid=172555 5* 03Yayimhere2(school) 5* (+24) 10/* Semantics */ > 1767900293 865346 PRIVMSG #esolangs :14[[07USI14]]4 10 02https://esolangs.org/w/index.php?diff=172557&oldid=172556 5* 03Yayimhere2(school) 5* (+18) 10/* Semantics */ > 1767900467 181513 PRIVMSG #esolangs :14[[07USI14]]4 10 02https://esolangs.org/w/index.php?diff=172558&oldid=172557 5* 03Yayimhere2(school) 5* (+0) 10 > 1767900533 705382 PRIVMSG #esolangs :14[[07User talk:FluixMakesEsolangs14]]4 10 02https://esolangs.org/w/index.php?diff=172559&oldid=172494 5* 03FluixMakesEsolangs 5* (+240) 10I eat dirt > 1767900581 460260 PRIVMSG #esolangs :14[[07User talk:FluixMakesEsolangs/Secret14]]4 10 02https://esolangs.org/w/index.php?diff=172560&oldid=172469 5* 03FluixMakesEsolangs 5* (+145) 10 < 1767900702 341833 :impomatic!~impomatic@2a00:23c7:5fc6:3201:3cc5:8e33:3808:f449 JOIN #esolangs * :[https://web.libera.chat] impomatic < 1767901063 874843 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 246 seconds < 1767901073 974203 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1767901153 443063 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 NICK :Lord_of_Life > 1767901177 868954 PRIVMSG #esolangs :14[[07USI14]]4 10 02https://esolangs.org/w/index.php?diff=172561&oldid=172558 5* 03Yayimhere2(school) 5* (+65) 10/* Memory */ > 1767901577 925297 PRIVMSG #esolangs :14[[07User talk:RaiseAfloppaFan392514]]4 10 02https://esolangs.org/w/index.php?diff=172562&oldid=172011 5* 03Frendoly 5* (+237) 10 > 1767901662 214235 PRIVMSG #esolangs :14[[07User talk:RaiseAfloppaFan392514]]4 10 02https://esolangs.org/w/index.php?diff=172563&oldid=172562 5* 03Frendoly 5* (+131) 10 > 1767901717 745234 PRIVMSG #esolangs :14[[07Countable14]]4 M10 02https://esolangs.org/w/index.php?diff=172564&oldid=172548 5* 03Aadenboy 5* (-210) 10/* Commands */ simplifying language > 1767901794 96942 PRIVMSG #esolangs :14[[07User talk:RaiseAfloppaFan392514]]4 M10 02https://esolangs.org/w/index.php?diff=172565&oldid=172563 5* 03Frendoly 5* (-1) 10 > 1767902219 962722 PRIVMSG #esolangs :14[[07Countable14]]4 10 02https://esolangs.org/w/index.php?diff=172566&oldid=172564 5* 03Aadenboy 5* (+46) 10/* Commands */ < 1767903503 716291 :somefan!~somefan@208.58.192.69 QUIT :Remote host closed the connection < 1767903511 339501 :somefan!~somefan@208.58.192.69 JOIN #esolangs * :[https://web.libera.chat] somefan < 1767903684 823039 :tromp!~textual@2001:1c00:3487:1b00:a460:d351:8685:d1f0 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1767903761 115677 :tromp!~textual@2001:1c00:3487:1b00:a460:d351:8685:d1f0 JOIN #esolangs * :Textual User > 1767905432 414602 PRIVMSG #esolangs :14[[07User talk:FluixMakesEsolangs/Secret14]]4 M10 02https://esolangs.org/w/index.php?diff=172567&oldid=172560 5* 03Ractangle 5* (+206) 10 > 1767905554 925046 PRIVMSG #esolangs :14[[07Talk:Pythong14]]4 N10 02https://esolangs.org/w/index.php?oldid=172568 5* 03 5* (+88) 10Created page with "but what if you type print("garfield")?! the program would be incorrect 20% of the time!" > 1767905573 658600 PRIVMSG #esolangs :14[[07Talk:Pythong14]]4 M10 02https://esolangs.org/w/index.php?diff=172569&oldid=172568 5* 03 5* (+0) 10 > 1767905605 865752 PRIVMSG #esolangs :14[[07User talk:FluixMakesEsolangs/Secret14]]4 10 02https://esolangs.org/w/index.php?diff=172570&oldid=172567 5* 03 5* (+19) 10 > 1767905612 257766 PRIVMSG #esolangs :14[[07User:Blashyrkh/Crazy J14]]4 M10 02https://esolangs.org/w/index.php?diff=172571&oldid=172547 5* 03Blashyrkh 5* (+14) 10Strike out few TODO entries > 1767906828 415230 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 036S37l0314M0ri1109 5* 10New user account > 1767907897 912233 PRIVMSG #esolangs :14[[07User:Hotcrystal0/Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=172572&oldid=172511 5* 03Hotcrystal0 5* (+54) 10 > 1767908603 760566 PRIVMSG #esolangs :14[[07Backtick14]]4 M10 02https://esolangs.org/w/index.php?diff=172573&oldid=172401 5* 03Splot-dev 5* (+458) 10Added why Backtick is Turing Complete. > 1767908642 998752 PRIVMSG #esolangs :14[[07Backtick14]]4 M10 02https://esolangs.org/w/index.php?diff=172574&oldid=172573 5* 03Splot-dev 5* (+0) 10Moved link. > 1767908763 456269 PRIVMSG #esolangs :14[[07Backtick14]]4 M10 02https://esolangs.org/w/index.php?diff=172575&oldid=172574 5* 03Splot-dev 5* (-1) 10fixed syntax > 1767908807 158376 PRIVMSG #esolangs :14[[07Backtick14]]4 M10 02https://esolangs.org/w/index.php?diff=172576&oldid=172575 5* 03Splot-dev 5* (-1) 10moved comment to new line > 1767908830 827882 PRIVMSG #esolangs :14[[07Backtick14]]4 M10 02https://esolangs.org/w/index.php?diff=172577&oldid=172576 5* 03Splot-dev 5* (+1) 10fixed grammar < 1767909704 94382 :APic!apic@apic.name PRIVMSG #esolangs :cu < 1767909842 775568 :impomatic!~impomatic@2a00:23c7:5fc6:3201:3cc5:8e33:3808:f449 QUIT :Quit: Client closed < 1767909842 891134 :somefan!~somefan@208.58.192.69 QUIT :Remote host closed the connection < 1767909852 339720 :somefan!~somefan@208.58.192.69 JOIN #esolangs * :[https://web.libera.chat] somefan > 1767910097 905279 PRIVMSG #esolangs :14[[07Language list14]]4 M10 02https://esolangs.org/w/index.php?diff=172578&oldid=172475 5* 03Buckets 5* (+14) 10/* M */ > 1767910128 794506 PRIVMSG #esolangs :14[[07User:Buckets14]]4 M10 02https://esolangs.org/w/index.php?diff=172579&oldid=172476 5* 03Buckets 5* (+13) 10 > 1767910142 517598 PRIVMSG #esolangs :14[[07Masheen14]]4 N10 02https://esolangs.org/w/index.php?oldid=172580 5* 03Buckets 5* (+1064) 10Created page with "Masheen is an Esoteric Programming Language created by [[User:Buckets]] in 2022. The IP Will start at the top-Left pointing Rightwards. {| class="wikitable" |- ! Commands !! Instructions |- | m || Point downwards if The Current value Is Perfectly Divisible by m(, so it < 1767912038 257236 :tromp!~textual@2001:1c00:3487:1b00:a460:d351:8685:d1f0 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1767913936 929891 :scoofy!~scoofy@user/scoofy QUIT :Ping timeout: 246 seconds