00:34:37 <esolangs> [[ButWhy]] https://esolangs.org/w/index.php?diff=161721&oldid=107225 * Stkptr * (+1218)
00:35:38 <esolangs> [[User talk:Stkptr]] https://esolangs.org/w/index.php?diff=161722&oldid=161675 * Stkptr * (+200) /* ButWhy subset */
00:38:20 <esolangs> [[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 <esolangs> [[Talk:ErrorFuck]] https://esolangs.org/w/index.php?diff=161724&oldid=161637 * None1 * (+279)
05:46:59 <esolangs> [[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 <esolangs> [[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 <esolangs> [[User:Stkptr]] https://esolangs.org/w/index.php?diff=161727&oldid=156882 * Stkptr * (-361) /* Todo */
07:44:31 <esolangs> [[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 <esolangs> [[Language list]] M https://esolangs.org/w/index.php?diff=161729&oldid=161491 * Creepy * (-29)
08:56:28 -!- wib_jonas has joined.
09:16:15 -!- tromp has quit (Ping timeout: 252 seconds).
09:32:03 <esolangs> [[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 <esolangs> [[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 <esolangs> [[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 <esolangs> [[User:Pifrited/]] N https://esolangs.org/w/index.php?oldid=161733 * Pifrited * (+42)
15:19:23 <esolangs> [[Talk:ErrorFull]] https://esolangs.org/w/index.php?diff=161734&oldid=114295 * Hotcrystal0 * (+481)
15:51:41 <esolangs> [[User:Pifrited/]] M https://esolangs.org/w/index.php?diff=161735&oldid=161733 * Pifrited * (+95)
16:36:00 <esolangs> [[Combinatory logic]] https://esolangs.org/w/index.php?diff=161736&oldid=159784 * Corbin * (+290) Clean up bluelink to TC proofs.
16:59:48 <esolangs> [[Special:Log/newusers]] create * Random.esotera * New user account
17:13:50 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=161737&oldid=161678 * Random.esotera * (+232)
17:52:38 <esolangs> [[User:Tommyaweosme]] https://esolangs.org/w/index.php?diff=161738&oldid=161337 * Tommyaweosme * (+56)
17:59:38 <esolangs> [[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 <esolangs> [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161740&oldid=161650 * Hotcrystal0 * (+1022)
18:28:15 <esolangs> [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161741&oldid=161740 * Hotcrystal0 * (-7)
18:30:58 <esolangs> [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161742&oldid=161741 * Hotcrystal0 * (+27)
18:57:36 <esolangs> [[Bobr Kurwa]] https://esolangs.org/w/index.php?diff=161743&oldid=161730 * Stkptr * (+185)
19:12:15 <esolangs> [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161744&oldid=161742 * Hotcrystal0 * (+99)
19:12:57 <esolangs> [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161745&oldid=161744 * Hotcrystal0 * (+20)
19:29:19 <esolangs> [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161746&oldid=161745 * Hotcrystal0 * (+177)
19:31:58 <esolangs> [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161747&oldid=161746 * Hotcrystal0 * (+89)
19:32:30 <esolangs> [[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 <esolangs> [[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 <esolangs> [[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).
21:01:35 <esolangs> [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161751&oldid=161750 * Hotcrystal0 * (+495)
21:01:49 <esolangs> [[User:Hotcrystal0/Sandbox/OotT ideas]] https://esolangs.org/w/index.php?diff=161752&oldid=161751 * Hotcrystal0 * (+18)
21:16:36 <esolangs> [[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 <esolangs> [[User:Ractangle]] https://esolangs.org/w/index.php?diff=161754&oldid=161704 * Ractangle * (-4) /* Esolangs */
21:42:35 <esolangs> [[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 <esolangs> [[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 <esolangs> [[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 <esolangs> [[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 <esolangs> [[CATASTROPHICA]] https://esolangs.org/w/index.php?diff=161759&oldid=161758 * Random.esotera * (+1379) /* Commands */
22:29:40 <esolangs> [[CATASTROPHICA]] https://esolangs.org/w/index.php?diff=161760&oldid=161759 * Random.esotera * (+1) /* Commands */
22:38:45 <fizzie> 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 <fizzie> 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 <esolangs> [[User:Hashibami]] https://esolangs.org/w/index.php?diff=161761&oldid=161257 * Hashibami * (+10)
23:13:23 <b_jonas> 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 <b_jonas> 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:18:14 <b_jonas> (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 <int-e> b_jonas: yeah it'll fault if the destination is in a read-only page
23:30:55 <ais523> 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 <ais523> rather than just using cmpxchg directly as a read operation
23:33:56 <ais523> I didn't think as using cmpxchg as an atomic read
23:34:10 <ais523> are normal aligned reads atomic on x86?
23:34:12 <b_jonas> 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 <b_jonas> 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 <ais523> 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 <ais523> also rust atomics only go up to u64, which is annoying for algorithms which want a double-pointer atomic
23:42:35 <b_jonas> 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 <ais523> oh, I just remembered something relevant
23:43:37 <ais523> 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 <ais523> but release-ordered reads don't exist in the C++ atomics model, or (in many cases) in hardware
23:44:05 <ais523> however! you can implement them as a release-ordered add of 0, and that does work in hardware
23:44:10 <ais523> but, it requires the memory to be writable
23:44:29 <b_jonas> ais523: can't you use a read and a memory fence or two to implement them instead?
23:44:46 <ais523> a memory fence is one way to implement memory orderings
23:44:55 <ais523> but, I'm not sure whether all platforms have fences
23:45:08 <ais523> and it is probably less efficient than synchronizing on the single address
23:45:26 <b_jonas> 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 <b_jonas> https://en.cppreference.com/w/cpp/atomic/atomic_thread_fence.html
23:46:24 <b_jonas> those are defined on the level of C++ memory model
23:46:31 <ais523> 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 <b_jonas> the rust version is https://doc.rust-lang.org/nightly/std/sync/atomic/fn.fence.html
23:47:23 <ais523> 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 <int-e> 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 <ais523> your cppreference link said that all the fences are no-ops on x86 except the seq_cst one
23:49:51 <b_jonas> ais523: sure, but I think it still affects how the optimizer can rearrange memory accesses
23:50:01 <b_jonas> the C++ fence calls affect that, that is
23:50:02 <ais523> indeed, it's a compiler fence too
23:50:03 <int-e> 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:19 <ais523> systems that care about this sort of thing normally distinguish hardware fences from compiler fences
23:50:31 <int-e> (This is notable because it includes some misaligned reads and writes.)
23:51:31 <b_jonas> ais523: yes, https://doc.rust-lang.org/nightly/std/sync/atomic/fn.compiler_fence.html is the compiler-only fence
23:52:16 <ais523> apparently, gcc compiles a seq_cst fence to a «lock or» of a stack slot with 0
23:52:21 <b_jonas> 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 <ais523> actually this is red zone, I think, not a stack slot
23:52:52 <ais523> whereas clang compiles it to mfence
23:53:49 <ais523> I'm guessing that the lock or would be more efficient if the relevant part of redzone is in cache
23:54:12 <ais523> – 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 <int-e> heh that depends on how long the function has been running
23:56:24 <b_jonas> ais523: this is on x86_64, and what's the exact assembly code or machine code?
23:56:45 <int-e> ais523: actually no, you'll interfere with return destination prediction, whatever that's called
23:56:53 <b_jonas> I think this is just short to encode and guaranteed to be writable
23:57:14 <ais523> b_jonas: a) yes; b) on clang «mfence», on gcc «lock or QWORD PTR [rsp], 0»
23:57:53 <int-e> ais523: I see no clear winner for this question (which part of the stack to use)
23:58:06 <ais523> 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:59:05 <HackEso> ls: cannot access '~/bin': No such file or directory
23:59:08 <int-e> ais523: hmm. yeah I guess that would be fine
23:59:25 -!- Noisytoot has joined.
23:59:30 <HackEso> ls: cannot access '/tmp/bin': No such file or directory
23:59:45 <ais523> `echo /hackenv/bin/as-*
23:59:46 <HackEso> /hackenv/bin:/usr/bin:/bin
23:59:50 <ais523> `echo /hackenv/bin/*-as