< 1632009839 726288 :Melvar!~melvar@dslb-178-001-195-022.178.001.pools.vodafone-ip.de PRIVMSG #esolangs :TIL about memfd_create, which is an operation I expected to exist for years (I think) but only found today.
> 1632010224 166785 PRIVMSG #esolangs :14[[07Wariolang14]]4 M10 02https://esolangs.org/w/index.php?diff=88090&oldid=86323 5* 03Nakilon 5* (+0) 10typo in category template
< 1632011731 708106 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :hmmmm
< 1632011789 528953 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :imagine ( and ) to mark a piece of funge code as one instruction for # and j
< 1632011802 413056 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :so #(would jump over all this)
< 1632011825 99337 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :bad thing is that there is no vertical ( ) in ascii at least
< 1632012015 598587 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :In Funge-98, the ; instruction jumps to the next ; on the path of the IP in the same delta in no time (as if it was empty space).
< 1632012046 277378 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :oh that's cool
< 1632012109 310566 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :(So arguably it's less of an instruction and more a syntax for denoting a space-time wormhole.)
< 1632012137 897847 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :this just makes one-line branching easier
< 1632012144 968789 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :no need to calculate j shift
< 1632015365 489061 :oerjan!oerjan@sprocket.nvg.ntnu.no QUIT :Quit: Nite
< 1632017923 778323 :earendel!uid498179@user/earendel QUIT :Quit: Updating details, brb
< 1632017933 379491 :earendel!uid498179@user/earendel JOIN #esolangs earendel :AmoreFS
< 1632023377 421380 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :The transpose and inverse of a rotation matrix are the same, according to some FAQ. I feel like that can help clear up some questions I had recently
< 1632025057 272663 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :Hmm, are translations not considered a form of rotation in a higher dimension? The transpose of a translation matrix certainly doesn't look like it inverts the translation
< 1632025518 340300 :delta23_!~delta23@user/delta23 JOIN #esolangs delta23 :delta23__
< 1632025559 161395 :delta23!~delta23@user/delta23 QUIT :Killed (NickServ (GHOST command used by delta23_))
< 1632025561 137915 :delta23_!~delta23@user/delta23 NICK :delta23
< 1632027562 621151 :tromp!~textual@dhcp-077-249-230-040.chello.nl JOIN #esolangs * :Textual User
< 1632027624 543496 :tromp!~textual@dhcp-077-249-230-040.chello.nl QUIT :Client Quit
< 1632027722 355149 :earendel!uid498179@user/earendel PRIVMSG #esolangs :if you want to first A) translate and then B) rotate .. you can calculate the final matrix by multiplying B with transposed A matrix (A*)
< 1632027804 908245 :earendel!uid498179@user/earendel PRIVMSG #esolangs :the order here is important. as translating first would set the pivot point of the rotation.
< 1632027957 604744 :int-e!~noone@int-e.eu QUIT :Ping timeout: 245 seconds
< 1632027966 458042 :int-e!~noone@int-e.eu JOIN #esolangs int-e :Bertram
< 1632028099 24717 :earendel!uid498179@user/earendel PRIVMSG #esolangs :you can do all kind of transformations by multiplicating the inverse matrices continuously...ending up with a final matrix which you can apply to all points. usually the last one is some projection matrix resulting in some pixel coordinates for the 2D screen
< 1632029682 250959 :earendel!uid498179@user/earendel PRIVMSG #esolangs :oh. the transpose and inverse of a rotation matrix. A* is transposed A. right? no clue what inversed A is. yet.
< 1632029898 339494 :delta23_!~delta23@user/delta23 JOIN #esolangs delta23 :delta23__
< 1632029901 341872 :delta23_!~delta23@user/delta23 QUIT :Client Quit
< 1632030065 337705 :delta23!~delta23@user/delta23 QUIT :Ping timeout: 268 seconds
< 1632035044 327221 :imode!~imode@user/imode QUIT :Ping timeout: 252 seconds
< 1632035502 347362 :tromp!~textual@dhcp-077-249-230-040.chello.nl JOIN #esolangs * :Textual User
< 1632035902 336850 :monoxane!~monoxane@119-18-17-227.771211.mel.static.aussiebb.net QUIT :Ping timeout: 252 seconds
< 1632038567 426682 :tromp!~textual@dhcp-077-249-230-040.chello.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1632038759 638561 :hendursa1!~weechat@user/hendursaga JOIN #esolangs hendursaga :weechat
< 1632038964 442203 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer
< 1632038967 655738 :hendursaga!~weechat@user/hendursaga QUIT :Ping timeout: 276 seconds
< 1632039599 320516 :tromp!~textual@dhcp-077-249-230-040.chello.nl JOIN #esolangs * :Textual User
< 1632042275 352314 :earendel!uid498179@user/earendel PRIVMSG #esolangs :i was just thinking about rotational speed of a spinning body.. and
< 1632042862 419116 :earendel!uid498179@user/earendel PRIVMSG #esolangs :wondered how relativity laws would play in such.. realizing that measure of total speed is 0 at center .. and grows larger with radius.. also know ice-dancers when pulling their arms in.. gain speed .. why? and .. is a center even moving at all? can this be calculated with calculus and ..
< 1632043062 75735 :earendel!uid498179@user/earendel PRIVMSG #esolangs :also like a few days ago, i read about a function that could approximately calculate a continous sin wave, with a starting value of sth with sin^2 and stepsize .. a wild association to the question if rotation is sth like translation but different :p
< 1632045674 15879 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :someone on reddit asked wtf is the "summer shower"
< 1632045679 819227 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :don't you guys have it?
< 1632045779 196826 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :like this one https://dachnye-reshenia.ru/wp-content/uploads/2016/11/%D0%AD%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC-1.jpg
< 1632045848 918930 :riv!~river@tilde.team/user/river PRIVMSG #esolangs :i dont have that
< 1632045866 685162 :riv!~river@tilde.team/user/river PRIVMSG #esolangs :does it kill you?
< 1632045896 869570 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :ahahah
< 1632047239 635810 :spruit11!~quassel@2a02:a467:ccd6:1:6:b8f5:e5f3:4cce JOIN #esolangs * :anon
< 1632047468 123925 :spruit11_!~quassel@2a02:a467:ccd6:1:563:f225:f6bf:7d85 QUIT :Ping timeout: 268 seconds
< 1632049657 852627 :tech_exorcist!txrcst@user/tech-exorcist/x-0447479 JOIN #esolangs tech_exorcist :he/him
< 1632049968 594944 :monoxane!~monoxane@119-18-17-227.771211.mel.static.aussiebb.net JOIN #esolangs monoxane :monoxane
< 1632050956 850931 :tech_exorcist!txrcst@user/tech-exorcist/x-0447479 QUIT :Ping timeout: 252 seconds
< 1632054209 568006 :riv!~river@tilde.team/user/river PRIVMSG #esolangs :the X + X = N thing is kind of like this http://www.inference.org.uk/cds/part3.htm
< 1632054222 910695 :riv!~river@tilde.team/user/river PRIVMSG #esolangs :except this is X - X = Z/nZ I guess
< 1632054291 561995 :riv!~river@tilde.team/user/river QUIT :Quit: Leaving
< 1632054610 974631 :riv!~river@tilde.team/user/river JOIN #esolangs river :river
< 1632054989 118304 :arseniiv_!~arseniiv@136.169.204.31 JOIN #esolangs * :the chaotic arseniiv
< 1632055175 146942 :riv!~river@tilde.team/user/river PRIVMSG #esolangs :could you do X - X = N?
< 1632055191 434814 :riv!~river@tilde.team/user/river PRIVMSG #esolangs :i suppose powers of 2 would work
< 1632055213 546490 :riv!~river@tilde.team/user/river PRIVMSG #esolangs :maybe fibs too?
< 1632055861 820714 :Thelie!~Thelie@business-24-134-17-157.pool2.vodafone-ip.de JOIN #esolangs * :Thelie
< 1632056110 812945 :earendel!uid498179@user/earendel QUIT :Quit: Connection closed for inactivity
< 1632056196 147255 :tromp!~textual@dhcp-077-249-230-040.chello.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1632056427 767357 :spruit11!~quassel@2a02:a467:ccd6:1:6:b8f5:e5f3:4cce QUIT :Quit: https://quassel-irc.org - Chat comfortably. Anywhere.
< 1632056621 580455 :tromp!~textual@dhcp-077-249-230-040.chello.nl JOIN #esolangs * :Textual User
< 1632057344 763843 :arseniiv_!~arseniiv@136.169.204.31 QUIT :Quit: gone too far
< 1632057500 338664 :arseniiv!~arseniiv@136.169.204.31 JOIN #esolangs * :the chaotic arseniiv
< 1632057649 852823 :riv!~river@tilde.team/user/river QUIT :Quit: Leaving
< 1632057748 864506 :riv!~river@tilde.team/user/river JOIN #esolangs river :river
< 1632058358 924658 :Thelie!~Thelie@business-24-134-17-157.pool2.vodafone-ip.de QUIT :Remote host closed the connection
< 1632058980 846795 :tech_exorcist!txrcst@user/tech-exorcist/x-0447479 JOIN #esolangs tech_exorcist :he/him
< 1632059221 89152 :hendursa1!~weechat@user/hendursaga QUIT :Quit: hendursa1
< 1632059247 637476 :hendursaga!~weechat@user/hendursaga JOIN #esolangs hendursaga :weechat
> 1632059997 828951 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Leomok2009 5* 10New user account
< 1632060198 242631 :tromp!~textual@dhcp-077-249-230-040.chello.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1632060508 416550 :src!~src@user/src JOIN #esolangs src :realname
< 1632061801 854277 :tromp!~textual@dhcp-077-249-230-040.chello.nl JOIN #esolangs * :Textual User
> 1632063946 315906 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Iamn00b 5* 10New user account
> 1632064181 281196 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=88091&oldid=88070 5* 03Iamn00b 5* (+272) 10
> 1632064515 322304 PRIVMSG #esolangs :14[[07User:Iamn00b14]]4 N10 02https://esolangs.org/w/index.php?oldid=88092 5* 03Iamn00b 5* (+123) 10Created page with "sup
is me, iamn00b
my discord is randomguy#0047
so far, i've made 1 lang spec: LCCBED, coming up"
< 1632064523 343010 :earendel!uid498179@user/earendel JOIN #esolangs earendel :AmoreFS
> 1632065882 326873 PRIVMSG #esolangs :14[[07LCCBED14]]4 N10 02https://esolangs.org/w/index.php?oldid=88093 5* 03Iamn00b 5* (+1809) 10Created page with "LCCBED stands for "Letter Command Brainf*** Enhanced Derivative. It was created by [[User:Iamn00b]] in 2021. Its goal was simple: to make a slightly more confusing yet wonderf..."
< 1632067360 403025 :tromp!~textual@dhcp-077-249-230-040.chello.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1632068109 693054 :river!~river@tilde.team/user/river JOIN #esolangs river :river
< 1632068248 859239 :riv!~river@tilde.team/user/river QUIT :Ping timeout: 252 seconds
< 1632068582 339117 :arseniiv!~arseniiv@136.169.204.31 QUIT :Ping timeout: 268 seconds
< 1632070011 334677 :imode!~imode@user/imode JOIN #esolangs imode :imode
< 1632070459 338555 :arseniiv!~arseniiv@136.169.204.31 JOIN #esolangs * :the chaotic arseniiv
< 1632071782 395740 :tromp!~textual@dhcp-077-249-230-040.chello.nl JOIN #esolangs * :Textual User
< 1632072030 232966 :immibis_!~hexchat@62.156.144.218 NICK :immibis
< 1632072467 342110 :arseniiv!~arseniiv@136.169.204.31 QUIT :Ping timeout: 268 seconds
< 1632072621 433627 :delta23!~delta23@user/delta23 JOIN #esolangs delta23 :delta23__
< 1632072822 883857 :Melvar!~melvar@dslb-178-001-195-022.178.001.pools.vodafone-ip.de PRIVMSG #esolangs :earendel: Pulling their arms in to gain speed: It’s preservation of angular momentum. Pulling in the arms decreases their moment of inertia, requiring their angular velocity to increase in order to maintain angular momentum.
< 1632073195 614993 :arseniiv!~arseniiv@136.169.204.31 JOIN #esolangs * :the chaotic arseniiv
< 1632073678 138581 :tromp!~textual@dhcp-077-249-230-040.chello.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1632074318 211774 :earendel!uid498179@user/earendel PRIVMSG #esolangs :are you sure it is inertia? how is the angular momentum calculated? like impulswe? mv? [and furtner on the relativity shizle: imagine the length of their arms beim 0,4 lightyears long. and no friction. and they would turn full angle once per year. so the speed of her fingertips would close on speed of light o)o ]
< 1632074605 816196 :earendel!uid498179@user/earendel PRIVMSG #esolangs :[ .. is angular velocity somehow accumulative with the movement of something which radius is bigger > 0 through space? ]
< 1632074606 129899 :j-bot!~jbot@irc.supplies PRIVMSG #esolangs :earendel: |spelling error
< 1632074606 162484 :j-bot!~jbot@irc.supplies PRIVMSG #esolangs :earendel: | .. is angular velocity somehow accumulative with the movement of something which radius is bigger > 0 through space? ]
< 1632074606 162531 :j-bot!~jbot@irc.supplies PRIVMSG #esolangs :earendel: | ^
< 1632074957 531927 :ais523!~ais523@213.205.242.138 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1632074971 758744 :earendel!uid498179@user/earendel PRIVMSG #esolangs :okay. it wouls obviously take some energy to slow down roatation of earth. and that inertia is due to its mass. and if you would shrink the earth, but keeping the mass, it would turn faster. right?
< 1632074997 557848 :tromp!~textual@dhcp-077-249-230-040.chello.nl JOIN #esolangs * :Textual User
< 1632075070 540327 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I'm currently trying to figure out how to implement Java-style interfaces in a new language I'm working on (a Java-style interface is basically a set of methods that can be implemented by more than one class, classes can implement more than one interface, and you can have a reference to an object that conforms to a particular interface without knowing what class it has, and call methods of the interface on it)
< 1632075072 818294 :earendel!uid498179@user/earendel PRIVMSG #esolangs :the dancer doesn't lose weight. it just centers towards its fuckn massenscshwerpunkt. can u roger taht.lol. ok. spacecowboys. sry for spamming.
< 1632075129 916907 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I feel like there has to be an easier way than the standard methods of doing it, but can't think of one
< 1632075133 770429 :APic!apic@apic.name PRIVMSG #esolangs :ais523 > *
< 1632075147 805910 :APic!apic@apic.name PRIVMSG #esolangs :ais523: You do not even need to do the Sokoban-Solver now because somebody else did 😸
< 1632075157 864775 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :APic: I don't think I was working on a Sokoban solver
< 1632075163 886731 :APic!apic@apic.name PRIVMSG #esolangs :But it would still rock to pack it into the NetHack4-Frontend 😉
< 1632075168 474155 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I was working on a Sokoban /generator/ at one point, but that's a different problem
< 1632075180 338232 :APic!apic@apic.name PRIVMSG #esolangs :True
< 1632075192 211545 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :oh, unless you count TAEB's Sokoban-solving routines, but they just used a hardcoded/memorized solution rather than actually solving the puzzle
< 1632075197 753705 :APic!apic@apic.name PRIVMSG #esolangs :But when You have a good Generator, the Solver is not that far ahead
< 1632075215 487704 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I could probably adapt the generator into a solver, but it isn't really a "good" generator yet
< 1632075261 871219 :APic!apic@apic.name PRIVMSG #esolangs :If it can solve _my_ SokoBan on NetHack.ALT.Org and/or nethack@EU.HardFought.Org i am very glad to try it out in two Days, when the green Cheese will be highly illuminated again
< 1632075338 260851 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :hmm, this conversation has indirectly taught me something about German grammar: "jemand" is technically a pronoun, not a noun, so it doesn't start with a capital letter
< 1632075385 390856 :APic!apic@apic.name PRIVMSG #esolangs :Indeed
< 1632075387 827687 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :the hard part of an automated Sokoban solver for playing NetHack isn't the actual solving, though, but doing the inputs (and fighting monsters along the way)
< 1632075411 650143 :APic!apic@apic.name PRIVMSG #esolangs :Yes, so i can procrastinate my other Tasks further 😸
< 1632075419 240165 :earendel!uid498179@user/earendel PRIVMSG #esolangs :green cheese?
< 1632075423 615393 :APic!apic@apic.name PRIVMSG #esolangs :The Moon.
< 1632075430 633715 :earendel!uid498179@user/earendel PRIVMSG #esolangs :ah.
< 1632075447 522059 :earendel!uid498179@user/earendel PRIVMSG #esolangs :wow. elliott?
< 1632075464 678065 :earendel!uid498179@user/earendel PRIVMSG #esolangs :pardon. i was confusing you with somebody else.
< 1632075481 463913 :ais523!~ais523@213.205.242.138 QUIT :Quit: sorry about my connection
< 1632075484 801464 :APic!apic@apic.name PRIVMSG #esolangs :Happens
< 1632075495 111018 :ais523!~ais523@213.205.242.138 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1632075496 147780 :APic!apic@apic.name PRIVMSG #esolangs :Especially because of my Hebephrenia.
< 1632075499 886579 :APic!apic@apic.name PRIVMSG #esolangs :wb ais523
< 1632075523 721538 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :…oh wow, I think I've seen this problem before
< 1632075533 101404 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :vtables for interfaces is the "match these inputs to these outputs" problem
< 1632075590 717331 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :i.e. given a set of (input, expected output) pairs, to generate a function that maps each of the provided inputs to the matching output, and it doesn't matter what the function does with other inputs
< 1632075639 556421 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I found a really neat solution to this a while ago in terms of minimizing the size of the generated function: https://codegolf.stackexchange.com/questions/105303/help-me-recognise-my-monster/214222#214222
< 1632075643 61577 :APic!apic@apic.name PRIVMSG #esolangs :vtables 13,4♥
< 1632075649 933635 :APic!apic@apic.name PRIVMSG #esolangs :Reminds me or good old Bobby Tables 😉
< 1632075661 358400 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :although, it may have bad performance
< 1632075722 514544 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :x86-64 has finite field builtins nowadays, but most of them deal with GF(2⁸), you'd want GF(2⁶⁴) for this
< 1632075749 683099 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :would be fun to see VPCLMULQDQ in a virtual method lookup routine
< 1632075752 883089 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :(but probably not efficient)
< 1632075897 838960 :APic!apic@apic.name PRIVMSG #esolangs :Epic Mnemonic.
< 1632075947 616150 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :maybe some sort of cuckoo hash is the right solution here? what we want is effectively a map structure with a) space-efficient storage, b) fast lookup; being able to modify it efficiently is not important
< 1632075954 774213 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :the construction I linked above handles a) but probably not b)
< 1632076138 98476 :earendel!uid498179@user/earendel PRIVMSG #esolangs :i think the crux is really to program against those interfaces. instead of mapping whatever model you have straight onto a view. better make it smalltext, longtext, headertext instead of isbn, vendor-description, vendor-titla-bla .. i mean. in the end you always end up with listst of some (expandible) blocks containing text, graphics, and buttons, and maybe moving parts. a detailed view of items. a formular to edit. [beside the genereric
< 1632076138 172864 :earendel!uid498179@user/earendel PRIVMSG #esolangs :extension things which are cool and final .net]
< 1632076158 611700 :Everything!~Everythin@37.115.210.35 JOIN #esolangs * :Everything
< 1632076164 484168 :earendel!uid498179@user/earendel PRIVMSG #esolangs :this would distinct interfaces from adapters which just map things together.
< 1632076209 571503 :earendel!uid498179@user/earendel PRIVMSG #esolangs :designing the interface. like not writing a line of code for years. is dharma-body of buddha.
< 1632076211 177245 :earendel!uid498179@user/earendel PRIVMSG #esolangs :brudi.
< 1632076364 492052 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :Rust's solution to this is to make "as" magic, I think; when casting from an object-pointer to an interface-pointer type, it adds extra metadata that specifies a vtable for that object implementing that interface
< 1632076376 649761 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I'm not sure how it handles casts from an interface-pointer type to a different interface-pointer type
< 1632076381 104672 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :time to try some experiments, I think
< 1632076383 524363 :earendel!uid498179@user/earendel PRIVMSG #esolangs :what i mean is: imagine you have that mediaplayer interface. and you want to be able to sick it at your robotsexslave, ../
< 1632076390 242660 :earendel!uid498179@user/earendel PRIVMSG #esolangs :ok.
< 1632076657 761770 :earendel!uid498179@user/earendel PRIVMSG #esolangs :i mean something like decorators is also not bad. mechanics: simple, bootstrap: little, lazyppl: lit
< 1632076746 458427 :earendel!uid498179@user/earendel PRIVMSG #esolangs :started viewing rust tutorial yesterday. u r right. first we have to rewrite the browser in rust. yes.
< 1632076759 346593 :earendel!uid498179@user/earendel PRIVMSG #esolangs :im soon on board now.
< 1632076912 302545 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :…oh wow, I think you *can't* cast from one interface-pointer type to another in Rust
< 1632076925 395763 :earendel!uid498179@user/earendel PRIVMSG #esolangs :then we create p2p distributed ai rss seti graph protocoll for querying news feeds.
< 1632076935 414470 :earendel!uid498179@user/earendel PRIVMSG #esolangs :rust.
< 1632077239 77359 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :after searching a bit more, I discovered that there are crates which add extra metadata to allow casting from one trait object type to another, which makes it very likely that there's no way to do it using Rust's usual implementation of trait objects (otherwise you wouldn't need the crate)
< 1632077252 519335 :earendel!uid498179@user/earendel PRIVMSG #esolangs :all i got so far is it has this owner concept. vars belond to some actors/subjects and can be lend to others, and kinda im/explicitly passed back etc. variables and scopes and garbage collector follow stricter rules. also no inheritanve but composing traits.
< 1632077271 479681 :earendel!uid498179@user/earendel PRIVMSG #esolangs :crates were like packages or sth right?
< 1632077334 762819 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :there's no garbage collector in rust
< 1632077364 396040 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :it's all based on smart-pointers and references
< 1632077367 400602 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :very similar to modern C++
< 1632077384 961396 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :but unlike C++, the compiler is able to check at compile time that references don't outlive the thing they refer to
< 1632077420 752103 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I think of Rust as being a language which lets you write clever code, but you need to be able to prove that what you're doing makes sense (and the proof ends up inside the source code as documentation of what it's doing)
< 1632077459 976704 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :not only that but it enforces a "many readers xor one writer" rule for references
< 1632077483 439183 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :if you have a &mut reference to something then it checks that other references are not being touched at the same time
< 1632077496 624723 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :this prevents iterator invalidation errors, which are a huge source of undefined behavior in C++
< 1632077500 943578 :earendel!uid498179@user/earendel PRIVMSG #esolangs :it's really for the solid bone of something. but still they say its only liek 10% less performant (with gui and bglah) than c cod .. that guy said.
< 1632077520 438801 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :any kind of broad performance comparion like that is useless
< 1632077523 364742 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :it deends on the use case
< 1632077531 269891 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I still don't really like the &mut name – the invariant is that while the reference is alive, it's the only way to refer to the object, it isn't really related to mutability
< 1632077545 75240 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :you can mutate things through & references if they're designed appropriately
< 1632077548 244128 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :and you can always bypass the static checking and do it the exact same way you would in C
< 1632077555 476408 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :if you can't figure out a zero overhead way to make the static checking happy
< 1632077559 717015 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :ais523: yes, and yes
< 1632077615 157490 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I guess the reason for the name is that in order to mutate something in Rust, you have to prove that the mutation of it is safe, and "this is the only reference" is an easy way to prove that it's safe
< 1632077637 734294 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :right
< 1632077644 529227 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :but as you said there are other types that let you prove that another way
< 1632077654 996968 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :Cell, RefCell and AtomicFoo
< 1632077659 919177 :earendel!uid498179@user/earendel PRIVMSG #esolangs :keegan: sorry. but i think its worth to take note of its high performance. dont say its useless when it can give u a hint if u can need it or not. like 1 of 5.
< 1632077671 747923 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :and Mutex, that's about it for the main ones
< 1632077687 317945 :earendel!uid498179@user/earendel PRIVMSG #esolangs :its some overhead you need that you can avarage down not calling it a benchmark.
< 1632077715 557028 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :…it just crossed my mind how similar Mutex and RefCell are
< 1632077740 261043 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :Mutex is basically just thread-safe RefCell, isn't it?
< 1632077841 396352 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :earendel: what i'm saying is there's nothing in Rust that provides an omnipresent overhead like a garbage collector or VM
< 1632077847 851248 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :it's bare metal compiled language
< 1632077867 684434 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :any overhead solely comes from whether you can express the most efficient way of doing things within the static safety constraints or not
< 1632077889 288281 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :it's kind of like arguing about the overhead of C++ versus C
< 1632077899 278408 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :would anyone say that C++ is 10% slower than C? of course not, it depends on how you write your C++
< 1632077904 862739 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :if it's full of virtual methods it might be slower
< 1632077910 154800 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :if you write very C-like code it might be the same
< 1632077912 779145 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :keegan: there is some overhead in the existing backends (not inherent in the language), e.g. in ensuring that the stack is always aligned and backtraceable; I'm the sort of person who gets irrationally annoyed by this
< 1632077921 188573 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :if you make heavy use of template metaprogramming it might even be faster than C
< 1632077928 603407 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :due to better opportunities for compile time specialization
< 1632077929 519715 :earendel!uid498179@user/earendel PRIVMSG #esolangs :right. lets skip that.
< 1632077931 946262 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :ais523: fair
< 1632077937 818183 :earendel!uid498179@user/earendel PRIVMSG #esolangs ::>
< 1632077997 538344 :tech_exorcist!txrcst@user/tech-exorcist/x-0447479 QUIT :Quit: see you tomorrow
< 1632078015 244464 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :a lot of C idioms are inefficient
< 1632078030 642093 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :keegan: that doesn't surprise me but I can't think of any examples right now
< 1632078036 963550 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :a lot of time a function pointer / void* dynamic polymorphism pattern is used when only static polymorphism is needed
< 1632078055 105622 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :whereas in C++ or Rust you would use generics and end up with more direct code and more optimization opportunities
< 1632078063 960145 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :ah right, the function pointer + void* method is a good example, ye
< 1632078065 355046 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :* yes
< 1632078073 449674 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :(of course this also relates to the compilation unit)
< 1632078144 659232 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :although there are tradeoffs, &dyn T (which is effectively equivalent to the function pointer + void * method) could be more efficient than &impl T if the generic function is large enough that instruction cache pressure is more of a bottleneck than branch mispredictions
< 1632078174 70095 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :that seems unlikely, though, branch mispredictions cost quite a lot so you'd need a huge amount of cache pressure to make the mispredictions cheaper
< 1632078286 156688 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :“ […] German grammar: "jemand" is technically a pronoun, not a noun, so it doesn't start with a capital letter” => and in Hungarian, you can only capitalize proper names if they're nouns, not adjectives, which I think is very silly, but we can't really change it now
< 1632078328 461942 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :true
< 1632078351 203939 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :in embedded code you might prefer the dynamic version to save on code space
< 1632078357 679831 :chiselfuse!~chiselfus@user/chiselfuse QUIT :Ping timeout: 276 seconds
< 1632078369 224741 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :but it's often the case in C that a "generic" library is only instantiated at /one/ client type
< 1632078382 756550 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :and in that case the static version would probably produce smaller code by specializing and removing unused stuff
< 1632078396 652615 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I think a good example are things like qsort, which are generic due to being compiled ahead-of-time but are often used at only one type in any given program
< 1632078444 648066 :chiselfuse!~chiselfus@user/chiselfuse JOIN #esolangs chiselfuse :chiselfuse
< 1632078449 892503 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :actually, memcpy is a really good example
< 1632078450 372790 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Templated C++ programs sometimes monomorphize and end up with huge binaries and ridiculous type names in stack traces and things.
< 1632078460 714043 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :although I think compilers special-case that one nowadays
< 1632078491 291917 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :shachaf: I think most modern systems langauges give a choice between monomorphization and dynamic dispatch, but there can be some debate about which to use
< 1632078507 13519 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :dynamic dispatch is needed if you have a heterogenous list, but there are many cases where both would work
< 1632078528 258140 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :the language I'm working on does both, but I realised I wasn't sure how to implement dynamic dispatch efficiently
< 1632078560 688667 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Dynamic dispatch is often implemented with some sort of boxing.
< 1632078574 50273 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: re type interfaces, to figure out what design you want, I think there are at least three questions about intended use that you should decide. 1. who is allowed to declare that a type implements an interface? only the module that defines the class, or only the module that defines the interface, or both? 2. in what namespace are the names of methods that interfaces provide? are they global, so you
< 1632078575 991936 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :But another alternative is the equivalent of passing in type size and alignment dynamically, but still having just one implementation.
< 1632078579 151338 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :E.g. in a data structure.
< 1632078580 61553 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :can define an interface after a method name is commonly used without an interface? namespaced so that if you define an interface and a method in it, existing methods with accidentally the same name won't clash with it?
< 1632078584 607360 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :I think maybe Swift does that?
< 1632078622 2683 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :b_jonas: I'm pretty sure that the correct solution for 2) is for the method name to be namespaced, so that two interfaces can define methods with the same names and a class can implement them both with different implementations if it wants to
< 1632078664 216606 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :most languages (e.g. Java) gets this wrong; Rust has an interesting compromise in which it gets it right, but with horrible syntax for disambiguating which method you need if you actually need to call the method after doing that
< 1632078698 232655 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :I wonder whether methods are an idea that makes sense at all.
< 1632078715 407014 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Probably?
< 1632078735 829139 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :they're useful when writing code out of order
< 1632078752 467527 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :like, writing generic code before you know what types it's going to be useful for
< 1632078768 727706 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :monomorphisation is very useful if it does end up getting used at only one type in practice
< 1632078815 397405 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Go resolves interfaces by doing type checking (including string comparison of method names and so on) at runtime.
< 1632078822 242997 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: in rust, when you define a trait, you can define that it's the subtrait of another trait, which more or less means that the vtbl has a reference to the vtbl of the supertrait. note also that rust doesn't allow you to cast from a ref to interface to a ref to a specific type that implements it, like C++'s dynamic_cast. if you want that, you have to define a method that does such a cast to one
< 1632078828 250396 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :specific type explicitly.
< 1632078866 137374 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :b_jonas: Rust lets you downcast to concrete types via Any nowadays, but it doesn't let you upcast from a trait to its supertrait
< 1632078907 211372 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :you can call methods of the supertrait on a trait object of the subtrait, but can't upcast to a supertrait object (which initially surprised me, but I couldn't figure out how it was implemented and discovered that it was illegal while experimenting, so maybe it's disallowed due to difficulty of implementation)
< 1632079057 309854 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :ah, seems relevant: https://stackoverflow.com/questions/28632968/why-doesnt-rust-support-trait-object-upcasting
< 1632079213 429914 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: re Mutex, yes, that's a good approximation, though I think the multi-threaded version of RefCell is std::sync::RwLock, which is slightly more powerful than Mutex. also Arc is the multi-threaded vesrion of Rc; and you can kind of think of std::sync::atomic::AtomicU32 as the multi-threaded version of Cell, though that analogy is more strained
< 1632079399 54202 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :you can't upcast from a trait to a supertrait? hmm
< 1632079409 333680 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I'm surprised there isn't a single-reader version of RefCell, actually; it would seem useful for performance in cases where you don't need multiple readers (unless the multiple-readers case is just as fast, which would seem unlikely)
< 1632079427 44701 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I see
< 1632079495 396876 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :it looks like the Rust developers want to implement trait→supertrait upcasting but doing so is hard
< 1632079518 611832 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :though rust now has default methods, and just like in haskell, only the trait can define what its supertraits are, so explicitly adding a method for upcasting from a trait to a specific supertrait should be easy enough,
< 1632079528 233856 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :so it's probably not a big problem
< 1632079547 997462 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: re "single-reader version of RefCell, do you mean a RefCell that you can only mut borrow??
< 1632079554 852922 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :b_jonas: right
< 1632079588 122940 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I'm not sure if you could implement that more efficiently than the current RefCell if you never borrow from it
< 1632079600 914931 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :that said, if you want something like that, you can impelment it yourself from UnsafeCell
< 1632079630 143254 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I actually implemented effectively that myself in a program I'm working on – I had what in effect wanted to be a Cell that held an enum, so I added an extra option to say that it was currently borrowed and unavailable
< 1632079635 563230 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :and then swap it out of the Cell whenever I want to work on it
< 1632079687 894441 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :this is pretty similar in practice to a single-reader RefCell
< 1632079773 614699 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :that could perhaps work, though I imagine if the enum is very large, then the optimizer might not see through that method properly
< 1632079870 672419 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :the inner enum doesn't happen to be the node type for the balanced tree library that you wanted to do at some point, right?
< 1632079874 816884 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :no
< 1632079901 499930 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :it switches between particular list implementations for an esolang
< 1632079928 676520 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :in which lists can potentially be larger than the computer's address space, and sometimes have their elements calculated lazily because of that
< 1632080022 398548 :Everything!~Everythin@37.115.210.35 QUIT :Quit: leaving
< 1632080395 784886 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: are the lists semantically mutable, and if not, can it change between representations after a value is created?
< 1632080867 640259 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :yeah, the second one is probably a silly question, obviously yes if you need a Cell
< 1632081097 848872 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :b_jonas: they're semantically immutable, but they can change representation after creation
< 1632081107 841113 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :(whilst still keeping the same value)
< 1632081245 92905 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :right. that comes up sometimes.
< 1632081624 595106 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :one idea I had for implementing vtables would be a sort of golomb-rulerish implementation where the address of each method was at a fixed offset from the start of the vtable, and you interleaved vtables in the dead space of each other in order to pack them more tightly in memory
< 1632081625 554105 :oerjan!oerjan@sprocket.nvg.ntnu.no JOIN #esolangs oerjan :Ørjan Johansen
< 1632081642 651772 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :but I don't know what the optimal packing density for that would be, or what sort of algorithm you'd use to achieve it
< 1632081780 455445 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :Huh. Isn't finding a Golomb ruler NP-complete?
< 1632081815 664562 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I'll also note that if you care that much about efficiency, you can impelment your custom dynamically typed object abstraction in rust with unsafe pointer dereferences, you aren't required to use the built-in dyn objects
< 1632081846 95080 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :Corbin: not if you don't want the shortest possible one
< 1632081856 875143 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :Ah, we don't know, but I was thinking of *optimal* Golomb rulers, which are harder.
< 1632081858 119184 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :Corbin: also not if you only have single-inheritance by the way
< 1632081879 376846 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :Corbin: also Fortran compilers are required to solve that sort of thing, so it's a kind of tradition
< 1632081889 228467 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I don't know if they're ever NP-complete by the way, just that it's not trivial
< 1632082087 255791 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I was thinking about the custom object thing in rust by the way, mostly because I want a *closed* set of types (enum as opposed to trait), dynamically allocated and you can't change their types, but with variable length, where you have to look at the discriminator (or custom flag bits) to figure out which methods and which destructor and deallocator to call
< 1632082127 910172 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :rust is trying hard to make sure that anything you would write in C you can implement as efficiently in unsafe rust
< 1632082178 361470 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :it's not quite there yet, because C compilers have grown a ton of extensions, often platform-specific ones, by now, but most of the time it's fine
< 1632082303 255764 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :rust has features that are there specifically to satisfy this, such as you can directly call C new style vararg functions from rust
< 1632082354 585846 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :Corbin: finding just any Golomb ruler is easy, finding optimal ones is hard
< 1632082382 838989 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and even define them
< 1632082385 413400 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :https://doc.rust-lang.org/nightly/unstable-book/language-features/c-variadic.html
< 1632082433 940746 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :it's there so you can interface with existing C programs that define or call a variadic function
< 1632082436 957739 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I vaguely remember that unsafe Rust has some way to simulate a C-style flexible array member
< 1632082495 271208 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: flexible array member: kind of, but not really. you can define a struct that notionally has a flexible array as its last member, and that struct is non-Sized,
< 1632082527 845048 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but the problem is, there's no reasonable way to *create* a value of such type, you more or less have to use pointer arithmetic for it. you can access such a type through pointers though.
< 1632082530 499354 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :your size-variable enums are also non-Sized
< 1632082558 786941 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :yes, this is more or less the correct approach,
< 1632082605 144868 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but C++ at some point planned to add a feature where there's an official way to declare a variable-sized type that knows its own size from a member that stores its size, and a way to construct them on the heap in a reasonably safe way, I think
< 1632082628 645176 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :one thing that I'd like to do in a systems language is to record type, lifetime, etc. information directly into pointers by allocating them in different parts of memory
< 1632082664 264643 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :so that, e.g., Cow<'static> would just be a single pointer, and you check to see whether the pointer is on the heap or in the executable in order to determine whether it's owned or borrowed
< 1632082670 735613 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :but, you can't do that in current Rust because of Box::leak
< 1632082681 535614 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :(which creates dynamically allocated static references)
< 1632082698 642717 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :what I'd really like is https://github.com/rust-lang/rfcs/blob/master/text/1861-extern-types.md to become stabilized
< 1632082726 288958 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :that lets you create types that are explicitly non-Sized so much that the language doesn't even know the size at runtime
< 1632082744 241070 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :that would be more general than just non-Sized array members
< 1632082764 558468 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :so far that feature is unstable
< 1632082797 455829 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and yes, they're more or less equivalent in power
< 1632082830 866036 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but saying that you have an unknown sized char array member is just notionally more silly than saying that you have an unknown type member
< 1632082842 976646 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :s/char/u8/
< 1632082889 850740 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :well, a flexible u8 array at least has the semantics that you're allowed to read the bytes
< 1632082919 217659 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :maybe that's correct for things that are Copy and have no trap/invalid representations? and an unknown type member for things that aren't?
< 1632082925 934420 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :probably an unknown type member is correct in most cases
< 1632082972 5363 :Melvar!~melvar@dslb-178-001-195-022.178.001.pools.vodafone-ip.de PRIVMSG #esolangs :earendel: Yeah the thing is that unlike linear momentum that is mass times velocity, angular momentum is moment-of-inertia times angular velocity. Moment of inertia is basically rotational inertia, but the neat thing is that it depends on the shape of the object (relative to the axis of rotation). For a single particle, the moment of inertia I = r²m, where m is the mass and r the rotational
< 1632082973 803026 :Melvar!~melvar@dslb-178-001-195-022.178.001.pools.vodafone-ip.de PRIVMSG #esolangs :radius, and the angular velocity ω = v/r where v is the linear velocity component perpendicular to the radius at any instant, giving the angular momentum L = Iω = rmv, so a single particle’s angular momentum is its instant linear momentum times the radius of rotation if it is circularly orbiting the center of rotation.
< 1632082987 262598 :tromp!~textual@dhcp-077-249-230-040.chello.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1632083010 320074 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :allowed to read which byte? it can be zero-sized.
< 1632083028 844287 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :any bytes that are proven to be there using size_of_val
< 1632083043 72691 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :(assuming that size_of_val is implemented, which it might not be I guess)
< 1632083046 221795 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I don't think that applies
< 1632083071 589415 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :the point of these types that unlike with slices and str and trait objects, even the compiler doesn't know how to compute the size of the object
< 1632083114 377385 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :you can only access the trailing part unsafely, when you guarantee you know (a lower bound) for the size, and can only deallocate it unsafely
< 1632083150 263445 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :ah, OK
< 1632083173 731954 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :this is mostly just a type system as in notation to avoid errors kind of thing, you can already use unsafe pointer dereferencing to implement all this
< 1632083198 742528 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :on that note: I think the programming world really needs to decide whether a) the allocator tracks the length of things that it allocates, in which case it might as well also track type information; or b) the allocating program tracks the length of things it allocates, in which case it should tell the allocator so that the allocator doesn't have to record that information separately
< 1632083231 855922 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :most existing programs/libraries try to do a) and b) simultaneously, leading to a lot of redundant work
< 1632083249 482158 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: I think you can genuinely want both of those
< 1632083251 689171 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :even in the same program
< 1632083266 268356 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :but for different allocations? or for the same allocation?
< 1632083282 394925 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :for different allocations. you must allow the caller to track the object size so that you can allocate small fixed size objects, like cons cells, without too much memory overhead;
< 1632083309 499338 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but you must allow something in the library or language to track the size so that you can allocate Box<[T]> or Vec
< 1632083344 212549 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :hmm, perhaps there should be malloc8, malloc16, malloc24, malloc32 functions for allocating specific small numbers of bytes (and a corresponding free8, free16, free24, free32)
< 1632083360 576932 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :existing mallocs can't normally do less than 8 bytes anyway
< 1632083368 642509 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :and are quite wasteful for very small allocations
< 1632083403 843512 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: yes, you can have the allocator be an inline function that handles the fast case, and calls a non-inline function for the difficult case, and nudge the compiler to constant fold the common case of known size
< 1632083413 798961 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :C++ new/delete hopefully already does that
< 1632083416 848375 :user3456!user3456@user/user3456 NICK :rip-libera-offto
< 1632083428 778698 :rip-libera-offto!user3456@user/user3456 NICK :user3456
< 1632083564 229999 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: in rust, the public interface for the default allocator is Box, which can do both fixed size (Sized) and dynamic size (slice) allocations, and has an interface to turn a Box to a plain pointer or pointer plus size (to simulate new) and back to a Box later (to simulate delete)
< 1632083645 8969 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and since T in Box is a type parameter, it is very likely that the compiler will constant fold the size to the inline part of the function
< 1632083663 60687 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :b_jonas: C++ new/delete doesn't seem to do that at present: https://godbolt.org/z/so19cnK93
< 1632083665 703796 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :at least not in gcc
< 1632083671 880053 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :generic parameters, in both C++ and rust, are the current state of the art to strongly nudge the compiler to constant-fold a value, since it's hard to figure that out otherwise
< 1632083684 895295 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I think ziglang has an explicit notation for a parameter that should be constant-folded
< 1632083738 951633 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :in Rust, I think it's more interesting to look at the public interface *from* the allocator (i.e. if you're replacing an allocator, what it gets to see)
< 1632083768 859216 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html
< 1632083781 163864 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: I admit I've never looked at that
< 1632083790 344 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I don't think I'll want to replace the global allocator
< 1632083803 399103 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :write a custom allocator that only my code uses, sure
< 1632083805 622639 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but not the global one
< 1632083808 251971 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :it looks like it's the responsibility of the code to track the size, under Rust's API
< 1632083822 71713 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :but there's no ability to specialise on the `Layout` parameter
< 1632083864 980502 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :to a large part this is because if I want a custom allocator, I probably want it to have a special interface, and not impelement it to work as a global allocator
< 1632083876 297910 :oerjan!oerjan@sprocket.nvg.ntnu.no PRIVMSG #esolangs : could you do X - X = N? <-- as a bijection? no. you obviously will get 0 in many ways.
< 1632083954 755148 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I guess part of the problem is that when allocating arrays, the element type will usually be known at runtime but the number of elements might not be
< 1632084048 57293 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I don't see why that's a problem
< 1632084048 268969 :oerjan!oerjan@sprocket.nvg.ntnu.no PRIVMSG #esolangs :oh, in the cyclic difference thing you explicitly exclude that particular case
< 1632084118 553630 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :b_jonas: the reason why you can't just make the layout a generic/compile-time parameter and specialise on it, as opposed to a runtime parameter
< 1632084158 296255 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :although, I guess you can just use an if statement, and hope that link-time optimisation will inline the relevant part of the function?
< 1632084158 547463 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :yes
< 1632084188 644214 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :hmm, knowing whether something is an array seems like important information for an allocator
< 1632084192 975579 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :you will need both allocations with compile-time known size, and ones with only runtime known sized
< 1632084201 924484 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :e.g. "this will never be realloc()ed" could be a useful piece of information to know for performance optimisations
< 1632084202 198200 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and you will want this distinction in the type of the smart pointer
< 1632084245 892052 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :oh, you want a fancy realloc that doesn't just check the capacity and malloc,memcpy,free if too small?
< 1632084257 547773 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I rarely think of that optimization
< 1632084272 225731 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I'm not sure it's really worth
< 1632084303 300302 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :one example is, if something is fairly large (at least pages) and reallocable, to mmap it at a random memory address so that you can expand it with mremap if necessary, rather than having to copy to different physical memory
< 1632084325 792354 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :whereas things that aren't reallocable make more sense to pack densely
< 1632084337 511071 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :hmm
< 1632084346 422001 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :maybe, that's just not a case I thought of much
< 1632084425 746573 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I think it probably makes more sense for the program to track the size for small non-resizable things, and for the allocator to track the size for large resizable things
< 1632084463 481610 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :…now I'm wondering if programs get to read their own page tables, probably not
< 1632084492 181761 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I think it's up to the kernel to decide whether it maps the page tables (or parts of them) somewhere a process can see them or not
< 1632084518 97229 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :(I remember an experiment in which someone wrote a kernel module to let programs write directly to their own page tables at runtime, in order to investigate how the processor handled changes)
< 1632084590 485494 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :the program read its own page tables? that would rarely be useful for a user-space probram
< 1632084652 315171 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :Web of Lies had some reason to do it, IIRC
< 1632084684 502360 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :although it accomplished it by parsing /proc/self/maps, which isn't very efficient (and even then that doesn't tell it the physical addresses, but it didn't care about that)
< 1632084805 136190 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: it's hard to care about the physical addresses, because the kernel has the right to change them at any time
< 1632084824 303547 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :it'll rarely do that, mostly for suspending the computer or hotswapping RAM, but still
< 1632084840 468396 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :right, the only time I can think of when it actually would would be during hibernate+unhibernate
< 1632084861 190409 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :no, it can also do that to swap them out, but you can stop swapping with mlock
< 1632084875 981467 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and in theory it could also do that to automatically turn them to hugepages
< 1632084887 18959 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :oh right, swap+unswap
< 1632084888 668771 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and to compress or deduplicate them, but those are mostly just swapping
< 1632084897 819383 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :a program could look at its own page tables to see if memory was swapped out at the time
< 1632084903 818382 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :but I think there's an API to check that, isn't there?
< 1632084906 611180 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but if you care about the physical address, you probably mlock the memory
< 1632084909 737827 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :actually there's a processor instruction to check that
< 1632084924 58221 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :so you don't even need to ask the kernel
< 1632084927 878150 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :(VERR)
< 1632084928 760720 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: iirc there's some new API too for some reason, not just the processor instruction
< 1632084938 639929 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :why you need it with the instruction there I don't remmeber
< 1632084958 468174 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :mincore(2) system clal
< 1632084974 721857 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :ah no, VERR checks a /segment/, not an address
< 1632085000 684374 :tromp!~textual@dhcp-077-249-230-040.chello.nl JOIN #esolangs * :Textual User
< 1632085005 149160 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :that… doesn't seem very useful
< 1632085020 509161 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :no wonder VERW got repurposed for some sort of Spectre mitigation
< 1632085025 219054 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :it's rarely useful, but it was added for some specific weird reason
< 1632085034 35149 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :oh, you mean VERR?
< 1632085038 72694 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :um
< 1632085040 123143 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I don't know about that
< 1632085078 89019 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :(VERR/VERW run in microcode and don't require privilege to use, so it was possible to patch it to flush the caches that needed to be flushed to stop some specific Spectre abuse, then do the intended functionality of VERW afterwards just in case someone was using it for its intended purpose)
< 1632085164 927635 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: is that with or without some extra prefix to VERR?
< 1632085197 401144 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :b_jonas: no prefix needed
< 1632085199 538398 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :x86 has some prefixed combinations that do the same as without the prefix on all existing CPUs but also isn't required to do the same thing, so they can be repurpused for things like this
< 1632085220 309288 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :in order to be backwards-compatible it had to be some existing instruction that wasn't supervisor-only and is a no-op on older CPUs
< 1632085227 887169 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :and also microcoded
< 1632085256 458928 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :there are backwards-compatible NOPs like endbr64, but those are hardcoded to not do anything on existing processors, you can't change what they do with a microcode update
< 1632085273 325751 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I see
< 1632085293 430084 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :VERR and VERW are near-no-ops (they just change one flag) and so are quite easy to work into a program
< 1632085297 205349 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :sounds like an interesting partial workaround
< 1632085311 701048 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :and their functionality can be updated in firmware
< 1632085330 810045 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but I'm also glad I could just buy a cpu that was already designed to be careful with Spectre-like vulns\
< 1632085378 819311 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :well, Spectre affects all major CPU families with speculative execution, I think (it's Meltdown that was Intel-specific)
< 1632085405 327798 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: yes, so there need to be separate fixes for Intel and AMD, to multiple similar vulns
< 1632085447 257402 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but the point is that the Spectre and its relatives are now old enough that the latest CPU microarchitectures were designed when they were already known and so designed to avoid them
< 1632085477 257109 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and IIUC the CPU that I bought for my new home computer is one of those
< 1632085512 557422 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :though I still wouldn't want to run one of those evaluator bots like HackEso or perlbot on my normal home desktop
< 1632085517 969853 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I'm not sure if they're fully designed to avoid them because it would hurt performance, they just have mitigations
< 1632085577 996048 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 265 seconds
< 1632085596 32349 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I'll only run such bots if I have a separate computer hardware for that kind of thing, or if I pay for a separate virtual machine at a hosting provider
< 1632085608 28048 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord
< 1632085639 590720 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: they probably can't protect from all the timing attacks, yes
< 1632085681 354257 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but they can protect from the ones where you can do an indexed memory access or jump where the address is speculatively evaluated and effectively *read* memory that you don't have access to from that
< 1632085693 884108 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :which is much better
< 1632085805 787729 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :this means that if you decode a block cypher then verify the program, and write it carefully to not leak timing data, then another process won't be able to read your ephemeral key or cleartext etc
< 1632085823 974033 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :unless it's like leaked in the form of variable power usage or wifi interference
< 1632085893 373484 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :whereas on old CPUs without mitigations, some other process could often just directly read bits of the ephemeral key if it was in cache and could guess the address
< 1632085952 482926 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :that was just too bad for cryptography in practice
< 1632086000 448072 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :or similarly, they might be able to read bits of private data in another process, regardless of whether cryptography is involved
< 1632086042 852508 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :there are still side-channels for lots of things, but hopefully fewer practical ones
> 1632086323 455883 PRIVMSG #esolangs :14[[07User:PolySaken14]]4 10 02https://esolangs.org/w/index.php?diff=88094&oldid=84930 5* 03PolySaken 5* (+252) 10
< 1632086579 371278 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :huh, odd
< 1632086626 360492 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :they sent me an encrypted pdf file that I can't open, the pdf reader says incorrect password
< 1632086629 366930 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I wonder what could be wrong
< 1632086682 15450 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I hope it's not something stupid like I need a newer version of the PDF reader or something
< 1632086756 437695 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :who's "they"? this sounds like the sort of thing that people would do if trying to infect your computer with a malicious PDF file
< 1632086773 497160 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: no, it's a document that I do expect to receive today in email
< 1632086781 3117 :oerjan!oerjan@sprocket.nvg.ntnu.no PRIVMSG #esolangs :fiendish
< 1632086803 656117 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :in theory it could be that the one they sent me didn't arrive and some clever targetting spammer send me a similar looking email
< 1632086818 685043 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :they are a covid PCR testing clinic
< 1632086833 603560 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :who took PCR test sample from my body earlier today
< 1632086854 35158 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and this is supposed to be the paper where they officially claim that their lab analyzed the sample and as far as they know I'm not infected with covid
< 1632086928 873696 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I'm not sure what the motivation to encrypt such a PDF would be
< 1632086942 766717 :oerjan!oerjan@sprocket.nvg.ntnu.no PRIVMSG #esolangs :it's health data, obviously
< 1632086949 718099 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :I can understand *signing* it, though – perhaps there's some confusion between signing and encrypting
< 1632086952 860900 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :oerjan: I guess
< 1632086967 899934 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :confidential health data, they're probably required by law to encrypt it
< 1632086972 710413 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :but it's very temporary health data
< 1632087002 481769 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :it might be important to keep a positive test result secret – maybe you therefore have to keep the negative results secret too, to prevent people figuring it out by elimination
< 1632087031 383622 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: or they might want to keep it secret what kind of test they did on me, since they do medical stuff other than covid PCR test
< 1632087055 119546 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :or even who they did the test on, if I use my email address for testing my hypothetical small child
< 1632087097 572800 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but mostly they probably don't have separate rules for not encrypting PCR test results but encrypting other medical documents when they send it in email
< 1632087141 604004 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :I imagine if you have a lot of friends who think the whole thing is a hoax, just the fact of revealing you got a test in the first place might have consequences. I'm not surprised at all they would consider those test results confidential by default.
< 1632087176 136187 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :fizzie: that doesn't work, since encrypting the contents while the sender is there doesn't really hide the fact that I did a test
< 1632087194 471073 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Well, it does, because like you said, they do a lot of other things too.
< 1632087206 239190 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Unless they put "here's your COVID test results" in the unencrypted subject line or something.
< 1632087225 213138 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :fizzie: in theory yes, but in practice they won't evaluate most of them on a Sunday
< 1632087248 626311 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :it could be some urgent blood test or something
< 1632087262 50013 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but there's a high chance that it's a covid test
< 1632087273 711713 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and no, the subject line and even the cleartext body is pretty generic
< 1632087287 651694 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :I wonder if there's some size-based side channel where you can distinguish positive and negative result PDFs just based on file size.
< 1632087300 319399 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :If they put a bunch of more detail in one but not the other, or something.
< 1632087301 145711 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :it does say laboratory result, and the From address tells which lab
< 1632087366 844155 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :fizzie: hehe, well there's a much bigger side channel where if it's positive then I'll tell my boss that I won't go into the office, plus they may be required to tell the police that I'm ordered to quarantine myself, but sure
< 1632087452 233649 :delta23!~delta23@user/delta23 QUIT :Quit: Leaving
< 1632087754 490602 :tromp!~textual@dhcp-077-249-230-040.chello.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1632087790 819865 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Re the other topic, I run fungot now on a KVM/qemu virtual (Alpine) system on the store room PC (itself a Debian). Previously it was running on that system directly (well, in a plain old-fashioned chroot jail). That whole computer's kind of less sensitive, but it does host some nominally private things (metrics, IRC logs, whatnot).
< 1632087791 251732 :fungot!fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :fizzie: comments are useful. it's a lot easier. i do use perl fingerprint *could* interact badly with ick has no problem with thinking that way of doing just fnord i said ' c's brain-damaging _syntax_.'
< 1632087934 171693 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Not that I think fungot is necessarily as problematic as HackEso. You'd probably have to be pretty motivated to do a Spectre-style attack using brainfuck (or Underload) as interpreted through a Befunge interpreter.
< 1632087934 449514 :fungot!fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :fizzie: doesn't sound so bad. chicken and plt
> 1632087955 489781 PRIVMSG #esolangs :14[[07Gluck14]]4 N10 02https://esolangs.org/w/index.php?oldid=88095 5* 03PolySaken 5* (+523) 10Created page with "'''Gluck''' is a successor to [[Clart]], designed by [[User:PolySaken]] to be used for a [[Virtual Machine]]. There are a few major differences from the original Clart rules,..."
> 1632087977 947962 PRIVMSG #esolangs :14[[07Gluck14]]4 10 02https://esolangs.org/w/index.php?diff=88096&oldid=88095 5* 03PolySaken 5* (+8) 10
< 1632088104 791113 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :hehe
< 1632088124 185570 :ais523!~ais523@213.205.242.138 PRIVMSG #esolangs :fizzie: neither BF nor Underload has any way to read the side channel on its own, potentially unless fungot's timeouts are time-based rather than instruction-count-based
< 1632088124 407185 :fungot!fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :ais523: he was the guy i thought you meant
< 1632088173 211956 :oerjan!oerjan@sprocket.nvg.ntnu.no PRIVMSG #esolangs :fungot: do your interpreters have any zero-day vulnerabilities twh
< 1632088173 409891 :fungot!fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :oerjan: will do. the player to start needs to be
< 1632088238 137230 :tromp!~textual@dhcp-077-249-230-040.chello.nl JOIN #esolangs * :Textual User
> 1632088847 471108 PRIVMSG #esolangs :14[[07User:PolySaken14]]4 10 02https://esolangs.org/w/index.php?diff=88097&oldid=88094 5* 03PolySaken 5* (+216) 10
> 1632088928 789248 PRIVMSG #esolangs :14[[07Gluck14]]4 10 02https://esolangs.org/w/index.php?diff=88098&oldid=88096 5* 03PolySaken 5* (+10) 10
> 1632089064 852346 PRIVMSG #esolangs :14[[07Gluck14]]4 10 02https://esolangs.org/w/index.php?diff=88099&oldid=88098 5* 03PolySaken 5* (+2) 10
< 1632089275 630295 :tromp!~textual@dhcp-077-249-230-040.chello.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
> 1632089408 895082 PRIVMSG #esolangs :14[[07Gluck14]]4 10 02https://esolangs.org/w/index.php?diff=88100&oldid=88099 5* 03PolySaken 5* (+33) 10
< 1632089411 232169 :earendel!uid498179@user/earendel QUIT :Quit: Connection closed for inactivity
> 1632089439 777883 PRIVMSG #esolangs :14[[07Gluck14]]4 10 02https://esolangs.org/w/index.php?diff=88101&oldid=88100 5* 03PolySaken 5* (+2) 10
> 1632089454 70492 PRIVMSG #esolangs :14[[07Gluck14]]4 10 02https://esolangs.org/w/index.php?diff=88102&oldid=88101 5* 03PolySaken 5* (-49) 10
< 1632089665 383050 :tromp!~textual@dhcp-077-249-230-040.chello.nl JOIN #esolangs * :Textual User
< 1632091528 338680 :tromp!~textual@dhcp-077-249-230-040.chello.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1632091606 328581 :src!~src@user/src QUIT :Ping timeout: 252 seconds
< 1632092292 414656 :tromp!~textual@dhcp-077-249-230-040.chello.nl JOIN #esolangs * :Textual User
< 1632093388 595455 :tromp!~textual@dhcp-077-249-230-040.chello.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1632093479 10177 :dutch!~DutchIngr@user/dutch QUIT :Quit: WeeChat 3.2.1
< 1632093546 137058 :dutch!~DutchIngr@user/dutch JOIN #esolangs DutchIngraham :dutch
< 1632093766 87765 :ais523!~ais523@213.205.242.138 QUIT :Quit: quit
< 1632094466 558540 :arseniiv!~arseniiv@136.169.204.31 QUIT :Ping timeout: 260 seconds