00:34:37 [[ButWhy]] https://esolangs.org/w/index.php?diff=161721&oldid=107225 * Stkptr * (+1218) 00:35:38 [[User talk:Stkptr]] https://esolangs.org/w/index.php?diff=161722&oldid=161675 * Stkptr * (+200) /* ButWhy subset */ 00:38:20 [[ButWhy]] https://esolangs.org/w/index.php?diff=161723&oldid=161721 * Stkptr * (+277) /* Computational class */ 00:54:19 -!- 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). 01:37:02 -!- alex__ has quit (Ping timeout: 244 seconds). 03:28:09 -!- Artea has quit (Remote host closed the connection). 03:30:49 -!- Artea has joined. 05:34:41 [[Talk:ErrorFuck]] https://esolangs.org/w/index.php?diff=161724&oldid=161637 * None1 * (+279) 05:46:59 [[ErrorFuck]] https://esolangs.org/w/index.php?diff=161725&oldid=161635 * None1 * (-97) 06:05:35 -!- Sgeo_ has joined. 06:08:28 -!- Sgeo has quit (Ping timeout: 240 seconds). 06:25:50 -!- ais523 has quit (Quit: sorry about my connection). 06:39:35 -!- tromp has joined. 06:44:44 -!- Sgeo_ has quit (Read error: Connection reset by peer). 06:46:16 -!- ais523 has joined. 06:47:37 -!- ais523 has quit (Client Quit). 07:40:59 [[User talk:I am islptng]] https://esolangs.org/w/index.php?diff=161726&oldid=161640 * I am islptng * (+175) /* User:Pifrited/chung wen */ 07:41:54 [[User:Stkptr]] https://esolangs.org/w/index.php?diff=161727&oldid=156882 * Stkptr * (-361) /* Todo */ 07:44:31 [[User talk:I am islptng]] https://esolangs.org/w/index.php?diff=161728&oldid=161726 * I am islptng * (+39) /* User:Pifrited/chung wen */ 08:47:27 [[Language list]] M https://esolangs.org/w/index.php?diff=161729&oldid=161491 * Creepy * (-29) 08:56:28 -!- wib_jonas has joined. 09:04:13 Hi 09:16:15 -!- tromp has quit (Ping timeout: 252 seconds). 09:32:03 [[Bobr Kurwa]] https://esolangs.org/w/index.php?diff=161730&oldid=161542 * Bobr123654 * (+46) 09:40:48 -!- DOS_User_webchat has joined. 09:50:39 -!- DOS_User_webchat has quit (Remote host closed the connection). 10:17:29 [[User:Dmitry samorodyuk]] N https://esolangs.org/w/index.php?oldid=161731 * Dmitry samorodyuk * (+54) Created page with "Young creator from Ukraine. Author of [[Boringscript]]" 10:23:05 -!- wib_jonas has quit (Quit: Client closed). 10:51:08 -!- alex__ has joined. 11:19:19 -!- Lord_of_Life has quit (Ping timeout: 260 seconds). 11:21:24 -!- Lord_of_Life has joined. 11:56:05 [[S and K Turing-completeness proof]] M https://esolangs.org/w/index.php?diff=161732&oldid=50517 * Tpaefawzen * (+0) /* Conversion */ long term typo? 12:02:58 -!- amby has joined. 13:37:04 -!- DOS_User_webchat has joined. 14:16:48 -!- DOS_User_webchat has quit (Remote host closed the connection). 14:18:38 -!- DOS_User_webchat has joined. 14:39:03 -!- DOS_User_webchat has quit (Ping timeout: 272 seconds). 14:53:30 [[User:Pifrited/]] N https://esolangs.org/w/index.php?oldid=161733 * Pifrited * (+42) 15:19:23 [[Talk:ErrorFull]] https://esolangs.org/w/index.php?diff=161734&oldid=114295 * Hotcrystal0 * (+481) 15:51:41 [[User:Pifrited/]] M https://esolangs.org/w/index.php?diff=161735&oldid=161733 * Pifrited * (+95) 16:36:00 [[Combinatory logic]] https://esolangs.org/w/index.php?diff=161736&oldid=159784 * Corbin * (+290) Clean up bluelink to TC proofs. 16:59:48 [[Special:Log/newusers]] create * Random.esotera * New user account 17:13:50 [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=161737&oldid=161678 * Random.esotera * (+232) 17:52:38 [[User:Tommyaweosme]] https://esolangs.org/w/index.php?diff=161738&oldid=161337 * Tommyaweosme * (+56) 17:59:38 [[S and K Turing-completeness proof]] https://esolangs.org/w/index.php?diff=161739&oldid=161732 * Corbin * (-869) Replace page with something more directly convincing. Note that I have not actually proven this correct, only typed it into a textbox. 18:28:04 [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161740&oldid=161650 * Hotcrystal0 * (+1022) 18:28:15 [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161741&oldid=161740 * Hotcrystal0 * (-7) 18:30:58 [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161742&oldid=161741 * Hotcrystal0 * (+27) 18:57:36 [[Bobr Kurwa]] https://esolangs.org/w/index.php?diff=161743&oldid=161730 * Stkptr * (+185) 19:12:15 [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161744&oldid=161742 * Hotcrystal0 * (+99) 19:12:57 [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161745&oldid=161744 * Hotcrystal0 * (+20) 19:29:19 [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161746&oldid=161745 * Hotcrystal0 * (+177) 19:31:58 [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161747&oldid=161746 * Hotcrystal0 * (+89) 19:32:30 [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161748&oldid=161747 * Hotcrystal0 * (+66) 19:37:11 -!- ais523 has joined. 19:39:36 [[S and K Turing-completeness proof]] https://esolangs.org/w/index.php?diff=161749&oldid=161739 * Ais523 * (+259) restore deleted external resources and see also section I don't see a reason to delete these, and suspect it was done unintentionally while trying to replace the proof 19:42:34 [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161750&oldid=161748 * Hotcrystal0 * (+11) 20:41:20 -!- ais523 has quit (Quit: sorry about my connection). 20:57:17 cu 21:01:35 [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161751&oldid=161750 * Hotcrystal0 * (+495) 21:01:49 [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161752&oldid=161751 * Hotcrystal0 * (+18) 21:16:36 [[User talk:Gilbert189]] https://esolangs.org/w/index.php?diff=161753&oldid=159719 * Hotcrystal0 * (+295) /* Scratch */ new section 21:34:29 -!- ais523 has joined. 21:41:30 [[User:Ractangle]] https://esolangs.org/w/index.php?diff=161754&oldid=161704 * Ractangle * (-4) /* Esolangs */ 21:42:35 [[Waretel BASIC]] M https://esolangs.org/w/index.php?diff=161755&oldid=137085 * Ractangle * (+0) Changed redirect target from [[Yayimhere like esolang]] to [[Yayimhere-like esolang]] 21:44:08 [[Hello world program in esoteric languages (T-Z)]] https://esolangs.org/w/index.php?diff=161756&oldid=152342 * Ractangle * (-61) /* Yayimhere-like esolang */ moving this 21:45:29 [[Hello world program in esoteric languages (nonalphabetic and A)]] https://esolangs.org/w/index.php?diff=161757&oldid=161579 * Ractangle * (+58) /* 2L */ 22:20:10 [[CATASTROPHICA]] N https://esolangs.org/w/index.php?oldid=161758 * Random.esotera * (+241) Created page with "CATASTROPHICA is an esolang created by [[User:Random.esotera]]. It is inspired by [[brainfuck]] and uses digit-based manipulation to define numbers. ''CATASTROPHICA is currently a W.I.P, so expect many changes in the future'' ===Commands===" 22:29:24 [[CATASTROPHICA]] https://esolangs.org/w/index.php?diff=161759&oldid=161758 * Random.esotera * (+1379) /* Commands */ 22:29:40 [[CATASTROPHICA]] https://esolangs.org/w/index.php?diff=161760&oldid=161759 * Random.esotera * (+1) /* Commands */ 22:38:45 FYI: I've switched the SMTP provider for the wiki now, since the previous one's free tier got disbanded. The settings should be such that it shouldn't be mangling the emails any (by adding tracking links and suchlike), and a test email through the "Email this user" feature seems pretty clean. But they do SPF/DKIM a little differently. 22:40:12 The new one's free tier allows for 1000 emails in a month, and last month the wiki sent a total of 33, so hopefully it's sufficient. 22:51:51 [[User:Hashibami]] https://esolangs.org/w/index.php?diff=161761&oldid=161257 * Hashibami * (+10) 23:13:23 ais523 re spurious write on Rust atomic read https://logs.esolangs.org/libera-esolangs/2025-02.html#l4I , I think this can happen on x86-32 with 80686 instruction set, where the CMPXCHG8B instruction may be the easiest way to implement an atomic read of 8 bytes, even just relaxed atomic to get a consistent snapshot. An x87 or MMX instruction may work but is less convenient to use for this, and there's 23:13:29 no SSE yet. The intel architecture manual says that CMPXCHG8B instruction will issue a write to memory even if the comparison is equal, but it's not entirely clear to me if this is only a description of what happens on the bus (to synchronize with other CPUs for example), or if it also implies a protection check and so would fail on a read-only page. If the latter then this may be what the rust manual 23:13:36 is talking about. 23:18:14 (this is totally irrelevant to the things I were thinking about in rust, it just came up while I was looking up things about it.) 23:27:58 b_jonas: yeah it'll fault if the destination is in a read-only page 23:29:34 int-e: thank you 23:30:55 b_jonas: I think I was talking about using a cmpxchg on a different address to act as a lock on the value you were reading 23:31:05 rather than just using cmpxchg directly as a read operation 23:31:15 wait, hold on 23:32:56 ah, never mind 23:33:56 I didn't think as using cmpxchg as an atomic read 23:34:01 * think of 23:34:10 are normal aligned reads atomic on x86? 23:34:12 ais523: yes, and that's a possibility for C++ or C atomics, but not for the rust std::sync::atomic Atomic* types, because the latter are guaranteed to be lock-free so they can't use a separate lock 23:34:40 they just aren't implemented if the underlying architecture makes it impossible to implement a lock-free atomic of the given size, which probably happens on every architecture for large enough types b 23:35:04 I guess, in a sense, *unaligned* reads are atomic because there is no way to do an atomic unaligned write, and thus any situation where the read tears could be interpreted as a situation where the write was torn instead 23:35:35 also rust atomics only go up to u64, which is annoying for algorithms which want a double-pointer atomic 23:42:35 ais523: I haven't delved deep into the x86 memory model so I'm not sure about this, but I think that yes, normal aligned reads on ordinary memory are atomic on x86, and I think on ordinary memory modern x86 can even do some atomic unaligned reads and writes too. but if you want to use that you'll probably need to write architecture-specific code in assembly, rust or C or C++ won't help you. 23:42:54 oh, I just remembered something relevant 23:43:37 my read_race thing ended up getting discussed, and it turns out to be relevant to sequence locks, which need a read with release ordering in order to work 23:43:51 but release-ordered reads don't exist in the C++ atomics model, or (in many cases) in hardware 23:44:05 however! you can implement them as a release-ordered add of 0, and that does work in hardware 23:44:10 but, it requires the memory to be writable 23:44:29 ais523: can't you use a read and a memory fence or two to implement them instead? 23:44:46 a memory fence is one way to implement memory orderings 23:44:55 but, I'm not sure whether all platforms have fences 23:45:08 and it is probably less efficient than synchronizing on the single address 23:45:26 sure, but doesn't C++ have memory fences, since the compiler optimizer has to know about them too, not just the architecture 23:46:09 https://en.cppreference.com/w/cpp/atomic/atomic_thread_fence.html 23:46:24 those are defined on the level of C++ memory model 23:46:31 but the real problem with sequence locks, at least in Rust, is that the memory model doesn't support doing atomic reads of addresses that are being written nonatomically, even if you discard the value you read 23:46:57 the rust version is https://doc.rust-lang.org/nightly/std/sync/atomic/fn.fence.html 23:47:23 it's possible to implement read_racy with an "argument from opaqueness" but they're unwilling to commit to the assumptions needed to make that sort of proof work (in particular, it requires the compiler not to reason about what the code could have done, but didn't) 23:48:58 Hmm. "An x87 instruction or an SSE instructions that accesses data larger than a quadword may be implemented using multiple memory accesses." 23:49:25 your cppreference link said that all the fences are no-ops on x86 except the seq_cst one 23:49:28 which is interesting 23:49:51 ais523: sure, but I think it still affects how the optimizer can rearrange memory accesses 23:50:01 the C++ fence calls affect that, that is 23:50:02 indeed, it's a compiler fence too 23:50:03 But on the other hand for sizes up to 64 bits, atomicity of reads and writes is guaranteed as long as the operand is within a single cache line. 23:50:06 (since P6) 23:50:19 systems that care about this sort of thing normally distinguish hardware fences from compiler fences 23:50:31 (This is notable because it includes some misaligned reads and writes.) 23:51:31 ais523: yes, https://doc.rust-lang.org/nightly/std/sync/atomic/fn.compiler_fence.html is the compiler-only fence 23:52:16 apparently, gcc compiles a seq_cst fence to a «lock or» of a stack slot with 0 23:52:21 this fence stuff gets deeper than the atomic stuff, I mostly just use the simple cases where everything is either accessed from one processor only, or seq_cst atomic, or relaxed atomic 23:52:30 actually this is red zone, I think, not a stack slot 23:52:52 whereas clang compiles it to mfence 23:53:49 I'm guessing that the lock or would be more efficient if the relevant part of redzone is in cache 23:54:12 – which makes me think that the correct address to use would be the return address stack slot, as that's very likely to be in cache 23:55:10 heh that depends on how long the function has been running 23:56:24 ais523: this is on x86_64, and what's the exact assembly code or machine code? 23:56:45 ais523: actually no, you'll interfere with return destination prediction, whatever that's called 23:56:53 I think this is just short to encode and guaranteed to be writable 23:57:14 b_jonas: a) yes; b) on clang «mfence», on gcc «lock or QWORD PTR [rsp], 0» 23:57:53 ais523: I see no clear winner for this question (which part of the stack to use) 23:58:06 int-e: I don't think so, return address prediction normally works as follows: a) speculatively jump to whichever address the matching call was from, b) check the relevant stack address to see if it contained the predicted return address, c) if it didn't, flush the pipeline 23:58:42 -!- Noisytoot has quit (Ping timeout: 248 seconds). 23:58:44 `echo bin/as-* 23:58:46 bin/as-* 23:58:50 `echo bin/*-as 23:58:51 bin/*-as 23:58:55 hmm 23:58:56 `ls bin 23:58:58 No output. 23:59:03 `ls ~/bin 23:59:05 ls: cannot access '~/bin': No such file or directory 23:59:08 ais523: hmm. yeah I guess that would be fine 23:59:22 `` echo $HOME 23:59:24 ​/tmp 23:59:25 -!- Noisytoot has joined. 23:59:29 `` ls ~/bin 23:59:30 ls: cannot access '/tmp/bin': No such file or directory 23:59:37 `` which quote 23:59:38 ​/hackenv/bin/quote 23:59:44 `` echo $PATH 23:59:45 `echo /hackenv/bin/as-* 23:59:46 ​/hackenv/bin:/usr/bin:/bin 23:59:47 ​/hackenv/bin/as-* 23:59:50 `echo /hackenv/bin/*-as 23:59:52 ​/hackenv/bin/*-as