> 1766969127 69300 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03SEGFAULT 5* 10New user account < 1766969204 323420 :impomatic!~impomatic@2a00:23c7:5fc6:3201:4452:d845:4cf7:6dfb QUIT :Quit: Client closed > 1766969503 92732 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 M10 02https://esolangs.org/w/index.php?diff=171525&oldid=171399 5* 03SEGFAULT 5* (+288) 10/* Introductions */ > 1766969547 709294 PRIVMSG #esolangs :14[[07User:SEGFAULT14]]4 N10 02https://esolangs.org/w/index.php?oldid=171526 5* 03SEGFAULT 5* (+47) 10Created page with "HII!!! IM MAKING AN ESOLANG CALLED COINLOCKER!!" < 1766971146 871510 :pool!~nathan@user/PoolloverNathan QUIT :Ping timeout: 256 seconds < 1766972727 453490 :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 < 1766972831 197562 :ais523!~ais523@user/ais523 QUIT :Quit: quit > 1766972984 171191 PRIVMSG #esolangs :14[[07EtomemoteetomemoteetomemoteetomemotE14]]4 N10 02https://esolangs.org/w/index.php?oldid=171527 5* 03A() 5* (+777) 10Created page with "This language operates on memory by copying flipping bits in a text file by [[User:A()]] ==Commands== {| class="wikitable" |+ Caption text |- ! Header text !! Header text |- | _ || Copy bit to next bit |- | / || flip bit |- | \ || flip copy |- | < 1766973639 342079 :somefan!~somefan@208.58.192.69 JOIN #esolangs * :[https://web.libera.chat] somefan > 1766977458 991053 PRIVMSG #esolangs :14[[07Cat Program (language)14]]4 M10 02https://esolangs.org/w/index.php?diff=171528&oldid=163413 5* 03Mun Hammer 5* (-20) 10made the python implementation actually work > 1766977662 840528 PRIVMSG #esolangs :14[[07Talk:Cat Program (language)14]]4 N10 02https://esolangs.org/w/index.php?oldid=171529 5* 03Mun Hammer 5* (+204) 10Started the talk page > 1766984912 922504 PRIVMSG #esolangs :14[[07Baba14]]4 10 02https://esolangs.org/w/index.php?diff=171530&oldid=171489 5* 03Akalysi 5* (+71) 10 > 1766985108 145882 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03UnavgAustralian 5* 10New user account > 1766988811 216401 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=171531&oldid=171525 5* 03UnavgAustralian 5* (+254) 10 < 1766990999 350344 :impomatic!~impomatic@2a00:23c7:5fc6:3201:4d06:9a2c:1d6d:c30f JOIN #esolangs * :[https://web.libera.chat] impomatic < 1766992126 561718 :somefan!~somefan@208.58.192.69 QUIT :Quit: Client closed < 1766993162 204728 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer < 1766996745 724274 :^[!~user@user//x-8473491 QUIT :Ping timeout: 245 seconds < 1766997604 752892 :tromp!~textual@2001:1c00:3487:1b00:548d:8305:1799:9c81 JOIN #esolangs * :Textual User > 1767001572 944442 PRIVMSG #esolangs :14[[07User talk:RaiseAfloppaFan392514]]4 M10 02https://esolangs.org/w/index.php?diff=171532&oldid=171501 5* 03RaiseAfloppaFan3925 5* (+62) 10/* I have 2 esolangs with long names */ don't worry, they'll be added right away > 1767001819 754484 PRIVMSG #esolangs :14[[07User:RaiseAfloppaFan392514]]4 M10 02https://esolangs.org/w/index.php?diff=171533&oldid=171290 5* 03RaiseAfloppaFan3925 5* (+54) 10add link to rankings > 1767001838 831815 PRIVMSG #esolangs :14[[07User:RaiseAfloppaFan3925/Rankings14]]4 M10 02https://esolangs.org/w/index.php?diff=171534&oldid=171031 5* 03RaiseAfloppaFan3925 5* (+1353) 10Add two esolangs < 1767002906 609736 :tromp!~textual@2001:1c00:3487:1b00:548d:8305:1799:9c81 CHGHOST ~textual :user/tromp > 1767003166 996578 PRIVMSG #esolangs :14[[07User talk:Yoyolin040914]]4 10 02https://esolangs.org/w/index.php?diff=171535&oldid=171442 5* 03Yoyolin0409 5* (+99) 10 < 1767006567 650450 :^[!~user@user//x-8473491 JOIN #esolangs ^[ :user > 1767006591 739596 PRIVMSG #esolangs :14[[07Talk:Cat Program (language)14]]4 10 02https://esolangs.org/w/index.php?diff=171536&oldid=171529 5* 03None1 5* (+438) 10/* Python implementation */ > 1767006654 591569 PRIVMSG #esolangs :14[[07User guessed14]]4 10 02https://esolangs.org/w/index.php?diff=171537&oldid=171414 5* 03None1 5* (+49) 10/* Commands */ guess > 1767006844 249290 PRIVMSG #esolangs :14[[07Do something14]]4 N10 02https://esolangs.org/w/index.php?oldid=171538 5* 03Yoyolin0409 5* (+619) 10Created page with "'''Do something''' is an esolang by [[User:Yoyolin0409]]. Its inspiration comes from a variety of other programming languages, including: [[INTERCAL]], [[Brainfuck]], [[Light Pattern]], [[Velato]], [[Malbolge]], [[Whitespace]], [[Piet]], [[Olympus]], [[Shakespea < 1767007620 770779 :APic!apic@apic.name PRIVMSG #esolangs :Hi > 1767009491 546819 PRIVMSG #esolangs :14[[07User guessed14]]4 10 02https://esolangs.org/w/index.php?diff=171539&oldid=171537 5* 03PrySigneToFry 5* (+65) 10 < 1767009858 256837 :amby!~ambylastn@host-81-178-158-35.as13285.net JOIN #esolangs * :realname < 1767010669 956018 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) > 1767012738 802597 PRIVMSG #esolangs :14[[07A Triple Sharp14]]4 10 02https://esolangs.org/w/index.php?diff=171540&oldid=171381 5* 03PrySigneToFry 5* (+29) 10 > 1767014079 695006 PRIVMSG #esolangs :14[[07Special:Log/upload14]]4 upload10 02 5* 03PrySigneToFry 5* 10uploaded "[[02File:Tritone.png10]]": It will be used to illustrate a 'tritone' and may be used by [[Fugue]] or its discussion page. > 1767014139 869528 PRIVMSG #esolangs :14[[07Talk:Fugue14]]4 10 02https://esolangs.org/w/index.php?diff=171542&oldid=153594 5* 03PrySigneToFry 5* (+35) 10 > 1767014848 569713 PRIVMSG #esolangs :14[[07Do something14]]4 10 02https://esolangs.org/w/index.php?diff=171543&oldid=171538 5* 03Yoyolin0409 5* (+2706) 10 > 1767014888 971766 PRIVMSG #esolangs :14[[07Do something14]]4 10 02https://esolangs.org/w/index.php?diff=171544&oldid=171543 5* 03Yoyolin0409 5* (+8) 10/* Do something */ > 1767014936 649620 PRIVMSG #esolangs :14[[07Do something14]]4 10 02https://esolangs.org/w/index.php?diff=171545&oldid=171544 5* 03Yoyolin0409 5* (-12) 10/* Do something */ > 1767015062 355596 PRIVMSG #esolangs :14[[07Do something14]]4 10 02https://esolangs.org/w/index.php?diff=171546&oldid=171545 5* 03Yoyolin0409 5* (+20) 10/* Do something */ > 1767015099 760930 PRIVMSG #esolangs :14[[07Do something14]]4 10 02https://esolangs.org/w/index.php?diff=171547&oldid=171546 5* 03Yoyolin0409 5* (+16) 10 > 1767015476 857731 PRIVMSG #esolangs :14[[07Do something14]]4 10 02https://esolangs.org/w/index.php?diff=171548&oldid=171547 5* 03Yoyolin0409 5* (+795) 10 > 1767016053 650093 PRIVMSG #esolangs :14[[07Do something14]]4 10 02https://esolangs.org/w/index.php?diff=171549&oldid=171548 5* 03Yoyolin0409 5* (+814) 10 < 1767016303 350087 :impomatic!~impomatic@2a00:23c7:5fc6:3201:4d06:9a2c:1d6d:c30f QUIT :Ping timeout: 272 seconds < 1767016704 310815 :tromp!~textual@user/tromp QUIT :Quit: My iMac has gone to sleep. ZZZzzz… > 1767016724 873045 PRIVMSG #esolangs :14[[07Do something14]]4 10 02https://esolangs.org/w/index.php?diff=171550&oldid=171549 5* 03Yoyolin0409 5* (+1782) 10/* Do craft */ > 1767016747 246817 PRIVMSG #esolangs :14[[07Do something14]]4 10 02https://esolangs.org/w/index.php?diff=171551&oldid=171550 5* 03Yoyolin0409 5* (+2) 10/* This section's Hello world! */ > 1767017181 528012 PRIVMSG #esolangs :14[[07SETANDCOUNT14]]4 10 02https://esolangs.org/w/index.php?diff=171552&oldid=162256 5* 03I am islptng 5* (-240) 10 > 1767017639 814085 PRIVMSG #esolangs :14[[07SetIncrementor14]]4 N10 02https://esolangs.org/w/index.php?oldid=171553 5* 03I am islptng 5* (+748) 10Created page with "SetIncrementor is an esolang derived from [[SETANDCOUNT]], made by islptng. == Data format == This esolang operates on a set(sorted) of positive integers. == Syntax == A list of tokens separated by spaces. If it is a number N, it increments the Nth n < 1767018145 380826 :impomatic!~impomatic@2a00:23c7:5fc6:3201:113c:fa9f:2a7d:97ef JOIN #esolangs * :[https://web.libera.chat] impomatic > 1767019363 920968 PRIVMSG #esolangs :14[[07User:/Harkan14]]4 N10 02https://esolangs.org/w/index.php?oldid=171554 5* 03 5* (+1628) 10Created page with "{{WIP}} '''Harkan''' is an esolang made by [[User:]]. It currently does not have an interpreter, but you can make one! == Basis == Harkan is built with the following starting command: 
 Harkan {      }
