**i*i*ii***i*i*i*ii***i*i*i*ii***i*i*i*ii*i*i*ii*i*i*ii**i*i*ii***i*i* i*ii**i*i*ii****i*i*i*ii***i*i*i*ii*i*i*ii*i*i*ii***i*i*i
< 1733190060 78477 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net QUIT :Remote host closed the connection
< 1733190331 613343 :Everything!~Everythin@46.211.80.247 QUIT :Quit: leaving
> 1733192334 693385 PRIVMSG #esolangs :14[[07User:Tommyaweosme/unnamed collab with yayimhere and ractangle14]]4 10 02https://esolangs.org/w/index.php?diff=147334&oldid=147319 5* 03MihaiEso 5* (+35) 10
> 1733193084 549126 PRIVMSG #esolangs :14[[07User talk:Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff14]]4 10 02https://esolangs.org/w/index.php?diff=147335&oldid=147008 5* 03Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5* (+90) 10/*  */ new section
> 1733193099 461817 PRIVMSG #esolangs :14[[07User talk:Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff14]]4 10 02https://esolangs.org/w/index.php?diff=147336&oldid=147335 5* 03Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5* (+2) 10/*  */
< 1733194039 867767 :molson_!~molson@2605-4A80-2101-99D0-B8F1-1CBD-33F9-8D15-dynamic.midco.net JOIN #esolangs molson :realname
< 1733194281 960699 :molson!~molson@2605-4A80-2101-99D0-B463-ADC7-3BF-B45C-dynamic.midco.net QUIT :Ping timeout: 252 seconds
< 1733194786 120386 :molson_!~molson@2605-4A80-2101-99D0-B8F1-1CBD-33F9-8D15-dynamic.midco.net QUIT :Remote host closed the connection
< 1733194959 492819 :molson!~molson@2605-4A80-2101-99D0-B8F1-1CBD-33F9-8D15-dynamic.midco.net JOIN #esolangs molson :realname
< 1733199631 901255 :ramiro__!~ramiro@host11.181-14-136.telecom.net.ar QUIT :Ping timeout: 264 seconds
> 1733200999 144997 PRIVMSG #esolangs :14[[07User:Tommyaweosme/unnamed collab with yayimhere and ractangle14]]4 10 02https://esolangs.org/w/index.php?diff=147337&oldid=147334 5* 03Ractangle 5* (-35) 10oh no you don't
< 1733202768 25295 :zemhill!bfjoust@selene.zem.fi PRIVMSG #esolangs :cyskus.mol: points 3.07, score 23.52, rank 15/47
< 1733205742 714720 :Hooloovoo!~Hooloovoo@hax0rbana.org QUIT :Quit: ZNC 1.8.2+deb2+deb11u1 - https://znc.in
< 1733205840 217042 :Hooloovoo!~Hooloovoo@hax0rbana.org JOIN #esolangs hooloovoo :Hooloovoo
< 1733205875 678705 :user3456!user3456@user/user3456 QUIT :Quit: I use ZNC - https://znc.in
< 1733206983 459168 :user3456!user3456@user/user3456 JOIN #esolangs user3456 :user3456
< 1733207437 851230 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer
< 1733208733 402584 :craigo!~craigo@user/craigo JOIN #esolangs craigo :realname
< 1733212631 978671 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User
> 1733215916 496600 PRIVMSG #esolangs :14[[07Brainfuck for humans14]]4 10 02https://esolangs.org/w/index.php?diff=147338&oldid=144430 5* 03LillyHStClaire 5* (+676) 10Add a hello world example
< 1733217612 917958 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
> 1733218939 708248 PRIVMSG #esolangs :14[[07User:H. H. P. M. P. Cole14]]4 M10 02https://esolangs.org/w/index.php?diff=147339&oldid=143020 5* 03H. H. P. M. P. Cole 5* (+46) 10
> 1733219000 699528 PRIVMSG #esolangs :14[[07User talk:H. H. P. M. P. Cole14]]4 M10 02https://esolangs.org/w/index.php?diff=147340&oldid=145254 5* 03H. H. P. M. P. Cole 5* (+263) 10
> 1733219169 345865 PRIVMSG #esolangs :14[[07User:H. H. P. M. P. Cole/Modulo 214]]4 M10 02https://esolangs.org/w/index.php?diff=147341&oldid=143081 5* 03H. H. P. M. P. Cole 5* (-1522) 10Bringing the alphabet down to 4 characters! Will work on syntax later.
> 1733219292 164735 PRIVMSG #esolangs :14[[07User:H. H. P. M. P. Cole/Modulo 214]]4 M10 02https://esolangs.org/w/index.php?diff=147342&oldid=147341 5* 03H. H. P. M. P. Cole 5* (+242) 10
> 1733219310 703696 PRIVMSG #esolangs :14[[07User:H. H. P. M. P. Cole14]]4 M10 02https://esolangs.org/w/index.php?diff=147343&oldid=147339 5* 03H. H. P. M. P. Cole 5* (-46) 10
> 1733219335 503945 PRIVMSG #esolangs :14[[07User:H. H. P. M. P. Cole14]]4 M10 02https://esolangs.org/w/index.php?diff=147344&oldid=147343 5* 03H. H. P. M. P. Cole 5* (+74) 10
> 1733219564 428543 PRIVMSG #esolangs :14[[07User:H. H. P. M. P. Cole/Modulo 214]]4 M10 02https://esolangs.org/w/index.php?diff=147345&oldid=147342 5* 03H. H. P. M. P. Cole 5* (+35) 10
> 1733219576 6510 PRIVMSG #esolangs :14[[07User:H. H. P. M. P. Cole/Modulo 214]]4 M10 02https://esolangs.org/w/index.php?diff=147346&oldid=147345 5* 03H. H. P. M. P. Cole 5* (+12) 10
> 1733219607 318807 PRIVMSG #esolangs :14[[07User:H. H. P. M. P. Cole/Modulo 214]]4 M10 02https://esolangs.org/w/index.php?diff=147347&oldid=147346 5* 03H. H. P. M. P. Cole 5* (+27) 10
> 1733219853 286826 PRIVMSG #esolangs :14[[07User:H. H. P. M. P. Cole/Modulo 214]]4 M10 02https://esolangs.org/w/index.php?diff=147348&oldid=147347 5* 03H. H. P. M. P. Cole 5* (+63) 10
> 1733219921 216522 PRIVMSG #esolangs :14[[07User:H. H. P. M. P. Cole/Modulo 214]]4 M10 02https://esolangs.org/w/index.php?diff=147349&oldid=147348 5* 03H. H. P. M. P. Cole 5* (+80) 10/* Syntax */
> 1733220631 686427 PRIVMSG #esolangs :14[[07User:H. H. P. M. P. Cole/Modulo 214]]4 M10 02https://esolangs.org/w/index.php?diff=147350&oldid=147349 5* 03H. H. P. M. P. Cole 5* (+4) 10/* Syntax */
< 1733221201 218601 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net JOIN #esolangs amby :realname
< 1733221900 400712 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User
< 1733222051 475731 :craigo!~craigo@user/craigo QUIT :Remote host closed the connection
< 1733222093 457714 :craigo!~craigo@user/craigo JOIN #esolangs craigo :realname
> 1733224730 960706 PRIVMSG #esolangs :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=147351&oldid=146796 5* 03Artyxa 5* (+20) 10/* Tests */
> 1733224773 236313 PRIVMSG #esolangs :14[[07Esolang:Sandbox14]]4 M10 02https://esolangs.org/w/index.php?diff=147352&oldid=147351 5* 03Artyxa 5* (-8) 10/* Tests */
< 1733225305 370025 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas
> 1733226594 981039 PRIVMSG #esolangs :14[[07Fish14]]4 10 02https://esolangs.org/w/index.php?diff=147353&oldid=147313 5* 03Ractangle 5* (+73) 10/* Cat Program */
> 1733226778 367406 PRIVMSG #esolangs :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=147354&oldid=147352 5* 03Ractangle 5* (-12) 10tify
> 1733226861 945332 PRIVMSG #esolangs :14[[07Fish14]]4 10 02https://esolangs.org/w/index.php?diff=147355&oldid=147353 5* 03Ractangle 5* (-5) 10/* Hello, world! */
< 1733227380 951912 :mtm!~textual@47.202.75.129 QUIT :Ping timeout: 252 seconds
< 1733227530 494554 :mtm!~textual@47.202.75.129 JOIN #esolangs mtm :Textual User
> 1733228085 527727 PRIVMSG #esolangs :14[[07User:Iddi0114]]4 10 02https://esolangs.org/w/index.php?diff=147356&oldid=145476 5* 03Iddi01 5* (+2257) 10[[brainfUck|Removed decoration since it has an impact on the function of this page]]
< 1733228485 107610 :__monty__!~toonn@user/toonn JOIN #esolangs toonn :Unknown
< 1733228666 903227 :SGautam!uid286066@id-286066.ilkley.irccloud.com JOIN #esolangs SGautam :Siddharth Gautam
> 1733229679 756019 PRIVMSG #esolangs :14[[07Semi-serious language list14]]4 M10 02https://esolangs.org/w/index.php?diff=147357&oldid=144067 5* 03Iddi01 5* (+141) 10[[Redcode|This list is incomplete without t h e. u l t i m a t e. p r o g r a m m i n g. g a m e.]]
> 1733229900 186355 PRIVMSG #esolangs :14[[07User:H. H. P. M. P. Cole/Modulo 214]]4 M10 02https://esolangs.org/w/index.php?diff=147358&oldid=147350 5* 03H. H. P. M. P. Cole 5* (-329) 10
> 1733230303 537396 PRIVMSG #esolangs :14[[07List of ideas14]]4 M10 02https://esolangs.org/w/index.php?diff=147359&oldid=147332 5* 03Iddi01 5* (+158) 10/* Joke/Silly Ideas */ Combining [[brainfUck]] (not [[bf]]!) with [[Redcode]], how crazy will that be, even though they are both [[:Category:Programming games|Programming games]]
> 1733232394 738454 PRIVMSG #esolangs :14[[07User talk:Tommyaweosme14]]4 10 02https://esolangs.org/w/index.php?diff=147360&oldid=147309 5* 03PrySigneToFry 5* (+655) 10
> 1733232575 857650 PRIVMSG #esolangs :14[[07User talk:ZCX islptng14]]4 10 02https://esolangs.org/w/index.php?diff=147361&oldid=147158 5* 03PrySigneToFry 5* (+627) 10
> 1733232695 791334 PRIVMSG #esolangs :14[[07User talk:None114]]4 10 02https://esolangs.org/w/index.php?diff=147362&oldid=147231 5* 03PrySigneToFry 5* (+688) 10/* Wasaya */ new section
< 1733232987 374135 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu QUIT :Ping timeout: 256 seconds
> 1733233197 40167 PRIVMSG #esolangs :14[[07Poetic (esolang)14]]4 10 02https://esolangs.org/w/index.php?diff=147363&oldid=138087 5* 03PrySigneToFry 5* (+356) 10
> 1733234101 257611 PRIVMSG #esolangs :14[[07Talk:Deadfish14]]4 10 02https://esolangs.org/w/index.php?diff=147364&oldid=147326 5* 03None1 5* (+261) 10/* A quine */
> 1733234870 845324 PRIVMSG #esolangs :14[[07Pete mort+14]]4 N10 02https://esolangs.org/w/index.php?oldid=147365 5* 03None1 5* (+1364) 10Created page with "'''Pete mort+''' (Romanian for Dead fish) is an esolang invented by [[User:None1]]. It is a [[deadfish]] derivative and an extension [[Pete mort]].  It can print ASCII characters. ==Commands== {| class="wikitable" |- ! Command !! Corresponding Romanian word !! Meaning 
> 1733234876 343076 PRIVMSG #esolangs :14[[07Fish14]]4 10 02https://esolangs.org/w/index.php?diff=147366&oldid=147355 5* 03BrainFuckGirl 5* (-95) 10/* Hello, world! */ removed non-functional code
> 1733234891 388796 PRIVMSG #esolangs :14[[07Pete mort+14]]4 M10 02https://esolangs.org/w/index.php?diff=147367&oldid=147365 5* 03None1 5* (+3) 10
> 1733234907 929263 PRIVMSG #esolangs :14[[07Pete mort+14]]4 M10 02https://esolangs.org/w/index.php?diff=147368&oldid=147367 5* 03None1 5* (+1) 10
> 1733235219 861860 PRIVMSG #esolangs :14[[07Pete mort+14]]4 M10 02https://esolangs.org/w/index.php?diff=147369&oldid=147368 5* 03None1 5* (+14) 10Fix hello world
> 1733235456 673917 PRIVMSG #esolangs :14[[07Fish14]]4 10 02https://esolangs.org/w/index.php?diff=147370&oldid=147366 5* 03BrainFuckGirl 5* (-307) 10/* Cat Program */ reduced section because it became to large
> 1733235555 498690 PRIVMSG #esolangs :14[[07Joke language list14]]4 10 02https://esolangs.org/w/index.php?diff=147371&oldid=147098 5* 03None1 5* (+50) 10/* General languages */
> 1733235600 934033 PRIVMSG #esolangs :14[[07User:None114]]4 10 02https://esolangs.org/w/index.php?diff=147372&oldid=146232 5* 03None1 5* (+50) 10/* My Esolangs */
> 1733235666 198998 PRIVMSG #esolangs :14[[07Peste mort+14]]4 N10 02https://esolangs.org/w/index.php?oldid=147373 5* 03None1 5* (+26) 10Redirected page to [[Pete mort+]]
> 1733236026 608300 PRIVMSG #esolangs :14[[07Wasaya14]]4 10 02https://esolangs.org/w/index.php?diff=147374&oldid=147191 5* 03None1 5* (+45) 10/* Examples */
> 1733236121 76955 PRIVMSG #esolangs :14[[07User talk:None114]]4 10 02https://esolangs.org/w/index.php?diff=147375&oldid=147362 5* 03None1 5* (+273) 10/* Wasaya */
< 1733236285 84746 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
> 1733236292 278426 PRIVMSG #esolangs :14[[07User talk:Ractangle14]]4 10 02https://esolangs.org/w/index.php?diff=147376&oldid=147118 5* 03BrainFuckGirl 5* (+843) 10Talk about Fish
> 1733236458 538896 PRIVMSG #esolangs :14[[07User:14]]4 10 02https://esolangs.org/w/index.php?diff=147377&oldid=146146 5* 03 5* (+73) 10
< 1733236495 221094 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User
> 1733237303 147517 PRIVMSG #esolangs :14[[07User talk:BrainFuckGirl14]]4 N10 02https://esolangs.org/w/index.php?oldid=147378 5* 03BrainFuckGirl 5* (+0) 10Created blank page
> 1733237683 830484 PRIVMSG #esolangs :14[[07Propositio14]]4 N10 02https://esolangs.org/w/index.php?oldid=147379 5* 03 5* (+625) 10Started page
> 1733237975 241213 PRIVMSG #esolangs :14[[07Propositio14]]4 10 02https://esolangs.org/w/index.php?diff=147380&oldid=147379 5* 03 5* (+341) 10
> 1733238079 157753 PRIVMSG #esolangs :14[[07User talk:14]]4 M10 02https://esolangs.org/w/index.php?diff=147381&oldid=147262 5* 03 5* (+19) 10
> 1733238465 859862 PRIVMSG #esolangs :14[[07User talk:14]]4 10 02https://esolangs.org/w/index.php?diff=147382&oldid=147381 5* 03 5* (+347) 10/* ULTRAESOLANG */ new section
> 1733239089 932479 PRIVMSG #esolangs :14[[07WHAT14]]4 N10 02https://esolangs.org/w/index.php?oldid=147383 5* 03 5* (+633) 10Started page
< 1733240844 402744 :FreeFull!~freefull@46.205.204.170.nat.ftth.dynamic.t-mobile.pl QUIT :
< 1733241751 321750 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
> 1733244085 242399 PRIVMSG #esolangs :14[[07User talk:Tommyaweosme14]]4 10 02https://esolangs.org/w/index.php?diff=147384&oldid=147360 5* 03Ractangle 5* (+211) 10
> 1733244196 379280 PRIVMSG #esolangs :14[[07User talk:Ractangle14]]4 10 02https://esolangs.org/w/index.php?diff=147385&oldid=147376 5* 03Ractangle 5* (+177) 10/* Cat Programs in > */
> 1733244286 826321 PRIVMSG #esolangs :14[[07Talk:Deadfish14]]4 10 02https://esolangs.org/w/index.php?diff=147386&oldid=147364 5* 03Ractangle 5* (+230) 10/* A quine */
> 1733244331 846727 PRIVMSG #esolangs :14[[07Signs14]]4 N10 02https://esolangs.org/w/index.php?oldid=147387 5* 03Ractangle 5* (+17) 10a very useful redirect
> 1733244700 196540 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Zaikawo 5*  10New user account
< 1733245429 981235 :FreeFull!~freefull@46.205.204.170.nat.ftth.dynamic.t-mobile.pl JOIN #esolangs FreeFull :FreeFull
< 1733246559 976743 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User
< 1733246632 732820 :SGautam!uid286066@id-286066.ilkley.irccloud.com QUIT :Quit: Connection closed for inactivity
< 1733246908 247588 :craigo!~craigo@user/craigo QUIT :Quit: Leaving
> 1733247681 921349 PRIVMSG #esolangs :14[[07User talk:Tommyaweosme14]]4 10 02https://esolangs.org/w/index.php?diff=147388&oldid=147384 5* 03Yayimhere 5* (+190) 10/* collab? */
> 1733249022 868557 PRIVMSG #esolangs :14[[07User:Tommyaweosme/unnamed collab with yayimhere and ractangle14]]4 10 02https://esolangs.org/w/index.php?diff=147389&oldid=147337 5* 03Yayimhere 5* (+7) 10
< 1733249238 136348 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord
< 1733249259 963452 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 252 seconds
< 1733249318 708631 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 NICK :Lord_of_Life
< 1733249749 914495 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1733250446 110415 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1733250540 295811 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Soni: so I think it's plausible to do memory safety verification on assembly language, by using, e.g., borrow-checking annotations and requiring a particular stack discipline
< 1733250574 396565 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :compilers don't actually do that in practice, but there's no reason why they couldn't other than historical reasons
< 1733250648 482603 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Java does, for example. Most JREs have a bytecode-verification step which looks like abstract interpretation, and the bytecode won't be instantiated if it e.g. has a guaranteed stack underflow.
< 1733250650 376209 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although, the easiest way to get an end-to-end memory-safe toolchain would be to use one of the old-fashioned programming languages in which all arrays are declared at compile time, it's then easy to statically check that all memory addresses are inbounds if you want to
< 1733250689 36027 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: well it's easier in Java because it's GCed, so the only place you can have memory-safety UB is on the stack
< 1733250720 808116 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Whereas e.g. Python does not do this. I happen to have memorized the bytecode program "KABOOM"; convert this to a Python code object and the interpreter will crash -- portably!
< 1733250752 416813 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that said, I've been meaning to write an article about how garbage collection doesn't prevent memory usage errors as well as borrow-checking does; it prevents memory-safety UB specifically, but it doesn't prevent memory safety bugs, just lessens their consequences
< 1733250764 616630 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's easy to write the equivalent of a use-after-free in Java, it isn't UB but may read stale data
< 1733250771 961744 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Of course. If the question is about languages with explicit memory management, then I think that somebody is begging some part of the question: why would we expect memory-safety from such systems?
< 1733250810 350291 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: the word "expect" is ambiguous in English, both meanings fit your sentence and I agree with you in one case and disagree in the other
< 1733250816 454824 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :If Soni were talking only of Rust, for example, then I'd straight-up refute the premise: Rust is *not* memory-safe when we talk about the subset used in actual crates.
< 1733250839 760960 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :ais523: we'd just type-annotate the stack ngl
< 1733250865 640970 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, type-annotating the stack and registers is a good example of the sort of thing you can do to make asm more type-safe
< 1733250869 174239 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Like, in the Latin sense? I agree that we must somehow produce memory-safety by writing a small amount of hand-engineered hand-proven assembly. I usually disagree with the idea that it should be more than a page or two of code per low-level bootstrapping step.
< 1733250889 398488 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :ais523: we mean instead of "requiring a particular stack discipline"
< 1733250904 562554 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :e.g. WebAssembly uses typed stacks as part of its memory-safety strategy.
< 1733250913 958373 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Soni: you have to give some semantics to the stack(s) in order to make function calls compose correctly
< 1733250931 842888 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :ais523: you just have to type the stack pointer
< 1733250957 440451 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Or require every function to consume the entire stack and replace it with an entirely new stack. WebAssembly, but also type systems of Joy and descendants.
< 1733250957 779809 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Soni: you are implicitly assuming a stack discipline there by assuming that the stack pointer points to the top of the stack
< 1733250975 218171 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in generalised asm, this isn't a given, although people normally do write like that
< 1733250986 252939 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Or forbid pointers~
< 1733250988 797526 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or at least, have the top of the stack always at a known offset from the stack poitner
< 1733250993 615799 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :ais523: not at all, if anything, you're probably assuming something that we aren't
< 1733251041 508323 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Soni: so the problem is, say we're writing a function that's meant to run in a type-safe way – some of the existing memory will be free for the function to use for its own purposes, some of it can only be changed in certain ways (or not at all) without violating memory safety
< 1733251051 441184 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Like, *all* bytecodes I've mentioned so far are lacking in pointers. WebAssembly knows what arrays and function refs are, but not pointers in general. Java only has object refs on the stack. Python doesn't have pointers, period.
< 1733251055 538077 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and some of it can't usefully be read because you can't make sufficient assumptions about what it holds
< 1733251057 894318 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :ais523: yes, that's all encoded in global typestate
< 1733251077 729546 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :which isn't even global at all, but it relates to global state
< 1733251108 434902 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a stack discipline is a simple way to solve this problem, you say "on entry to the function, it can touch all memory below SP and above the stack guard page, but can't touch memory above SP unless given a pointer to it"
< 1733251125 394455 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if you don't have a stack discpline you need some other solution
< 1733251128 971201 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :ais523: yes, you encode that in a type
< 1733251138 748877 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :you encode that whole phrase in a type
< 1733251151 971083 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, this might be a type but I am not convinced
< 1733251155 108709 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :this is called your function's "world"
< 1733251174 974012 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :A stack discipline is effectively a FORTH, via Greenspun's Tenth Law. It's going to generate a DSL which we might as well prefer instead of machine code.
< 1733251197 196589 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Similarly, a global typestate which is isolated to a single struct is effectively a Self-style Smalltalk, again via Greenspun.
< 1733251204 246090 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :the world is also part of the function's type, so in theory the assembler would automatically fail stack overflows
< 1733251212 439895 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: so my thoughts on this is that memory-safe languages can't have raw pointers, but can have references which are, in effect, raw pointers together with rules for what you can do with them
< 1733251239 589132 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I'd say "those who didn't read the VPRI or STEPS reports" paraphrasing Santayana, but STEPS didn't really produce many artifacts for us to study. They didn't have much to say about the boot process; instead, their languages do stuff like graphics.
< 1733251242 999418 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or, well, you can have raw pointers as long as you never read or write through them, but that isn't very useful
< 1733251295 896930 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :ais523: we think having an escape hatch is necessary tho
< 1733251309 484535 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :for real-world use at least
< 1733251315 827191 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I am not sure a "generalised" escape hatch is necessary
< 1733251343 660543 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think that you do often need a number of special cases that don't easily fit into the rest of the language, but am not sure why you would need more than a finite number of them
< 1733251403 753658 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :we just think not having to think about all possible abstractions and let someone else build them is fine
< 1733251413 308436 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :anyway, we're supposed to be streaming
< 1733251419 17315 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Sure. There's a big general meta-statement that an actor/object/etc. is fundamentally a fat pointer of script/code/class and locals/vars/fields. Often, we want that first pointer to be an executable function pointer, and the second to point to a struct.
< 1733251419 56235 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :>.<
< 1733251470 911124 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: well, objects in the Java or Rust sense usually have multiple code-address-like entry points
< 1733251472 324901 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Smalltalk had a bunch of functionality around this. It could let one object become another object, it could change the class of an object, etc. Some of this infected other languages, like C++'s reinterpret_cast<>.
< 1733251528 888626 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Sure. Methods can be compiled down in a lot of ways, though. It turns out to be useful to let the script have the Strategy Pattern; deliver a message to the script, and let the script do its own dispatch. Anything fancier can be figured out in JIT.
< 1733251540 514419 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Perl allows you to change the class of an object at runtime, but it works differently from C++
< 1733251587 830690 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: hmm, the systems programmer in me dislikes that approach, basically because it forces you to serialise the message
< 1733251610 868551 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: This might be the clearest indication that I grew up in the object-oriented world~
< 1733251622 740696 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess I dislike having concrete representations of things unless there's a really good reason
< 1733251649 533647 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one of the things I dislike most about Rust is that the language effectively forces &T to be represented as a pointer to some actual T in memory
< 1733251676 201707 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :whereas most uses of &T don't care about that and aren't conceptually thinking about the reference like that at all
< 1733251703 414973 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :We came up with a good reason in Monte: it lets us adopt the same extremely powerful named-args convention as Ruby and Python, while still guaranteeing E's fancy distributed semantics work for objects that generically forward messages.
< 1733251713 52506 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I suspect that you could get fairly large savings by, say, optimising an &u32 into a u32 with the same value as the target
< 1733251734 704825 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :We also didn't care about the widths of ints, so it's fair to say that we didn't care about systems-programming goals.
< 1733251770 262317 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right – I see named arguments as sugar, in that they can easily be compiled into positional arguments if you can see both the callsite and the definition
< 1733251784 616293 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :they are convenient for the programmer but don't need to exist in the compiled program
< 1733251886 75393 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :on the subject of int widths, I have been meaning to write a long rant about that
< 1733251896 91146 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Makes sense. For distributed systems, we must assume that we get a uniform wrapper over an opaque blob of data. So we must transmit everything in the wrapper, and can't assume anything not in the wrapper.
< 1733251907 25492 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in most languages (that have finite-width ints), it is unreasonably hard to write, say, a program that averages two integers
< 1733251965 539843 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Rust is considering adding a builtin for that to its standard library, because it's hard to write correctly and almost impossible to write efficiently in a platform-independent way
< 1733251996 210374 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :E's wrapper is a tuple (verb :str, args :list[ref]). Monte's wrapper, we argue, is the much nicer tuple (verb :str, args :list[ref], kwargs :map[str, ref]). In both cases, that's *all* that the receiver knows, and anything else must be done very carefully.
< 1733252039 842807 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so I had a job working on distributed systems, but we did it a bit differently – every system involved in the computation had the same compiled codebase available, and they would assume that the same code existed on every node
< 1733252072 28944 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so messages didn't have to be generically understandable, you could just send blobs to objects on other systems in a way that they would understand
< 1733252073 354596 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Ah, a common form of cope. Painful.
< 1733252107 928383 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I remember watching as a child when a paperless office upgraded from one version of Microsoft Office to another, back when Office loaded documents via mmap.
< 1733252119 414701 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the only generic component needed was a sort of dispatcher/multiplex because you don't want every object to open its own network port to listen to messages
< 1733252155 943905 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oof. And so you end up with an object server, even if you didn't want to write one.
< 1733252172 851741 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, you need one anyway
< 1733252187 478894 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or, hmm, I should backtrack a bit
< 1733252197 758960 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"Perl allows you to change the class of an object at runtime," => so does python, as long as their representation is compatible, which is the easiest to get if they are subclasses of a common class and neither adds more data over what that common class has. I think python inherited that from smalltalk, but I'm not entirely sure.
< 1733252217 12855 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Right. Object servers, event loops, etc. are required, so they should be built-in. Erlang is a great demonstration of how this can turn into real high-reliability distributed-systems toolkits.
< 1733252219 363327 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the entire purpose of the project was to split up existing programs across multiple nodes, but it was still intended to act as a single program with a single entry point
< 1733252245 525816 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: well Perl doesn't even care if the representation is compatible :-)
< 1733252273 463612 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"you can have raw pointers as long as you never read or write through them, but that isn't very useful" => rust does exactly that, and it is helpful, but that's because it allows you to read/write them if you assume the responsibility for avoiding UB which includes keeping memory safety
< 1733252276 164811 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it just trusts that the programmer knows what they are doing and/or will change the representation to match
< 1733252284 808389 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: Python 3's default class is the new-style object class with inferred slots, and there's no tools for making that work nicely. Python 2's default class did allow that, though; objects were a fat pointer to their class and their dict of locals. Ruby still does it that way IIUC.
< 1733252306 559627 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'd be astonished if Ruby didn't still do it that way, given the sort of language it is
< 1733252356 294688 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Python changed because PyPy adopted Smalltalk's "maps" (awful name!) for computing optimized class layouts with inheritance. RPython implementations of SOM and Monte do it too.
< 1733252392 587177 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :So all of a sudden CPython used a lot more memory than PyPy, and that was politically unacceptable. Ergo, new class layouts that do about half of what PyPy does, get the memory usage down, and make Microsoft and Google happy.
< 1733252421 608355 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the "office loading documents via mmap" is different because the .doc format is ostensibly intended for long-term storage, whereas most people don't even attempt to allow programs to continue running on a new codebase if the codebase has changed more than trivially
< 1733252460 389375 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Any message put onto the network is in long-term storage.
< 1733252472 663726 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Time is an illusion, wall-clock time doubly so.
< 1733252497 178252 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :not necessarily? if you are using rendevouz-style messaging then the time that the message spends in transit effectively doesn't exist from the program's point of view
< 1733252511 784162 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"I suspect that you could get fairly large savings by, say, optimising an &u32 into a u32 with the same value as the target" => right, there was a proposal to add such a thing to C++, as in a new type that you use as a function parameter and it's either a const reference or a copy of the value and the compiler decides which one it is. rust doesn't have that, but its rules about references are strict 
< 1733252517 854889 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :enough that a compiler can reasonably do such an optimization when you pass a function argument by reference and the compiler knows that it's a specific small sized type.
< 1733252544 701145 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's OK to say "if this message is late arriving, then the 'thread' will just pause until it arrives" ('thread' in quotes because I'm referring to a chain of code-causing-each-other-to-run that might not correspond to an actual program or OS-level thread)
< 1733252548 783589 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :That's what I'm saying: the program's concept of time is constructed from what the OS and I/O tell it.
< 1733252575 217770 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: but what I am saying is that from the program's point of view, this is not long-term storage and is not in fact a form of storage at all
< 1733252580 238388 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's the equivalent of a pre-empted thread
< 1733252643 528041 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: so its rules about references are *almost* strict enough, but it doesn't prevent a function you call doing "immutable_ref as *const u32"
< 1733252667 420885 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: It's I/O. Programs don't know what I/O is hooked up to.
< 1733252673 944870 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and the fact that functions can do that and compare the results means that it needs to track the identity of every u32 reference, even though programs basically never care
< 1733252682 790084 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: it isn't I/O from the point of view of the program! only from the point of view of the runtime
< 1733252695 178725 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"Rust is considering adding a builtin for [averaging two integers] because it's hard to write correctly and almost impossible to write efficiently in a platform-independent way" => it's not *that* impossible to write efficiently in a platform-independent way, I think there are two portable magic formulas for it, but nevertheless it's easy to mess it up so it makes sense as a library function, and 
< 1733252701 187184 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :further there's an SSE instruction that averages two integers so the compiler can sometimes optimize to that and so a compiler builtin makes sense too. (of course this is mostly llvm's business, but llvm is developed partly to support rustc.)
< 1733252702 727122 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the program need not know whether its messages are being handled locally or over the network
< 1733252714 126295 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh. Oh noes.
< 1733252736 954557 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Okay, so yes, but only because the program should be written so that its messages are *always* over a network.
< 1733252755 353280 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :my complaint isn't that attract is annoying to implement, but that other operations are annoying to implement based on just attract and repel (with no explicitly copy, you have to eg. loop attract for that)
< 1733252758 489804 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, it should be written so that it doesn't know or care whether the messages are over a network
< 1733252826 124584 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: In E, a program knows whether its refs are "near" or "far". Near refs can be deconstructed and treated as data. Far refs can only be targets of messages, returning promises or other far refs.
< 1733252827 596735 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the whole purpose of what we were working on was to make the multiple networked nodes act as though they were a single computer with additonal cores
< 1733252848 18328 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Sure. But that doesn't work.
< 1733252868 39168 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: right, that is a sensible optimisation – what we were doing treated everything as near refs, potentially requiring a network round trip to deconstruct
< 1733252891 395857 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Like, Beowulf'ing it was a meme before I was born. The RPC debates were when I was a child. The question of NUMA has been answered: NUMA can't be substituted for SMP.
< 1733252895 387352 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although if there was a small enough amount of data involved, we just sent a copy pre-emptively in case it needed deconstruction
< 1733252920 999848 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can only get away with this in a GC'ed language, otherwise you get memory lieaks
< 1733252959 48206 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it is quite possible/probable that this would have hit either an insurmountable semantic barrier or an insurmountable performance barrier – I lost confidence in the project towards the end and left that job
< 1733252960 810190 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh, in *any* language, there's the question of cyclic GC where the cycle extends across the network. This was one of E's big contributions, and most systems still don't implement it because it's such a PITA.
< 1733252993 446663 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, I think our GC didn't implement that, we were probably planning to implement it at some point when we figured out how
< 1733253027 915653 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The laws are strong when it comes to pulling apart a monolith. Amdahl's Law and Conway's Law suggest that the first step is to convert the monolith to a job server and farm out the most compute-intensive tasks to a fleet of identical workers.
< 1733253068 969222 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User
< 1733253095 592467 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :my guess is that the goal of the project wasn't to find something that worked "efficiently" – just faster than on a single computer, with no manual intervention
< 1733253120 210959 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Conway's Law further suggests that a linguafranca is required in order to make this scale, like gRPC at Google, Thrift at Facebook, or the pile of crappy JSON-over-HTTP APIs that AWS and other cloud vendors offer.
< 1733253167 317370 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Ah, yeah, management rarely knows the laws. Frustrating but common. I can't think of a job where I haven't had to explain the Fallacies of Distributed Computing to management.
< 1733253219 797918 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think you may be wrong about what Conway's Law suggests in general, though: if you are running a scheme where (semantically) anything can run on any node with a common code base, and the only difference between locations is efficiency / NUMA
< 1733253252 672541 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :then that doesn't necessarily imply that a lingua franca exists, just that there is some way to communicate messages between nodes that looks like it was running on a single node
< 1733253282 131874 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if the structure is "anything can be anywhere, putting it in the right place is an optimisation decision" then there is no structure to mirror
< 1733253306 835724 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :In this case, Conway's Law is that if two nodes communicate with each other, then the designers of the software on those nodes communicated with each other. A linguafranca gives those designers a common language to facilitate their designs.
< 1733253327 463182 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: right but we had the same software on every node, because it was intended to act like a single computer running a single piece of software
< 1733253362 879956 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Otherwise you end up with e.g. one designer trying their best to imagine what it must be like to be that other designer and guessing their intent. Incorrect API use, unstated invariants or requirements around usage, etc.
< 1733253362 961661 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if you wanted to change it, you would exit the process and start a new one (copying its code everywhere in between), just like you would do ona single computer
< 1733253394 834195 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: "functions can [take the address of a reference] and compare the results" => I see! that makes sense and may be unfortunate. it means if your function reborrows its parameter (or a field in it) to an opaque function then it can't use a copied/moved version of the value, nor pass the value in a register, because the function might need to compare its address.
< 1733253427 974246 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: By an easy handwave, there must have been times when at least two nodes differed in the version of software that they ran. At scale, that turns into downtime.
< 1733253449 586270 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :So, at scale, distributed systems usually are designed to gracefully accept messages from different versions.
< 1733253460 572420 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : "Rust is considering adding a builtin for [averaging two integers] because it's hard to write correctly and almost impossible to write efficiently in a platform-independent way" => it's not *that* impossible to write efficiently in a platform-independent way, I think there are two portable magic formulas for it ← so (with unsigned ints) you can do (a >> 1) + (b >> 1) + (a & b & 1) but that doesn't go near to the optimal code on x86_64
< 1733253503 894953 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"in *any* language, there's the question of cyclic GC where the cycle extends across the network." => how does Windows COM handle that incidentally? it has transparent remote objects (between processes) doesn't it?
< 1733253511 872437 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: yes, in this model the downtime becomes startup latency, because some time is needed to copy the codebase onto every node after restarting the program
< 1733253514 425535 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :maybe it only does reference counting?
< 1733253541 470285 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ooh, actually I think our GC *did* handle cycles – if there was a potential cycle it tried to migrate all the objects onto the same node so that that node could detect the cycle and free them
< 1733253555 91818 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :err, a potential unreferenced cycle, that is
< 1733253580 33044 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the way you do it is, if a node contains an object with no inbound local references, it moves the object to a node that does have a reference to it
< 1733253593 403292 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Sure. A cool trick from the E world is to separate the object server from the user-level codebase, so that only a small slug of user code has to be copied. In Monte, we can do this incrementally on a per-module basis, although I never wrote a compiler that took serious advantage of it.
< 1733253599 351424 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(or if it contains a cycle with no inbound references from otuside the cycle)
< 1733253640 444270 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: hmm, I wonder if COM is able to create a reference cycle
< 1733253644 38173 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :probably it is
< 1733253659 396061 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but there are some languages where you can't modify things while they have inbound references, those languages are unable to create cycles
< 1733253669 802707 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :But e.g. I had a single object server doing lots of different raytracing jobs, with each job specified as a big generated Monte AST. When the object server received a request to draw a pixel, it also got a ref to that AST, and it could cache compilations for ASTs already seen before.
< 1733253686 483648 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :as a simple example, you can't create a reference cycle in Rust without using unsafe code or something that contains an UnsafeCell, so a hypothetical "cell-free Rust" couldn't have reference cycles
< 1733253744 982277 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :This is roughly how production RenderMan works, although the scene isn't executable in their case. But because a film contains so many different scenes, the scheduler has to have some awareness that a worker still "has the scene in memory" so to speak.
< 1733253752 752239 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"tried to migrate all the objects onto the same node so that that node could detect the cycle and free them" => aren't there cases when that rule causes to migrate everything to the same computer, which causes it to run out of memory or at least catastrophically degrades performance?
< 1733253864 34170 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: yes, that case happens if the program is effectively single-threaded, you can work around the problem by creating extra "GC roots" that are pinned in place
< 1733253875 777501 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"if COM is able to create a reference cycle" => it can at least represent two objects that reference each other, but that's with two objects within the same process and the server probably already knows how to clean them up, eg. either one of the references behaves as a weak reference, or one of the objects is guaranteed to have a longer lifetime than the COM client referencing them
< 1733253891 889966 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Distributed GC can't progress that way. It looks like distributed reference counting; when an exported object isn't referred to locally, then its server can notify everybody else that the object wants to be GC'd.
< 1733253936 292136 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Only at that point, if the object is safe and consenting to copy, can it possibly be transferred to other servers.
< 1733253981 498905 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think we were able to move the object elsewhere even if it did have local references, we would replace the local references with a shim object that would do the network accesses
< 1733253989 814367 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Or quoting http://erights.org/elib/distrib/captp/dagc.html "Only the side that has the arrowtail can find out (by finalization from his local intra-vat garbage collector) that there is no longer any local interest in using the tail of that reference. This does not necessarily mean it's safe to drop the reference!"
< 1733254002 286979 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :otherwise that would violate the "anything can be anywhere" principle
< 1733254021 455938 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :obviously, doing that would probably be bad for performance unless the other node needed it much more
< 1733254049 939342 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :or the reference from the COM client to the object acts like a weak reference, so the object can be destroyed while the client has a reference to it and most ways to try to use that object fails afterwards though in a safe way
< 1733254052 298855 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :maybe that was only a planned feature, rather than implemented
< 1733254088 741970 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Some things are closely held. An object with the capability for local I/O can always export methods that invoke that capability, but they can't allow it to be copied to another machine/process/etc. In Capn Proto, there's two kinds of opaque refs: pointers to blobs, and refs to capabilities.
< 1733254100 423636 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: so I have realised that weak references are useful even in non-GCed languages, and in general, many programs semantically want to be able to free an object while it still has inbound references
< 1733254150 829359 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: you can always copy something that's semantically identical to the object, though (and that does I/O on the original machine via forwarding the requests over the network)
< 1733254160 908502 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yes. it's just complicated because there are multiple variants of weak reference.
< 1733254177 128331 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :obviously the implementation will be different, but the caller/message-sender doesn't need to know the details
< 1733254206 904033 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :NetHack is a good example, semantically you can destroy an object or kill a monster while parts of memory still refer to it
< 1733254213 198313 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: So, in cap theory, we say that that's *not* a copy. It's a "transparent forwarder", borrowing Smalltalk's phrasing. The weakness or ability to cut off forwarding makes it "revokable", in cap theory.
< 1733254244 343676 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: so you work around this by having the forwarders be the only thing that exist from the program's point of view
< 1733254246 818572 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :By saying this, we can start to imagine isolation as a provable property of objects: if an object holds something closely, then the only way to inspect that thing is via consent.
< 1733254270 431493 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: right, M:tG even more so
< 1733254274 406566 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or, well, you say that there is no way from within the program to determine whether something is a forwarder or not
< 1733254285 301030 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: M:tG isn't a computer program, but yes
< 1733254317 785257 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a program like Arena needs weak references to handle cases where an object refers to something that has changed zone and thus is considered a new object
< 1733254326 338697 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Sure! The Joule language works like this. There's an obvious cost to not being able to treat objects as near refs; we need to indirect through the heap just to do local ALU ops. Haskell has the same problem for a different reason; lazy threading through the heap for strict ALU ops.
< 1733254364 797245 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :In both cases, it seems like it's a PITA to ask users to guess at whether a Sufficiently Smart Compiler will correctly guess that everything is strict/near/etc. So let's just give users the distinction and make them pick up the pieces.
< 1733254388 468887 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: the history of Java is informative here – even non-distributed Java treated everything other than primitives as objects until recently
< 1733254423 74711 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but ended up adding what are in effect non-virtual objects (in C++ terminology) in order to avoid that performance pitfall
< 1733254460 147857 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: We could argue that, starting with Self, the forwarders were the only thing that an object could access. Those forwarders just happen to look like fat pointers from the implementation's POV. And that's kind of the history of the modern everything-is-an-object approach.
< 1733254500 83729 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I suppose that Java made this choice for performance when compared to Self? That's normally the justification for this sort of difference.
< 1733254514 102747 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right – I think everything-is-an-object is usually a good mental model for programmers to deal with, even if it is occasionally very difficult for implementations to implement efficiently
< 1733254551 254268 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :just look at Python's integers, for example – they can transparently convert to bignums to avoid arithmetic overflow, and as a result Python is one of the only widely used languages where programmers don't have to worry about overflow at all
< 1733254571 766403 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Meta-tracing was the key insight, and even among JIT pros it's a controversial one. Without meta-tracing, JIT can only start and end on user-chosen boundaries like functions or methods.
< 1733254609 399659 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :But meta-tracing means that the JIT starts on compiler-engineer-chosen boundaries, like interpreter-level loops.
< 1733254641 119080 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, JIT works well in an everything-is-an-object world, where the exact type of the objects isn't known (only a superclass or set of interfaces), because the objects will in practice usually have the same type but that is hard to prove
< 1733254675 767006 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and a JIT allows you to make optimisations that would be unsound in rare circumstances, by checking to see if the conditions for soundness hold, and reversing the optimisation when they dont'
< 1733254679 821377 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yeah
< 1733254732 114129 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :AOT compilers can use similar optimisations sometimes
< 1733254760 119279 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :e.g. clang/LLVM will assume an object always has the same type if only one type exists in the compilation that fits the superclass/interfaces you specified
< 1733254772 954539 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :That's all pre-meta-tracing JIT. In particular, deoptimization should never happen; at worst, if an invariant fails, the JIT should just toss out all of the machine code tagged with that invariant.
< 1733254786 978825 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: that's a form of deoptimization, isn't it?
< 1733254791 999987 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(also what I was referring to)
< 1733254864 424778 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Usually folks are referring to the nasty process of generating a new interpreter state, copying the JIT's variables into that state, and restarting the interpreter in the middle of user-level code.
< 1733254865 424478 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: anyway, the best way to average two unsigned integers in x86_64 asm is to add them with the add instruction, then rcr the result
< 1733254883 758027 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I haven't figured out how to get compilers to ever generate an rcr without using an intrinsic for the purpose
< 1733254917 778531 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: hmm, now I'm imagining AOT-compiled code with an injected fastpath
< 1733254939 377244 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :compile X into if (a holds) { X assuming a; } else { general implementation of X; }
< 1733254946 668385 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :But meta-tracing offers a different path. At compile time, generate multiple copies of the interpreter: one for normal interp, one for tracing, one for running JIT code, etc. Then, at each compiler-level "merge point", make a universal decision about which interp to use next.
< 1733254956 584947 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I have noticed gcc doing this on occasion, but am not sure what heuristics it uses
< 1733254985 951640 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Deoptimization is now merely when a guard in JIT code jumps to the normal interp.
< 1733255030 995298 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I understand why JITs have interpreters, but in a way it feels conceptually wrong to me
< 1733255054 995500 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: you can also try to do such optimizations without JIT, in something like python, but it gets ugly. you hope that the object will be of the same concrete type every time, and so for method calls in the code you try to cache the specific method to call. this gets ugly because any code could change the class so that the method points to a different function, so you need some very ugly 
< 1733255061 147627 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :representation, but it can be done. and it's especially worth for those integers that you mentioned and floats, because there you don't just gain on faster method calls, but you can avoid allocating an actual object for a float or int temporary if you guess its type correctly and it doesn't overflow a fixed sized integer.
< 1733255076 546790 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if part of program, under a set of assumptions, spends a long time running, then it is correct to compile it and run the compiled version; if it doesn't, performance isn't important so the time spent compiling it isn't a big cost
< 1733255112 736656 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"add them with the add instruction, then rcr the result" => ah, so you want not only a portable method but one that's the most efficient. that makes sense.
< 1733255115 237198 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: well, there's the OCaml approach where everything is a disjoint union of integer and pointer
< 1733255152 259659 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if it's of a type that can't be represented as an integer, it has to always be stored as a pointer, and the other disjoint union option isn't use
< 1733255153 723946 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* used
< 1733255160 17073 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(this is why OCaml has 31-bit integers)
< 1733255167 358601 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: It's for uniformity. In a meta-tracing JIT, the interps are running compiled versions of interpreters for user-level languages; the JIT isn't tracing Python ops, but RPython ops.
< 1733255190 2376 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: can you cast both to a larger size integer, add them, shift right, and then cast down to the original size? there's somethign similar for multiplications that compilers specifically look for and optimize
< 1733255216 204791 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: if there is a larger-sized integer, yes, but I think compilers will compile using larger-sized operations
< 1733255227 414640 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :let me load up godbolt and check for the 64→128 case
< 1733255257 421669 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"everything is a disjoint union of integer and pointer" => right, ruby 1.8 does something similar to that (only there are a few more possibilities besides those two for reasons that I don't understand)
< 1733255273 828685 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but that specifically doesn't work for python floats
< 1733255302 339401 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I think scheme is designed to possibly work with those sorts of integers too
< 1733255303 587447 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :So the "part of program" that "spends a long time running" is something like a bytecode dispatch loop, and the "set of assumptions" is when the addresses for the bytecodes are repeated. This is why the JIT needs merge points: it needs hints that a user-level loop is happening.
< 1733255317 973078 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: https://godbolt.org/z/77vK8vv7r
< 1733255364 664649 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that's a fun algorithm, but it isn't the RCR algorithm, and in fact doesn't use the carry bit at all
< 1733255378 264787 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think it is doing a 128-bit addition but has cancelled out a left-shift and a right-shift
< 1733255404 635096 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: oh, I see, you are thinking about languages like Python that are inherently interpreted
< 1733255434 941521 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :CHICKEN Scheme is another good example of this; https://www.more-magic.net/posts/internals-data-representation.html for more on that. Objective-C is another good example, particularly packing selectors.
< 1733255448 954965 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or, well, AoT python exists but your JIT is trying to optimise an interpreter rather than trying to optimise the interpreted program
< 1733255457 864282 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: it's strange that you write it with i128 instead of u128, because then the division rounds towards zero and you have to notice that the dividend is nonnegative so that doesn't matter
< 1733255478 586324 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: it was a thinko but doesn't matter, LLVM is very good at noticing that sort of thing
< 1733255487 874859 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Right. Most JITs do the first Futamura projection. Our JIT goes one higher.
< 1733255501 342500 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :let me look up what the blue book says
< 1733255513 137431 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I tried with u128 and get the same result
< 1733255526 365513 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yeah
< 1733255554 417713 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I also tried with u<65> but apparently it hasn't been implemented yet, not even on nightly
< 1733255576 456306 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and it probably wouldn't be special-case implemented as a register plus a flag, even if it conceptually would be
< 1733255581 493171 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* conceptually should be
< 1733255607 72442 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I think zig implements that, you could try with a zig compiler
< 1733255625 299176 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :out of interest, what does zig use for its code generation / backend?
< 1733255676 771558 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I think it uses llvm too, but I'm not quite sure. it bundles a clang so there is at least an llvm somewhere in there.
< 1733255726 499812 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I am worried about how LLVM-dependent the world is getting, LLVM seems inherently somewhat unsound to me
< 1733255757 955019 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there was a miscompilation bug semi-recently that was caused by C++ autogenerating an == implementation for a type that didn't reflect actual equality for objects of that type, and nobody had noticed until the bug report
< 1733255764 781620 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ok, so the blue book chapter 2-5 says you can use { (a & b) + ((a ^ b) >> 1) } for that, and then elaborates on what to do if you want to round up or your inputs are signed
< 1733255786 544792 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, that's the algorithm that LLVM picked
< 1733255816 325979 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :anyway, my more global point is – I think arithmetic operations in programming languages should round/truncate/wrap only where the programmer says they should, not at points determined by the language
< 1733255835 326938 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I should be able to write, say, [ (a + b) / 2 ] and get a correct averaging routine even though the intermediate values can be outside the range of the data type
< 1733255849 667410 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the square brackets show where rounding/truncation/wrapping is allowed
< 1733255863 190142 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this would also be very useful with floats, e.g. [ a * b + c ] for a fused multiply-add
< 1733255898 53159 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that would be rather hard to implement in general and efficiently
< 1733255903 274817 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(at present, (a * b) + c means [ [ a * b ] + c ] in most programming languages – this can't be compiled into a fused multiply-add without fast-math because the result is different)
< 1733255920 904851 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :obviously we already have some special cases like (a*b+c) optimized to a fused multiply-add if you allow it
< 1733255940 347994 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: quite possibly, but I don't care – it beats programs producing incorrect results
< 1733255955 960426 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you could perhaps generate a compile error if the compiler can't find an efficient implementation
< 1733255965 953817 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and the (a+b)/2 *should* work if you upcast to a one larger integer type, even if you showed that llvm doesn't optimize it correctly, it could
< 1733255966 952262 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :asking the programmer to add additional rounding/wrapping points
< 1733255980 57219 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :hmm 
< 1733255986 635841 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :upcasting to a larger type should work for pretty much any integer example of this
< 1733256002 788617 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :except where exponentials/shifts are involved (OK, it technically works even then, but the type would be too large)
< 1733256027 573138 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :[ a << b ] is fun, it unambiguously returns 0 if b is larger than the width of a
< 1733256055 845942 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(whereas a << b in C is UB in that case and often in practice returns a shifted a lesser distance)
< 1733256191 366072 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, oh no, current Rust compiles a << b into a shl instruction in release mode
< 1733256206 954845 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: the problem is that there are some common cases where getting a guaranteed correctly rounded result is actually very hard and very often it's fine to get a result that might have a small error, this includes converting a machine float to decimal (for formatting it as a decimal string usually) or decimal to machine float (for scanning a decimal string usually) as well as floating-point exp, log, 
< 1733256213 249521 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :sin, cos, tan, atan, asin, acos
< 1733256228 231786 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that has to be wrong, doesn't it? shl takes the bottom 5 significant bits of b, whereas it should be wrapping mod the width of a
< 1733256236 317604 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :according to the defined semantics of release-mode arithmetic
< 1733256250 983895 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and so the programmer needs a way to specify whether he wants the definitely exact solution, or he wants a solution that may sometimes be off by a little bit, or even something worse
< 1733256263 614961 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: well, those are function calls, and those inherently round because they're returning a result of a concrete type
< 1733256310 771612 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I think b_jonas is referring to the Table-maker's Dilemma. Rounding transcendental functions correctly is somewhere between exponential and undecidable IIRC.
< 1733256366 754365 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"[ a << b ] is fun, it unambiguously returns 0 if b is larger than the width of a" => it's not that simple! the problem is that x86 has multiple shift instructions, and if you try to shift an u64 by 64 bits, some of them return zero and some treat it as a shift by 0, and because of this it does make sense for C to have a << operator that doesn't guarantee what result you get for ((uint64_t)1)<<64, even 
< 1733256372 843630 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :if as a programmer sometimes you would like a shift that always gives 0 for this
< 1733256395 327630 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :
ACTION really should go run errands

< 1733256473 819900 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :korvo: I believe for decimal conversion, exp, log, sin, cos, tan it happens to be decidable, and even decidable in a time limit, but the time limit is something like a polynomial of the maximum exponent of the float, which can sometimes be too big in practice
< 1733256517 625149 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: so Rust currently seems to be compiling << with unspecified overflow behaviour, when in release mode (it does correctly panic in debug mode)
< 1733256554 138463 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this seems like a bug in Rust? LLVM is assuming C-like overflow behaviour even though Rust doesn't use that
< 1733256585 34835 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :for sin, cos, atan this is because a nonzero machine float can't get closer to a multiple of pi than something on the order of magnitude of the smallest floating point number, and there's a similar reason for decimal conversion
< 1733256631 194820 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, hmm, it seems intentional, the LLVM IR generated by Rust is masking off the bottom five bits of the shift and then doing the shift
< 1733256679 571277 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, println!("{}", 1u16 << black_box(17)); prints 2
< 1733256729 875137 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: it shouldn't matter, but out of curiosity, what type is the 17 there?
< 1733256738 822358 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: Oh no, now I'm remembering that one cringe idea I had a while ago for letting trigonometric functions be fuzzy to avoid precision issues.
< 1733256749 855907 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: u32 I think, although I keep getting confused about the type of the right hand side of shift operations
< 1733256762 350344 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :maybe i32
< 1733256770 772664 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I do remember that it's something that's too large
< 1733256788 107464 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :https://langdev.stackexchange.com/q/3284 this one. Very funny, even if most folks didn't actually understand why I'd want this.
< 1733256788 222578 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I'm guessing i32 but I'm not sure
< 1733256797 853025 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I really need lunch now. Peace.
< 1733256815 29113 :zenmov!~zenmov@user/zenmov QUIT :Ping timeout: 260 seconds
< 1733256904 690562 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I have probably already linked from #esolangs to both of these about floating-point but just in case: https://www.exploringbinary.com/ a blog mostly about floating point to or from decimal conversions, I had known those were hard but reading the blog convinced me that they are *even harder* than I had thought; and http://sleef.org/ for transcendental functions on machine floats
< 1733257002 21381 :zenmov!~zenmov@user/zenmov JOIN #esolangs zenmov :zenmov
< 1733257246 520214 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I think the situation is more that a) they're hard to do efficiently and b) people keep forgetting about how weird floats are when implementing them
< 1733257289 343162 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there should be a fairly simple correct implementation that entirely uses integer arithmetic and uses a big array to keep track of all the accumulated digits
< 1733257295 418582 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but it'd be slow
> 1733257349 62066 PRIVMSG #esolangs :14[[07Snakel/Errors14]]4 10 02https://esolangs.org/w/index.php?diff=147390&oldid=145463 5* 03Ractangle 5* (+63) 10/* SyntaxError */
> 1733257494 857255 PRIVMSG #esolangs :14[[07Snakel/Errors14]]4 10 02https://esolangs.org/w/index.php?diff=147391&oldid=147390 5* 03Ractangle 5* (+93) 10/* Using anything BUT a tab or 4 spaces as your indentation */
> 1733257534 104515 PRIVMSG #esolangs :14[[07Snakel/Errors14]]4 10 02https://esolangs.org/w/index.php?diff=147392&oldid=147391 5* 03Ractangle 5* (+5) 10/* Removing an entry that is not on the list */
> 1733257566 99169 PRIVMSG #esolangs :14[[07Snakel/Errors14]]4 10 02https://esolangs.org/w/index.php?diff=147393&oldid=147392 5* 03Ractangle 5* (+0) 10/* Not specifying a type or specify a non existent type to a variable */
< 1733257689 350747 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :whoa! so the intel x86 arch manual says that SHLD with 16-bit operands gives an undefined result value and flags if the shift count unsigned modulo 32 is greater than 16, but a shift by exactly 16 is fine and will shift by 16 bits; but a SHLD with 32-bit operands is never undefined and a shift count of 32 shifts by 0 bits, so the two behave in an entirely different manner. I didn't know this
< 1733257723 843405 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: yes, that's a fine summary
< 1733257942 983142 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :it also says that for the ordinary SAL instructions with 8 or 16 or 32 bit sized arguments, the shift count is modulo 32, except that before 286 it was IIUC modulo 256 instead. that is funny because I think SHLD was added by 386, not 286 (since it has a prefix, and 286, so the reason for the change is not the new SHLD instruction but just different optimizations
> 1733258204 97370 PRIVMSG #esolangs :14[[07User talk:5anz14]]4 10 02https://esolangs.org/w/index.php?diff=147394&oldid=147318 5* 035anz 5* (-1) 10/* esolang? */
> 1733258535 254120 PRIVMSG #esolangs :14[[07Estrita14]]4 M10 02https://esolangs.org/w/index.php?diff=147395&oldid=146611 5* 03Aadenboy 5* (+320) 10minor updagte
< 1733258634 441795 :olsner_!~olsner@c83-252-234-66.bredband.tele2.se JOIN #esolangs olsner :olsner?
< 1733258740 707933 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ah, this is getting even more hilarious. for the SSE2 shift instructions PSLLDW/PSLLD/PSLLQ, which shift each 16-bit, 32-bit, or 64-bit part of an XMM/YMM/ZMM vector, the shift count is an unsigned 64-bit integer that comes from either an XMM register or memory, which means there's an instruction that rotates part of a 256-bit YMM register, reads a 128 bits shift count operand from memory, throws away 
< 1733258746 717669 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :the top 64 bits of that operand, then checks the middle 60/59/58 bits and if they aren't all zero it shifts zeros into every bit of the result. let me see what the later vector shift instruction does too.
< 1733258773 96353 :olsner!~olsner@c83-252-234-66.bredband.tele2.se QUIT :Ping timeout: 248 seconds
< 1733258788 559431 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I hadn't known that AVX has an instruction with two differently sized vector operands
< 1733258807 910121 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :s/AVX/AVX2/
< 1733259173 582888 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :so in the AVX2 instruction VPSLLV[WDQ] the shift counts are the same size as the shifted pieces, 16-bit in VPSLLVW, 32-bit in VPSLLVD, VPSLLVQ, and in all cases the shift count is unsigned and if it's too big the result is zero; but for the AVX512 instructions VPSHLD[WDQ] and VPSHLDV[WDQ] the shift count is modulo 16, 32, 64 respectively when they operate on 16, 32, 64 bit chunks
< 1733259223 334790 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :wow
< 1733259235 724464 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I didn't know x86 got this so complicated
< 1733259262 853208 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :shifts are inherently complicated because the two operands are basically in different units (the shift count is on a log scale compared to the value being shifted)
< 1733259269 142224 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yeah
< 1733259324 639009 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and I can understand that more than one of the wrapping behavior can be convenient (as a low-level programmer) in different circumstances
< 1733259461 383951 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think most of my programs that shift naturally never have an overflowing shift, and the few that do would want the result to be 0
< 1733259478 586642 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and that wrapping the shift count is bascially only done because it is the easiest to implement in hardware (you just ignore some of the wires)
< 1733259521 421517 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there's a reason that 32 bit x86 wraps the shift count mod 32 even if it's shifting something smaller than 32 bits
< 1733259536 261484 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because changing the number of wires you ignored would be less efficient than ignoring a constant number
< 1733259552 63229 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :did you never try to use single shifts to implement a double shift? because that's the common case where you want, for 32-bit shifted numbers, that single shifting by 32 results in zero 
< 1733259605 759248 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: that's one of "the few that do"
< 1733259626 651193 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but most commonly I want overflowing shifts to hit the adjacent elements of an array
< 1733259639 524484 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(IIRC x86 has a bit selection routine that actually does that)
< 1733259643 146824 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"there's a reason that 32 bit x86 wraps the shift count mod 32 even if it's shifting something smaller than 32 bits" => yes, but they introduced the modulo 32 rule in 286, which does not yet have 32-bit shifts nor double shifts. and I guess that makes sense because it means shifting by 16 results in 0 so you can implement a double shift easily.
< 1733259955 825980 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yes, either you call the double 386 shift instruction SHLD with the two adjacent array elements as its input operands; or the 386 BT/BTR/BTS/BTS instructions which lets you affect one bit from a memory array and so use most of the shift count to determine how much to index your array
< 1733260007 991458 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it wouldn't surprise me if BT were microcoded and thus really slow
< 1733260012 952206 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although I don't remember for certain
< 1733260056 346461 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :microcoded on what cpu?
< 1733260084 744029 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :let me check Agner's docs
< 1733260087 525805 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :recent x86alikes
< 1733260327 468914 :Everything!~Everythin@46-133-12-50.mobile.vf-ua.net JOIN #esolangs Everything :Everything
< 1733260628 260249 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :it looks like on some cpus memory BT are slow (as in you'd usually better use other instructions) but not very slow, and on some cpus they're fast enough, so you are at least partly right. 
> 1733260764 894853 PRIVMSG #esolangs :14[[07Special:Log/upload14]]4 upload10 02 5* 03Tommyaweosme 5*  10uploaded "[[02File:Emojic wheel result.png10]]"
> 1733261010 936248 PRIVMSG #esolangs :14[[07File talk:Emojic wheel result.png14]]4 N10 02https://esolangs.org/w/index.php?oldid=147397 5* 03Ractangle 5* (+46) 10Created page with "Yayimhere's suggestion is gonna be used then~~"
> 1733261094 297566 PRIVMSG #esolangs :14[[07User:Ractangle/unnamed collab with yayimhere and ractangle14]]4 N10 02https://esolangs.org/w/index.php?oldid=147398 5* 03Ractangle 5* (+75) 10Redirected page to [[User:Tommyaweosme/unnamed collab with yayimhere and ractangle]]
> 1733261125 697064 PRIVMSG #esolangs :14[[07User:Tommyaweosme/unnamed collab with yayimhere and ractangle14]]4 10 02https://esolangs.org/w/index.php?diff=147399&oldid=147389 5* 03Tommyaweosme 5* (+483) 10
> 1733261264 582446 PRIVMSG #esolangs :14[[07Talk:14]]4 M10 02https://esolangs.org/w/index.php?diff=147400&oldid=124497 5* 03Brain Boy 53 5* (+29) 10
> 1733261284 245925 PRIVMSG #esolangs :14[[07User:Tommyaweosme14]]4 M10 02https://esolangs.org/w/index.php?diff=147401&oldid=147311 5* 03Tommyaweosme 5* (+6) 10
> 1733261331 108536 PRIVMSG #esolangs :14[[07User:Tommyaweosme/unnamed collab with yayimhere and ractangle14]]4 10 02https://esolangs.org/w/index.php?diff=147402&oldid=147399 5* 03Ractangle 5* (+62) 10/* commands */
< 1733262179 902570 :olsner_!~olsner@c83-252-234-66.bredband.tele2.se NICK :olsner
< 1733262449 996386 :zenmov!~zenmov@user/zenmov QUIT :Ping timeout: 260 seconds
> 1733262777 980626 PRIVMSG #esolangs :14[[07User:Tommyaweosme/unnamed collab with yayimhere and ractangle14]]4 10 02https://esolangs.org/w/index.php?diff=147403&oldid=147402 5* 03Tommyaweosme 5* (+548) 10
> 1733262919 496453 PRIVMSG #esolangs :14[[07User:Tommyaweosme/unnamed collab with yayimhere and ractangle14]]4 10 02https://esolangs.org/w/index.php?diff=147404&oldid=147403 5* 03Tommyaweosme 5* (+92) 10
< 1733263153 151858 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
> 1733263587 250253 PRIVMSG #esolangs :14[[07Bbtos14]]4 10 02https://esolangs.org/w/index.php?diff=147405&oldid=142253 5* 03Tommyaweosme 5* (+53) 10
< 1733263742 579979 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User
> 1733263779 896383 PRIVMSG #esolangs :14[[07Talk:Nine-hundred-eleven14]]4 10 02https://esolangs.org/w/index.php?diff=147406&oldid=142473 5* 03Tommyaweosme 5* (-7) 10
> 1733264667 255629 PRIVMSG #esolangs :14[[07Nile14]]4 N10 02https://esolangs.org/w/index.php?oldid=147407 5* 03Corbin 5* (+697) 10Stub a page on one of the STEPS languages.
< 1733264861 364392 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname
< 1733265293 153084 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1733269035 892951 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :cursed idea: what would a "resource fork"-native API look like, if we could pretend there's no filesystem altogether and just stack resource forks on resource forks? (and then use it for regular filesystems anyway because the rest of the world refuses to improve)
< 1733269217 815398 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The API can look like whatever you want, really. Consider git, which I'm currently using instead of a filesystem; git's lowest-level API is a declarative content-addressed store, but folks usually use the "porcelain" API which provides a version-control system.
< 1733269270 852426 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :sure
< 1733269288 548279 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :what would a programming language's IO library look like if it were built with resource forks in mind, instead of files
< 1733269300 596522 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :(yes, *instead of*, not in addition to)
< 1733270207 459493 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Soni: well a resource fork is part of a file – do you mean that executables would look at their own resource fork?
< 1733270222 608506 :ais523!~ais523@user/ais523 QUIT :Quit: sorry about my connection
< 1733270243 174646 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1733270245 655428 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :... did you just quit after replying
< 1733270257 585212 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I misclicked
< 1733270261 150835 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :oh
< 1733270264 551650 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :thus the fast rejoin
< 1733270283 706047 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :have you heard of "file-dir duality"?
< 1733270291 83299 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :accidentally opened my OS's equivalent of a start menu trying to tab away from the window, then accidentally clicked the close window button trying to close the menu
< 1733270310 866061 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Soni: no – it's possible that I'll know the concept under another name
< 1733270327 882086 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :is it the way you can treat, e.g., a zip file as though it were a directory, and in theory vice versa although most filesystems don't do that?
< 1733270351 109243 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :do you know how http://foo.example/bar is not the same as http://foo.example/bar/ ?
< 1733270371 842624 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :indeed, although websites often choose to treat them the same way
< 1733270389 592245 :Soni!~quassel@sodapop.autistic.space PRIVMSG #esolangs :yes, so file-dir duality is the same but for the filesystem