< 1755648497 465779 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Remote host closed the connection < 1755648600 9078 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :!zjoust medium http://nethack4.org/pastebin/medium.bfjoust < 1755648600 378328 :zemhill!bfjoust@selene.zem.fi PRIVMSG #esolangs :ais523.medium: points 10.38, score 33.76, rank 5/47 (--) < 1755648786 668817 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord > 1755649075 546432 PRIVMSG #esolangs :14[[07User:DumbEsolangsOrgUser14]]4 10 02https://esolangs.org/w/index.php?diff=163637&oldid=163613 5* 03DumbEsolangsOrgUser 5* (+33) 10 < 1755649177 575832 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :!zjoust medium http://nethack4.org/pastebin/medium.bfjoust < 1755649177 801854 :zemhill!bfjoust@selene.zem.fi PRIVMSG #esolangs :ais523.medium: points 10.67, score 34.09, rank 5/47 (--) < 1755649632 306679 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine > 1755649824 891715 PRIVMSG #esolangs :14[[07Dumbascii-214]]4 10 02https://esolangs.org/w/index.php?diff=163638&oldid=163617 5* 03DumbEsolangsOrgUser 5* (+787) 10/* Language Overview */ < 1755649836 895782 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord > 1755649851 151929 PRIVMSG #esolangs :14[[07Dumbascii-214]]4 10 02https://esolangs.org/w/index.php?diff=163639&oldid=163638 5* 03DumbEsolangsOrgUser 5* (+2) 10/* Python IDE */ < 1755650555 237751 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :!zjoust medium http://nethack4.org/pastebin/medium.bfjoust < 1755650555 449895 :zemhill!bfjoust@selene.zem.fi PRIVMSG #esolangs :ais523.medium: points 10.76, score 34.29, rank 5/47 (--) < 1755651873 949631 :ski!~ski@remote11.chalmers.se QUIT :Ping timeout: 245 seconds > 1755652195 279785 PRIVMSG #esolangs :14[[07BadEsolangIMadeForABet14]]4 N10 02https://esolangs.org/w/index.php?oldid=163640 5* 03Mouldyair 5* (+3023) 10created page for BEIMFAB < 1755652734 965219 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :!zjoust medium http://nethack4.org/pastebin/medium.bfjoust < 1755652735 190505 :zemhill!bfjoust@selene.zem.fi PRIVMSG #esolangs :ais523.medium: points 11.26, score 34.79, rank 5/47 (--) < 1755652748 268734 :ski!~ski@remote11.chalmers.se JOIN #esolangs * :Stefan Ljungstrand < 1755652766 766822 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.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 < 1755653076 262895 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :!zjoust medium http://nethack4.org/pastebin/medium.bfjoust < 1755653076 445683 :zemhill!bfjoust@selene.zem.fi PRIVMSG #esolangs :ais523.medium: points 11.29, score 34.82, rank 5/47 (--) < 1755653641 533277 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :!zjoust medium http://nethack4.org/pastebin/medium.bfjoust < 1755653641 765764 :zemhill!bfjoust@selene.zem.fi PRIVMSG #esolangs :ais523.medium: points 11.57, score 35.26, rank 5/47 (--) < 1755653796 859067 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca QUIT :Ping timeout: 272 seconds < 1755654346 566311 :ais523!~ais523@user/ais523 QUIT :Quit: quit < 1755654841 302843 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca JOIN #esolangs zzo38 :zzo38 < 1755658989 199096 :chloetax!~chloe@user/chloetax QUIT :Quit: Leaving < 1755659011 330932 :chloetax!~chloe@user/chloetax JOIN #esolangs chloetax :chloe < 1755659204 865686 :Lymia!~lymia@lilac.servers.aura.moe QUIT :Server closed connection < 1755659217 331439 :Lymia!~lymia@lilac.servers.aura.moe JOIN #esolangs Lymia :Lymia Aluysia > 1755660744 176521 PRIVMSG #esolangs :14[[07Gur yvsr14]]4 M10 02https://esolangs.org/w/index.php?diff=163641&oldid=163610 5* 03Placeholding 5* (+5) 10 < 1755663658 454391 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1755663673 195921 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :!zjoust medium http://nethack4.org/pastebin/medium.bfjoust < 1755663673 447032 :zemhill!bfjoust@selene.zem.fi PRIVMSG #esolangs :ais523.medium: points 12.55, score 37.03, rank 5/47 (--) < 1755664546 668509 :ais523!~ais523@user/ais523 QUIT :Quit: quit < 1755667103 844248 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer < 1755668973 606611 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I read about the Legasm and I think of some things that could be done differently if I would be designing it better. The flag register seems only used for carry, so now it will be the carry register instead, set to 1 or 0 by addition and to -1 or 0 by subtraction, and the ones the adc and sbb will add the previous value of the carry register to the result. < 1755669104 836754 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :For the insrtuctions that sign-extend immediate values, I would just have it automatically set all of the high bits regardless of the value, since otherwise you could use the unsigned variants if the value to set is a constant anyways. < 1755669335 83148 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I would also think to add instructions for multiplication and division, and for rotate through carry, and to have two stacks. (The push and pop instructions currently have many unused bits, so possibly some of them can be used to select any arbitrary register to use for the stack pointer.) < 1755669475 36841 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :(The existing stack pointer can be used for subroutine calls.) > 1755669663 856263 PRIVMSG #esolangs :14[[07Pigs14]]4 10 02https://esolangs.org/w/index.php?diff=163642&oldid=163340 5* 03Corbin 5* (+14) 10Remove undiscussed category. See also Deadfish, a likely influence. < 1755670651 167857 :user3456!user3456@user/user3456 QUIT :Ping timeout: 252 seconds > 1755670693 443248 PRIVMSG #esolangs :14[[07(piggus)14]]4 10 02https://esolangs.org/w/index.php?diff=163643&oldid=162824 5* 03Corbin 5* (+301) 10Fix categories. Refactor to emphasize that this is a TBS. < 1755674279 340261 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :strerror: thank you, I tried xinput --test-xi2 , and it does seem like I get subpixel precision mouse coordinates when I move the mouse slowly to not trigger mouse acceleration. I don't get much more precision than a pixel, but that of course can depend on the mouse and the speed setting, so I'm fine with that. < 1755675251 65881 :strerror!~strerror@user/strerror PRIVMSG #esolangs :b_jonas: Did it have temporal precision as well? (I'm not sure if xinput can determine this, you might need to do the mouse query in a tight loop) > 1755675548 892308 PRIVMSG #esolangs :14[[07OBrainfuck14]]4 N10 02https://esolangs.org/w/index.php?oldid=163644 5* 03L4.m2 5* (+481) 10Created page with "oBrainfuck is like brainfuck but the k-th [ matches the k-th ]. aka, the k-th [ matches in C goto Rk;Lk: and the k-th ] matches in C Rk:if(*cur)goto Lk;.+-<>,. work same. Thus, < 1755677176 436231 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :strerror: I don't know, with those arguments it's not printing any timestamps so it's slightly more tricky to test for that and I haven't tried yet, and I'm not familiar with xinput in general > 1755677196 802119 PRIVMSG #esolangs :14[[07Algebraic Brainfuck14]]4 10 02https://esolangs.org/w/index.php?diff=163645&oldid=145100 5* 03Corbin 5* (+615) 10Fix capitalization. Update bluelinks. Stub a section on computability. < 1755677543 971824 :APic!apic@chiptune.apic.name PRIVMSG #esolangs :Hi * < 1755680343 729382 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Morning. > 1755680793 764007 PRIVMSG #esolangs :14[[07Computable14]]4 10 02https://esolangs.org/w/index.php?diff=163646&oldid=163203 5* 03Corbin 5* (+3689) 10Sketch the Diophantine path. This wasn't part of my education and I'm going to have to do a lot of reading in order to shore it up; nonetheless this captures the important bits. < 1755680859 24898 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I'm gonna have to sleep on this new section. Rice's theorem (and Gödel's first incompleteness) are very weird-tasting for Diophantine equations. < 1755680943 659737 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Pick a sufficiently-strong language of arithmetic. Its set of proofs is Diophantine. Its set of WFFs is Diophantine. Its set of provable WFFs is *not* Diophantine; that's Rice's theorem! So there's a way to pen-and-paper all of the proofs that are valid, but not all of the provable statements. > 1755682040 966539 PRIVMSG #esolangs :14[[07Algebraic Brainfuck14]]4 10 02https://esolangs.org/w/index.php?diff=163647&oldid=163645 5* 03Corbin 5* (+841) 10/* Computability */ A new approach to Halting for BF: BF can encode Diophantine searches! No input or output commands needed, just a pre-allocated output register. > 1755682156 719343 PRIVMSG #esolangs :14[[07Brainfuck14]]4 M10 02https://esolangs.org/w/index.php?diff=163648&oldid=156122 5* 03RixTheTyrunt 5* (+262) 10/* Truth-machine */ < 1755686071 830474 :strerror!~strerror@user/strerror PRIVMSG #esolangs :Perhaps the wiki could link to oddball, counter-intuitive (and in that sense *esoteric*) characterizations of RE < 1755686099 325518 :strerror!~strerror@user/strerror PRIVMSG #esolangs :Like Demaine & Hearn's game (a finite multiplayer game with finite hidden information at each turn), or the claimed proof of MIP*=RE (https://scottaaronson.blog/?p=4512) < 1755686176 438917 :strerror!~strerror@user/strerror PRIVMSG #esolangs :There have also been attempts to disprove the Navier-Stokes smoothness conjecture by constructing zeno machines in the model, though none have worked yet < 1755686867 365437 :tromp!~textual@2001:1c00:3487:1b00:9c04:acc7:66ee:fca9 JOIN #esolangs * :Textual User < 1755688508 980276 :tromp!~textual@2001:1c00:3487:1b00:9c04:acc7:66ee:fca9 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1755688684 144220 :tromp!~textual@2001:1c00:3487:1b00:9c04:acc7:66ee:fca9 JOIN #esolangs * :Textual User > 1755688734 51248 PRIVMSG #esolangs :14[[07GolfScratch14]]4 M10 02https://esolangs.org/w/index.php?diff=163649&oldid=141449 5* 03Ractangle 5* (+488) 10/* External links */ > 1755688748 249677 PRIVMSG #esolangs :14[[07GolfScratch14]]4 M10 02https://esolangs.org/w/index.php?diff=163650&oldid=163649 5* 03Ractangle 5* (+1) 10/* External links */ < 1755689100 636220 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1755689136 870702 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 272 seconds < 1755689180 877182 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 NICK :Lord_of_Life < 1755689385 104837 :tromp!~textual@2001:1c00:3487:1b00:9c04:acc7:66ee:fca9 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1755694412 116364 :tromp!~textual@2001:1c00:3487:1b00:9c04:acc7:66ee:fca9 JOIN #esolangs * :Textual User < 1755694674 364789 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net JOIN #esolangs amby :realname > 1755696003 310811 PRIVMSG #esolangs :14[[07Espaol14]]4 10 02https://esolangs.org/w/index.php?diff=163651&oldid=81407 5* 03MijiGamin1 5* (-18) 10fixed beginning sentence < 1755700352 985203 :tromp!~textual@2001:1c00:3487:1b00:9c04:acc7:66ee:fca9 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1755700435 687789 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine < 1755700944 231831 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1755705987 346623 :tromp!~textual@2001:1c00:3487:1b00:9c04:acc7:66ee:fca9 JOIN #esolangs * :Textual User < 1755706388 172145 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) > 1755708110 77103 PRIVMSG #esolangs :14[[07Dumbascii-214]]4 10 02https://esolangs.org/w/index.php?diff=163652&oldid=163639 5* 03DumbEsolangsOrgUser 5* (+85) 10 < 1755708214 851708 :tromp!~textual@2001:1c00:3487:1b00:9c04:acc7:66ee:fca9 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… > 1755708409 393721 PRIVMSG #esolangs :14[[07User:ChuckEsoteric0814]]4 10 02https://esolangs.org/w/index.php?diff=163653&oldid=163624 5* 03ChuckEsoteric08 5* (+12) 10/* 2024 */ < 1755708555 334960 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine < 1755708801 239600 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1755709038 484814 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Client Quit < 1755709238 305277 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1755709402 662435 :gAy_Dragon!A_D@libera/staff/dragon NICK :Awoobis < 1755709456 4511 :Awoobis!A_D@libera/staff/dragon NICK :gAy_Dragon < 1755711003 940200 :tromp!~textual@2001:1c00:3487:1b00:9c04:acc7:66ee:fca9 JOIN #esolangs * :Textual User < 1755714935 941693 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :is there a general name for the type of garbage collector that looks through memory to determine what's unreferenced (e.g. mark/sweep, generational, compacting), as opposed to things like reference counting which can also be considered a form of garbage collection? < 1755715261 753163 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :"tracing", from "A unified theory of GC" https://courses.cs.washington.edu/courses/cse590p/05au/p50-bacon.pdf < 1755715450 201922 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: ah, that makes sense – I have heard the terminology before but forgot < 1755715503 858979 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: No worries. The unified theory is not even a decade old and we live in an industry that actively spreads misinformation about GC; it takes a lot of active effort to just kind of remember that this exists, and I had to dig for a few minutes to find it. < 1755715616 715081 :FreeFull!~freefull@79.186.58.23.ipv4.supernova.orange.pl QUIT :Quit: Lost terminal < 1755715660 860776 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: although I'm not surprised about the misinformation, I don't think I've been on the receiving end of it much < 1755715665 45 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :what sort of things does the industry say? < 1755715693 570194 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :GC is slow, interrupting, unmanageable, requires tuning, etc. < 1755715746 430927 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fwiw I suspect that the "correct" way to do things is some sort of mixture where some things are GCed and other things have their allocation and deallocation times statically calculated and proven at compile time < 1755715798 564268 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Sure. RPython has an explicit malloc-removal phase at compile time along with a choice of hybrid GCs at runtime, and all evidence suggests that this is the right direction. < 1755715813 787561 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :generational GCs existing is kind-of ridiculous from my point of view, because it's an optimisation to easily clean up the short-lived objects – but usually you can statically determine from the program when the short-lived objects need deallocating, and it is the long-lived objects which are more interesting to GC < 1755715826 911193 :tromp!~textual@2001:1c00:3487:1b00:9c04:acc7:66ee:fca9 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1755715866 322563 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there usually seems to be about a 10× speedup when people port from GCed languages to Rust, but I suspect the speedup may be based more on the static typing than the lack of GC < 1755715893 655026 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :"Using [the BCR] framework, [BCR] show that all high-performance collectors are in fact hybrids of tracing and RC'ing. ...[The BCR cost model] allows the correct scheme to be selected based on ... performance requirements and the ... properties of the ... application." < 1755715921 222603 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although they probably exist, I can't think offhand of any widely used languages which a) are GCed and b) have non-primitive types that are sufficiently static to optimise the generated code based on knowledge of the type < 1755715953 348730 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :OCaml? OCaml, Haskell, and RPython are all environments where GC is part of how I expect to reliably beat Rust on speed. < 1755716007 416870 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, I actually don't know that much about ocaml's internals, except for the "everything is either a pointer or an integer with one reserved bit" thing < 1755716010 513922 :JAA!~JAA@user/meow/JAA QUIT :Server closed connection < 1755716020 949825 :JAA!~JAA@user/meow/JAA JOIN #esolangs JAA :JustAnotherArchivist < 1755716028 776801 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(with the reserved bit being used to distinguish integers from pointers in memory so that a GC can trace them without having to know the types) < 1755716089 584997 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :My perspective is likely skewed. I see the C++ memory model that Rust inherited as a big speed barrier. Fortran's memory model is better, but both Haskell's lazy model and OCaml's strict model (or Cammy or other CAM-likes) have their own further advantages. < 1755716120 959972 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Rust only shares C++'s memory model with respect to atomics/multithreading, I think – they're different in other respects < 1755716145 500981 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah, at the value level, OCaml values are just tagged. I don't know of a good writeup, but CHICKEN Scheme uses almost the same setup and there's a great post on that: https://www.more-magic.net/posts/internals-data-representation.html < 1755716229 74979 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :my thoughts on all this are along the lines of "it is definitely possible to do better than Rust, but I think I have to really understand Rust first in order to beat it" < 1755716258 55882 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think C may also be beatable (for code written idiomatically), primarily through compiler optimisations that wouldn't be valid in C < 1755716311 380839 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :err, I meant "via" rather than "through" I think, English is hard sometimes < 1755716340 3723 :tromp!~textual@2001:1c00:3487:1b00:9c04:acc7:66ee:fca9 JOIN #esolangs * :Textual User < 1755716591 176417 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :English doesn't have an instructive case so we have to try to fake it using prepositions < 1755716872 873432 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :My experience is from Python-driven HPC, so maybe this is not something you've seen before, but IMO the atomics and multithreading *are* the issue. Suppose we have an embarrassingly-parallel for-loop and we're using something like OpenMP. When the compiler is optimizing blocks, it has to determine whether any pointers in the block are used elsewhere, because it needs to know whether it can safely remove loads/stores. < 1755716880 916698 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Fortran < 1755716900 37805 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :*Fortran's memory model is better than C's model. It straight-up doesn't permit as much aliasing. < 1755717389 773272 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: nor does Rust's < 1755717494 321380 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :e.g. unless you use a type that is explicitly defined as a special case, function arguments that are references cannot alias with each other unless they are read-only, but the assumption that something is not aliased is less powerful than an assumption that it is read-only < 1755717549 673686 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :rustc puts an LLVM "noalias" attribute on every function argument (that isn't a defined special case or raw pointer) because of that, which is the same thing that Fortran's memory model lets you do < 1755717612 333821 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the guarantees for things that aren't function arguments are complex and not fully decided yet – I have been writing a blog post about it, it's the same blog post where I discuss how linear logic's ? seems to be present in Rust) < 1755717644 677342 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but, LLVM only knows how to optimise based on non-aliasing assumptions for function arguments, because C and Fortran only have them in that location < 1755717670 577505 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(to be precise: they don't alias each other nor alias global variables, that's true for Rust and for C restrict, I am not sure about Fortran but it probably has the same rule) < 1755717697 380282 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and don't alias memory reached via each other either < 1755717730 756503 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah. Rust or e.g. Pony extend Fortran's approach by making it possible to have immutable objects, so that we *don't care* if they're aliased. If all the threads want to access some constant input data, then those accesses can be optimized away sometimes. < 1755717773 73060 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right < 1755717810 672764 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :anyway, atomics are one of those special-cased that are allowed to be aliased – they wouldn't be very useful otherwise > 1755718013 351212 PRIVMSG #esolangs :14[[07Onlydot14]]4 N10 02https://esolangs.org/w/index.php?oldid=163654 5* 03DumbEsolangsOrgUser 5* (+374) 10Created page with "{{lowercase}} {{wip}} :'''Onlydot' writing in full in lower case, excepting start of proposal.'' '''[[onlydot]]''' is [[:Category:Joke languages| joke]] [[esoteric programming language]] where valid command is only .. =Language overview= onlydo > 1755718041 880476 PRIVMSG #esolangs :14[[07User:DumbEsolangsOrgUser14]]4 10 02https://esolangs.org/w/index.php?diff=163655&oldid=163637 5* 03DumbEsolangsOrgUser 5* (+4) 10/* Newest Esolang */ > 1755718080 941063 PRIVMSG #esolangs :14[[07User:DumbEsolangsOrgUser14]]4 10 02https://esolangs.org/w/index.php?diff=163656&oldid=163655 5* 03DumbEsolangsOrgUser 5* (+15) 10/* O */ < 1755718219 77948 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yes, definitely. But maybe atomics aren't necessary. < 1755718299 186653 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :In Monte, there aren't any atomic variables. Instead, everything is serialized into "turns", which are single deliveries of single events to a single thread. Any cross-thread communication is done via the same generic IPC mechanism as cross-machine communication: promises! < 1755718350 966313 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think atomics are mostly only necessary in cases where you need blocking-free algorithms, i.e. a guarantee that any given thread can make progress even if all others are paused < 1755718366 723993 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :To let threads share starting data, each thread can be given a transitively-immutable object. Incidentally, Monte modules are transitively immutable at import time. After that, they have to send messages asynchronously to communicate. < 1755718397 737491 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :signal handlers are a notable example of that, because they block the thread to which the signal was sent < 1755718433 57073 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :"how do you allocate memory from a signal handler" has been a longstanding area of interest for me, existing programming frameworks make it unreasonably difficult and yet it is a potentially useful thing to do < 1755718460 160687 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(at least, it's unreasonably difficult if you want to be able to deallocate the memory again, from outside the handler) < 1755718554 665195 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :signalfd makes it straightforward on Linux. Taming signals is historically a nasty thing, and if it weren't for signalfd then I wouldn't have bothered at all. < 1755718855 516439 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: So, one other nice thing about any sort of referentially-transparent machine, whether it's lazy or strict, is that *any* algebraic optimizations are valid when inlining. SML/NJ, OCaml, GHC, and other popular compilers all have some sort of straight-line monomorphic detection phase that "strictifies" or "destackifies" with respect to that algebra. < 1755718938 544292 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I don't know exactly how referentially transparent Rust is. I hear that LLVM Rust is already starting to be sensitive to phase ordering in LLVM, which is not a good sign. < 1755719041 356507 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :ais523: You can just call mmap, right? < 1755719425 981471 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :shachaf: I was allocating small things, but I guess that *would* work < 1755719501 428153 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: Rust feels like it's kind-of sort-of meant to be referentially transparent but a lot of things break that in practice < 1755719547 487653 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :unsafe code allows you to do a lot of things that seem like the memory model shouldn't allow them, and yet it continues to be supported because it would break too much code if it wasn't < 1755719573 374442 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Okay, good to hear. Or bad to hear, but good for my expectations. Or bad for my expectations because I shouldn't be so cynical... < 1755719616 298896 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I suppose that the flip side of this is that there's thousands of lines of Monte code that merely reimplement standard floating-point routines because there wasn't a safe way to get those routines from existing C/C++ code. < 1755719618 103221 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one thing I realised while working on the ? blog post is that the standard traits Clone and Debug can both be meaningful for both a) smart pointers and b) the objects they point to < 1755719634 447127 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but, for Clone you usually want to clone the pointer itself and for Debug you usually want to debug the value inside < 1755719715 763437 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and I think this is a design flaw – it feels like Rust wants a rule "implementing a trait on a value also implements it on smart pointers to that value", which means that Clone and Debug should probably really be CloneAs and DebugAs that let you specify which level of indirection you want to clone at or debug at < 1755719765 835477 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :("feels like" is partly just feelings, but also partly soundness bugs that have come about as a consequence of people not realising that a custom reference (smart pointer) type and the object it points to could implement the same standard trait in entirely unrelated ways) < 1755719786 754149 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Right. Move semantics suddenly imply subtyping rules, somehow. < 1755719818 65361 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I don't think this is actually based on the move semantics, it's a different aspect of the language design and one that I don't think is as fundamental < 1755719892 320003 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although, I'm also not sure the Deref/DerefMut traits know what they actually are – they have a defined API but it is less clear what they actually *mean*, in terms of what assumptions you can make when using that API < 1755719901 64151 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :In Monte, m`def x :T := z` desugars to roughly m`def &&x := makeBinding(T.coerce(z, null), makeFinalSlot(T))`. There are exactly two levels of underlying indirection (slot and binding) and they may only be captured or introspected in order to facilitate that .coerce/2 method. < 1755719914 422404 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(other than "you can't make any assumptions because they are safe to implement with arbitrary code, thus anything that isn't guaranteed by the API isn't guaranteed by the compiler") < 1755719986 989789 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :This is another surprising limitation of C-style memory management: being able to take a pointer of a pointer *of a pointer* is too much; at some point, you're going to take a pointer into Somebody Else's Memory that you are borrowing for stack/locals. < 1755720036 448851 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is the whole Three Star Programmer thing that I named the language after, isn't it? < 1755720057 527458 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :In E or Monte, if x is a local name then `x` dereferences, `&x` gets the slot, and `&&x` gets the binding. There isn't a generic operator & which takes any value; it must be a name in scope, so `&42` doesn't do anything. < 1755720066 56814 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I think so! < 1755720100 621497 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in Rust you can use the borrow operator & on anything, if necessary it creates a temporary and gives you a reference to that < 1755720119 965956 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can write &&&42 and get a reference to a reference to a reference to 42 < 1755720129 389678 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I am not sure I agree with this < 1755720168 387396 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :We have the same ergonomics. m`var x := whatever; f(&x)` will pass a mutable slot, and m`def f(&x) { x += 5; ... }` accepts the mutable slot and sets it up in the local scope as something that can be mutated with augmented assignments. < 1755720169 927082 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the program will be rejected if the compiler can't make the reference live long enough, but there are at least two ways in which the lifetime of the reference can be extended, so it works in more cases than it looks like it sohuld be able to) < 1755720231 323255 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one of the things I dislike most about Rust is how much it does that's implicit in the syntax, in order to try to make the program meaningful < 1755720234 819276 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can write it explicitly but usually don't < 1755720291 546528 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in particular, pattern matches have a whole lot of dereferencing and referencing added implicitly – you can be explicit but usually aren't – and I basically end up relying on compiler error messages to work out what is or isn't a reference when working with htem < 1755720392 753625 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah, me too. < 1755720753 545885 :user3456!user3456@user/user3456 JOIN #esolangs user3456 :user3456 < 1755720955 830850 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: thanks for your earlier link to the paper about how to hybridise tracing and reference counting – the content feels like information that is beneficial for me to know < 1755720989 651231 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: No biggie. It made a big splash in the JIT world a few years ago but doesn't seem to have become more popular. < 1755724303 991103 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"Rust only shares C++'s memory model with respect to atomics/multithreading, I think" => also in that both allow memory to be in an uninitialized state where it's UB to read even as a type like uint8_t where any combination of bits is valid, even when writing the same memory would be fine < 1755724507 707651 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :in both C++ and rust if a vector allocates memory with more capacity than size, the memory will be in that uninitialized state, and the program has to make sure to initialize it before use > 1755724605 1673 PRIVMSG #esolangs :14[[07Maybegolf14]]4 N10 02https://esolangs.org/w/index.php?oldid=163657 5* 03DumbEsolangsOrgUser 5* (+144) 10Created page with "{{Wip}} [[Maybegolf]] is [[esoteric programming language]] for golf, emphasis on the multitude of commands and the unification of some into one." < 1755724843 754507 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I think that you can get uninitialized memory in GHC Haskell if you ask for it, with some sort of primitive Array type. It's not possible in Monte or Pony though. < 1755724883 861844 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :E and Monte actually have some determinism requirements. E never quite figured out randomness and Monte requires it to be passed around like an RNG monad. > 1755725040 776483 PRIVMSG #esolangs :14[[07Computable14]]4 10 02https://esolangs.org/w/index.php?diff=163658&oldid=163646 5* 03Corbin 5* (+948) 10/* Via Diophantine equations */ Define Diophantine equations and sets. I need to figure out whether listability (effective enumerability) and Davis normal form need to be mentioned here. < 1755726121 488958 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : also in that both allow memory to be in an uninitialized state where it's UB to read even as a type like uint8_t where any combination of bits is valid, even when writing the same memory would be fine ← so although Rust and C++ both do that, the rules are actually different! < 1755726149 16263 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in C++, memory that is initialised using an object of one type can't be read through a pointer of a different type < 1755726163 789221 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so memory isn't just initialised, it's initialised with a particular type < 1755726183 439097 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Rust's rule is different, memory that has been initialised using any type can be read using any other type that can hold the same range of values, except for padding bytes < 1755726194 375687 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so, e.g., Rust lets you read the second byte of a float as u8 and C++ doesn't < 1755726219 384054 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this means that C++ needs a special case for "the type that memcpy uses to copy bytes around" < 1755726226 262329 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :whereas Rust can just use u8 < 1755726271 393864 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :" I think atomics are mostly only necessary in cases where you need blocking-free algorithms" => I think there's at least one more use case. Suppose you have a lot of small objects that are rarely shared and rarely written, but you can't prove that they aren't shared so you have to use some thread-safety for them. An inter-thread mutex in every object would be logical, but as the objects are < 1755726277 807289 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :small it would consume more memory and might even use more bandwidth to the memory shared between cpu threads, so accessing the objects atomically is probably better. < 1755726277 844160 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the difference leads to some interesting consequences sometimes, e.g. in Rust's model it matters whether bytes are part of a pointer or not, so if you, e.g., reverse the bytes in a pointer by reading them as u8, then reverse them again, there's some issue with whether you're allowed to read from the resulting pointer or not < 1755726280 809694 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :But I'm not really sure about this. < 1755726285 906640 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think the answer changed to "you aren't" to "you are" recently < 1755726294 222622 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* changed from "you aren't" to "you are" < 1755726372 883186 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: ah, so C++ has more complicated rules about what memory counts as uninitialized. true. I don't understand those rules much because they don't come up often in practice. < 1755726379 370485 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :at least not in the code that I write. < 1755726402 652440 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: occasionally I need to type-pun and have to remember the legal way to do that < 1755726424 465140 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in C, I believe that memcpy is sufficient, as long as you memcpy the actual bytes you are reinterpreting and not a pointer to them < 1755726451 412312 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in Rust, transmuting a pointer is sufficient (and transmuting a reference is OK as long as you match size and alignment and lifetime) < 1755726522 378581 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: yeah < 1755726704 529113 :callforjudgement!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1755726718 267388 :ais523!~ais523@user/ais523 QUIT :Ping timeout: 256 seconds < 1755726783 412693 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: re Deref/DerefMut, yes, I don't think there's much semantics they're supposed to represent, so you'd rarely write code that's generic over the trait. those traits are there to allow user code to define new types that can use a syntactic sugar of omitting the splat when you're calling a method. it's sort of like the Mul trait, which is there so you can define new types that can use the infix * < 1755726789 420230 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :operator for syntactic convenience, not because there's some general semantics that all Mul types satisfy. < 1755726842 185537 :callforjudgement!~ais523@user/ais523 NICK :ais523 < 1755726867 690563 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: is that a generic "you"? I personally would write such code but I may be the only person who does < 1755726949 833338 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :" In E or Monte, if x is a local name then `x` dereferences, `&x` gets the slot, and `&&x` gets the binding. There isn't a generic operator & which takes any value" => is that like perl package variables where you can use $x by value, use $x by reference (including assigning to it), or use *x by reference, but you can't go deeper. < 1755726952 213871 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :https://github.com/rust-lang/rust/issues/129147#issuecomment-3026624324 < 1755727000 526614 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: yes, generic you < 1755727036 614766 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the link is me arguing that method receivers that are generic over Deref should be allowed, with caveats, and explaining why I want it) < 1755727060 355658 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :unfortunately I have to post it on Github because that's where Rust's issue tracker is < 1755727392 809779 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"Rust lets you read the second byte of a float as u8" => not really related to the memory models, but fortunately Rust added a safe high-level wrapper for that now. and you might need to use it because the standard library still doesn't have a frickin' ldexp/scalbn or frexp/ilogb builtin. nor good ways to strigify floats for that matter. < 1755727633 632888 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :though float/int transmutes are an important enough special case that the library functions are worth it for other reasons even if you have a working ldexp/frexp like in C++ < 1755727672 150071 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: Same sort of idea, I think, yes. I don't fully understand the whole Perl/PHP way of looking up names; there's probably a piece of history that I don't know. < 1755727683 678878 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, float/int transmutes are in the standard library (and safe), I was quite impressed when I saw them < 1755727693 636930 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I want to use them for serializing floats, manipulating nans, and more < 1755727695 416213 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :But E does heavily borrow from Perl. Some of E's pattern matching comes from the =~ operator, for example. < 1755727720 363318 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :korvo: piece of history => yes < 1755727747 698771 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I even used them recently, except that I was writing a C program so I had to do the transmute with memcpy instead < 1755727790 453857 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the context was a "how many digits are there in this integer" function, which was being used in memory allocation code that calculated how long a string would eventually be when formatted) < 1755727805 301962 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :korvo: anyway, even for perl lexically local variables where that history isn't relevant, you can take a reference to such a local variable, but taking a reference to a reference isn't very useful, you'd just get a reference to a temporary and that temporary would be different each time < 1755727831 412394 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in Rust, you can't normally ==-compare things unless they have the same level of indirection < 1755727856 619938 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so when you end up with a double indirection (e.g. when iterating over a list of references without consuming it), you often end up with code like |x| x = &&6 < 1755727890 192694 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there are various ways to avoid this situation happening but sometimes the double reference is the most obvious way to express it < 1755727899 166762 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(this is, of course, another way in which Rust fails at referential transparency) < 1755727920 953987 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :of course, in C++, prefix && has a different meaning to two prefix &s < 1755728775 109106 :tromp!~textual@2001:1c00:3487:1b00:9c04:acc7:66ee:fca9 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1755731416 527428 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname > 1755734223 707230 PRIVMSG #esolangs :14[[07Crazy?14]]4 N10 02https://esolangs.org/w/index.php?oldid=163659 5* 03Mouldyair 5* (+38979) 10Created page with "{{Wrongtitle|title=Crazy? I was crazy once. They locked me in a room. A rubber room. A rubber room with rats. And rats make me crazy.Crazy? I was crazy once. They locked me in a room. A rubber room. A rubber room with rats. And rats make me crazy.Crazy? I was crazy on