It is the main class where its contents are run. == Classes > 1767019390 946003 PRIVMSG #esolangs :14[[07Special:Log/move14]]4 move10 02 5* 03 5* 10moved [[02User:/Harkan10]] to [[Harkan]] > 1767019444 611713 PRIVMSG #esolangs :14[[07User:/esolangs14]]4 10 02https://esolangs.org/w/index.php?diff=171557&oldid=171499 5* 03 5* (+74) 10 > 1767019491 417596 PRIVMSG #esolangs :14[[07Harkan14]]4 M10 02https://esolangs.org/w/index.php?diff=171558&oldid=171555 5* 03 5* (-18) 10 > 1767019697 727674 PRIVMSG #esolangs :14[[07SetIncrementor14]]4 10 02https://esolangs.org/w/index.php?diff=171559&oldid=171553 5* 03I am islptng 5* (+666) 10 > 1767020139 820919 PRIVMSG #esolangs :14[[07SetIncrementor14]]4 10 02https://esolangs.org/w/index.php?diff=171560&oldid=171559 5* 03I am islptng 5* (+541) 10 > 1767020176 97239 PRIVMSG #esolangs :14[[07SetIncrementor14]]4 10 02https://esolangs.org/w/index.php?diff=171561&oldid=171560 5* 03I am islptng 5* (-11) 10 < 1767020259 50135 :tromp!~textual@2001:1c00:3487:1b00:6867:e45a:c028:8b87 JOIN #esolangs * :Textual User > 1767021666 301202 PRIVMSG #esolangs :14[[07Abacus Computer14]]4 10 02https://esolangs.org/w/index.php?diff=171562&oldid=171052 5* 03Timm 5* (+260) 10 < 1767022035 169073 :ais523!~ais523@user/ais523 QUIT :Quit: quit < 1767022174 519859 :tromp!~textual@2001:1c00:3487:1b00:6867:e45a:c028:8b87 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1767022231 483967 :tromp!~textual@2001:1c00:3487:1b00:6867:e45a:c028:8b87 JOIN #esolangs * :Textual User < 1767022348 296805 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1767023665 676796 :tromp!~textual@2001:1c00:3487:1b00:6867:e45a:c028:8b87 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… > 1767025639 785534 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=171563&oldid=171521 5* 03A() 5* (+43) 10/* E */ > 1767025673 110800 PRIVMSG #esolangs :14[[07User:A()14]]4 10 02https://esolangs.org/w/index.php?diff=171564&oldid=171496 5* 03A() 5* (+42) 10 < 1767025727 824489 :tromp!~textual@2001:1c00:3487:1b00:6867:e45a:c028:8b87 JOIN #esolangs * :Textual User < 1767026618 647424 :APic!apic@apic.name PRIVMSG #esolangs :Good Night > 1767026924 197617 PRIVMSG #esolangs :14[[07EtomemoteetomemoteetomemoteetomemotE14]]4 10 02https://esolangs.org/w/index.php?diff=171565&oldid=171527 5* 03A() 5* (+172) 10 < 1767028061 340705 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net JOIN #esolangs * :[https://web.libera.chat] Yayimhere < 1767028106 564484 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :hello < 1767028638 455736 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Morning. < 1767028675 35725 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :thanks korvo! < 1767028685 193155 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :sorry for the topple thing btw < 1767028707 670428 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It's okay. I only stepped in to chill an edit war, and it seems that the warring stopped. < 1767028720 10729 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :it infact did < 1767028725 262521 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :*in fac < 1767028728 464674 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :*fact > 1767028748 203573 PRIVMSG #esolangs :14[[07EtomemoteetomemoteetomemoteetomemotE14]]4 10 02https://esolangs.org/w/index.php?diff=171566&oldid=171565 5* 03A() 5* (+269) 10 < 1767028822 316328 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: I had a brain moment last night and I think that I have three computable models of linear logic. LMK if this is the sort of thing that you're hunting for, although I suspect that you already know all this. < 1767028864 933679 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The models are FdVect_Q, Chu_2, and a novel values-and-boxes model that somewhat resembles the Rust pirating discussion. < 1767028880 795369 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I think that this is a different level of abstraction from the one I've been focusing on < 1767028906 751969 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :OTOH, I've been actively working on a box-based model in order to try to explain Rust mutable references in terms of things the language already had, that's my plan for my next blog post < 1767028914 728740 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah, this is like "what if Cammy, but linear", not "how to improve Rust". But I didn't want to withhold it. < 1767028918 731919 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but that's not linear-logic-related < 1767028959 629998 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess my *current* point of view about the whole pirating thing is "oh good, I can stop worrying about shared references in my models any more, they have a simple type theory that I can just apply to my model" < 1767028974 166489 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and just try to work on Rust-without-shared-references and add them back alter < 1767028976 853409 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* later < 1767029010 411737 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think my biggest observation along these lines is that pirating a mutable reference gives you a shared reference, but pirating a Rust `Box` *also* gives you a shared reference < 1767029038 385515 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which seems redundant but is incredibly useful when you're trying to create mutable references from scratch < 1767029049 601416 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Ah, so mutation is primitive in your approach. That might be the biggest difference. I'm modeling mutation with "linear" implication. < 1767029102 801517 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Like, it's not technically a problem for me if a non-linear operation on bits is part of a CPU's functionality. I can just pretend that the underlying storage for those bits is linear, like a row of light switches which just happen to encode classical bits, < 1767029109 876631 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I *think* the mutation primitive in my approach is the "box overwrite" but it's one of the awkward parts of it < 1767029126 403834 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or maybe even the box swap < 1767029138 54096 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think it's been observed before that Rust's underlying mutation primitive seems to be a swap < 1767029183 62978 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Makes sense. You're able to see the locations of boxes too, right? Like, an address or a pointer? I'm imagining that the boxes are wholly opaque. Like there's a vast desert and occasionally I've cordoned off a little section of flat desert and said "this is a region" even though there's nothing there. < 1767029191 81062 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in particular Cell::swap is interesting because all the normal the mutation operations in Rust can be defined in terms of it, but it can't be defined in terms of any of the others < 1767029200 938013 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :And then values are like raised sections of desert, or holes for negated values. < 1767029235 301028 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :actually it's the reverse, I'm pretty sure each box defines its own address space (but that has a relationship to the box it was borrowed from), and that this is where provenance comes from < 1767029239 69151 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Whoa, that's actually pretty deep. < 1767029256 708358 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh, like a hierarchy of boxes? < 1767029303 213641 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's subtle, pinning down this exact subtlety is important because as far as I can tell, pinning down the subtlety correctly defines the entire Rust aliasing model which is something that people have been trying to figure out for years < 1767029332 651289 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but the basic approach I'm planning in my blog post is "instead of a mutable borrow, let's move part of this box into another box" and then having the boxes share memory is an optimisation < 1767029373 561590 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but, in order to be able to model how Rust mutable references currently work, you need a "reclaim" information which forcibly moves values from the smaller box back into the bigger one, even if you don't have access to the smaller box < 1767029420 71716 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the reclaim operation is mathematically a mess, and causes a lot of problems for Rust use in practice too, but it's implied to exist by how Rust &mut works – and I think this is the root cause of many (all?) of the problems observed with &mut in practice < 1767029455 631011 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if you don't have reclaiming, the boxes could theoretically be entirely independent (but you'd still probably want to track a hierarchy of them to be able to optimise the code correctly) < 1767029546 922839 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It's almost like versioned storage. I'm still mulling over how you put this before: because linear logic has disjunctions that operate in parallel, it's possible for mutations to involve one of *several* rows of versioned objects, depending on how the compiler chooses to interleave them. < 1767029587 859780 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :...Which, by Galois-Yanofsky theory, seems like a broken symmetry that the compiler provides rather than a core part of the mathematical model. < 1767029601 711575 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :re: Cell::swap, I don't think it's the *actual* primitive – the actual primitive is something more like GhostCell::swap, but cells keyed to weird proofs of uniqueness don't exist in the standard library, you have to use external crates for those < 1767029614 470998 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so Cell::swap is enough for the standard library types < 1767029702 388379 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I'm imagining a little earth mover out in the desert. This is what a linear implication looks like; it's a little machine that moves stuff from one place to another. To assemble *any* non-negated value, just assemble stuff, one hunk of moved earth at a time. > 1767029741 450218 PRIVMSG #esolangs :14[[07Hello world program in esoteric languages (D-G)14]]4 10 02https://esolangs.org/w/index.php?diff=171567&oldid=163611 5* 03A() 5* (+224) 10 < 1767029746 222088 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :In FdVect_Q or any Vect-like category, there's basis vectors. Build up any value by expressing it along the basis. In Chu_2, there's the two Boolean values, and again there's basis spaces that can build any tableau. < 1767029764 429902 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :is the aim to produce a denotational semantics? < 1767029810 54935 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :So, if we assume that our values are discrete or otherwise set-like then swapping everything into place seems like a complete basis for constructions. You can build anything you want if it's made up of "move a 0 into place" and "move a 1 into place" mini-instructions. < 1767029871 472151 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, I've noticed the recursive nature of constructing values < 1767029874 732610 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: A little. I think any claimed model of linear logic should have a story for multiplicative disjunction, and I'm annoyed that it seems to trivialize in every model. I am coming to understand that, in linear logic, values don't exist on their own; instead, values are either *to consume* or *to produce*, with a polarity. < 1767029877 724921 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I'm surprised that boxes even come into this < 1767029904 372242 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the regress has to bottom out somewhere, 0 and 1 may be fine if you're working entirely at the value level < 1767029915 737177 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :at least from Rust's point of view, you also have to deal with constructing/moving zero-sized types < 1767029933 47601 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: They naturally show up as dual values. If a value is a bump of earth in the desert, a box for that value is a hole in the desert. We can receive a value into a box, we can dig a value out of a box and leave it empty, etc. < 1767029944 871579 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but those are more part of the type system than they are part of a runtime semantics < 1767030111 703365 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :yes, the runtime rules are pretty chill about reading and writing zero-sized types. < 1767030222 536820 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :but they aren't really enough, we need to be able to read and write types that aren't zero-sized. > 1767030458 768025 PRIVMSG #esolangs :14[[07EtomemoteetomemoteetomemoteetomemotE14]]4 10 02https://esolangs.org/w/index.php?diff=171568&oldid=171566 5* 03A() 5* (+0) 10 < 1767030537 791157 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: this has actually frustated me a bit because I've been interested in making a typed asm with similar safety proofs to Rust < 1767030577 314176 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but doing the safety proofs involves a lot of ZST manipulation, and while it's easy enough to add asm pseudo-instructions to read and write ZSTs so that you can use them in the type proof, actually modelling what a ZST is at runtime is much harder < 1767030612 261303 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I *think* I have a working formalism in which they have infinitesimal rather than zero size (and non-ZSTs are made infinitesimally smaller to leave gaps to store the ZSTs in) < 1767030652 101703 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but typical asms aren't designed to handle this sort of thing, and in particular it is hard to distinguish between two ZSTs at the same address > 1767030749 93867 PRIVMSG #esolangs :14[[07EtomemoteetomemoteetomemoteetomemotE14]]4 10 02https://esolangs.org/w/index.php?diff=171569&oldid=171568 5* 03A() 5* (+90) 10 < 1767030895 340235 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net QUIT :Ping timeout: 272 seconds < 1767031035 311859 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I'm not sure whether I care about zero-sized values. In FdVect_Q, the smallest possible object is a singleton that still has to be passed around as a correctness token and (I think) cannot be erased. < 1767031058 932458 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ZSTs are an instance of the phantom-type pattern, right? Or do they carry data at runtime too? < 1767031671 134928 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in Rust they don't carry data at runtime < 1767031678 868634 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :they exist for type-level proof purposes < 1767031711 111270 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in my typed-asm model they are capable of carrying provenance, which is needed to prove certain optimisations to be correct (i.e. you can't perform the optimisation without the ZST being present) < 1767031754 41785 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so even though they still do nothing at runtime, they are needed to be able to do a correctness proof of the asm, which involves being able to (from the asm's point of view) read and write them > 1767032163 982555 PRIVMSG #esolangs :14[[07EtomemoteetomemoteetomemoteetomemotE14]]4 10 02https://esolangs.org/w/index.php?diff=171570&oldid=171569 5* 03A() 5* (+318) 10 < 1767032172 510740 :tromp!~textual@2001:1c00:3487:1b00:6867:e45a:c028:8b87 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… > 1767032203 531543 PRIVMSG #esolangs :14[[07EtomemoteetomemoteetomemoteetomemotE14]]4 10 02https://esolangs.org/w/index.php?diff=171571&oldid=171570 5* 03A() 5* (-1) 10 < 1767033235 477207 :tromp!~textual@2001:1c00:3487:1b00:6867:e45a:c028:8b87 JOIN #esolangs * :Textual User < 1767033313 946063 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: you could do that in your typed assembler model, but it would be incompatible with normal rust zero-sized types (not necessarily with provenance) < 1767033332 951852 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: yes, it wouldn't model unsafe uses of Rust ZSTs < 1767033352 271620 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but, the typed asm would struggle to typecheck unsafe Rust anyway because the whole point is that it can't be typechecked… < 1767033364 340045 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net JOIN #esolangs * :[https://web.libera.chat] Yayimhere < 1767033375 150598 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the intention is to verify safety proofs post-compile, it's hard to produce a safety proof for unsafe code) > 1767033558 431006 PRIVMSG #esolangs :14[[07EtomemoteetomemoteetomemoteetomemotE14]]4 10 02https://esolangs.org/w/index.php?diff=171572&oldid=171571 5* 03A() 5* (+529) 10 < 1767033664 366160 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :korvo: you mentioned this novel values and boxes model, care to elaborate? perhaps the name is self explanatory and im just too non versed in rust, but im interetsed < 1767033664 857456 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :(if you wondering, I did look at you and ais's chat, but I didnt gain too much info, but it was enough to get me hooked) > 1767033726 84599 PRIVMSG #esolangs :14[[07EtomemoteetomemoteetomemoteetomemotE14]]4 10 02https://esolangs.org/w/index.php?diff=171573&oldid=171572 5* 03A() 5* (+17) 10 > 1767033778 341156 PRIVMSG #esolangs :14[[07I cannot understand that.14]]4 10 02https://esolangs.org/w/index.php?diff=171574&oldid=112448 5* 03Mun Hammer 5* (+568) 10Added a compiler > 1767034035 124022 PRIVMSG #esolangs :14[[0714]]4 10 02https://esolangs.org/w/index.php?diff=171575&oldid=166489 5* 03Yayimhere2(school) 5* (-445) 10/* >>= kinda */ > 1767034050 901477 PRIVMSG #esolangs :14[[0714]]4 10 02https://esolangs.org/w/index.php?diff=171576&oldid=171575 5* 03Yayimhere2(school) 5* (-123) 10/* commands and semantics */ < 1767034099 739163 :impomatic!~impomatic@2a00:23c7:5fc6:3201:113c:fa9f:2a7d:97ef QUIT :Quit: Ping timeout (120 seconds) < 1767034343 349676 :impomatic!~impomatic@2a00:23c7:5fc6:3201:113c:fa9f:2a7d:97ef JOIN #esolangs * :[https://web.libera.chat] impomatic > 1767034360 996464 PRIVMSG #esolangs :14[[07EtomemoteetomemoteetomemoteetomemotE14]]4 10 02https://esolangs.org/w/index.php?diff=171577&oldid=171573 5* 03A() 5* (+304) 10 < 1767034422 71346 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :"box" has a specific meaning in Rust but I suspect korvo was using it differently (I'm not sure though) < 1767034430 951241 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :hm < 1767034502 348609 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in current Rust, a Box is a memory allocation that contains a value (e.g. if I write «Box::::new(5)» then this corresponds to making a memory allocation that's big enough to hold an unsigned 64-bit integer and storing 5 in that allocation) < 1767034519 388777 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :yea < 1767034569 321192 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although I think this is mixing together two concepts (that there is a memory allocation that belongs to the Box, and that the Box ensures the memory is holding a value while the Box exists and drops the value when the Box is dropped) < 1767034626 611920 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :most Rust users think that the important concept is the first one (the Box managing the allocation), but I think the second is more fundamental < 1767034643 278949 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :hm > 1767034661 57018 PRIVMSG #esolangs :14[[07EtomemoteetomemoteetomemoteetomemotE14]]4 10 02https://esolangs.org/w/index.php?diff=171578&oldid=171577 5* 03A() 5* (+7) 10 < 1767034999 234242 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: and there's a bit more of the first property, which is that the allocation can be identified by just the rust pointer to the contents of the box < 1767035049 791894 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: although that is true in current Rust, I'm not sure that it's inherent in a definition of Box or even guaranteed by the current Rust guarantees < 1767035072 689309 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I think it is guaranteed < 1767035075 430858 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :except inasmuch as a Box has the same representation as a pointer to its contents in FFI < 1767035130 267745 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I don't know if it's guaranteed to have the same representation, but it can be losslessly converted to a pointer with the Box::into_raw function and back with the Box::from_raw function < 1767035201 894539 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Rc's into_raw/from_raw used to change representation < 1767035225 492484 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yayimhere: Think of a row of light switches. On one hand, the light switches are in a position, and if we had eight switches then we could store a byte. That's a "value". We also have the light switches themselves! Those are a "box" which stores values. < 1767035232 660785 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although recently the internals of Rc were changed so that it just stores the value that would be returned by into_raw rather than a pointer to the start of the allocation < 1767035248 250785 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :korvo: yea that makes a lot of sense < 1767035252 156845 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :hm < 1767035261 308721 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :All of the rest of this is *linear logic*, the logic of how resources move through a system when they can't be created or destroyed. If we flip the light switches then we are reconfiguring the system without creating or destroying. < 1767035277 945564 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :thats actually interesting to think about as a "mechanic" of a language. < 1767035283 211253 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :korvo: yea < 1767035288 25221 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The reason I'm imagining this is because a stick of RAM has several billion microscopic light switches, mostly. < 1767035294 951428 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :yep < 1767035347 581157 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :but thinking of these "boxes" as a mechanic, a thing you can modify is interesting < 1767035396 642062 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Yayimhere: extremely interesting, I think it's the biggest unsolved problem in systems programming < 1767035398 137379 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah. To connect with what ais523 is saying, imagine *allocating* some RAM. We're saying that, out of the existing box of billions of switches, we want to choose a few hundred specific switches. A smaller box that is part of a larger box. < 1767035430 350891 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :ais523: is this ironic? < 1767035443 663195 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :korvo: makes sense aswell < 1767035454 730802 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Yayimhere: no – C and C++ and Rust are all struggling with the idea of when memory is just memory versus when memory is a box with defined behaviour < 1767035467 328139 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :ais523: k < 1767035479 950732 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if I have a box with eight switches in it, and flip the sixteenth switch, I am changing values outside the box < 1767035490 629615 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :is -c c--? < 1767035504 763792 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :trying to define when that's allowed/disallowed and when that even makes sense is very difficult < 1767035532 205743 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :yea < 1767035542 312706 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but systems programming languages have a sort of dual view of memory, one view as just this continuous sequence of switches that you can move around as you like, and one as a set of nested boxes < 1767035552 848476 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: is the question whether overwriting the contents of a box like `*abox = value` can change the addres where the box is pointing to? < 1767035556 184134 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and trying to reconcile these views is really difficult < 1767035568 507246 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :hm < 1767035586 511773 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: no, it's about when doing `box[offset] = value` is legal > 1767035589 504785 PRIVMSG #esolangs :14[[07EtomemoteetomemoteetomemoteetomemotE14]]4 10 02https://esolangs.org/w/index.php?diff=171579&oldid=171578 5* 03A() 5* (+244) 10 < 1767035619 435725 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :is that for like a boxed slice or boxed array? < 1767035634 500834 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in most languages this is undefined behaviour if the offset goes outside the box, *but* that means you have to define what the box actually is < 1767035637 883239 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :well, I guess ill be thinking about that for a while < 1767035638 589185 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh yeah, in systems programming, we have values which *refer* to the locations of boxes. We have words like "referrer", "referent", and "reference". It's awful and I wish that there were a better way. < 1767035656 560402 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: boxed slice is a good way to think about it in Rust terms, but I meant the example to extend to C as well < 1767035755 821154 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: Rust has been trying to standardise terminology on "address" = where in memory the location is (independent of any rules for accessing it), "pointer" = address + provenance, "reference" = address + provenance + proof of access safety < 1767035781 782018 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but it probably won't catch on in other languages < 1767035796 639202 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I don't understand this `box[offset] = value` thing. if it's not a slice/array in the box then why could it work? < 1767035802 60742 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(also I think there are actually four components rather than three) < 1767035820 341315 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: well, suppose you're using a model where you haven't defined what the box is < 1767035826 413221 :int-e!~noone@int-e.eu PRIVMSG #esolangs :b_jonas: it's a bit lower level than that so it includes accessing struct fields etc < 1767035840 3945 :slavfox!~slavfox@193.28.84.32 QUIT :Ping timeout: 240 seconds < 1767035847 501967 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :box[1] = 2 will write to the memory address after *box – how is a compiler going to prove that you can't do that, without defining what a box is first? < 1767035873 983807 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: Well, check this out. This is where my mind is currently struggling. Where's `value` come from? A register? How can we have values without boxes? < 1767035887 107649 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :why would the compiler have to prove that you can't do that, if you can only write it in unsafe code? < 1767035892 864272 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :re: four components: address, allocation, provenance, proof of access safety < 1767035904 299451 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I think that if values and boxes are dual then it doesn't make sense to talk about a bare value or bare box. They're always connected via duality. < 1767035905 886664 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: because otherwise most optimisations aren't legal < 1767035906 535687 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :is it to eg. optimize an array access so it can assume the index is 0? < 1767035917 241762 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I see < 1767035945 590731 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I'm not sure the compiler is allowed such optimizations with rust Box currently < 1767035951 85517 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you want to be able to prove that a write to one address can't overwrite unrelated addresses, but then you have to define "unrelated" < 1767035985 79781 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the compiler is definitely allowed such optimizations with current Rust Box, it has (for accidental historical reasons) some of the strongest requirements of any type on using it unsafely < 1767035985 165417 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :even if the contents isn't zero-sized < 1767036037 360704 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if you pass a Box to a function, the compiler can and does optimise on the basis that any reads/writes to the memory backing the Box must be through the Box, and any reads/writes through the Box must be to the memory backing it < 1767036065 935441 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :hmm, maybe < 1767036087 383697 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :oh, *that* it can certainly optimize < 1767036099 511351 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :these requirements apply even to unsafe code, which causes problems sometimes because it's somewhat easy to violate them accidentally (e.g. by unsafely copying the box and then doing things through the copy) < 1767036109 532998 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :the box behaves like it has a mut reference to its contents < 1767036124 93077 :int-e!~noone@int-e.eu PRIVMSG #esolangs :this could become quite the volatile discussion and the keyword hasn't even been mentioned :P < 1767036138 611814 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I would clarify that to "the box behaves like it has a mut reference to *the memory containing* its contents" < 1767036138 682901 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :so same requirements as with any mut reference < 1767036183 911459 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: this is because there's a consensus that (except in Java) volatile doesn't actually do anything from the allowing-otherwise-unsafe-code point of view, what would be UB without volatile is still UB even with volatile < 1767036235 519719 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: Yeah that would obviously be more about memory-mapped IO angle. But I'm pathologically attracted to puns. < 1767036260 660275 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(going all the way back to the little light switches) < 1767036308 531265 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :my main use for volatile is for creating variables that can safely be written using a debugger < 1767036384 293810 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(I use this for variables that request extra debug information to be printed, and use a debugger to turn the option to print it on) < 1767036596 101725 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Hmm. Semi-relatedly, I *guess* /proc/self/mem can't be mmap-ped because of https://xkcd.com/878/ < 1767036608 123928 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Oh! I remember my issue now. I'm not sure if there's NNOs in the relevant categories. I think that FdVect_C (or _R I guess) can encode counting as a linear transformation like "multiply by 2" and the composite map is a logarithm, base 2, but I didn't work out whether it's correct. < 1767036620 170149 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(I was reminded of https://docs.rs/totally-safe-transmute/latest/totally_safe_transmute/fn.totally_safe_transmute.html ) < 1767036623 83795 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :what does NNO stand for here? < 1767036632 426841 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :And I was thinking that maybe the inability of linear logic to count is something deep. < 1767036676 79686 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh, sorry. Natural Numbers Object. An object that behaves like N in Set. For every diagram 1 -> X -> X, there's a diagram made from zero : 1 -> N and succ : N -> N which can "count" in X. < 1767036697 957366 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net QUIT :Quit: Client closed < 1767036720 339799 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net JOIN #esolangs * :[https://web.libera.chat] Yayimhere < 1767036722 958985 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, practical programming languages usually don't have one of those in their semantics, because they don't expect to be able to store actually unlimited numbers < 1767036747 791460 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Python does, but I get what you mean. Cammy's not practical, for example. < 1767036760 949770 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although, one proposal I had for Rust would be numbers that can store bignums in finite size but are allowed to panic any time the number is out of the range that would be implied by the size < 1767036786 801468 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :from the operational semantics point of view, the high bits of the number are stored in the provenance < 1767036821 174070 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the purpose of this would be to make it legal to optimize "x.increment_reference_count(); x.decrement_reference_count()" into a no-op < 1767036842 639197 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(currently this optimization is not legal as the program semantically is supposed to panic on reference count overflow) < 1767036902 415280 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: /proc/self/mem not only can be memory mapped, IIRC it's designed to be – the trick is to mmap only a subset of it rather than the whole thing < 1767036937 40857 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm not sure what happens if you map it in a way that the map contains part of itself at a slight offset, though < 1767036961 567112 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 264 seconds < 1767037017 269510 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1767037109 158540 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Hall of mirrors, but with pointers. < 1767037237 399416 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :man proc_pid_mem doesn't help explain what happens in this situation (it's one of the shortest manpages I've ever seen) < 1767037245 428976 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :...English WP deleted their hall-of-mirrors article. This one is pretty good: https://www.thealmightyguru.com/Wiki/index.php?title=Hall_of_mirrors_effect < 1767037267 680372 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so finding out would require either checking kernel source or experimenting < 1767037318 942288 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: oh, I thought you were referencing an actual hall of mirrors (which can contain mirrors that reflect each other) rather than the rendering issue < 1767037342 279252 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: I'm thinking of them as all having the same underlying issue: some sort of spatiotemporal aliasing. < 1767037370 234114 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the rendering issue is different because it's affected by the way that the camera has historically moved < 1767037376 525998 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The aliasing causes a deference/bounce to point at the "wrong" target because something else has been mapped/interspersed in the way. < 1767037388 603772 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Right, the visual effect is temporal aliasing. < 1767037410 998541 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or a good way to think about it is that when rendering, the undefined areas hold pixels from a *previous* rendering, but if you mmap /proc/self/mem at an offset, it logically contains bytes from its own *current* value < 1767037441 867865 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :thus causing memory addresses separated by a multiple of the offset size to become aliases for each other < 1767037478 671562 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I can't find any good examples offhand, but e.g. Super Mario 64 has spatiotemporal halls of mirrors due to how it rasterizes; when looking through an untextured/missing polygon it's possible to get a valid texel from a wrong texture rather than an invalid texel. > 1767037500 2365 PRIVMSG #esolangs :14[[07EtomemoteetomemoteetomemoteetomemotE14]]4 10 02https://esolangs.org/w/index.php?diff=171580&oldid=171579 5* 03A() 5* (-1259) 10 < 1767037519 620387 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: nope: https://elixir.bootlin.com/linux/v5.19.17/source/fs/proc/base.c#L928-L934 and contrast that with https://elixir.bootlin.com/linux/v5.19.17/source/drivers/char/mem.c#L647-L657 for /dev/mem (whose mmap is free of circularity because it creates virtual -> physical mappings) < 1767037522 248961 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :This normally can't happen on today's GPUs because of texture binding; each draw call is always done with the correct textures. < 1767037603 481397 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: isn't it effectively the equivalent of reading out-of-bounds texels? maybe not the same mechanic, but the same end result < 1767037618 702596 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I suspect that could happen even nowadays because I doubt GPUs are doing bounds checks < 1767037626 333690 :int-e!~noone@int-e.eu PRIVMSG #esolangs :not sure why I'm looking at 5.x instead of 6.x < 1767037666 257009 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: I realize that I might be a little physics-brained about this. An IRL hall of mirrors, *under special relativity*, isn't instantaneous. I imagine that the kernel's page-management algorithm isn't deterministic, so that self-inspection of the memory map could interfere with mutation. < 1767037706 971489 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: hmm, I was thinking about golfing languages, which often go out of their way to do exactly what you asked for even when it's inconsistent with other uses of the same operation < 1767037711 572604 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: It's more like reading the texel that would have been correct, *if* the polygon had been textured a certain way; but it had no texture at all, so there's not really any correct color value. < 1767037734 770741 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :"make a[0..4] an alias for a[1..5]" is physically possible to do, although I didn't expect the kernel to actually implement it < 1767037752 753109 :int-e!~noone@int-e.eu PRIVMSG #esolangs :But it hasn't changed: https://elixir.bootlin.com/linux/v6.18.2/source/fs/proc/base.c#L992-L999 and https://elixir.bootlin.com/linux/v6.18.2/source/drivers/char/mem.c#L631-L642 < 1767037789 47935 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(apart from a new .fop_flags field that is irrelevant) < 1767037904 204236 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: doesn't mmapping /proc/$pid/mem already have to handle what to do if the mapping for the addresses that it's aliasing is changed? < 1767037924 321256 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: as int-e points out, it isn't actually allowed, but I guess it would < 1767037982 725276 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: so technically the manpage does help but you have to recognize that the given list of operations is exhaustive < 1767037986 193412 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: For Super Mario 64 and friends, it's because the N64 didn't have a full hardware TCL (Transform, Clipping, Lighting IIRC?) pipeline with "texture combiners" or what we now call shaders. Today, the GPU usually won't even consider a "fragment", a pixel prepared for coloring and lighting, unless it came from the hardware rasterizer. The sort of thing that is fixed by better architecture. < 1767038030 42837 :int-e!~noone@int-e.eu PRIVMSG #esolangs :anyway. happy I confirmed my theory :) < 1767038042 845404 :int-e!~noone@int-e.eu PRIVMSG #esolangs :or guess, I suppose < 1767038049 320934 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: well, I'm thinking along these lines: a very simple pixel shader just indexes into the memory holding the texture – but if that doesn't do a bounds check it might index out of bounds of the texture < 1767038154 925222 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :I'm scared enough of the lifetime management and locking for vm_area structs as they are, recursive would be so much worse < 1767038217 949319 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Yeah. To make another tangent, it's like how each mmap comes with size and flags; the textures are always laid out in memory prior to rendering, and the process of laying it out, decompression, mip-mapping, etc. validates the bounds. < 1767038241 342339 :int-e!~noone@int-e.eu PRIVMSG #esolangs :sorear: And all that trouble would hardly serve any purpose. < 1767038274 740216 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(snapshotting process memory without forking (cloning with CLONE_VM) would be nice I guess) < 1767038277 496225 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: the thing I'm unsure about is mostly as to whether that's a hardware feature of the GPU or whether that's just a thing that's commonly enforced in GPU software/drivers < 1767038315 224309 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Hm. Texels are typed, there's a (FourCC) format, and texel access is always aligned. Even if it's OOB, I suppose, although OOB texel coordinates are hard to generate today. < 1767038369 51818 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: It's usually a hardware feature for discrete GPU boards that communicate over PCIe, but wholly in software for hybrid cores or APUs. It was only in hardware when it had to be. < 1767038374 830890 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, u/v coordinates noramlly wrap in practice < 1767038386 454764 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm not sure whether they actually *have* to, but it's useful that they do < 1767038483 322314 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :But also, as soon as render-to-framebuffer came out, there was a big push to add fences to GPU drawing commands. Everybody wanted the result of intermediate draw calls to be well-defined; if I draw a scene to a texture then I want that first draw to finish before the texture's bound for the second draw. < 1767038502 154957 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :That's another good example. Or Z coordinates being auto-scaled when read from hardware Z buffer. < 1767038538 279761 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :BTW I'm hoping that my knowledge of GPU drivers here is helping to generate insights. I'm not trying to argue or to get anyplace specific. < 1767038596 941361 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I was formally taught GPU programming twice, from two different points of view, but oddly textures weren't involved either time (or involved only very marginally) < 1767038604 789383 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Like, if I have some weird way that my process's memory is bound, maybe like part of my memory is exported to Somebody Else's MMap, then both of our processes probably want some serialization for how I mutate vs how they read. < 1767038656 274964 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Or e.g. SysV message queues have a similar sort of problem. On classic USA post/mail boxes, there's a little red flag that can be raised to indicate the presence of mail; there's no associated software mailbox for SysV MQ. < 1767038699 389440 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : Like, if I have some weird way that my process's memory is bound, maybe like part of my memory is exported to Somebody Else's MMap, then both of our processes probably want some serialization for how I mutate vs how they read. ← I believe this is a currently unsolved problem, i.e. both runtimes and languages leave it up to the individual programs to come to an agreement and don't try to define what happens if they don't < 1767038708 25143 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Oh, nice! I wasn't formally taught anything. I helped write some AMD/ATI drivers because I had bought a laptop and wanted to play some video games. Then I learned formal raytracing and decided that GPU drivers were not a fun career. < 1767038740 311482 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the first time was a really old version of OpenGL, back when it was fixed-pipeline; the second time was CUDA < 1767038766 496460 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yes! I remember when Go came out. There was enormous noise about a CSP principle, "don't communicate by sharing memory; share memory by communicating." Lovely in principle but no idea how to actually glue that to POSIX. < 1767038797 224592 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, the POSIX non-shared-memory communication primitive is the pipe < 1767038920 62601 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah. If we go down that route, I'm basically 100% with Kell and Jakubovic on this; the process isn't the right unit of isolation for talking about a persistent object. You need something like a directory, which is really just a name that can hold multiple FIFOs. < 1767038924 820992 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I've actually considered trying to come up with something that is to a pipe as a futex is to a mutex, i.e. it interoperates correctly cross-process and the kernel can be involved if necessary, but the common case works even with no context switches < 1767038927 6309 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: I thought it was PF_UNIX family sockets < 1767038935 821957 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :including socketpairs < 1767038938 284209 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: maybe, the two are extremely similar < 1767038945 169734 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I think that there's no coincidence in e.g. s6's concept of "fifodir", where a directory of FIFOs is a central abstraction. < 1767038960 936265 :int-e!~noone@int-e.eu PRIVMSG #esolangs :but unix domain sockets add ancillary data < 1767038961 572728 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :pipes are what you use on Win32 as a poor man's replacement < 1767038995 772188 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ACTION remembers how DOS implemented "pipes" < 1767039073 921214 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: does it just run the programs one at a time, using a temporary file instead of a pipe? < 1767039080 518782 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: yup < 1767039134 900947 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I remember porting a program I'd written from SunOS to Linux, the only change I needed to make was to fix one of my pipe system calls < 1767039158 401623 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because I'd accidentally swapped the two ends of the pipe, apparently they're bidirectional on SunOS and unidirectional on Linux < 1767039188 711790 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but this makes me wonder whether, if you do a | b on SunOS, the programs can communicate bidirectionally by writing stdin/reading stdout to do the reverse direction communication < 1767039211 964654 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :hey peeps, could I perhaps employ your help in naming an esolang I have created? I know it is not the most < 1767039214 940178 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :oops < 1767039226 93672 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :someone decided that pipe was redundant with socketpair? < 1767039258 711463 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :oh that was mentioned < 1767039284 113443 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: bidirectional in what way? writing on either side writes to the same buffer, or in two separate buffers that can be read only from the other pipe handle? < 1767039380 365470 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :you need to be able to detect when all possible write handles have been closed so the reads will EOF < 1767039421 110784 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I actually don't know, I never tried anything that would distinguish < 1767039430 911940 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because I was mostly interested in getting the software working < 1767039480 326312 :slavfox!~slavfox@193.28.84.32 JOIN #esolangs slavfox :slavfox < 1767039660 202718 :int-e!~noone@int-e.eu PRIVMSG #esolangs :bah, the "OpenGL ES 3.2 Reference Pages" link on https://www.khronos.org/opengles/ is broken < 1767039707 487836 :int-e!~noone@int-e.eu PRIVMSG #esolangs :https://registry.khronos.org/OpenGL-Refpages/es3/ works < 1767039722 343439 :DOS_User_webchat!~DOS_User_@user/DOS-User:11249 JOIN #esolangs DOS_User :[https://web.libera.chat] DOS_User_webchat < 1767039822 907006 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yayimhere: What's up? < 1767039905 851955 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :About memory sharing, I had a idea that I had mentioned before; only a read-only mapping can be shared; if you transfer a writable mapping then you will lose access to it (although you can change the access to read-only in order to make it shareable, you cannot then change it back to writable unless you ask someone for a memory allocation and tell the system to use the existing memory; the system will optimize it if possible) < 1767040033 870293 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :korvo: assuming your talking about the language, its a string rewriting language where the only operation is based on overlapping (as in, when doing the only available operation, it chooses two substrings, but then the next substrings chosen, the last choice of the first operation will be the first of the second operation) < 1767040088 471504 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yayimhere: What motivated you to create it? < 1767040099 251542 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :korvo: to function similairly to < 1767040100 799792 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :hmm < 1767040104 855692 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :what was that l,anguage < 1767040106 990174 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :wait a sec < 1767040139 321947 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :zzo38: Have you read ais523's pirate post? http://ais523.me.uk/blog/logic-of-shared-references.html < 1767040189 476206 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It sounds like you're thinking about the same problem. How can "the system" know whether a reference has been shared, and what does it actually have to track at runtime? < 1767040203 876207 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :ok, so, ais523 had created a similar language, but in which that same thing happened in the programs reading instead of the strings < 1767040205 488371 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I had read it but I will read it again because I do not remember. < 1767040231 365369 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :I go inspired by it slightly, and then later thought about bracketed expressions in which brackets arent nested, but next to each other < 1767040256 718995 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :and then I wondered how to make a string written like that be able to interact without two brackets next to each other functioning as just one string < 1767040283 533186 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :The kernel would know if a reference is shared because the kernel keeps track of the processes in the system, I think. (So, mine is at a level of the operating system rather than the level of the programming language) < 1767040296 602788 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :so yea, korvo < 1767040299 183599 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :thats it < 1767040301 872378 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :but I have to go < 1767040309 769654 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net PRIVMSG #esolangs :sorry¨ < 1767040344 405014 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :zzo38: Makes sense. I think seL4 does that sort of thing since all memory allocation is in the kernel, but I don't remember details. < 1767040352 725872 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yayimhere: No worries. Take it easy. < 1767040376 936655 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :but anyway, besides PF_UNIX sockets (including both ones created by socketpair and ones created by socket), posix also has message queues with the mq_open and similar functions https://man7.org/linux/man-pages/man7/mq_overview.7.html , as well as semaphores and shared memory, which are apparently made to replace the less flexible old SYSV message queue / semaphore / shared memory interfaces < 1767040440 940002 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: Yes. POSIX MQ is much nicer despite having nearly the same API. < 1767040632 893747 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :to be honest I don't understand what the use of message queue is these days, except for historical compatibility < 1767040775 341274 :Yayimhere!~Yayimhere@128-76-215-116-cable.dk.customer.tdc.net QUIT :Ping timeout: 272 seconds < 1767041224 604285 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: On their own, they kind of suck because of the mailbox problem I mentioned above. However, on Linux and a few other kernels, we can poll() or select() MQ descriptors as ordinary FDs. So, let's imagine a tree of processes that are doing some best-effort monitoring or computation. They each are reporting their current/intermediate results to a central integrator. < 1767041303 686619 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Each reporter can put its results in an MQ. The integrator can select() on the MQs to figure out which reporters have updated. The integrator can mutate the MQ to talk to the reporter, with the understanding that not every command will be delivered due to races. < 1767041396 266597 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The entire point is, quoting that man page, "if not removed by mq_unlink(), a message queue will exist until the system is shut down." So the integrator and reporters can both be restarted or upgraded in place, hot-swapping, without affecting the integrity of the tree. < 1767041452 917462 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :And MQs are subject to IPC namespacing on Linux, so it's possible to have *private* MQs that can't be inspected or attacked by anybody else. You don't have to do like s6 and park a fifodir where superusers can touch it. < 1767041541 607837 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :Why is CAP_DAC_OVERRIDE inherently more concerning than CAP_SYS_PTRACE? < 1767041670 182498 :DOS_User_webchat!~DOS_User_@user/DOS-User:11249 QUIT :Remote host closed the connection < 1767041709 327031 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oo, I haven't heard this one. Why is DAC_OVERRIDE more concerning than SYS_PTRACE? < 1767041740 316744 :int-e!~noone@int-e.eu PRIVMSG #esolangs :they sound more or less equivalent to me, damage wise < 1767041766 414751 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :I don't know, I'm asking you. "superusers" can inspect or attack anything that happens by processes making syscalls, because they can inject syscalls into any process < 1767041841 478660 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(ptrace will be more effort) < 1767041845 662461 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I don't really like that they had to put everything into namespaces like that; my own system design does not have any namespaces (and does not have file names). < 1767041937 857719 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :Having global namespaces will have problems in my opinion; however, a program can implement a namespace if it is useful for that program, and can allow other programs to access it < 1767042173 464615 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :korvo: you can create PF_UNIX sockets on the file system, in which case on linux you can only access them through the controlling directory, so the permissions and file system namespacing of the directory can restrict it. < 1767042216 908809 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :but the other partthat you said may be an advantage of message queues < 1767042290 528585 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :Creating unix sockets (and other stuff) in the file system is sometimes useful (even though a single global name space has some problems in my opinion), and my own "scorpiond" program takes advantage of this as an alternative of CGI programs (which has some advantages over CGI programs). < 1767042451 159189 :impomatic!~impomatic@2a00:23c7:5fc6:3201:113c:fa9f:2a7d:97ef QUIT :Quit: Client closed < 1767042694 855359 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :About ais523's article: "T&T is equivalent to just a single T (it's an object that can be consumed as either a T or a T and the choice doesn't matter)" Does it doesn't matter, or could there be multiple views of the same type? (Rust and other programming languages might not be able to do that, but I mean theoretically) < 1767042786 284454 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: my understanding is that there are quite a few capabilities that are able, via one means or another, to break down security barriers in a way that makes anything possible; I suspect that both DAC override and ptrace are able to do that < 1767042803 313156 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: Yeah, that's definitely worth doing as well. I think that a good capability system for Unix will have all of these fine-grained defenses as part of a multi-layered strategy. < 1767042824 718837 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :sorear: Oh, I was ready to learn a new joke. I guess that Linux capabilities are an old joke! < 1767042845 447014 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :what sucks is that the interesting properties are all emergent. DAC_OVERRIDE hurts much more if you have or can mount a procfs; SYS_PTRACE is pretty harmless if everyone has their own pidns < 1767042888 52224 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I was recently saying that Linux caps should be thought of as a *bitset* of flags; root has the full bitset, most users have the empty bitset, and there's ways to incrementally alter it. A Linux process may be *partially* root. https://lobste.rs/s/vp1zbg/tier_list_linux_security_mechanisms_2024#c_hbtrtq < 1767042962 523008 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It does suck that Linux has almost no path towards deprecating some of the older caps. I think it's worth doing what Wayland did instead, with hosting Xorg servers as a Wayland client. I recently was looking at L4Linux to see if Linux-on-L4 is still an easy thing. < 1767042984 73182 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I think that isn't the best security mechanism, although having read the man page I would also have thought of working like bitsets (although these capabilities are too coarse for many uses). < 1767043165 340727 :somefan!~somefan@208.58.192.69 JOIN #esolangs * :[https://web.libera.chat] somefan > 1767043280 148482 PRIVMSG #esolangs :14[[07Talk:CLC-INTERCAL14]]4 10 02https://esolangs.org/w/index.php?diff=171581&oldid=122864 5* 03Tpaefawzen 5* (+188) 10/* Author is gone again! (2025-12) */ new section < 1767043780 817619 :ursa-major!114efe6c39@2a03:6000:1812:100::11f3 QUIT :Ping timeout: 246 seconds < 1767043895 759547 :dcreager!a9e780c4d1@2a03:6000:1812:100::136b QUIT :Ping timeout: 245 seconds < 1767043920 772615 :ManDeJan!3da94070ba@user/mandejan QUIT :Ping timeout: 245 seconds < 1767044067 418291 :dcreager!a9e780c4d1@2a03:6000:1812:100::136b JOIN #esolangs dcreager :Douglas Creager < 1767044068 533398 :ManDeJan!3da94070ba@user/mandejan JOIN #esolangs ManDeJan :ManDeJan < 1767044094 510866 :ursa-major!114efe6c39@2a03:6000:1812:100::11f3 JOIN #esolangs ursa-major :Bailey Bjornstad < 1767045200 51637 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :zzo38: hmm, I guess you can imagine an object that can be viewed as a T in two different ways, but then you run into the question of what aspect of the programming language the type theory is trying to model < 1767045288 396745 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Rust specifically solves this problem by treating a particular way in which an object can be viewed as having a type as being a type in its own right, e.g. u32 is an unsigned 32-bit integer type where >= is a greater-than-or-equals operation, and Reverse is an unsigned 32-bit integer type where >= is a less-than-or-equals operation < 1767045308 265112 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :u32 can be viewed as being an Ord in (at least) two different ways, but Rust gives the two views different names < 1767045472 461314 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :OK, that makes sense. Rust is not a programming language that I am very familiar with, but I have some familiarity with Haskell and a similar thing can be done with implementing a class differently by making it a different type (because e.g. there are many monoids that can be made from a type, including reversing the existing one) < 1767048559 491117 :tromp!~textual@2001:1c00:3487:1b00:6867:e45a:c028:8b87 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… > 1767049094 458992 PRIVMSG #esolangs :14[[07Language list14]]4 M10 02https://esolangs.org/w/index.php?diff=171582&oldid=171563 5* 03Buckets 5* (+12) 10/* Q */ < 1767049098 724613 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname > 1767049132 160932 PRIVMSG #esolangs :14[[07User:Buckets14]]4 M10 02https://esolangs.org/w/index.php?diff=171583&oldid=171522 5* 03Buckets 5* (+11) 10 > 1767049150 792224 PRIVMSG #esolangs :14[[07Quate14]]4 N10 02https://esolangs.org/w/index.php?oldid=171584 5* 03Buckets 5* (+1092) 10Created page with "Quate is an Esoteric Programming language created by [[User:Buckets]] In 2021. {| class="wikitable" |- ! Commands !! Instructions |- | * || Push third Top value * -2. |- | ! || Goto Coordinates 0, 0. |- | < || If the Second Top value has A negative Or Positive sign, Copy > 1767049338 376521 PRIVMSG #esolangs :14[[07EtomemoteetomemoteetomemoteetomemotE14]]4 10 02https://esolangs.org/w/index.php?diff=171585&oldid=171580 5* 03A() 5* (+3020) 10 > 1767049412 75229 PRIVMSG #esolangs :14[[07Hello world program in esoteric languages (D-G)14]]4 10 02https://esolangs.org/w/index.php?diff=171586&oldid=171567 5* 03A() 5* (+1555) 10/* EtomemoteetomemoteetomemoteetomemotE */ < 1767049527 213030 :somefan!~somefan@208.58.192.69 QUIT :Quit: Client closed