L increments cell  L' decrements cell  R goes to the ne
< 1764248775 532462 :tromp!~textual@2001:1c00:3487:1b00:9176:7929:ae5a:d4f6 JOIN #esolangs * :Textual User
> 1764249022 833231 PRIVMSG #esolangs :14[[07Brainsteg14]]4 N10 02https://esolangs.org/w/index.php?oldid=169400 5* 03JIT 5* (+1365) 10Created page with "Brainsteg is an esolang by [[User:JIT]], 2025  ''"What if [[StegFuck]] was a bit better in [[Steganography]]?"''  : -[[User:JIT]], 2025  it does it on all last channels on the least significant bit {| class="wikitable" |+ yaaaay |- ! action !! what it does |- | same bit a
> 1764249068 210049 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=169401&oldid=169394 5* 03JIT 5* (+16) 10
< 1764249279 899569 :chomwitt!~alex@2a02:85f:9a5f:900:42b0:76ff:fe46:a5fd QUIT :Read error: Connection reset by peer
< 1764249299 279339 :chomwitt!~alex@2a02:85f:9a5f:900:42b0:76ff:fe46:a5fd JOIN #esolangs chomwitt :realname
< 1764249813 893578 :chomwitt_alt!~alex@2a02:85f:9a5f:900:42b0:76ff:fe46:a5fd JOIN #esolangs chomwitt :realname
< 1764249864 271599 :chomwitt!~alex@2a02:85f:9a5f:900:42b0:76ff:fe46:a5fd QUIT :Ping timeout: 252 seconds
< 1764250249 267890 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord
> 1764251001 821755 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=169402&oldid=169401 5* 03Yayimhere2(school) 5* (+12) 10/* F */
> 1764251292 240703 PRIVMSG #esolangs :14[[07Fluid14]]4 10 02https://esolangs.org/w/index.php?diff=169403&oldid=169377 5* 03Yayimhere2(school) 5* (+895) 10/* A non BIX definition */
> 1764251412 636047 PRIVMSG #esolangs :14[[07Fluid14]]4 10 02https://esolangs.org/w/index.php?diff=169404&oldid=169403 5* 03Yayimhere2(school) 5* (-465) 10/* A non BIX definition */
> 1764251478 530812 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=169405&oldid=169402 5* 03CraftyBLUE 5* (+12) 10added Nand1
> 1764252343 450527 PRIVMSG #esolangs :14[[07Brainsteg14]]4 M10 02https://esolangs.org/w/index.php?diff=169406&oldid=169400 5* 03JIT 5* (+1) 10oops
> 1764252420 413596 PRIVMSG #esolangs :14[[07DerpScrp14]]4 M10 02https://esolangs.org/w/index.php?diff=169407&oldid=166213 5* 03Kaveh Yousefi 5* (+0) 10Meliorated an instance of cacography by exchanging extention for the correct extension.
> 1764252889 162867 PRIVMSG #esolangs :14[[07Fluid14]]4 10 02https://esolangs.org/w/index.php?diff=169408&oldid=169404 5* 03Yayimhere2(school) 5* (+71) 10/* Implementations */
< 1764253011 99558 :Yayimhere!~Yayimhere@197.185.151.129 JOIN #esolangs * :[https://web.libera.chat] Yayimhere
< 1764253019 415801 :Yayimhere!~Yayimhere@197.185.151.129 PRIVMSG #esolangs :hello!
> 1764253278 720818 PRIVMSG #esolangs :14[[07Brainfucker14]]4 10 02https://esolangs.org/w/index.php?diff=169409&oldid=135241 5* 03JIT 5* (+9) 10
> 1764253524 554719 PRIVMSG #esolangs :14[[07Selfermodif14]]4 10 02https://esolangs.org/w/index.php?diff=169410&oldid=130441 5* 03JIT 5* (+23) 10
> 1764253545 537389 PRIVMSG #esolangs :14[[07ByteByteIfJump14]]4 10 02https://esolangs.org/w/index.php?diff=169411&oldid=168963 5* 03Timm 5* (+40) 10
> 1764253659 644704 PRIVMSG #esolangs :14[[07ByteByteIfJump14]]4 10 02https://esolangs.org/w/index.php?diff=169412&oldid=169411 5* 03Timm 5* (+50) 10
> 1764253862 107693 PRIVMSG #esolangs :14[[07Cat do end14]]4 N10 02https://esolangs.org/w/index.php?oldid=169413 5* 03Timm 5* (+829) 10Created page with " CatDo: name of cat  start the cat all code executes in cats   :End  stop the cat can new run ex:   CatDo: fur  :End  CatDo: fur  :End  same cat same remember   meu|text|  prints text   cat = 42  cat remember 42   c.name  get memory from other cats   c.name = 42  cat nam
> 1764253874 614179 PRIVMSG #esolangs :14[[07ByteByteIfJump14]]4 M10 02https://esolangs.org/w/index.php?diff=169414&oldid=169412 5* 03JIT 5* (-21) 10fixed
> 1764253915 13147 PRIVMSG #esolangs :14[[07User:Timm14]]4 10 02https://esolangs.org/w/index.php?diff=169415&oldid=168973 5* 03Timm 5* (+26) 10
> 1764253985 607754 PRIVMSG #esolangs :14[[07Selfermodif14]]4 10 02https://esolangs.org/w/index.php?diff=169416&oldid=169410 5* 03Yayimhere2(school) 5* (+9) 10add stub
> 1764254007 878952 PRIVMSG #esolangs :14[[07Cat do end14]]4 10 02https://esolangs.org/w/index.php?diff=169417&oldid=169413 5* 03Timm 5* (-5) 10
> 1764254078 52439 PRIVMSG #esolangs :14[[07Nand114]]4 10 02https://esolangs.org/w/index.php?diff=169418&oldid=169368 5* 03CraftyBLUE 5* (-1) 10fixed critical typo: "Input byte" was spelled as "Output byte"
> 1764254243 243874 PRIVMSG #esolangs :14[[07NoQuinebrainfuck14]]4 10 02https://esolangs.org/w/index.php?diff=169419&oldid=164010 5* 03JIT 5* (+13) 10
< 1764255493 99711 :Yayimhere!~Yayimhere@197.185.151.129 QUIT :Ping timeout: 250 seconds
< 1764256377 99817 :Yayimhere!~Yayimhere@197.185.151.129 JOIN #esolangs * :[https://web.libera.chat] Yayimhere
< 1764256767 548230 :tromp!~textual@2001:1c00:3487:1b00:9176:7929:ae5a:d4f6 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1764258004 407475 :Yayimhere!~Yayimhere@197.185.151.129 QUIT :Quit: Client closed
< 1764258456 896750 :tromp!~textual@2001:1c00:3487:1b00:9176:7929:ae5a:d4f6 JOIN #esolangs * :Textual User
> 1764258529 32843 PRIVMSG #esolangs :14[[07Dipsh!t14]]4 10 02https://esolangs.org/w/index.php?diff=169420&oldid=169275 5* 03HeckYeah100 5* (+57) 10
> 1764258586 45138 PRIVMSG #esolangs :14[[07Non14]]4 M10 02https://esolangs.org/w/index.php?diff=169421&oldid=169252 5* 03HeckYeah100 5* (+26) 10
> 1764258600 158133 PRIVMSG #esolangs :14[[07Non14]]4 10 02https://esolangs.org/w/index.php?diff=169422&oldid=169421 5* 03HeckYeah100 5* (+1) 10
> 1764258646 749146 PRIVMSG #esolangs :14[[07Non14]]4 10 02https://esolangs.org/w/index.php?diff=169423&oldid=169422 5* 03HeckYeah100 5* (-3386) 10
> 1764258811 158583 PRIVMSG #esolangs :14[[07Non14]]4 M10 02https://esolangs.org/w/index.php?diff=169424&oldid=169423 5* 03HeckYeah100 5* (+104) 10
> 1764261631 709457 PRIVMSG #esolangs :14[[07Main Page14]]4 10 02https://esolangs.org/w/index.php?diff=169425&oldid=168605 5* 03Jay 5* (+5) 10
> 1764261648 595630 PRIVMSG #esolangs :14[[07Main Page14]]4 10 02https://esolangs.org/w/index.php?diff=169426&oldid=169425 5* 03Jay 5* (-5) 10
> 1764262640 457628 PRIVMSG #esolangs :14[[07Main Page14]]4 10 02https://esolangs.org/w/index.php?diff=169427&oldid=169426 5* 03Corbin 5* (-156) 10Clean up some lingering vandalism.
< 1764262870 445547 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
> 1764264208 236394 PRIVMSG #esolangs :14[[07Talk:FlipJump14]]4 N10 02https://esolangs.org/w/index.php?oldid=169428 5* 03Yayimhere2(school) 5* (+214) 10Created page with "It cant do *every* computation, since its a bounded memory machine, so its not turing complete. --~~~~"
< 1764264563 287155 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I see that Yay has discovered the classic question, "Is C Turing-complete?"
< 1764264608 120439 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I believe the answer is "yes because the standard doesn't inherently place limits on the length of a file"
< 1764264660 258121 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: I think so. Or yes via unbounded stack, perhaps.
< 1764264696 133803 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so the problem when using unbounded stack to try to prove C TC is that the only way to refer to deeper stack frames is by pointer
< 1764264731 60803 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and It's not immediately obvious that C doesn't limit how many different pointers can exist simultaneously in a program
< 1764264764 639010 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think, because intptr_t is optional, it may be strictly conforming to have a C implementation that does in fact allow infinitely many different pointers
< 1764264844 580379 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Rust has slightly more guarantees, which leads to fun bugs like this: https://github.com/rust-lang/rust/issues/130388
< 1764264933 239935 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :that leads to the other classic question, "does C guarantee Liskov substitutability for numerically equal pointers"; CHERI says no
< 1764264953 160452 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(tl;dr: you can convert a pointer's address to an integer, then compare it to every possible integer, and get a mismatch on all the comparisons)
< 1764264989 760552 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: I think the consensus at this point is no – the standard doesn't require it and the C standards body has mostly been convinced to use an address-exposure provenance model
< 1764265035 50774 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :intptr_t is optional but in a non-provenance world you can memcpy pointers, with memcpy being defined as operating on unsigned char[n[
< 1764265035 819465 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the situation with some C compilers is more complex, LLVM doesn't even guarantee substitution of numerically equal *integers* in some cases where they were derived from pointer addresses
< 1764265065 453289 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which at least the Rust people consider a bug
< 1764265072 173666 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* substitutability
< 1764265141 539457 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fwiw, I think there's an increasing consensus along the lines of "whatever memcpy does to copy arbitrary memory around, it isn't using pure integers, and the "unsigned char" that's capable of aliasing any type therefore isn't a pure integer type"
< 1764265163 860164 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :C++ and Rust have both added types to represent a memory byte that has possible provenance (std::byte and MaybeUninit respectively)
< 1764265202 649827 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: We can also refer to older stack using recurrence. I don't think we have to be fancy about it; it's enough to show that it's undecidable whether a C program halts, and a program can always spend infinite time recursing.
< 1764265225 568235 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: how does that get you Turing-completeness rather than just a PDA?
< 1764265230 305025 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :Does this mean that memcpy/memmove necessarily has semantics beyond a loop copying std::bytes one at a time?
< 1764265245 238783 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: I assert that we can emulate any Turing machine in C. Hopefully that's not a tough sell.
> 1764265266 669036 PRIVMSG #esolangs :14[[07Needle14]]4 10 02https://esolangs.org/w/index.php?diff=169429&oldid=163625 5* 03ChuckEsoteric08 5* (+184) 10/* Computational class */  Added translation for halting
< 1764265289 659980 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :OK, so Rust's view of this (which I disagree with) is that the provenance of a pointer is somehow attached to the individual bytes of it, if you use the same bytes in the same order (and copy them with only provenance-aware operations) you will get the same pointer back with the same provenance, if you rearrange the bytes or combine bytes from different pointers you have no useful provenance
< 1764265307 612877 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(that was a reply to sorear)
< 1764265309 510747 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :personally I don't feel the need to distinguish between Turing-complete and EXPSPACE-complete for practical purposes
< 1764265338 507701 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Or, more aggressively, I assert that we can encode a Diophantine search using structural recursion only. I think that folks get caught up on the idea that an infinite TM tape has to correspond to some specific C data structure in memory.
< 1764265390 180597 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: doesn't that require an unlimitedly large "heap" (specifically, "area from which the memory allocation functions allocate", doesn't have to be an actual heap) to exist?
< 1764265408 201210 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :otherwise you can't create the structures to recurse over
< 1764265425 676205 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :structures or arbitrarily large integers?
< 1764265435 865937 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: I don't think so? It only needs an infinitely large stack. We can exit() when we find a solution, and we can encode any particular Diophantine search's finite row of variables as finitely many arguments to each procedure call.
< 1764265452 428019 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: I'm not sure there's any distinction in C, because it lets you run sizeof on anything including integer types
< 1764265469 799376 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Like, I'm not imagining something which runs successfully on Linux.
< 1764265481 698931 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: but I can implement this on a push-down automaton, so it can't be TC
< 1764265519 350471 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :MRDP-type equations have _very_ large solutions...
< 1764265550 427185 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :...at which point we need someplace to store them, and so the heap is relevant. Okay, I see.
< 1764265550 900056 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :unless you allow either a) the variables to be arbitrarily large, or b) the variables to be pointers that provide access to potentially arbitrarily large structures
> 1764265601 71460 PRIVMSG #esolangs :14[[07Formin14]]4 10 02https://esolangs.org/w/index.php?diff=169430&oldid=167669 5* 03Yayimhere2(school) 5* (-85) 10/* External links */ delete/replace non existent categories
> 1764265612 396468 PRIVMSG #esolangs :14[[07Formin14]]4 10 02https://esolangs.org/w/index.php?diff=169431&oldid=169430 5* 03Yayimhere2(school) 5* (-66) 10/* External links */
< 1764265638 818039 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu JOIN #esolangs b_jonas :b_jonas
< 1764265661 700297 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fwiw I am increasingly thinking that the "bytes have provenance" model is wrong for programming in general (it is of course correct for CHERI) – I do think that provenance *exists* and is important, but am not convinced that it attaches to individual bytes of memory
< 1764265678 100313 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or, well, it's correct for CHERI only if you copy a word at a time rather than a byte at a time
< 1764265760 406897 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Provenance is a social construction. We have to choose to attach it to each bytestring.
< 1764265828 235935 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The reason that we're pressured to say that it physically exists is because lawyers think that it physically exists. There's a great Moglen essay about this: https://moglen.law.columbia.edu/publications/anarchism.html
> 1764265870 19931 PRIVMSG #esolangs :14[[07Intermediate language14]]4 10 02https://esolangs.org/w/index.php?diff=169432&oldid=169381 5* 03ChuckEsoteric08 5* (+179) 10/* Some examples in alphabetical order */
< 1764265886 720431 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I'm actually increasingly coming to think that (from the programming, not social, point of view) there are actually two or three different forms of provenance that attach to individual pointers
< 1764265930 529603 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which allocation/object the target belongs to, what accesses are allowed through the pointer, and what the aliasing rules of the pointer are
< 1764265950 251753 :joast!~joast@2603:90d8:500:31cf:5e0f:3f4b:1cfe:5060 QUIT :Quit: Leaving.
< 1764265994 159472 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the second and third might be the same, that's why I'm not sure whether there are two or three)
< 1764266042 359364 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the first is qualitatively different in that if two pointers mismatch on that provenance, they are conceptually unequal even if they have the same address, pointers that mismatch on the other forms of provenance are conceptually pointing to the same thing but not interchangeable
< 1764266063 50807 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Aliasing is definitely its own thing. In cap theory, we traditionally say that caps are copyable; you can alias a pointer as much as you like. But some caps, like physical tokens, are *not* copyable; shouldn't our theory have something to say about that? We usually trivialize it: if you've issued k different caps, you get to spend O(k) time tracking them precisely.
< 1764266067 873261 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* pointers that mismatch only on the other forms of provenance
< 1764266137 787674 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Right. This occurs e.g. in instruction selection; if we have two nodes which share a subnode, but it's actually going to be cheaper to duplicate the subnode and inline it into each parent, then we want the subnodes to be "conceptually unequal" so that they get emitted twice.
< 1764266143 768179 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: so at least this is fairly easy for me to think about because of the pirated-reference thing, my mental model now is "just start with a model where nothing is copyable/sharable and then add pirating", with the only question being about just which operations work on pirated references and which operations need the original
< 1764266175 952384 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :what if the problem is that "equality of two pointers" cannot be treated with classical logic
< 1764266181 188874 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It also occurs in E-style network-transparent references. Two refs are only equal if we've *proven* that they're equal, which is expensive enough that the user has to explicitly E.join() refs instead of asking for equality.
< 1764266215 660292 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: well, "equality" on its own is insufficiently well defined, I think you have to talk about what notion of equality you want
< 1764266257 319731 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a lot of miscompiles in Rust are caused by the compiler confusing the various different notions of pointer equality with each other
< 1764266264 573868 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Oh, that's a fun tangent. Usually we want a cap to be genuinely delegated; if I give you a cryptographic signature then you should be able to take it offline and sign stuff without my knowledge or presence. But if the cap can be revoked then usually that means that you somehow have to signal me before invoking the cap, to double-check that you didn't get revoked already.
< 1764266304 943764 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The bookkeeping of checking for a revokable cap sounds similar to the bookkeeping for pirated references, although I think that you hope to do it at compile time?
< 1764266314 438800 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: right, this is why pirating has a lifetime – Rust enforces lifetimes with a compile-time check, but that doesn't conceptually be a requirement
< 1764266346 360325 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think of lifetimes conceptually as "the thing that lended can revoke this" and Rust's borrow checker is basically ensuring statically that the program doesn't attempt to use anything after it's been revoked
< 1764266357 801089 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but that check doesn't conceptually have to be static, it just happens to be static in Rust
< 1764266395 940667 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :actually, in *unsafe* Rust it is defined as a dynamic check (that causes undefined behaviour if it fails)
< 1764266417 586 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the exact definition hasn't been nailed down yet but all the proposed deginitions agree on that
< 1764266436 614575 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah, in E it's fully late-bound; a revokable cap includes a non-revokable ref back to the original issuer, and the issuer's local machine has a Boolean flag encapsulated by its own object. Can't decide if it's perfectly sensible or utterly mad.
< 1764266513 818379 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Something like: to run() { return when (def ok := callHomeAndCheck<-()) -> { if (ok) { actuallyRun() } else { throw("sorry, we've been revoked") } } }
< 1764266535 893905 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess this sort of logic leaves me concerned about race conditions
> 1764266556 169915 PRIVMSG #esolangs :14[[07Formin14]]4 10 02https://esolangs.org/w/index.php?diff=169433&oldid=169431 5* 03 5* (+29) 10This seems AI
< 1764266557 719965 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there might be some separate way to prevent them being a problem
< 1764266598 159673 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Sure. More seriously, this is what we'd actually do: to run(x) { return try { callHomeAndCheck<-(x)<-actuallyRun() } catch _ { throw("sorry") } }
< 1764266653 609900 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Promise pipelining tends to have the correct ordering of events. There's a deep thermodynamic reason for that, but also the obvious surface reason: you can't act on objects whose refs you don't have yet.
< 1764266670 938723 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :I suspect that Rust lifetimes can be interpreted in a fully linear manner where references aren't so much revoked as passed back up and consumed
< 1764266688 399764 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: this conversation has become very close to what I'm planning for my next blog post
< 1764266722 339718 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the "revoke a lifetime versus consume a reference" distinction is something I've been thinking about a whole lot (especially because I'm pretty sure Rust's current design gets it wrong)
< 1764266742 50703 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I imagine, just from physics intution, that Rust lifetimes are naturally partially ordered? I don't know Rust well enough to know whether lifetimes can be cyclic, or if that even makes sense.
< 1764266775 539528 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :lifetimes have an "outlives" relationship which is the inverse of "contained-in", if you have a cycle in that relationship it proves the lifetimes are equal
< 1764266836 711751 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh. That's so clean! I continue to not understand Rust haters.
< 1764267019 565466 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess this is actually a mathematical relation, not just an informal relationship
< 1764268036 566963 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :"LLVM doesn't even guarantee substitution of numerically equal *integers* in some cases where they were derived from pointer addresses" => you aren't just referring to the thing where the language sometimes allows you to write an expression that counts as constant expression by language standard but its value isn't actually known at compile time because the address is decided at link time or even 
< 1764268042 573885 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :dynamic link time, right? 
< 1764268050 794204 :msv!~msv@user/msv JOIN #esolangs msv :msv
< 1764268354 148682 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :"yes because the standard doesn't inherently place limits on the length of a file" => so how relevant are files here? is it less cheating if you use standard functions like fopen, fwrite, fread, rewind to access a tape drive with unlimited tape length, because you happen to know that open("/dev/tapedrive1", "r+") behaves that way on the implementation, than if you just call a bunch of custom library 
< 1764268360 155882 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :functions on the implementation that directly let you access unbounded amount of memory?
< 1764268499 685983 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: no, was referring to outright bugs in which pointers-converted-to-integers are sometimes optimised by LLVM as though they were the original pointers, then compared lie pointers
< 1764268501 505891 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* like pointers
< 1764268520 391123 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :rather than being compared like integers (which they should be, given that they actually are integers)
< 1764268559 486571 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :re: files, I was more talking about how a theoretical implementation running with unbounded memory would be allowed to provide that memory to the program without violating the standard
< 1764268565 142873 :int-e!~noone@int-e.eu PRIVMSG #esolangs :hmm is there a deep reason why Debian dropped https://packages.debian.org/bookworm/libpcre3 from trixie, or is it just "it's old"
< 1764268602 766322 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but yes, you could do it with implementation-specific builtins instead, just give them a name that starts with two underscores
< 1764268636 9128 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: yes, but the standard also allows the implementation to just provide extra functions in its library. there are some limits on the names and header files but they're not really limiting us.
< 1764268646 17901 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :yes, what you said
> 1764268662 229537 PRIVMSG #esolangs :14[[07Gstvnts14]]4 N10 02https://esolangs.org/w/index.php?oldid=169434 5* 03 5* (+592) 10Created page with "'''Gstvnts''' is an [[OISC]] created by [[User:]]. Here's how it works:  a b c d  command. if (*a > *b+*c) {a=b-c; goto command;} else {a=b+c; goto *d;} Where a is the variable to write to, b and c are the variables/numbers to write data to a, and d is the jump destination. ==T
< 1764268730 408485 :strerror!~strerror@user/strerror PRIVMSG #esolangs :int-e: perhaps because no packages in trixie depend on it
< 1764268740 699321 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :and it can even be compiler extensions, not just functions, like what you get in a DOS compiler if normal pointers are near pointers but you can access objects outside of one segment, or if normal pointers are far/huge pointers that point into the real mode address space but you can access extended memory
< 1764268792 480579 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :of course those don't give you infinite memory, and you can even run into very real limits, like how most DOS programs won't be able to use more than 64 M of memory even if you emulate them on a modern system that has tons of RAM
< 1764268801 41631 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :64 megabytes
< 1764268819 778868 :tromp!~textual@2001:1c00:3487:1b00:9176:7929:ae5a:d4f6 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1764268851 672792 :strerror!~strerror@user/strerror PRIVMSG #esolangs :BF is TC, so you could just add inline BF as an extension
> 1764268866 445379 PRIVMSG #esolangs :14[[07OISC14]]4 10 02https://esolangs.org/w/index.php?diff=169435&oldid=169393 5* 03 5* (+125) 10/* List of OISCs */
< 1764268986 617253 :strerror!~strerror@user/strerror PRIVMSG #esolangs :int-e: it looks like Debian recommends upgrading to the newer version, naturally named libpcre2
< 1764269045 487469 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Yeah. This may not be as bad as I thought.
< 1764269268 103386 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh, libpcre3 is ABI version 3 of PCRE v1, and libpcre2 is PCRE v2. So not an SDL situation.
> 1764269268 247258 PRIVMSG #esolangs :14[[07Gstvnts14]]4 10 02https://esolangs.org/w/index.php?diff=169436&oldid=169434 5* 03 5* (-40) 10/* Infinite loop */
< 1764269280 171327 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523 re "which allocation/object the target belongs to" => incidentally, does this mean that if you want to implement a memory allocator similar to malloc/free in C or C++, and want to allow the compiler to optimize using the rule that you can't access one allocation from another using pointer arithmetic, you need a non-standard compiler feature like a gcc attribute? 
< 1764269312 659852 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I think so – actually I've been complaining about a similar situation in Rust over the last few days
< 1764269338 238855 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I see
< 1764269349 296143 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: Yes. Or, if we think of e.g. file descriptors as caps, then it matters which UID/GID the cap was allocated under, which Linux admin cap flags it has set, etc.
< 1764269391 683335 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :korvo: I don't get the context, is that for me?
< 1764269411 826484 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this also affects "retrofit memory-safety onto C" implementations that don't implement automatic narrowing of capability scopes (and in a different way affects implementations that do, in that it will end up breaking many "manually implemented memory allocators" if they try to access their own metadata through the pointer that's being deallocated)
< 1764269428 482547 :int-e!~noone@int-e.eu PRIVMSG #esolangs :strerror: fine, they win: https://github.com/lambdabot/lambdabot/blob/libera/patches/misfortune-0.1.2.1.patch -- could be worse
< 1764269436 237872 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Linux UIDs are "virtual" in a very specific sense: they pretend that there's a gap between different users, but everybody's actually colocated, so a central controller can manage all of the different relationships and revokation isn't actually a remote action. There's a parallel with e.g. k8s having "virtual" clusters with Namespaces.
< 1764269443 902597 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I don't think file descriptors carry that kind of information. files do, but file descriptors have much fewer bits.
< 1764269466 267502 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(fortunately somebody already created the bindings)
< 1764269568 819756 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: They definitely have some context which acts as a provenance. It's ambient whether an integer happens to represent a valid descriptor, just like whether it's a valid pointer. But when it does, there's a kernel struct that has some of that information.
< 1764269639 644818 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I'm just explaining why provenance matters locally; it's how we emulate the unknowability of remote resources and create a uniform security model from the gaps between those resources.
< 1764269658 680343 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :...Sorry, that sounds like salad. I should go do something else.
< 1764269717 468684 :tromp!~textual@2001:1c00:3487:1b00:9176:7929:ae5a:d4f6 JOIN #esolangs * :Textual User
< 1764269795 449982 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :korvo: I mean the file descriptors don't carry anything like an UID/GID specifically. the UID/GID and similar of the process is checked to the UID/GID and permissions when you create the file descriptor, and after that all the file descriptor just carries one of the open modes that tell what you can do with that descriptor like O_RDONLY, O_WRONLY, O_RDWR (there are a bunch of more exotic ones), plus a 
< 1764269801 458985 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :few weird magic permission bits like whether it's append-only, whether it's your controlling terminal, etc.
< 1764269976 640480 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :and you can retreive most of that info with system calls like fcntl, getsockopt. the only hard part is finding out which two descriptors refer to the same file description, which is hard to do without cooperation of the file descriptor's users.
< 1764270128 793592 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: You're right. For some reason, I had thought that Linux's file_struct had UID and GID attached, set when the descriptor was created.
< 1764270165 222244 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :io_uring lets you write a file descriptor that's tied to a specific io_uring instance
< 1764270174 237500 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :With the appropriate CONFIG, Linux *does* have fown_struct attached to each descriptor, which has a UID and EUID, but that's apparently for specific security modules: https://docs.huihoo.com/doxygen/linux/kernel/3.7/structfown__struct.html
< 1764270178 39253 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but that isn't intended for security, but rather for performance because it means that less locking is needed
< 1764270277 921411 :ais523!~ais523@user/ais523 QUIT :Quit: quit
< 1764270305 231312 :amby!~ambylastn@host-81-178-154-63.as13285.net JOIN #esolangs amby :realname
< 1764271208 667254 :tromp!~textual@2001:1c00:3487:1b00:9176:7929:ae5a:d4f6 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
> 1764271430 157667 PRIVMSG #esolangs :14[[078ial14]]4 M10 02https://esolangs.org/w/index.php?diff=169437&oldid=169376 5* 03Ractangle 5* (+1291) 10
> 1764271602 65851 PRIVMSG #esolangs :14[[078ial14]]4 M10 02https://esolangs.org/w/index.php?diff=169438&oldid=169437 5* 03Ractangle 5* (+23) 10/* Simulating a Minsky machine */
< 1764271735 234958 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 240 seconds
< 1764271736 874292 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord
< 1764271903 640583 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 NICK :Lord_of_Life
< 1764271904 374758 :int-e!~noone@int-e.eu PRIVMSG #esolangs :LOL what an idiotic failure: Install dictd, then install 5 dictionaries at once... and run into an error because systemd thinks that the service is restarting too frequently?!
> 1764272058 814580 PRIVMSG #esolangs :14[[078ial14]]4 M10 02https://esolangs.org/w/index.php?diff=169439&oldid=169438 5* 03Ractangle 5* (-7) 10/* Simulating a Minsky machine */
> 1764272153 809075 PRIVMSG #esolangs :14[[078ial14]]4 M10 02https://esolangs.org/w/index.php?diff=169440&oldid=169439 5* 03Ractangle 5* (-694) 10/* Computational Class */
> 1764272340 705952 PRIVMSG #esolangs :14[[078ial14]]4 M10 02https://esolangs.org/w/index.php?diff=169441&oldid=169440 5* 03Ractangle 5* (+19) 10/* Computational Class */
< 1764272352 265811 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Oh it was 6, not 5: https://paste.debian.net/1410888/
< 1764272653 585274 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :On libpcre and its package names, I just recently saw something particularly ridonkulous in Debian package names, let's see if I could recall what it was.
< 1764272763 641260 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :Oh yes, it was libzmq. The runtime library package is named `libzmq5`, the *corresponding* development package for it is named `libzmq3-dev`, and the actual (upstream) version of the library is 4.3.5.
< 1764272789 81172 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :I'm sure there's a rational process that led to this situation, which I didn't bother to look up.
< 1764272876 40567 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :(Oh, and the source package that generates those two binary packages is named `zeromq3`, which at least matches one of them.)
> 1764272876 457721 PRIVMSG #esolangs :14[[078ial14]]4 M10 02https://esolangs.org/w/index.php?diff=169442&oldid=169441 5* 03Ractangle 5* (+106) 10/* Computational Class */
< 1764274112 203537 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname
< 1764274534 908810 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :we've been on libc6 version 2.x for (looks at changelog) 26 years
< 1764276637 18945 :APic!apic@apic.name PRIVMSG #esolangs :G'Night
< 1764278159 463340 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :If a Magic: the Gathering card says "Sacrifice target permanent: You gain 3 life." then how would you expect it to work? I would expect that the target is no longer valid when it is time to resolve (unless something changes the target), so you would not gain 3 life. Although a permanent you do not control is a valid target, you would not be able to pay the cost in that case.
< 1764279689 204414 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1764279970 234716 :recook!~recook@93.red-83-42-60.dynamicip.rima-tde.net JOIN #esolangs * :recook
< 1764279994 953901 :recook!~recook@93.red-83-42-60.dynamicip.rima-tde.net PART :#esolangs
> 1764280148 366699 PRIVMSG #esolangs :14[[078ial14]]4 M10 02https://esolangs.org/w/index.php?diff=169443&oldid=169442 5* 03Ractangle 5* (+2) 10minor fix
< 1764280160 174765 :tromp!~textual@2001:1c00:3487:1b00:9176:7929:ae5a:d4f6 JOIN #esolangs * :Textual User
> 1764281101 731240 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=169444&oldid=169352 5* 03NTMDev 5* (+154) 10/* List Utilities */
< 1764281139 616033 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :zzo38: my guess is that the Magic templating team intentionally don't word costs like that, so that the question never comes up
< 1764281158 676124 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's like a legalistically-written document version of undefined behaviour
< 1764281205 187606 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :and when they write confusing wording then they usually add reminder text or a judgement into the set FAQ
> 1764281238 129345 PRIVMSG #esolangs :14[[078ial14]]4 M10 02https://esolangs.org/w/index.php?diff=169445&oldid=169443 5* 03Ractangle 5* (-8) 10I just realised that it's the OUT command prints the registry and not the tos
< 1764281239 945494 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :or if a wording becomes confusing because of later rule changes then they errata the text or errata in reminder text
> 1764281241 764936 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=169446&oldid=169444 5* 03NTMDev 5* (+192) 10/* Sort */
< 1764281477 185304 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :besides the problem with the target being valid, I think they would also never write "sacrifice target permanent" in an effect (rather than a cost), they'd either write "sacrifice target permanent you control", or write "target permanent's controller sacrifices it"
< 1764281492 155215 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :so there's like double the confusion
< 1764281674 740784 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: they recently changed the template for edicts to "target opponent sacrifices a creature they control of their choice"
< 1764281682 204930 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which I think supports your theory
< 1764281818 899699 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I know Wizards of the Coast does not write things like I mentioned (they do not put targets in costs, probably because of the confusion), but I was trying to see what it would be if it was like I wrote.
< 1764282122 904501 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I always find it interesting when people interact with esolangs in a way other than what the author intended
< 1764282151 476885 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :just treating Magic as an esolang in the first place is that kind of interaction, I think – but trying to combine the rules in ways they were never intended to be combined is another
< 1764282211 826031 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I remember when Keymaker wrote a quine in Acyclic Tag, and writing quines is basically unrelated to the idea behind / purpose of the language, so I was surprised
< 1764282227 89078 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(especially given the nature of tag systems, which you wouldn't really expect to be a good choice for writing quines in)
< 1764282251 605141 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: funnily there's a difference here. Wizards doesn't write rules text that would often make you sacrifice a permanent that someone else controls, like "sacrifice target permanent", but they do write text that would instruct you to do that in rare cases, like when the controller of the permanent changes the permanent in response to a trigger. the rules say that the sacrifice just doesn't happen in 
< 1764282257 610049 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :that case. meanwhile,
< 1764282355 366231 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Yu-Gi-Oh! has a couple of cards that explicitly use the opponent's monstesr to pay costs that you can normally pay only with your own monsters, e.g. https://yugipedia.com/wiki/Soul_Exchange and https://yugipedia.com/wiki/Underworld_Goddess_of_the_Closed_World
< 1764282359 565789 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* monsters
< 1764282434 416507 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :unlike in Magic, tributing an opponent's monster or using it as material works if a card explicitly instructs you to do that
< 1764282465 695337 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :Wizrds doesn't write rules text that would often make you put an object into a hand or library or graveyard of a player other than the object's owner, but they can write rules text that would rarely result in that. but I think when the rules instruct you to do that, the object moves into its owner's hand or library or graveyard instead.
< 1764282515 639962 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yu-gi-oh also has a rule like that but rules text is written to trigger it stupidly often
< 1764282547 338022 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like, cards say the equivalent of "return that card to its owner's hand" when 99% of the time it'll be used to put a card back into the extra deck (because it's a sort of card that can't exist in a hand)
< 1764282599 6475 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oddly, yu-gi-oh rules do allow a card to exist in its owner's opponent's hand (although mostly not in any of the other hidden zones belonging to the opponent, apart from that one card that gets shuffled into the opponent's deck face up which is generally considered a mistake)
< 1764282645 495823 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I spent a couple of years learning yugioh in an attempt to prove it TC
< 1764282657 915022 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :hehe
< 1764282689 145909 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I currently think that it probably is, but don't have a stable proof, and it needs more assumptions than Magic does (in Magic you can prove TCness with player choices being irrelevant, in Yugioh I think you need the "players do not make choices that would obviously lose them the game" that I used for Netrunner)
< 1764282699 808395 :strerror!~strerror@user/strerror PRIVMSG #esolangs :sorear: and TeX 3.14159 for three decades now
> 1764283104 786859 PRIVMSG #esolangs :14[[07User:Buckets14]]4 M10 02https://esolangs.org/w/index.php?diff=169447&oldid=169347 5* 03Buckets 5* (+17) 10
> 1764283135 160727 PRIVMSG #esolangs :14[[07Language list14]]4 M10 02https://esolangs.org/w/index.php?diff=169448&oldid=169405 5* 03Buckets 5* (+18) 10
> 1764283142 964040 PRIVMSG #esolangs :14[[07Knock knock14]]4 N10 02https://esolangs.org/w/index.php?oldid=169449 5* 03Buckets 5* (+1175) 10Created page with "Knock knock Is An Esoteric programming Language created By [[User:Buckets]] in 2020. {| class="wikitable" |- ! Commands !! Instructions |- | Knock! || Go left If the Command to The right is knock!, Else go downwards. |- | Knock || Go downwards Once. |- | knock || Go
> 1764283174 197647 PRIVMSG #esolangs :14[[07Knock knock14]]4 M10 02https://esolangs.org/w/index.php?diff=169450&oldid=169449 5* 03Buckets 5* (-2) 10
< 1764283374 300851 :int-e!~noone@int-e.eu PRIVMSG #esolangs :@check 1 == 0
< 1764283375 733874 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esolangs : *** Failed! Falsifiable (after 1 test):
< 1764283381 905256 :int-e!~noone@int-e.eu PRIVMSG #esolangs :@check 1 == 1
< 1764283384 6408 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esolangs : +++ OK, passed 100 tests.
< 1764283431 48561 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, so quickcheck doesn't stop early if it's tried every possibility?
< 1764283690 523366 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :100 tests for such a simple statement counts as stopping early
> 1764284117 576834 PRIVMSG #esolangs :14[[07Nand114]]4 10 02https://esolangs.org/w/index.php?diff=169451&oldid=169418 5* 03CraftyBLUE 5* (-53) 10unset computation class, because I (the creator of the language) don't know it
< 1764284207 280227 :strerror!~strerror@user/strerror PRIVMSG #esolangs :@check \x -> x || not x
< 1764284209 82037 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esolangs : +++ OK, passed 100 tests.
< 1764284272 763923 :int-e!~noone@int-e.eu PRIVMSG #esolangs :@check \a b c d e -> even (a * b * c * d * e)
< 1764284274 306887 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esolangs : *** Failed! Falsifiable (after 8 tests and 5 shrinks):
< 1764284274 306930 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esolangs : -1 -5 -7 -3 3
< 1764284326 826051 :joast!~joast@2603:90d8:500:31cf:5e0f:3f4b:1cfe:5060 JOIN #esolangs joast :joast
< 1764284561 307985 :strerror!~strerror@user/strerror PRIVMSG #esolangs :Actually quickcheck might be sampling with replacement, so 100 cases might not be enough to cover n < 100 values
< 1764284606 759625 :int-e!~noone@int-e.eu PRIVMSG #esolangs :without replacement you wouldn't be able to get 100 tests for 1 == 1
< 1764284638 555455 :int-e!~noone@int-e.eu PRIVMSG #esolangs :so yes, that command should fail to find a counterexample from time to time
< 1764284873 159280 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :@check \a -> a != 123456789
< 1764284874 751003 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esolangs : error:
< 1764284874 830002 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esolangs : • Variable not in scope: (!=) :: t0 -> t2 -> t1 • Perhaps you meant one of t...
< 1764284883 845396 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :@check \a -> not (a == 123456789)
< 1764284886 346283 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esolangs : +++ OK, passed 100 tests.
< 1764284889 688332 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: it's /=
< 1764284904 828863 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: I thought I would just have had the name wrong
< 1764284938 398478 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I can see how adding `not` is the path of least resistance :)
< 1764285023 346876 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :recently I was working on an algorithm which had a codepath that was only used 1 in 2³² of the time
< 1764285077 836172 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which was especially interesting because it was effectively operating on random numbers (not quite random but there were highly arbitrary constants involved which would affect when the codepath was taken)
< 1764285342 415632 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :bignum carry chains...
< 1764285413 897836 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Somebody mentioned something like this on #crypto recently.
< 1764285455 259356 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(in some contexts a failure to carry carries can completely break a cryptographic system)
< 1764285473 23612 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(as in, enable private key recovery)
< 1764285577 127115 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :actually pretty common because of how the proofs work for rabin, sigma protocols, etc
< 1764285617 379014 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this was a double-carry when adding two large numbers and one small one
< 1764285633 619868 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :"this is as hard as private key recovery because if you can perform a private key operation in two different ways you have the private key" well uh something went wrong and the private key operation happened in two ways, now what?
< 1764285646 547202 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I think rare code paths are normal. My code has a lot that should never run, in there in case I made a mistake or make a mistake in the future when changing the code.
< 1764285673 357032 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I feel like code paths that never run are qualitatively different from code paths that run extremely rarely in normal operation
< 1764285700 320820 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :…even though the odds of "this codepath should never run" codepaths actually running due to a programmer mistake are higher than 1 in 4 billion, those odds don't compound every time the piece of code is used
< 1764285716 533731 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :yeah
< 1764285936 995595 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :for a lot of the code paths I don't know how often they'll run or if they'll ever run, because the data comes from external sources where I don't have a good guess on their distribution
> 1764287122 318467 PRIVMSG #esolangs :14[[07$ESOLANG14]]4 10 02https://esolangs.org/w/index.php?diff=169452&oldid=160803 5* 03 5* (+1) 10