> 1761007097 779672 PRIVMSG #esolangs :14[[07Functional paradigm14]]4 N10 02https://esolangs.org/w/index.php?oldid=166334 5* 03Corbin 5* (+1821) 10"Moving" a category page to main namespace, per IRC discussion.
> 1761007117 352593 PRIVMSG #esolangs :14[[07Category:Functional paradigm14]]4 10 02https://esolangs.org/w/index.php?diff=166335&oldid=162713 5* 03Corbin 5* (-1795) 10Fork to [[functional paradigm]] to put content in main namespace, per IRC discussion.
< 1761007219 661295 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Sgeo: I'd say yes to all of that.
> 1761009282 490927 PRIVMSG #esolangs :14[[07Smalltix14]]4 10 02https://esolangs.org/w/index.php?diff=166336&oldid=166295 5* 03Corbin 5* (+388) 10Document the core of the correspondence between Smalltalk and Unix. This is technically a surjection rather than an isomorphism but we will paper over that.
< 1761010079 855878 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :korvo: nql compiler works for me with python 3.12.11 and pyparsing 3.2.3?  is the patch something specifically required by your harness, or is there still something weird with my setup?
< 1761010140 33472 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :i think i've figured out how ajwade's variable length PC works well enough to try it
< 1761012774 824934 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :sorear: Probably my harness. Nix says that I'm also on CPython 3.12.11 with pyparsing 3.2.3. Perhaps order of imports is important? I import framework, nqlast, nqlgrammar in that order.
< 1761012826 97689 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :...Although I've just tried rebuilding the entire BB Gauge with your repository as upstream and the 8yr commit as the target revision, and everything appears to work. So perhaps my commit's not needed.
< 1761013936 486705 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1761013973 649709 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Sgeo: quite a few of the languages I was working with during my PhD were call-by-name and Algol-based, so I used an actual Algol 60 implementation to test some of the programs (by translating them)
< 1761014032 90874 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the non-fixed syntax looks pretty esoteric to modern eyes – at the time, each implementation was expected to come up with its own syntax and the syntax used in the specification was designed for typesetting, not programming in
< 1761014047 362708 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :did Algol 60 also allow spaces in identifiers? or was that just Algol 68?
< 1761014084 962071 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(incidentally, Algol-68 does have I/O but it looks very esoteric to modern eyes)
< 1761014458 345418 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :How is the I/O of Algol-68? Is there a program to convert the syntax for programming to the syntax for typesetting? (I think WEB does something similar, but different)
< 1761014661 643052 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :For Algol 60, iiuc different computers had different programming syntaxes. Some put keywords in quotes (e.g. 'BEGIN'), some capitalized
< 1761014671 99244 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: doesn't the non-fixed syntax mean only that keywords can be represented as single symbols or short combinations or full words depending on how capable your input devices (eg. card reader) are, since Algol may be running from five-bit telegraph with two shift modes and only like 55 usable characters, or an EBCDIC card reader that can recognize 256 characters that you can each punch by 
< 1761014677 105062 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :backspacing, etc?
< 1761014728 214410 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :BASIC is kind of like this too: on some microcomputers you can type BASIC keywords from letters, on others you can only enter them as a single shifted keyboard symbol that's only shown on screen as letters
< 1761014745 714824 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: yes, but also keywords and variable names could be the same and so implementations needed a way to disambiguate (in the Algol 68 specification, this was done using different fonts)
< 1761014751 37928 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I have seen that before
< 1761014784 237482 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and when you don't have every printer standardized on being able to print most of ASCII then it would be silly to say that some symbol must be represented as exactly a left square bracket, another as a yen sign etc, just use whatever your printer can show
< 1761014872 676657 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: makes sense, that means you can even have versions with built-ins represented in different natural languages, like Excel or LOGO. you could even use a terminal that doesn't have latin letters.
< 1761014894 431583 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm trying to remember how Algol 68's I/O works
< 1761014903 97263 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think all the files had to be opened before the program starts, although I'm not 100% sure
< 1761014967 789605 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :have I complained lately about how hard it is to find on the internet sources that are written in English and list *all* the Russian abbreviations for SI units and prefixes?
< 1761014988 68909 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :why doesn't someone have a complete table somewhere? is it really that hard?
< 1761015005 244266 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :are you supposed to learn them only from printed university textbooks for engineers or something?
< 1761015023 922775 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, apparently ECMA 6 (which later became ISO 646) was first published in 1965
< 1761015030 802662 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :also if you only list the russian abbreviation for kilogram, not for gram, then you're doing it wrong
< 1761015046 33897 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so Algol 60 couldn't have used it, and although Algol 68 could have done, there wasn't time for it to have "won" yet
< 1761015057 545635 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: yeah
< 1761015067 752292 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :even if ASCII exists doesn't mean all computers are using it
< 1761015092 423944 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ECMA 6 isn't exactly ASCII, it's a precursor to it
< 1761015116 110600 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's what C was designed against, which is why C has trigraphs (they make it possible to type the ASCII characters that C uses that aren't guaranteed by ECMA 6)
< 1761015532 268032 :strerror!~strerror@user/strerror PRIVMSG #esolangs :Sgeo: It's a bit hard to avoid IO creeping into your standard after systems started widely adopting, well, stdio.
< 1761015670 169300 :strerror!~strerror@user/strerror PRIVMSG #esolangs :So you might want to look at systems that still don't have that. Such as Ecmascript! It looks like the console object isn't actually in the standard. https://tc39.es/ecma262/#sec-ecmascript-standard-built-in-objects
< 1761015776 176280 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :JavaScript does have built-in date/time and random numbers though, which means that it still has some I/O, although console.log is not a core function it is common among multiple implementations (console.log with a single argument which must be a string, might be the most portable way to do output in JavaScript, and if it doesn't have it, it is easy to add it)
< 1761015799 889939 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :(Some people do not consider date/time and random numbers to be I/O, but to me, I consider that it is.)
< 1761016134 436958 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :strerror: which is why C++ overreacted and went the opposite way. iostreams was basically the first part of C++ that got (at least unofficially) standardized between different implementations, with both the language and the standard library changing a lot since, and the weirdest part of the language were designed specifically to serve iostreams – have you ever seen virtual inheritence used in C++ for 
< 1761016140 445924 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :anything other than implementing the classes of iostreams such that basic_stream can inherit from both basic_istream and basic_ostream but only have one copy of ios and one format flag?
< 1761016158 222301 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I remember, at a previous job, having to explain why a program was producing progress output to the terminal in 4KiB chunks rather than immediately (libc buffering), and then having to explain why libc was involved even though the program was written in Haskell
< 1761016273 768731 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I hate the way that on many OSes you have to go through libc to interact with the OS at all, even though it contains functions that have nothing to do with OS interaction (like strlen)
< 1761016396 436941 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: ooh, you had to go through fifty years of computer history with that one. I recently learned that the officially documented API of the Commodore 64 kernal ROM has unix-like file description abstractions in it, where you can open numbered file descriptors that can correspond to either the screen or tape or floppy disk and then you're supposed to write them with a system call for *every byte*, 
< 1761016402 444806 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :even though this is such a silly design that the designers should really have expected that no sane program will use it
< 1761016457 780597 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it is surprising how silly many API designs end up
< 1761016485 536918 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and then the whole CP/M thing where there's a standardized operating system interface (without unix-like file descriptors and with files read/writable only in fixed-sized blocks and no byte-granular size) without shared language or CPU
< 1761016504 621199 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :CPUID is one of my pet hates – in order to use it you first have to use CPUID request 0, which gives you a value for the highest CPUID request you can use – higher requests are undefined behaviour, lower requests might or might not be implemented, but return all-bits-zero if not implemented
< 1761016537 543268 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I also did not like that you have to go through libc; my own design is deliberately design that you do not have to use libc (which, in my system, lacks the functions for interacting with the OS anyways) to interact with the OS. (Also, you cannot necessarily interact with the I/O anyways; you can interact with capabilities.)
< 1761016544 896267 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: this one is actually less silly than it seems at first, one character at a time does make more sense than it seems at first with how the floppy drive and tape works
< 1761016547 640444 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it would have made so much more sense to say "unimplemented requests return all-bits-zero" so that using request 0 wasn't mandatory, you just make the request you want (because you have to check for the all-bits-zero case anyway)
< 1761016564 223400 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :(And, I do not like CPUID either, so my own design would be one that does not have such a thing, at least for application mode.)
< 1761016582 910237 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the only logical reason I can see for the CPUID design is so that Intel can fill your ebx, ecx and edx registers with advertising
< 1761016589 759348 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(it actually does that, while it returns the result in eax)
< 1761016601 636601 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :(And that about CPUID is not very good either)
< 1761016631 725017 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :anyway, buffering output before doing the actual write call is both older than unix's unified write operating system API, and even on a typical linux it has lots of reimplementations besides libc
< 1761016636 28394 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think Intel encouraged people to verify that the CPU was an Intel CPU before trusting the CPUID result (which would have the consequence of programs running non-optimised on non-Intel x86 clones) – and later actually did that themselves in icc
< 1761016670 106785 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but, no sensible manufacturer would create an x86 clones for which the CPUID results had different meanings than on Intel
< 1761016696 656621 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :it's so old that TAOCP volume 1 explains how to buffer input and output, both because you're doing IO in fixed-sized blocks and because you're using a larger ring buffer for background IO in parallel to computations
< 1761016752 803363 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the funny thing is, later AMD created their own CPUID requests in the billions, to avoid any likely clashes with Intel's which were all small integers, and enough software started using them (even though it was defined by Intel as UB) that Intel had to partially implement some of them in order to prevent code running more slowly on Intel processors than it would on AMD)
< 1761016760 284297 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais5523: sure, but Intel kind of has to do that because they can't promise that every bit of their documentation will apply to all third-party CPUs made, even with how much they specifically work together with AMD to make the CPUs as compatible as reasonably possible
< 1761016781 347718 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :no they don't, they just say "on Intel processors, CPUID works like this"
< 1761016808 368771 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and if a non-Intel processor doesn't match the documentation Intel just blames it on the manufacturer
< 1761016858 878904 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but that's not just CPUID, all of their documentation basically says "Intel processors work like this", so much that the architecture programming manual tells you the details of how all CPUs going back to the 8086 work and how to detect if you're running on a modern CPU rather than a 8086 in like five easy steps starting from distinguishing 8086 from 80286 etc
< 1761016943 897136 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, you're supposed to start by seeing whether certain flags bits keep their value when you try to set them, I think?
< 1761016947 657858 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(rather than reverting back to 0)
< 1761016966 260409 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and that detects enough early CPUs that you can rule out all the ones that don't implement CPUID, and then use CPUID
< 1761017013 156273 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :no, the flag bit distinguishes between pentiums with or without CPUID, that's near the last step, I think there are three or four more steps before. IIRC the first is to check what push SP pushes to see if you're on a 8086 or 80286, but I forget how you test for a 80286 vs 80386, then 80386 versus later
< 1761017045 882324 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I might be misremembering, I should look this up
< 1761017062 344241 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, maybe INTERCAL's version test isn't so unique after all
< 1761017168 422018 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in any case, most software nowadays doesn't support anything earlier than i686 when compiling for 32-bit x86
< 1761017183 136059 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(and increasing amounts of software aren't supporting 32-bit x86 at all)
< 1761017503 510312 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :no, you were closer to right. Intel architecutre manual volume 1 chapter 20.1.2. the test between 8086 vs 80286 vs 80386 or newer is with FLAGS: top bit is always set on 8086 but always clear on others in real mode but you *can* skip that part, test the three bits below them to see if they are changable on 80386 or newer vs fixed on older (though with different values on 8086 vs 80286); 
< 1761017577 527594 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :then there are two EFLAGS bits but you only really need one which indicates that CPUID is available, but of course to even access the top half of EFLGAS you need to know that you're on a 80386 or newer.
< 1761017652 971760 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :so it's not as bad as I remembered, it's really only four tests, one to test if a bit in FLAGS can be both set and cleared and retains both, then test if a bit in EFLAGS can be both set and cleared and retains both, and if those all pass you have CPUID. unless of course you actually want compatibility with CPUs older than CPUID.
< 1761017790 67133 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :though of course the later tests with CPUID are complex, because the official intel documentation doesn't promise you that SSE2 is always available in 64-bit code. mind you, that is actually *correct* from their perspective, because being able to use XMM registers requires operating system support, and even though in practice any 64-bit program can rely on that being there if they even want to use any 
< 1761017796 74303 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :OS ABI, the Intel CPU manual has to describe the more general case where there needn't be a typical operating system running.
< 1761017953 32985 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think at least Rust does CPUID checks along the lines of "this software was compiled for Windows, so we can assume the existence of any CPU instructions that are required by Windows"
< 1761017984 857928 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :…which leads to weird per-OS performance increases because some OSes require newer instructions than others, making software that isn't multiversioned run faster
< 1761018338 623924 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :hehe, yes, that would lead to a consistent drawback on programs compiled for linux, because there will always be operating systems supporting parts of the linux system call ABI that run on the weirdest CPUs
< 1761018345 153201 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :for any one architecture
< 1761018373 893573 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :whereas most Windows programs these days can just check for at least Windows 10 and bail early on Windows 7 or earlier
< 1761018454 561491 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but I still think at least on a linux x86_64 program you can rely on SSE2 being there
< 1761018565 227292 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :(I wouldn't rely on it being implemented completely correctly; I should go back some day and get a qemu x86_64 guest *without acceleration* to compile and test if it indeed has a bug in what NaN values some SSE instructions return and report the bug if it's there)
< 1761018631 237491 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I mean especially if you are linking to libc then the function call ABI requires XMM registers present
< 1761018670 506554 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :if there's an fabs function, or a printf that can format doubles, then there has to be SSE instructions at least
< 1761018923 325971 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, if the OS hasn't given permission to the CPU to use XMM registers, do attempts to use them actually fail? or do they succeed and just hide the CPUID bit?
< 1761018968 176543 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that said, even if the CPU instruction subset part is complicated, the OS ABI part turns out to be pretty simple, because most programs will, whenever they do a unix system call other than group_exit, check if it returns an error with an errno code that they don't specifically handle, and that automatically checks for old OSes not implementing any particular system call.
< 1761018971 631978 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess it doesn't really matter
< 1761018991 626351 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :your programs will still break if they get context-switched while using registers the OS doesn't know exist
< 1761018993 321673 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: IIRC yes, the CPU ABI is that the CPUID bit is only enabled when the operating system has explicitly enabled support for XMM registers;
< 1761019022 991403 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :though that applies for XMM and YMM and ZMM only, x87/MMX registers also require OS support and I don't know how you test that
< 1761019054 211253 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and now you've made me wonder whether glibc actually puts ENOSYS in errno or whether it just aborts upon seeing that the OS doesn't support a system call it expected to exist
< 1761019079 946235 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it might plausibly depend on which system call you ask for – there are some that glibc will recognise as being conditionally supported
< 1761019139 666392 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it took me a surprisingly long time to realise that the reason why MMX registers are mapped over x87 registers is so that the OS will know how to context-switch them even if it doesn't know about MMX
< 1761019193 281007 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: yes, but it's not *just* the OS, I think it's also user-space context switch or light threading libraries
< 1761019200 520914 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it would be logical to map mask registers over x87 for the same reason (so that programs could use masked EVEX-encoded instructions on 128-bit and 256-bit registers even if the OS didn't know about AVX-512)
< 1761019207 711592 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :well no, sorry, ignore that
< 1761019227 224212 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :the ABI basically says that MMX can't be initialized around generic function calls, the CPU is always in x87 mode
< 1761019235 198234 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :so a user-space library doesn't have to support MMX
< 1761019237 692601 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :only the OS does
< 1761019264 938749 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well the ABI also doesn't let you initialise ymm registers around function calls either
< 1761019292 887419 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(and that's *on top* of making all the xmm registers call-clobbered)
< 1761019314 928792 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or maybe it's specifically returns rather than calls
< 1761019317 26589 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: I don't think so, mask registers were introduced in AVX512, that's late enough that by that time the CPU architecture exposed a generic interface that operating systems can use to save all the state of a process
< 1761019363 311340 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but x87 also has enough complications that it would be very annoying if you mapped something else onto it now
< 1761019412 747477 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and they're technically still in the x86_64 linux ABI for passing a long double to a function (like fabsl)
< 1761019422 138777 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :or do I remember that part wrong?
< 1761019563 409359 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I just checked, long doubles as arguments are passed using stack slots, but a long double return value is returned in ST(0)
< 1761019606 439936 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ST(1) can be used in the specific case of returning a complex long double (but no other cases, e.g. a structure containing two long doubles is returned via outpointer)
< 1761019632 682699 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so you were almost right
< 1761019728 468415 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(this seems slightly illogical to me – "first long double in ST(0), rest in stack slots" would be more consistent with the rest of the ABI – but I didn't design it)
< 1761021061 697589 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :sorear: Okay, let's assume that my commit is not necessary. It is meant to patch up an upstream change in pyparsing anyway; as long as everything else works, it's not relevant to our main goal.
< 1761021421 757471 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :ais523: preventing user code from writing registers the OS doesn't know about is crucial unless you want covert channels
< 1761021449 731801 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: I don't think Intel has a very good track record of stopping those :-(
< 1761021555 625081 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this reminds me of the trick that was used to implement rseq before it was added as a system call (you change the base of the gs segment in such a way that it looks unchanged to the OS, then if you get context-switched the OS restores gs incorrectly, and you use that to cause the last command in the rseq to fail)
< 1761021598 944434 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although that's the opposite of a covert channel, it gets incorrectly clobbered as opposed to incorrectly non-clobbered
< 1761021641 946825 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :"trap on FP register access" has been a standard feature of ISAs forever because people think they want lazy FP register restoring, e.g. cr0.TS, not quite the same as OSXSAVE but
< 1761021714 195234 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I had wanted to design the CPU to avoid covert channels and other problems with it, as well as some enhancements; security is one issue but there are other issues too.
< 1761021846 657122 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this reminds me of when lazy FP state restore turned out to be exploitable (using speculative execution to leak other processes' FPU registers), but recent-at-the-time Linux was unaffected because they'd disabled it by default a little earlier
< 1761021865 980658 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :due to it not being useful as a performance optimisation on modern CPUs
< 1761021928 244233 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I suspect the concern was mostly not so much x87 (unlikely to hold sensitive information) as SSE (which could plausibly hold sensitive information due to being used for inline memcpys)
< 1761022005 716869 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah, it's specific to recent-at-the-time Linux on recent-at-the-time processors, older processors were still affected because the lazy restore was considered by Linux to be faster on those
< 1761022073 819313 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :it's exploitable due to TS being checked too late, not due to an inherent property of the ISA
< 1761022105 208834 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, as usual this happened on Intel but not AMD (AMD has had its own specific vulnerabilities but they tend to look different from the Intel-specific ones)
< 1761022105 328650 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :but intel did the same thing with page permissions so
< 1761022213 756664 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the recent ARM64-specific one was even more dramatic (the CPU was speculatively reading from register values if they looked like pointers, which could be attacked by getting crypto code to create numbers that looked like pointers internally if the key had a bit in a particular place)
< 1761022227 702415 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :(most of my ISA stuff is indexed on riscv since that's what I've been doing since 2016)
< 1761022301 948860 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think that one's less likely to be a problem on x86es for memory-ordering reasons, reads are acquire-ordered by default on x86 and so speculating on a read before the read instruction appears in the instruction stream is almost useless
< 1761022380 633206 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :that sounds like something half-remembered that's either related to value predictors or prefetching
< 1761022435 314002 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :dynamically most register values are small integers, all of which are architecturally valid pointers
< 1761022468 568692 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, but "looking like a pointer" is different from being a valid pointer – it's something that you can predict on (e.g. by seeing which memory addresses are being accessed and looking for addresses that look similar)
< 1761022501 493639 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :riscv has svukte now (negative addresses are rejected in U-mode before even hitting the PTW) and A64 probably has had something similar for a while but I don't think anyone's promoted mmap_min_addr to architecture
< 1761022516 941831 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I think it is better to not put that many complications like that into the CPU since it can cause these kind of problems
< 1761022609 625398 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, I see, mmap_min_addr doesn't need to be architectural for security reasons, but it might potentially help for performance if you're trying to figure out what might be a pointer
< 1761022626 206135 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :discover problem caused by complexity, solve it by adding more complexity, repeat until full employment is achieved
< 1761022670 573143 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Except for those of us who've burnt out, I suppose.
< 1761022699 537187 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :Another way can be: Redesign most of the computer, operating system, etc. It is not only about complexity and security but also the other problems.
< 1761022741 507882 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :zzo38: I would like to do that but am having problems finding enough mental energy to do it
< 1761022775 408496 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although, I think that even though it would be beneficial to redesign everything properly, some parts of it are more beneficial than others (i.e. less effort to change and greater benefit)
< 1761022818 50061 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I would want to make a discussion group to do it. I have no name for it so far, but I do have many ideas.
< 1761022871 45115 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the "lowest effort to greatest benefit" to me is in the "generalised ABI", i.e. the rules for how a process can use the processor registers and do argument passing and interact with the OS
< 1761022894 941671 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because that could be adopted piecemeal, one program at a time, without breaking existing systems, and yet it's an area with huge scope for changing things
< 1761022950 510290 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :like you want to simplify the x86_64 sysv calling convention?  what does that benefit, or am I taking you too literally?
< 1761022950 589024 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :for example, it would be possible to enforce an object-capability system at that level (via static analysis of the source code or binary)
< 1761022986 649742 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: the calling convention is part of it, btu actually I wanted to complicate it, the current calling convention is very rigid and it causes a lot of register spills as a consequence
< 1761022991 395018 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :For modifying existing systems, I suppose so, but I thought to do a new system; still the ABI (and perhaps those other things) would probably be one part of it though.
< 1761023022 406009 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :But couldn't we have object-capability systems via static analysis already? Or is this like CHERI where the security property comes from a conjunction of correct hardware *and* correct software?
< 1761023035 465860 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: we can but only within a single process
< 1761023040 798902 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :(Although, my idea of a system has a small number of system calls (possibly only one).)
< 1761023065 245481 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you need an expanded ABI to allow multiple processes to send capabilities between each other (e.g. via exeec)
< 1761023066 792280 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* exec
< 1761023100 512918 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I think that a combination of correct hardware and correct software would be a good idea. However, I think CHERI is security within a process and my idea is more about security between processes.
< 1761023123 469362 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :even the single-process version would be good though
< 1761023192 876225 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :CHERI works within an address space.  "Process" can get a bit fuzzy
< 1761023196 336725 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fwiw, I am sceptical of CHERI – I don't think it actually enforces memory safety unless you modify the software to take advantage of it
< 1761023215 225625 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :whereas working with almost unmodified software is its only real claimed advantage
< 1761023231 23619 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :And, to send capabilities is by passing messages between processes, including the initial message (the process won't run if the initial message contains no capabilities, unless a debugger is attached)
< 1761023267 841378 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Or we switch to unguessability. Usually a reference within a process is "unforgeable"; there's formally no tools for constructing references. But whenever we have any sort of coding, we have "unguessable" references instead. Cryptography, ASLR, etc.
< 1761023305 633019 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :my working example is C code like «enum user_mode { admin, user }; struct userinfo { char name[12]; enum user_mode mode; }; void set_username(struct userinfo *info, char *name) { if (strlen(name) > 12) return; strcpy(info->name, name); }
< 1761023313 141349 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :»
< 1761023314 107054 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :? CHERI fails closed.  if you have C code which relies on accessing objects with pointers derived from pointers to other objects, you have to modify it in order for it to do anything on CHERI besides segfault
< 1761023314 436304 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I'm currently looking at Smalltix as supporting capabilities by not having the tools necessary to construct paths e.g. into the Nix store. This is yet another step on the transitional path that Nix has laid out.l
< 1761023334 961507 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :every "C but memory-safe" I've seen won't catch the bug in this code
< 1761023371 269481 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(CHERI only does if you explicitly narrow the permission on the info->name projection, but doing that would break too much C code)
< 1761023416 818239 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :the only times you need to modify CHERI C to make it *more* secure is if you have a user-level memory allocator and you want CHERI to know about and enforce the subobject boundaries
< 1761023435 321702 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I don't trust unguessability as a security feature at all, given how many speculative execution vulnerabilities there are
< 1761023451 216580 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: does CHERI catch the bug in the code I posted above?
< 1761023532 841880 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Um? Maybe we're talking about different stuff. Unguessability is stuff like TLS being technically insecure in the sense that a determined attacker could crack a key. Or are you thinking of like timing attacks?
< 1761023555 369122 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :
ACTION distracted by kitchen

< 1761023567 533274 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I'm mostly thinking of same-CPU covert channel attacks (which includes timing attacks)
< 1761023596 113424 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if the attacker can't run code on your CPU then things are safer
< 1761023606 618879 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I think I'll go with option 1, where trying to write a literal array has the same semantics as trying to index out of bounds into an array or use-after-free of an array. the UB or runtime check is already there because of the array indexing, so it doesn't really have extra cost to add more of it.
< 1761023617 265217 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Ah, okay. That stuff threatens unforgeability too. In general, colocation doesn't appear like it can be safe unless we're doing hypervirt.
< 1761023620 799115 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :https://ctsrd-cheri.github.io/cheri-c-programming/impact/subobject-bounds.html
< 1761023653 792237 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: OK, that's exactly what I thought – CHERI can't support it without code changes, but can support it with
< 1761023654 731956 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :And then ISTR that there's some master theorem about how your ISA has to be hypervirt-safe from the late 80s.
< 1761023662 209865 :strerror!~strerror@user/strerror PRIVMSG #esolangs :If your security feature is “like ASLR”, there are already a lot of attacks on that, which need not involve CPU exploits; e.g. printf("%p")
< 1761023678 124533 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :https://cheri-compiler-explorer.cl.cam.ac.uk/z/aKq1n7 what code changes?
< 1761023719 652987 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: in that you used a compiler option that breaks too much existing code to enable by default
< 1761023737 485828 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I thought also that it should need a capability to be able to measure timing at all. That also partially mitigates timing attacks, although it is not the only thing to do. Applications programs are deterministic except for system calls (and if the program is suspended or terminated by something external, which it cannot detect), and there are not many system calls, so hopefully that should help.
< 1761023765 393622 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :zzo38: I also thought that
< 1761023797 433485 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :zzo38: Yes, timers have to be tamed, and it's an open problem how to best do it.
< 1761023824 367805 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :I'm struggling to interpret this as good faith.  All of the provable, involable inter-object OCAP protections are worthless because intra-object protection fails in some cases that were never advertised?
< 1761023900 820935 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: it's more "I've seen many people have a default assumption that an allocation boundary is a security boundary, and that isn't true for a substantial amount of existing C code" combined with "you need some rules for telling the compiler when a subobject boundary is supposed to be restrictive and when it isn't"
< 1761023920 761928 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :programmers frequently use subobject boundaries that aren't supposed to be restrictive, and frequently use subobject boundaries that are
< 1761023923 645394 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :korvo: I think that redesigning the entire system is the way to do it, although it is possible that other people have other ideas.
< 1761023959 230200 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it doesn't make the protections worthless because a pretty high proportion of spacial exploits are cross-allocation
< 1761023969 33475 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so you're getting a pretty good mitigation percentage
< 1761023983 885984 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but there isn't a magic bullet to getting 100% memory safety from existing C programs
< 1761023984 351172 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :zzo38: this doesn't apply to all the vulnerabilities mentioned, but it's really hard to keep a fast L1 cache, paging, SMP, large main RAM, and a fast CPU clock cycle, without also having lots of complexity that can cause vulnerabilities.
< 1761024036 395892 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :b_jonas: Yes, although some of these complexities can be avoided (and in some of the cases, they can be handled by the compiler instead)
< 1761024075 413969 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(interestingly, apparently the iOS kernel has a rule of not mixing things with different security properties within a single allocation, i.e. you need to use two different allocations with one pointing to the other – that means that an allocation boundary really is a security boundary inside the iOS kernel)
< 1761024158 95579 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: hehe, writing past the end with strcpy. 
< 1761024191 273637 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I wanted an example that a) is a plausible example of a bug that might occur and b) is easy for C programmers to notice as being buggy if told there's a bug there
< 1761024224 111791 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :the point is compartmentalization, unaudited code can fail to be memory safe but it cannot be memory unsafe in ways that violate the security of code that _has_ been audited
< 1761024239 729207 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :strerror: ASLR isn't trying to be unguessable in the cryptographical sense, it never did. pointers don't have enough address bits for that.
< 1761024273 364502 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: OK, that's valid (although it differs from the security claims I typically see on the subject)
< 1761024319 66997 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :zzo38: In Monte, the only way to get a system timer is with a top-level capability. It gives out absolute timestamps, but we called that .unsafeNow() since we were pretty sure that it's not safe. The idea is that a user might only get Timer.measureTimeTaken and nothing else. https://github.com/monte-language/typhon/blob/master/typhon/objects/timers.py#L65
< 1761024334 514065 :strerror!~strerror@user/strerror PRIVMSG #esolangs :b_jonas: In a sufficiently large program it's not unguessable in any sense, since anything that prints a pointer (printf, JIT runtime, leftover debugging code) will disclose addresses immediately
< 1761024372 287198 :strerror!~strerror@user/strerror PRIVMSG #esolangs :In the past “sufficiently large program” was emacs, now it's a web browser
< 1761024425 846240 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :re: timing permissions, I think the ideal goal for a capability system would be "making it safe to run untrusted code" (browsers already do this!), and this raises the problem of preventing the code observing timing using network requests
< 1761024449 646620 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(it could also potentially use racing loops to create a timer, but that seems easier to fix at the compiler level)
< 1761024474 562000 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :strerror: sure, that too, but I still think using cryptographically unguessable tokens for security makes sense in some cases, and is even hard to avoid in some, even if we suffer because it's undermined by virtualization putting untrusted code on the same CPU which may leak such values more easily than timing or power usage or other side channels
< 1761024563 436204 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: sadly making it impossible to observe time and use it as a side channel is basically impossible in most practical settings. all settings where you want reasonable performance at the very least, and often even if you're fine with low performance.
< 1761024566 368478 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Networking's also a top-level capability (like a half-dozen fine-grained caps, actually) in Monte, and networking doesn't come with timing information by default. So it'd have to be a situation where you're permitted to call out to arbitrary webhooks to begin with, rather than a predefined situation.
< 1761024568 341275 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I have been thinking about ASLR a lot, I think too much ASLR is actually a net disbenefit to security (because it prevents you hardcoding pointers and the code that would otherwise hardcode pointers has to do something else)
< 1761024570 93924 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :complexity rebalances in large systems.  a big increase in µarch and compiler complexity saves a few % on time and energy, which means you get to make and install fewer chips and smaller power systems
< 1761024571 151742 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :korvo: I suppose it is one way to do it, and I would probably have the kernel to have a somewhat similar function; many application programs might use proxy capabilities, if they require any timing at all (for example, it is useful for many kind of programs to have the current date/time, but many (probably most) programs shouldn't need it)
< 1761024595 885596 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I'm mostly thinking of the "script on web page" situation – those are expected to be able to make network requests
< 1761024616 689777 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :zzo38: pledge() is another cool approach. There's nothing wrong with having the time available in the VDSO; the problem comes from the assumption that any code in the process is allowed to touch the VDSO.
< 1761024635 511984 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: I'm not sure, we are using dynamic linkers anyway to share libraries between processes, and they have to do relocation, and our dynamic linkers are robust enough, so why would ASLR make this worse?
< 1761024646 362310 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: the problem is not just the vDSO, but the RDTSC processor instruciton
< 1761024677 326299 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Sure. Always worth remembering that E's authors were not able to fully rewrite ECMAScript to be cap-safe; ECMAScript is a big success story but it's still world-exposed.
< 1761024684 923894 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ASLR may still be a bad idea, but I don't think your argument proves that
< 1761024691 502299 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: oh, I also see the dynamic linker as a problem – I think it allows too much
< 1761024697 333652 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but I'm not sure what the correct amount is
< 1761024706 737978 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :ASLR was a big step back when the state of the art in attacks was return-to-libc (overflow a stack buffer and overwrite the return address with a pointer to system())
< 1761024717 424220 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :My own way is entirely involving capabilities, and would be a new instruction set too (so that there is no RDTSC, or at least, if there is, only the kernel is allowed to use it).
< 1761024729 193598 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: even if the dynamic linker is allowed to load anything only when the process is starting, before it executes user code?
< 1761024753 768651 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Sure. We generally assume that a cap-safe environment must have "safe code loading", like e.g. JVM's bytecode verifier, to prove that the loaded code is not going to attempt any obvious wrongness. A code loader is safe when it respects isolation and confinement.
< 1761024754 816939 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :arm and riscv both have no timer unconditionally exposed to user code
< 1761024759 641444 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I do not want to use VDSO or whatever like that; when a program receives a capability, it might be a proxy capability, and a proxy capability can work like any other capabilities.
< 1761024761 339745 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I certainly see why dynamic linker invoked at runtime allows too much, but I like dynamic linker at startup time
< 1761024762 61423 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :scounteren.TM
< 1761024763 151766 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I suppose that this implies that the ISA itself must be tamed!
< 1761024777 853880 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: one reasonable middle-ground would be what you suggest, but current dynamic linkers allow for the possibility of libraries loading at runtime and doing relocations both ways
< 1761024827 460636 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: IIRC one of RDTSC and RDRAND has a way to disable it from the kernel and the other doesn't
< 1761024866 238263 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, right! one of my big realisations was you can prove that a program or portion of one doesn't receive via any side channel or covert channel via proving that it is deterministic
< 1761024878 832480 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :the original riscv linux uABI guaranteed that user code _could_ access the cycle counter, was messily broken a couple years ago to dubious security benefit (if you have multithreading, you can estimate times by engineering a race, and noisy times can always be improved with statistics)
< 1761024879 632083 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: certainly, but it's not like we can stop that because that function of the dynamic linker can be implemented completely in user-space by opening files with arbitrary filenames and mmap, and in contexts where you restrict those operations, you shouldn't allow invoking the dynamic linker either. now admittedly something like allowing to run untrusted code that can invoke the dynamic linker *is* a 
< 1761024884 597653 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although this doesn't prevent it sending or forwarding via a side channel or covert channel
< 1761024885 856971 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :bad idea even if people do it in practice in some high-level languages.
< 1761024908 600000 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :ais523: It is also one of my reasons for making it deterministic (by designing the instruction set and operating system in such a way)
< 1761024946 25812 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: this would presumably be used in an environment where you need a capability to create new executable mappings
< 1761024975 217513 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Oh, there's no way that we would let the untrusted user submit ISA-specific instructions! Google tried that with Native Client, creating the amazing situation where exploits break through three distinct sandboxes like Tai Lung leaping out of prison at the beginning of Kung Fu Panda. No, we must JIT instead. That's why WASM and Monte do it, and why E had to become a distinct language from Java, Alice from ML, etc.
< 1761024982 31042 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :deterministic concurrency would be an interesting security feature, but it doesn't help when mallory is doing RPCs and timing them on _her_ end
< 1761025027 346143 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: yep, that's why I a) mentioned forwarding via a side channel and b) was worried about how to timing-sandbox network requests
< 1761025090 62478 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: The tradeoff is something called a "spellserver". The user gives the spellserver a (cryptographic) cap and it executes (native) code on the user's behalf. The user isn't allowed to choose the code, but they are allowed to pass in other caps as arguments and delegate authority, so the spellserver can act on the user's behalf while doing optimized/privileged things.'
< 1761025111 450470 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :native client checks every instruction in the image against an allowlist and ensures that no instructions not in the image can be executed without going through the validator again.  I don't see how "ISA-specific" makes this any worse than  JIT
< 1761025129 136566 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :In some cases, you can add extra delays where needed (e.g. a proxy capability might do this; my idea is that delay is one of the proxies included in CAQL)
< 1761025144 977709 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I hadn't heard the name "spellserver" before, but understand the concept
< 1761025158 109074 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: I think one of the main difficulties is that even if you go most of the way to run untrusted code in a deterministic way and not allow it much IO capabilities, in the end you have to put some kind of timeout on it to stop it if it takes too much time, and that will be observable. but if you want any sort of performance (like in a Browser) then untrusted code can deliberately do things where 
< 1761025164 119142 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :timing can easily vary by a factor of hundred or thousand in a way that's very hard to prevent. so either you do some deterministic cycle counting but then your timeout will be vague by a factor of a hundred or thousand, or code will be able to observe timing.
< 1761025190 603577 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: yes, I agree that this is a main difficulty
< 1761025202 146085 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :A proxy capability can also lie about the amount of time that has elapsed (this does not prevent external timing measurement, but can prevent internal ones)
< 1761025222 928119 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess you could go along the lines of "you have to prove your program will execute within X seconds or it doesn't get run" but that would require some really worst-case timing estimates
< 1761025232 478169 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :sorear: The trick is to not sandbox at all. Instead of starting with a powerful encoding and trying to limit its behavior (taming), we start with weak primitives and add specific preselected behaviors for which we case-by-case prove safety. This means that the user does not have perfect control over what the CPU executes, but we already know that that control is exploitable, so we shouldn't offer it.
< 1761025272 197536 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: fwiw I consider that to be a type of sandbox, too (but agree that it's massively preferable to the taming approach)
< 1761025277 535478 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :nacl doesn't start off with a powerful encoding, it starts off with no allowed instructions and adds them one at a time
< 1761025319 871641 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :korvo: That is what I thought too. Usually this is by the use of a VM code, although I think a CPU could also be designed to help with it (in cooperation with the operating system kernel), although existing CPUs and operating systems are not that way
< 1761025373 225692 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The ISA is an encoding of behaviors.
< 1761025390 639813 :strerror!~strerror@user/strerror PRIVMSG #esolangs :AFAIK, preventing information leakage and covert channels is much harder than preventing tampering. (This is also why unforgeable caps are better than unguessable.) In practice you want to share as little as possible, with air gaps or data diodes (yes, physical ones)
< 1761025452 973350 :strerror!~strerror@user/strerror PRIVMSG #esolangs :I think it's reasonable to want a microarchitecture that prevents the latter, but the former is a lost cause
< 1761025455 371252 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I also think that unforgeable is better than unguessable. Within one computer, I think it could work.
< 1761025489 703617 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :With a language and CPU that work together, unforgeability can extend as far as the ports of a single motherboard. That's a pretty impressive integration!
< 1761025506 496659 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm a bit internally conflicted because it's clear to me that at least on present CPUs, a sophisticated attacker who can run arbitrary sandboxed code almost certainly has an arbitrary read primitive available – but most of our security depends on keys and passwords which are not safe in that threat model
< 1761025524 45755 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :they got bored with nacl, dropped it, and are now adding LFI which as far as I can tell is exactly the same
< 1761025554 516864 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Well, assuming we trust the memory controller. E trusts iteratees and iterators and collections to be correctly implemented; Monte doesn't, or at least Monte assumes that remote computers can have incorrectly-implemented collections that iterate wrongly.
< 1761025574 745515 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :My idea is the operating system kernel and CPU to work together to do that; programming languages (e.g. a C compiler) might not (and does not need to know about the specific implementation, although of course the instruction set and system call interface would need to be known)
< 1761025579 345780 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :there are a few contexts where we can afford the potentially huge performance hit, but most contexts where we want to run untrusted code aren't like that. so it's probably worth to pursue both routes: the apparently harder one of defining entirely new architectures without the traditional L1 cache where there are fewer timing differences – useful anyway for proven real-time industrial control 
< 1761025585 510932 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :applications so we might as well use it for something else too –, and the less hard one where we figure out how to do cryptographic operations in a way that the keys can't be leaked by timing or other side-channel attacks even to code on the same CPU, even if admittedly we have a bad track record with this.
< 1761025594 530522 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: you're reminding me of the problems with mmapping files in Rust
< 1761025606 81161 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Right. But, also, simply-typed lambda calculi are cap-safe by default and it's clear to me that we can offer just about any computational abilty to users within a simply-typed context. We do this to ourselves.
< 1761025627 224398 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Rust programs frequently just do that in practice, even though it's unsound in theory (because the Rust implementation assumes that reading the same memory twice without writing it in between gives you the same value)
< 1761025648 807536 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :i expect/hope we'll see a shift away from "isolation" and towards a model which distinguishes confidentiality domains from integrity domains
< 1761025658 11660 :strerror!~strerror@user/strerror PRIVMSG #esolangs :Most of most people's security depends on them not being rich enough to be a target for serious attackers.
< 1761025667 223592 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can work around the issue by mapping the memory as relaxed atomics rather than regular numbers, but few people actually do that
< 1761025677 32779 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :integrity is cheap, confidentiality requires complete system partitioning and/or time slicing with complete state clears
< 1761025707 955411 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I assume you mean simply-typed lambda calculi with fixedpoint? not the non-TC version?
< 1761025717 743124 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Isolation's a really powerful primitive in distributed systems. Admittedly it's usually baked into spacetime and the configuration of computers in a room, but it's still useful.
< 1761025719 755722 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :err, fixpoint
< 1761025720 76904 :strerror!~strerror@user/strerror PRIVMSG #esolangs :There are now devices like Yubikeys though, which sort of give you a segregated chip to store your keys
< 1761025725 606415 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I have ideas about how to make it work with network transparency, although in that case many kind of external attacks are possible. You still cannot send or use a capability that you neither have yourself nor received from the other side, but exteral interference can still result in undesired operations with these capabilities (but encryption can mitigate this).
< 1761025772 37260 :strerror!~strerror@user/strerror PRIVMSG #esolangs :ais523: hm, does mapping it as atomic actually remove the unsoundness, or just admit that it's there?
< 1761025790 321770 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: I mean truly simply typed with no fixpoints. The sort of thing Cammy can do, by zero coincidence. TC means that the user will learn *something* about your computational substrate.
< 1761025794 43925 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :strerror: it actually removes it, if you relaxed-read an atomic twice the compiler doesn't assume it'll get the same value both times
< 1761025835 497734 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :the difficulty with making side-channel operations hard even with untrusted code running on the same CPU is that you can only make that work if *both* CPU manufacturers and compiler writers work on it together, you can't do it with just one side or the other. 
< 1761025841 290129 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: now you have me wondering how many useful programs can be written like that (both in terms of "it is possible to write" and in terms of "a typical program can figure out how to write")
< 1761025871 265646 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :This was Monte's biggest weakness IMO. In Monte, E, Joule, etc. as well as Python's Twisted or Ruby's EventMachine, there's simply no guarantee of productivity for a sent message. There's not even a guarantee of receipt or way to find out what happened in case of error. Great model for UDP but terrible for in-memory event queues.
< 1761025875 627033 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :at the llvm level you also have "unordered atomics" which were invented to handle Java's constrained behavior for data races
< 1761025889 113168 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :how does that differ from relaxed?
< 1761025931 677078 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :relaxed atomics cannot be reordered if they might alias
< 1761025961 922969 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :sorear: wait, is that true?
< 1761025963 20357 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :presumably it doesn't work very well since c++ didn't copy it
< 1761025991 806524 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :yes, two relaxed reads to the same address must be executed in program order
< 1761026005 65771 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ok, I still don't understand the C++ atomics model then
< 1761026062 303067 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :2016 riscv allowed load instructions to the same address to be executed in either order, so relaxed atomics needed a fence until the model was tightened (matching arm and ppc instead of alpha)
< 1761026093 324607 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: relaxed doesn't require ordering between multiple threads, e.g. if thread A relaxed-reads address X then relaxed-writes address X, and thread B relaxed-reads address X then relaxed-writes a function of its value to address X, then the value thread A reads can be based on the value that thread A writes
< 1761026098 280461 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :so this java thing would be something more relaxed then relaxed atomics, but more strict than ais523's operation that lets you read an integer with valid but undefined result in case of a data race, because it still wouldn't allow tearing so you'd keep memory-safe pointers?
< 1761026145 706437 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :https://en.wikipedia.org/wiki/ALGOL_68#Books,_channels_and_files
< 1761026154 443880 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(although this is only allowed if the value it writes doesn't depend on the value it reads – programs aren't supposed to be able to create an actual time paradox, even using relaxed atomics)
< 1761026203 389834 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :pointer tearing can't happen on any real architecture ("single-copy atomicity").  fat pointers e.g. Go are a separate issue
< 1761026251 303423 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :time paradoxes are called "out of thin air reads" and are unfortunately allowed in most memory models
< 1761026265 203889 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: in the C++ memory model they're disallowed by fiat
< 1761026272 975774 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the standard says not to do them, without defining what that means
< 1761026295 913062 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :I do love standard requirements that don't mean anything
< 1761026315 221597 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :sorear: of course, but I think the read operation that ais523 wants would allow pointer tearing
< 1761026325 793636 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fwiw I am now at this point almost convinced that the correct definition is "do not create a loop in the happens-before + semantically-depends relation" although I may have problems actually justifying it
< 1761026358 43142 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I'm fine to allow pointer tearing because part of the rules for the operation is that if there is a race condition you don't do anything with the resulting value
< 1761026358 785419 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I can see why these are hard problems at least
< 1761026359 784334 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* value
< 1761026370 615924 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :having a torn pointer is safe as long as you never dereference it
< 1761026387 304855 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: but are you allowed to use the torn value as an integer?
< 1761026400 840798 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :or do you have to check before you're even allowed to do arithmetic or conditionals on it?
< 1761026405 316284 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :err, not just happens-before + semantically-depends, it also includes read-written-value
< 1761026435 583941 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: with my suggestion, no, but I can see an argument that it should be yes
< 1761026464 741869 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in fact there was a long discussion about that in the Rust forums or bug tracker (I forget which)
< 1761026485 672179 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :(also fun: `final` affects the memory model!  if you have a class with final fields and you're on Alpha which does not enforce in-order loads in the presence of an address dependency, if you receive an object pointer you need to fence before reading final fields so the fields can't appear to change)
< 1761026493 317470 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and my attempted proofs that my version was safe didn't work for the version where using the read value as an integer were possible
< 1761026564 162606 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(that doesn't necessarily mean that it is unsafe, just that it's harder to prove safe)
< 1761026643 241349 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this came up in the context of implementing LLVM's "freeze" operation in Rust (which works as follows: in LLVM, "undefined" is a separate value that all types can have; an LLVM-freeze changes undefined values to an arbitrary value and is a no-op on defined values)
< 1761026664 379632 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and there was a huge debate about whether this was safe to add to the language, in the sense of not causing miscompiles
< 1761026831 322869 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(my guess is that it probably is, but I can't prove it and it may be difficult to prove)
< 1761026836 994272 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I think you would have to ensure that the implementation is correct, but it could be done, e.g. marking a register as "in use" without changing its value, in one case, possibly
< 1761027560 898692 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer
< 1761027760 161602 :^[!~user@user//x-8473491 QUIT :Ping timeout: 256 seconds
< 1761028480 642643 :^[!~user@user//x-8473491 JOIN #esolangs ^[ :user
< 1761029687 769362 :ais523!~ais523@user/ais523 QUIT :Quit: quit
< 1761031314 334276 :tromp!~textual@2001:1c00:3487:1b00:75ad:6ea9:b519:8422 JOIN #esolangs * :Textual User
< 1761031976 103179 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs * :[https://web.libera.chat] wob_jonas
< 1761032063 319841 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: so an operation that can read an integer from memory non-atomically such that is unpredictable but not a trap value when there's an inter-thread race would be useful for running untrusted multithreaded code, which is why I think this came up in Java
< 1761032141 370525 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but I don't know if that's the same operation as reading a relaxed atomic.
< 1761032875 211489 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :does that LLVM-freeze only make sense for types like built-in integer or float types, or would it also apply to pointers? because I don't see how you could implement it for pointers.
< 1761032895 173672 :tromp!~textual@2001:1c00:3487:1b00:75ad:6ea9:b519:8422 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1761032975 780025 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :hmm, in https://logs.esolangs.org/libera-esolangs/2025-10-21.html#lse you say that relaxed atomics is appropriate for mmapping areas that other processes could modify, so maybe what I'm asking for *is* just relaxed atomic reads and writes. but the problem is that in the C++ model, relaxed atomic reads are considered unsafe if another process does a
< 1761032976 280172 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :non-atomic write, aren't they.
< 1761033730 314174 :tromp!~textual@2001:1c00:3487:1b00:75ad:6ea9:b519:8422 JOIN #esolangs * :Textual User
< 1761034355 535476 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :oh yeah, question. can you safely use C11 call_once from a signal handler, in the sense that you share a global once_flag variable that you may use from either any thread of the process or a signal handler in any thread? and if I want this, should I declare it volatile?
< 1761034875 571082 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I guess this might not be the right question, because that's rarely useful.
< 1761037569 913638 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1761037650 842653 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although I don't know for certain, I don't see why you couldn't LLVM-freeze a pointer (although, if the value was previously undefined, you wouldn't be able to dereference the resulting pointer – it would still be safe to treat its address as an integer though)
< 1761037757 705197 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and yes, I think the C++/C11 atomics model disallows a race between an atomic read and a non-atomic write – but on most processors it's impossible to do a write weaker than relaxed unless the write splits a cache line (I think the discussion about doing relaxed-atomic reads of mmaps required you to read it a byte at a time, because of that)
< 1761037785 561847 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in other words, your atomic read at the C++ level is racing with an atomic write at the asm level, so it works if you interpret the other process as being written in asm/machine code
< 1761037822 474626 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess technically this would be unsound if an implementation decided to optimize across processes, but that seems like an unlikely optimisation choice
< 1761037854 728205 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :oh, so not only do I have to do relaxed atomic reads, I have to do bytewise relaxed atomic reads? that sounds kind of annoying at first, but the compiler can probably optimize it to larger reads when I read a whole aligned word's worth of reads.
< 1761037975 972523 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm not sure whether compilers are allowed to take advantage of the fact that reads are guaranteed never to be torn, if it can't tell what's doing the write
< 1761037981 989228 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* are able to take advantage
< 1761038012 24296 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I can't think of any optimisations that would allow, so just reading it atomically as aligned u32s or the like is probably going to be safe in practice
< 1761038044 946182 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the glibc documentation says that their call_once is currently safe to call in a signal handler but they aren't committing to that yet
< 1761038067 251812 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this implies that in C11 generally it isn't safe, otherwise the glibc devs would probably have committed to following the standard
< 1761038117 685427 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(and the obvious implementation of it could deadlock if called from a signal handler)
< 1761038180 482708 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :…actually I'm not sure *how* it could be safe to call from a signal handler, what happens if the signal arrives halfway through the interrupted thread running the function?
< 1761038279 262400 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I'm not sure C11 even tries to define how user-defined signal handlers in a multi-threaded program work. I have the feeling that the C standard doesn't even want to be concerned with signal handlers, they are just forced to because the signal function was in an early C standard as kind of a mistake and they don't want to remove it now.
< 1761038299 169278 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :that's more POSIX's territory
< 1761038513 205206 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :as for calling init_once from a signal handler while the initialization function is already in progress in the same thread, I think from the perspective of init_once, that's not really worse than an ordinary recursive call of init_once from the initialization routine when signal handlers aren't involved
< 1761038800 813779 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: looks like call_once is not safe to call from a signal handler, despite the glibc docs (I have a TIO URL but it's too long to paste and am not sure I trust any of the URL shorteners I'm aware of)
< 1761038849 433053 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :https://tio.run/##fVA7a8MwEN79K46UFJnYpZnddCshcyBTQYiTbAtkKUiyl5C/HlVXOy3pUA16fPoed4d1h5jSk7ZoRqngLfZeCRle@vfiFwy6s8L8waLUjqAiRBE1grOoeGtEB7Q1P/jkTD6NguzCRXSDRh4B3Wij8rCD10ydnJbQOsfoUsKlgLw2m4XUfD@90EGx42F//Nifyqa4LrKguon3wkqjPNM2Uo4dh7sLCmM41caeqa6KYmY1cQeh7UPo3Oo9pnpwL5v/HOnr7LNpy1Zr@WlXFVA55dIEZaZ0Q5KEVNd5fjvcblNtzvPMvwA
< 1761038851 954561 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah, there we go
< 1761038868 357068 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :doing it as a separate line was enough
< 1761038909 874983 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this looks very much like it deadlocked (and it's hard to imagine any other reasonable result)
< 1761038951 35093 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in particular it timed out without any noticeable CPU usage
< 1761038978 834763 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(what little CPU usage is shown is probably almost entirely from the compiler)
< 1761039176 269040 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: but wouldn't call_once deliberately deadlocked if you tried this without the signal handler, as in if foo tried to call_once(&flag, ...) ?
< 1761039208 313516 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wob_jonas: right, but it's an async signal, those can happen at any point (that's kind-of the definition of an async signal)
< 1761039247 186296 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so to be async-signal-safe, the code has to work regardless of when the signal arrives, including the most inconvenient possible time (which in this case is the middle of the function passed as an argument to call_once)
< 1761039306 23183 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a possible "fix" would be to mask all signals temporarily while running the call_once function (although that would have its own issues)
< 1761039328 840001 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :right, so you just shouldn't call call_once from a signal handler, there's no sane semantics, which is why my original question was a bad one.
< 1761039379 432341 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well the glibc documenters seem to have got this wrong too, so it's at least non-obvious to some people
< 1761040428 884926 :APic!apic@apic.name PRIVMSG #esolangs :Hi
< 1761046188 169829 :amby!~ambylastn@host-92-17-37-198.as13285.net JOIN #esolangs * :realname
< 1761046663 587872 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 256 seconds
< 1761046817 587512 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord
< 1761046844 417898 :chiselfuse!~chiselfus@user/chiselfuse QUIT :Remote host closed the connection
< 1761046857 336148 :chiselfuse!~chiselfus@user/chiselfuse JOIN #esolangs chiselfuse :chiselfuse
< 1761047881 504274 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu QUIT :Quit: Client closed
< 1761049652 552057 :sytra!~sytra@212.24.11.211 JOIN #esolangs * :Jordan
< 1761049712 818880 :ais523!~ais523@user/ais523 QUIT :Quit: quit
< 1761049808 685874 :sytra!~sytra@212.24.11.211 QUIT :Client Quit
< 1761049821 487846 :sytra!~sytra@212.24.11.211 JOIN #esolangs * :Jordan
< 1761053048 957555 :sytra!~sytra@212.24.11.211 QUIT :Quit: sytra
> 1761054893 314359 PRIVMSG #esolangs :14[[07Mango14]]4 N10 02https://esolangs.org/w/index.php?oldid=166337 5* 03RaiseAfloppaFan3925 5* (+1464) 10Created page with "{{Template:Stub}}  Mango is an unimplemented programming language by [[User:RaiseAfloppaFan3925]] inspired by modern 2010-20s slang.  {{infobox proglang | name = Mango | paradigms=imperative, procedural | author = [[User:RaiseAfloppaFan3925]] | year = 2025 | c
> 1761055000 12300 PRIVMSG #esolangs :14[[07User:RaiseAfloppaFan392514]]4 10 02https://esolangs.org/w/index.php?diff=166338&oldid=159606 5* 03RaiseAfloppaFan3925 5* (+179) 10
< 1761056459 794685 :tromp!~textual@2001:1c00:3487:1b00:75ad:6ea9:b519:8422 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1761056506 803744 :tromp!~textual@2001:1c00:3487:1b00:75ad:6ea9:b519:8422 JOIN #esolangs * :Textual User
< 1761056632 633080 :simcop2387!~simcop238@perlbot/patrician/simcop2387 QUIT :Ping timeout: 260 seconds
< 1761056632 633287 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot QUIT :Ping timeout: 260 seconds
> 1761057231 445820 PRIVMSG #esolangs :14[[07Sorry14]]4 10 02https://esolangs.org/w/index.php?diff=166339&oldid=139445 5* 03Yayimhere2(school) 5* (+1) 10
> 1761057288 704340 PRIVMSG #esolangs :14[[07Sorry14]]4 10 02https://esolangs.org/w/index.php?diff=166340&oldid=166339 5* 03Yayimhere2(school) 5* (+0) 10
> 1761058487 779679 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Swatinine 5*  10New user account
< 1761058749 231853 :simcop2387!~simcop238@perlbot/patrician/simcop2387 JOIN #esolangs simcop2387 :ZNC - https://znc.in
> 1761058926 449826 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=166341&oldid=166302 5* 03Swatinine 5* (+150) 10
> 1761058953 747955 PRIVMSG #esolangs :14[[07User:Aadenboy14]]4 10 02https://esolangs.org/w/index.php?diff=166342&oldid=166330 5* 03Aadenboy 5* (-149) 10/* ESOLANGS */ class="rectwrap"
> 1761058965 556714 PRIVMSG #esolangs :14[[07A=ab=bc=cd=d!14]]4 10 02https://esolangs.org/w/index.php?diff=166343&oldid=165004 5* 03Aadenboy 5* (+17) 10/* Truth Machine */ class="rectwrap"
> 1761058973 605874 PRIVMSG #esolangs :14[[07User:Swatinine14]]4 N10 02https://esolangs.org/w/index.php?oldid=166344 5* 03Swatinine 5* (+26) 10Created page with "Hello! I'm Swatinine! "
> 1761059038 599192 PRIVMSG #esolangs :14[[07User:Swatinine14]]4 10 02https://esolangs.org/w/index.php?diff=166345&oldid=166344 5* 03Swatinine 5* (+38) 10
> 1761059042 414024 PRIVMSG #esolangs :14[[07Mango14]]4 10 02https://esolangs.org/w/index.php?diff=166346&oldid=166337 5* 03RaiseAfloppaFan3925 5* (+992) 10Added Deadfish interpreter example + new keywords
> 1761059263 879510 PRIVMSG #esolangs :14[[07Mango14]]4 M10 02https://esolangs.org/w/index.php?diff=166347&oldid=166346 5* 03Aadenboy 5* (-9) 10remove unnecessary namespace inclusion
> 1761059281 348278 PRIVMSG #esolangs :14[[07Mango14]]4 10 02https://esolangs.org/w/index.php?diff=166348&oldid=166347 5* 03Aadenboy 5* (-1) 10move infobox to top
> 1761059471 933445 PRIVMSG #esolangs :14[[07Mango14]]4 M10 02https://esolangs.org/w/index.php?diff=166349&oldid=166348 5* 03RaiseAfloppaFan3925 5* (+1) 10oops typo in the category, changed to high level
> 1761061106 16831 PRIVMSG #esolangs :14[[07Talk:TDQ14]]4 N10 02https://esolangs.org/w/index.php?oldid=166350 5* 03Yayimhere2(school) 5* (+143) 10Created page with "Hey, thanks for that!!!   --~~~~"
< 1761061125 845876 :tromp!~textual@2001:1c00:3487:1b00:75ad:6ea9:b519:8422 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
> 1761061569 682124 PRIVMSG #esolangs :14[[07Thing14]]4 10 02https://esolangs.org/w/index.php?diff=166351&oldid=135948 5* 03Yayimhere2(school) 5* (+81) 10
< 1761062681 709681 :tromp!~textual@2001:1c00:3487:1b00:75ad:6ea9:b519:8422 JOIN #esolangs * :Textual User
< 1761064966 387108 :tromp!~textual@2001:1c00:3487:1b00:75ad:6ea9:b519:8422 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
> 1761066243 228732 PRIVMSG #esolangs :14[[07Bijection14]]4 10 02https://esolangs.org/w/index.php?diff=166352&oldid=138371 5* 03Yayimhere2(school) 5* (+5) 10
< 1761066338 912686 :tromp!~textual@2001:1c00:3487:1b00:75ad:6ea9:b519:8422 JOIN #esolangs * :Textual User
< 1761066416 100976 :Yayimhere!~Yayimhere@197.184.123.213 JOIN #esolangs * :[https://web.libera.chat] Yayimhere
< 1761066428 125960 :Yayimhere!~Yayimhere@197.184.123.213 PRIVMSG #esolangs :hello esolangs!
< 1761066445 780146 :Yayimhere!~Yayimhere@197.184.123.213 PRIVMSG #esolangs :or Esolang people or whatever
< 1761066552 220568 :Yayimhere!~Yayimhere@197.184.123.213 PRIVMSG #esolangs :how are you
< 1761066864 249445 :Yayimhere!~Yayimhere@197.184.123.213 QUIT :Quit: Client closed
< 1761066874 99446 :Yayimhere!~Yayimhere@197.184.123.213 JOIN #esolangs * :[https://web.libera.chat] Yayimhere
< 1761067072 561939 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yayimhere: Morning.
< 1761067151 484626 :Yayimhere!~Yayimhere@197.184.123.213 PRIVMSG #esolangs :Korvo: Morning! are you good? and are you working on anything lol?
< 1761067539 121687 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh, to not be working on anything. I'm theoretically helping sorear clean up the NQL toolchain and merge in some community contributions, although frankly they do not need my help. I'm looking at Smalltix, a brand-new way of doing Smalltalk in Unix which I might operationalize. And I'm thinking of cleaning up the recent stub for Joy, but I'm not sure what should be done besides infobox.
< 1761067682 589227 :Yayimhere!~Yayimhere@197.184.123.213 PRIVMSG #esolangs :cool! I actually just looked at the page for smalltix(though I dont understand, but thats a me problem). me personally, am trying to make an esolang focused on being undecidable, cuz I though it was interesting, for making a simple language. but its not going very well lol. but ill figure it out. but yea, nice!
< 1761067735 198905 :Yayimhere!~Yayimhere@197.184.123.213 PRIVMSG #esolangs :ive been very inspired to do work, cuz I read some of my older works, and found them, quite good in my opion
< 1761067744 798843 :Yayimhere!~Yayimhere@197.184.123.213 PRIVMSG #esolangs :*opinion
< 1761067818 500978 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Undecidability is fairly easy. It's undecidable whether untyped lambda terms have normal forms, for example. What might your language compute?
< 1761067880 878840 :Yayimhere!~Yayimhere@197.184.123.213 PRIVMSG #esolangs :I know it's simple, but I want to duo it creatively. but I think ill work on (if possible) make the language compile, self compiler style. but tbh idk what the hell im doing lol.
< 1761067900 144283 :Yayimhere!~Yayimhere@197.184.123.213 PRIVMSG #esolangs :*do
< 1761068424 495879 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :No worries. There's no rush.
< 1761068426 600174 :Yayimhere!~Yayimhere@197.184.123.213 PRIVMSG #esolangs :ok I think ive found a got concept!
< 1761068429 177351 :Yayimhere!~Yayimhere@197.184.123.213 PRIVMSG #esolangs :lol
< 1761068437 558006 :Yayimhere!~Yayimhere@197.184.123.213 PRIVMSG #esolangs :korvo: ofc!
> 1761068483 866111 PRIVMSG #esolangs :14[[07Joy14]]4 10 02https://esolangs.org/w/index.php?diff=166353&oldid=166110 5* 03Corbin 5* (+156) 10Fill out a bit more of this stub. I was going to be upset that this isn't just a contribution to catlangwiki, but on the other hand this is an opportunity to write a better article.
> 1761068629 631367 PRIVMSG #esolangs :14[[07Quote14]]4 N10 02https://esolangs.org/w/index.php?oldid=166354 5* 03Corbin 5* (+341) 10Stub a common concept. Not sure of the best name for this article.
> 1761069102 112581 PRIVMSG #esolangs :14[[07Manfred von Thun14]]4 N10 02https://esolangs.org/w/index.php?oldid=166355 5* 03Corbin 5* (+328) 10Stub for Von Thun.
< 1761069245 99884 :Yayimhere!~Yayimhere@197.184.123.213 QUIT :Ping timeout: 250 seconds
> 1761069489 285492 PRIVMSG #esolangs :14[[07Talk:Concatenative calculus14]]4 N10 02https://esolangs.org/w/index.php?oldid=166356 5* 03Corbin 5* (+840) 10Still thinking on this one.
> 1761069847 119860 PRIVMSG #esolangs :14[[07Concatenative language14]]4 10 02https://esolangs.org/w/index.php?diff=166357&oldid=156941 5* 03Corbin 5* (+137) 10Update bluelinks. catlangwiki doesn't do underscores like MW, so I've hacked up something equivalent.
> 1761069992 581624 PRIVMSG #esolangs :14[[07Concatenative language14]]4 M10 02https://esolangs.org/w/index.php?diff=166358&oldid=166357 5* 03Corbin 5* (+14) 10Tighten up a bit of phrasing. Link [[monoid]] as main article for monoidal viewpoint.
> 1761070071 262145 PRIVMSG #esolangs :14[[07Mlatu14]]4 M10 02https://esolangs.org/w/index.php?diff=166359&oldid=156894 5* 03Corbin 5* (-12) 10Bluelink.
> 1761070097 541347 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Goodbyevoidhelloworld1 5*  10New user account
> 1761070235 160143 PRIVMSG #esolangs :14[[07Cammy14]]4 M10 02https://esolangs.org/w/index.php?diff=166360&oldid=165389 5* 03Corbin 5* (+28) 10Bluelinks.
< 1761070322 93992 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :One must imagine Sisyphus happy.
< 1761070336 349178 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Really, one must imagine that Sisyphus deserved it~
< 1761071609 426933 :APic!apic@apic.name PRIVMSG #esolangs :G'Night
< 1761071833 690914 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Night.
> 1761072245 779579 PRIVMSG #esolangs :14[[07Quote14]]4 10 02https://esolangs.org/w/index.php?diff=166361&oldid=166354 5* 03Aadenboy 5* (+64) 10distinguish? might be a little silly
< 1761072409 134209 :vista_user!~vista_use@72.red-88-1-117.dynamicip.rima-tde.net JOIN #esolangs * :[https://web.libera.chat] vista_user
< 1761072427 764577 :vista_user!~vista_use@72.red-88-1-117.dynamicip.rima-tde.net CHGHOST ~vista_use :user/DOS-User:11249
< 1761072767 526102 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Welcome back.
< 1761072780 749304 :vista_user!~vista_use@user/DOS-User:11249 PRIVMSG #esolangs :who
< 1761072782 780902 :vista_user!~vista_use@user/DOS-User:11249 PRIVMSG #esolangs :m3?
< 1761072787 578838 :vista_user!~vista_use@user/DOS-User:11249 PRIVMSG #esolangs :*me
> 1761072797 309508 PRIVMSG #esolangs :14[[07Quote14]]4 M10 02https://esolangs.org/w/index.php?diff=166362&oldid=166361 5* 03Somefan 5* (+33) 10str
< 1761072924 416479 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :vista_user: Oh, I thought you were another webchat user. Welcome nonetheless.
< 1761073114 495611 :vista_user2!~vista_use@72.red-88-1-117.dynamicip.rima-tde.net JOIN #esolangs * :[https://web.libera.chat] vista_user2
< 1761073119 100880 :vista_user!~vista_use@user/DOS-User:11249 QUIT :Ping timeout: 250 seconds
< 1761073119 199530 :vista_user2!~vista_use@72.red-88-1-117.dynamicip.rima-tde.net PRIVMSG #esolangs :20:55:24 <korvo> vista_user: Oh, I thought you were another webchat user. Welcome nonetheless.
< 1761073120 949424 :vista_user2!~vista_use@72.red-88-1-117.dynamicip.rima-tde.net PRIVMSG #esolangs :i see
< 1761073129 567432 :vista_user2!~vista_use@72.red-88-1-117.dynamicip.rima-tde.net PRIVMSG #esolangs :ugh dangit ghost user
< 1761073175 843479 :vista_user2!~vista_use@72.red-88-1-117.dynamicip.rima-tde.net PRIVMSG #esolangs :and now its offlime?
< 1761073179 875886 :vista_user2!~vista_use@72.red-88-1-117.dynamicip.rima-tde.net PRIVMSG #esolangs :wtf libera
< 1761073186 857513 :vista_user2!~vista_use@72.red-88-1-117.dynamicip.rima-tde.net NICK :vista_user
< 1761073197 645575 :vista_user!~vista_use@72.red-88-1-117.dynamicip.rima-tde.net CHGHOST ~vista_use :user/DOS-User:11249
< 1761073204 575773 :vista_user!~vista_use@user/DOS-User:11249 PRIVMSG #esolangs :finally
> 1761073275 687247 PRIVMSG #esolangs :14[[07Quote14]]4 10 02https://esolangs.org/w/index.php?diff=166363&oldid=166362 5* 03Aadenboy 5* (+23) 10format
> 1761073294 432679 PRIVMSG #esolangs :14[[07Adofaiscript14]]4 N10 02https://esolangs.org/w/index.php?oldid=166364 5* 03 5* (+1889) 10Started it
> 1761073419 231598 PRIVMSG #esolangs :14[[07Adofaiscript14]]4 10 02https://esolangs.org/w/index.php?diff=166365&oldid=166364 5* 03Aadenboy 5* (+50) 10{{WIP}} + categories
> 1761073456 154452 PRIVMSG #esolangs :14[[07Quote14]]4 M10 02https://esolangs.org/w/index.php?diff=166366&oldid=166363 5* 03Corbin 5* (+12) 10Funnier.
> 1761073846 326033 PRIVMSG #esolangs :14[[07Quote14]]4 10 02https://esolangs.org/w/index.php?diff=166367&oldid=166366 5* 03Aadenboy 5* (-26) 10merge
< 1761074870 249057 :sytra!~sytra@212.24.11.211 JOIN #esolangs * :Jordan
< 1761075043 102515 :vista_user!~vista_use@user/DOS-User:11249 QUIT :Ping timeout: 250 seconds
< 1761076088 943361 :FreeFull!~freefull@79.186.201.19.ipv4.supernova.orange.pl JOIN #esolangs FreeFull :FreeFull
< 1761081243 426984 :sytra!~sytra@212.24.11.211 QUIT :Quit: sytra
< 1761081588 798542 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1761081594 967164 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :https://tio.run/##rVLRSuNAFH3PVxwrthNIW1OXhV1rHhasFkQFEV8WZJK5aYYdZ8Jkxj6sfnudJK1QX0Qw5GHmnjvnnHu4OW@qzabgDhncpMB8Pjq/WYyiQ6kL5QVh3jghzaTK9kpW6tV@jazVH9q8luHxh6dypblqa5HUDk9cavZspIjxP0L4epzdLS9ul7fnCcLhcXlxHZ/2KLnn3Jcs0Aa9BNf3V1cJHpc3iz@LBD@Of/2MTzGdoqmMVwI5gUObsamRe4ei4npFDYx3tXcdYecaZzju@eswlyvZ4Ej81YME5dpKR2xwSUqZBGtjlTgI9TT8swS9i7iXDDSa1kpq2mN6CAwhKzizbQfLqTSWUMuakFvi/@LfOGo6wRBsaDGWdb7i3dSKqGaz7e37LDdOKvUF47x0ZL/g@xOnpfJNxd4d7fUsWqyV7@
< 1761081596 572084 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :FPhCw5b3Wr8xqF7Y1WRdEt89jARZOpw0k2nGGWDVOk2fAEL32kSHGIZs3r3YRci/YY9iOBq0h3s467Wdt7m9MWBzNK7NJEH0wa1rMwWmw2bw
< 1761081606 200591 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is me trying to understand stdio buffering
< 1761081627 956101 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but the output is really confusing and not only doesn't seem to match the docs, I can't form a consistent model of it
< 1761081848 677781 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(sorry about the link being split over two lines)
< 1761082191 85006 :int-e!~noone@int-e.eu PRIVMSG #esolangs :stderr is unbuffered by default?
< 1761082210 94151 :int-e!~noone@int-e.eu PRIVMSG #esolangs :and the `setvbuf` changes that
< 1761082420 917049 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: it's documented as line-buffered if interactive, fully buffered if not interactive (and in this case stderr is a pipe, so not interactive)
< 1761082448 941524 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but, if it were fully buffered, then the fwrite call shouldn't be able to see that the pipe has broken because it shouldn't produce output at all
< 1761082456 500942 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the second fwrite call, that is
< 1761082465 189735 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :python 3.14 has significant changes in its garbage collector implementation, just in case anyone's interested in that sort of thing
< 1761082466 725224 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and returning 1 is just bizarre
< 1761082500 678335 :int-e!~noone@int-e.eu PRIVMSG #esolangs :"The  standard  error stream stderr is always unbuffered by default." -- setvbuf(3)
< 1761082541 721321 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: ah, you're reading the man page and I'm reading the info page
< 1761082559 160759 :int-e!~noone@int-e.eu PRIVMSG #esolangs :fun
< 1761082560 182784 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the info page doesn't have that special case (and in fact says there are no special cases other than the interactive case)
< 1761082572 62134 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that's one mystery solved, at least – but the output for buffered stderr still doesn't make sense
< 1761082593 57428 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(and the buffering clearly does something because the second fwrite returns 0 rather than 1 without it)
< 1761082633 100555 :vista_user!~vista_use@user/DOS-User:11249 JOIN #esolangs DOS_User :[https://web.libera.chat] vista_user
< 1761082700 228497 :vista_user!~vista_use@user/DOS-User:11249 PRIVMSG #esolangs :python 3.14...finally, πthon
< 1761082711 473580 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: It acts normal for me in a terminal. (12, 12, -1)
< 1761082729 245393 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ooh, let me try in mine
< 1761082758 621233 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, normal in mine too
< 1761082829 181191 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the original thing that prompted the experiment is a Rust bug report that was traced to stderr flushing doing something unexpected, although that was on mingw – there was speculation that it might act differently in a container for some reason, and now there's evidence of it acting differently in a sandbox/container on Linux too which is interesting)
< 1761082869 843922 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although it might be a case of different glibc version, or the like
< 1761082888 26724 :vista_user!~vista_use@user/DOS-User:11249 QUIT :Remote host closed the connection
> 1761083123 487512 PRIVMSG #esolangs :14[[07Izeva14]]4 N10 02https://esolangs.org/w/index.php?oldid=166368 5* 03Ivava 5* (+922) 10Created page with "{{WIP}}  :'' Does not apply to '''IZEVA - International Council on Clean Transportation''' and other  '''Izeva''' is easy(Maybe. It hasn't cycles) character-by-character esolang, has IO based on single accumulator. Hasn't good or useful commands. The only pleasant thing is a
< 1761083207 40273 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think my computer has glibc 2.41 and TIO has glibc 2.28, although it's hard to be confident
< 1761083542 637091 :int-e!~noone@int-e.eu PRIVMSG #esolangs :https://tio.run/##S0oszvj/P7lAQT8nM8nMBEQm6xrpGVnoFecr6HHpoQj8/w8A
< 1761083611 93257 :int-e!~noone@int-e.eu PRIVMSG #esolangs :pretty confident about this one ;-)
< 1761083766 316785 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :huh, I didn't realise you could just execute glibc as an executabe
< 1761083770 229907 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* executable
< 1761083813 100782 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 JOIN #esolangs * :[https://web.libera.chat] CodeMelon
< 1761083821 508269 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Hiii
< 1761083838 421154 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Anyone online?
< 1761083853 159485 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes
< 1761083868 750820 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although it's usual to wait on IRC for a while to find that out, because people aren't necessarily checking it constantly
< 1761083869 94580 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Cool :D
< 1761083877 938340 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Ok
< 1761083892 229314 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :for this channel, a good option is to read the logs to see if people have been talking (but not all channels have public logs)
< 1761083907 705113 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :I've just started going down the esolang rabbit hole
< 1761083958 724527 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :And ive wrote my first esolang script can you rate it for me?
< 1761084023 490366 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :do you mean a program written in an esolang or a program that implements an esolang?
< 1761084029 773517 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :It's also a crude very short and not so fleshed out brainfuck explenation.
< 1761084042 178755 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :A program written in one
< 1761084065 116753 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :So... yeah or nah?
< 1761084114 930662 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :reading BF is normally quite difficult
< 1761084121 674509 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Its probably been done before anyway but this is my own version of this kind of script
< 1761084126 553956 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Ita not bf
< 1761084140 254584 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Its a bf "mod"
< 1761084143 579478 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Idk
< 1761084158 640131 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah, we have a huge number of those already
< 1761084168 391831 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Like a version of bf thats still bf but a little different
< 1761084176 240463 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so one more won't hurt much, but most of the existing ones aren't particularly creative
< 1761084196 581723 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :No i think you nderstand me wrong
< 1761084197 66812 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :CodeMelon: Out of curiosity, are you here from truttle1 the Youtuber?
< 1761084204 27852 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Nope
< 1761084226 84525 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I agree that I don't think I understand what you've done
< 1761084262 744796 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Can i just show you? Like is it allowed to write a short code snippet in chat?
< 1761084276 54592 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :CodeMelon: Use a pastebin please! bpa.st is an option.
< 1761084288 354396 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Or maybe webchat does it automatically?
< 1761084293 93331 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :don't post things directly in chat if they're more than about two lines long, use a pastebin instead
< 1761084319 667080 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Aight
< 1761084334 51060 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Here ya go: https://bpa.st/K4RBO
< 1761084364 968268 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah, it's polyglot code
< 1761084370 233448 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :between English and an esolang
< 1761084376 595033 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Nope
< 1761084380 192782 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Guessing that the ASCII case bit is a carrier, like in the PNG format.
< 1761084382 24577 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Or wait
< 1761084392 756850 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: appears to be https://esolangs.org/wiki/OOo_CODE
< 1761084397 777287 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Yes
< 1761084403 118086 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Its oOo code
< 1761084428 23000 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Nice find.
< 1761084439 706754 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Its said in the text and it does what it says it will do while explaining the basics of bf
< 1761084460 378163 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :So is this as my first esolang script good?
< 1761084477 268256 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in this situation you can use arbitrary ASCII text as a carrier, so it's basically just an encoding of a BF constant string printer
< 1761084486 146328 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Yes
< 1761084497 920470 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so it isn't technically interesting, but it is artistically interesting – whether that's "good" or not is a matter of perspective
< 1761084498 895643 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Fun! I haven't checked that it's correct, but it's a decent concept. Did you generate this from another script or did you write it by hand? Impressive either way.
< 1761084578 136896 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :korvo I made a website that turns bf into oOo code and you can combine bf and self written text into oOo :)
< 1761084608 364944 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Just a  fun project i made this afternoon
< 1761084617 441132 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :now I'm thinking about oOo code quines – it's easy enough if you just write the entire program with o and O, but making them use readable text as the carrier would be interesting
< 1761084637 523583 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Yeah :)
< 1761084647 444225 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it would by nature necessarily have to be substantially compressible, which means that the challenge would be to find a text document that was highly compressible but didn't *look* highly compressible, whilst still remaning meaningful
< 1761084651 424146 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yep, that makes sense. Good times. Totally useless most of the time, unfortunately. Stego's the sort of thing that only makes sense during Little Brother scenarios, and then you need for your stego to be completely invisible rather than fairly obvious.
< 1761084678 293812 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: it doesn't have to be steganography, it could be polyglotting instead
< 1761084692 841619 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :i.e. the information channel's existence is obvious but it doesn't interfere with reading the source code a different way
< 1761084720 138839 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :I still have trouble writing quines theyre so scary :(
< 1761084728 246511 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :And hard
< 1761084737 105815 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Like to come up with
< 1761084785 844910 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :something like the Code Golf Stack Exchange polyglot, being valid in over 300+ different languages/implementations, is *entirely* obvious signal but much of it may be hard to decode because it's masked by the other obvious signal
< 1761084898 586371 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :CodeMelon: Once you've memorized the recipe, it'll be easier. Eventually it's a matter of figuring out how to print various characters. What have you tried so far?
< 1761084924 881352 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(now at 451 languages/implementations, I just checked)
< 1761084947 304364 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :to be precise, two different versions of the same language only count if it produces different output without an explicit version check
< 1761084956 774152 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 QUIT :Quit: Client closed
< 1761084968 100149 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 JOIN #esolangs * :[https://web.libera.chat] CodeMelon
< 1761085017 247265 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Umm... ive not tried to make a quine yet, ive just learned it today what it is since ive stumbled onto esolangs
< 1761085039 510981 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :^ul (:a*S):a*S
< 1761085039 559952 :fungot!~fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs ::a*S(:a*S)
< 1761085053 774160 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :The heck is that
< 1761085060 310151 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a quine in Underload
< 1761085066 372338 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Crazy
< 1761085089 334337 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :But how why?!
< 1761085093 916689 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :almost all quines follow one of two basic patterns, Underload has built-ins for all the relevant parts of the quning pattern so the quine is very short
< 1761085104 273497 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :^ul (a(:^)*S):^
< 1761085104 334342 :fungot!~fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :(a(:^)*S):^
< 1761085106 459702 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that's the other one
< 1761085132 853077 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, the first quine is backwards
< 1761085141 734258 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :^ul (:a~*S):a~*S
< 1761085141 783994 :fungot!~fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :(:a~*S):a~*S
< 1761085144 282713 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that's better
< 1761085145 908863 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Woah ok thats very cool, gonna look into underload today after ive gone to sleep(its 12pm)
< 1761085209 923183 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but writing a quine in any language is basically doing one of those two things – the hard part is normally regenerating the source code representation of a string from the string itself (Underload "a")
< 1761085238 782811 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :CodeMelon: No worries. Have a good night. Glad to show you something new.
< 1761085252 820088 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(there are a few other ways to do quines, but most of them can be considered to be cheating in one way or another, or are just overly complicated versions of one of those two basic patterns)
< 1761085262 464015 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Thank you so much guys
< 1761085374 480032 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Oh and heres the bf -> oOo / bf + text -> oOo site i made, Im on mobile btw (i program on mobile judge me) so the site might not look right on pc + im not a graphics designer, https://ozelotgamer.github.io/oOoCoder.html
< 1761085395 490749 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :> let a = " in \"let a = \" ++ show a ++ a" in "let a = " ++ show a ++ a
< 1761085396 750370 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esolangs : "let a = \" in \\\"let a = \\\" ++ show a ++ a\" in \"let a = \" ++ show a +...
< 1761085409 701495 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: On my plate to write up: https://dl.acm.org/doi/pdf/10.1145/3759429.3762631 "Gauguin, Descartes, Bayes: A Diurnal Golem’s Brain"
< 1761085446 678419 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :They propose a *gauguine*: a program that probabalistically infers its own source code given a description of its own behavior.
< 1761085480 924492 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: reminds me a bit of 7, except that its 6 command is deterministic
< 1761085494 708966 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(and very useful for quines)
< 1761085519 965115 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Ok good night
< 1761085522 739540 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :7 is a bit of an impoverished version of the idea, though
< 1761085525 53651 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 PRIVMSG #esolangs :Cya
< 1761085528 112827 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :night
< 1761085548 830903 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because it's just "generate source code for a program that produces this output" which in a sense isn't interesting
< 1761085585 381109 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a gaugine doesn't have to be diagonalised, right? it could just be "probabilistically infer the source code of a program given a description of its behaviour"
< 1761085597 513064 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :…and I just realised that current coding LLMs actually do that%, albeit badly
< 1761085599 301373 :CodeMelon!~CodeMelon@2a00:fbc:e024:af99:f80d:4455:bc3f:dc67 QUIT :Quit: Client closed
< 1761085606 142514 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* …and I just realised that current coding LLMs actually do that, albeit badly
< 1761085626 303413 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Sure. On the other end of the power spectrum, I'm looking at the self-normalization barrier, which I think really misses that a practical Unix terminal is simply typed in bytes.
< 1761085656 642937 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you could prompt one with "write a program that takes a text description of how a program behaves, and outputs the source code of that program" and with a perfect coding LLM that would make it into a quine
< 1761085670 716629 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in practice I doubt it'd manage a very good attempt
< 1761085683 189145 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yep! Indeed, the paper's construction only specifies its behavior at a high level, and everything else is inferred. It looks like most of the program is about encoding the syntax of the Church language, which is the probabalistic PL used to run the program.
< 1761085688 569089 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :To...sample from the program?
< 1761085689 93100 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although maybe it's seen LLM source code to plagiarise, I doubt it'd be able to recreate the weights / training data
< 1761085749 394061 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Ah! Yes, that concept's been explored. The original papers are on "Gödel machines", so named because there are obvious ways that they must provably be unable to improve themselves.
< 1761085785 642147 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The most recent iteration I saw was "Darwin Gödel machines", which added genetic algorithms and language models. TBF I think that genetic algorithms would be a great fit, but maybe not so much on the language models.
< 1761085916 47656 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it has crossed my mind that given a sufficiently good estimator of "how close" a program is to implementing a given behaviour, you could use a genetic algorithm to produce a program that implements it
< 1761085929 894531 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :…and this may be what coding agents are actually doing, in the case where they work (rather than using knowledge or reasoning)
< 1761085940 621838 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Also, there's probably a way to cheat with LLMs. The fundamental idea is something like https://www.pcg-random.org/party-tricks.html
< 1761085993 673594 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :And then there's a variety of ways to gradient-descent in the wrong direction for reasonably cheap. Something like "reverse prompt engineering" https://arxiv.org/abs/2411.06729v3
< 1761086067 183224 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Coding agents are definitely not doing genetic algorithms. Rather, they're doing chain-of-thought and lots of scratch tokens. We know from bertology that the models *can* emit high-quality code; we just didn't know what sorts of prompts and RL would elicit agentive code-writing behavior.
< 1761086132 37901 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :(Cammy's reference implementation has a coding oracle "kamis" which uses the SOTA genetic algorithm for functional programming. See the refs on the wiki page.)
< 1761086149 552505 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname
< 1761086178 486322 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :(The supervising author on those genetic-algo papers was O'Neill, the author of PCG. Curious coincidence?)
< 1761086229 663988 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: well, a coding agent is a loop – take the existing state of the repository, prompt the agent with it, apply the action that it suggests
< 1761086246 210695 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one loop iteration clearly isn't an evolutionary algorithm, but the loop as a whole may be
< 1761086259 621215 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(I guess it can't be "genetic" unless you mix in old / parallel states)
< 1761086387 546827 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: It has to have some sort of pressure which causes selection. In the O'Neill paradigm, fitness minimizes towards zero, but folks often run coding agents in an open-ended mode with ill-defined stopping points.
< 1761086437 590219 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: right, so the condition for this to work is basically "is the LLM able to determine whether or not the new version of the repository is a better fit for the request than the old version?"
< 1761086451 420001 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and my guess is that sometimes that condition is satisfied and you get useful output, usually it isn't and you get useless output
< 1761086451 505289 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The full Brigg-O'Neill approach is to use structure (like, homomorphic structure) to rip apart candidates. Each candidate's shreds are put through a type-checker and added to the available gene pool.
< 1761086483 460340 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but notably, I don't think most coding agents revert when a change has made things worse
< 1761086508 960373 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(they may attempt to create a counteracting change, but there's no guarantee that it's a correct revert)
< 1761086538 771263 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think you're right, agentic LLMs aren't actually doing this properly (but they would probably work better if they did)
< 1761086569 279923 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The key phrase to search is "meta in-context learning". The model has to optimize three goals at three different times: predicting the next token during pretraining, decreasing regret during RL, and writing good-enough code during inference.
< 1761086611 109803 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Haaaaave you read "Simulators" yet? The simulators viewpoint is the best way to understand how correct code might arise from a pile of memes.
< 1761086618 960599 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :no
< 1761086645 541752 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Warning: bertology, LessWrong-style rationalism, GPT-generated text; here's the original post: https://generative.ink/posts/simulators/
< 1761086650 760495 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm not surprised that it's possible, but I'm sceptical about how much of it is due to the LLM itself and how much is due to the scaffolding
< 1761086709 385409 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :My work-safe summary: https://genai.stackexchange.com/q/260 Language models aren't agents, genies, oracles, or tools; they are general-purpose *simulators* which *simulate* conversations that humans might have with hypothetical agents, genies, oracles, or tools.
< 1761086729 856895 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :They don't reason like humans. They reason like screenwriters imagining what humans might say.
< 1761086779 196996 :Riviera!Riviera@user/riviera PRIVMSG #esolangs :Is that not "common knowledge?"
< 1761086783 962996 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :RL turns any model into an agent. Take a weather simulation and say "make it look good for humans", and you'll eventually get attractive ladies who talk about how lovely the weekend will be. But the underlying simulation is only trying to get the weather right.
< 1761086806 677744 :Riviera!Riviera@user/riviera PRIVMSG #esolangs :They were trained with textual input, and that's what they generate.
< 1761086819 544802 :Riviera!Riviera@user/riviera PRIVMSG #esolangs :"Stuff that looks like texts."
< 1761086820 880514 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Riviera: Sadly, most practitioners seem to either believe that it's just matrix multiplication and don't know what a meme is, or think that they're literally summoning demons into the GPUs.
< 1761086870 712701 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The best take is from Emily Bender, who agrees with me that there's a gap between syntax and semantics. She has a great quip: "Play syntactic games, win syntactic prizes." They're meme machines.
< 1761086892 727771 :Riviera!Riviera@user/riviera PRIVMSG #esolangs :I'm less concerned with whether I am missing something.
< 1761086915 910994 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I think you're arguing at a different point than the one I'm trying to think about
< 1761086951 427010 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :i.e. I don't disagree with you but I'm working on a different part of the problem
< 1761086988 552248 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(and I'm using "agent" purely in the sense of "a program that runs an LLM in a loop and changes the input based on the output")
< 1761087018 572103 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Well, that thing that Naur talked about, theory-building, it's not something that the model can do. It's just not there. So whatever code is generated is *memetic*; it's emergent from cultural practices and shaped by the languages that we use to communicate, but not necessarily *grounded*. AI researchers complain of "symbol grounding".
< 1761087089 370826 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I am not disagreeing with this – I am instead trying to work out, in effect, how stupid/simple one loop iteration of an agentic loop can be whilst still producing useful output (and have a suspicion that you don't need anything close to as powerful as today's LLMs)
< 1761087119 986814 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Ah! We usually say that an agent has a *goal*. Without a goal and RL, that sort of loop will decay to a stationary distribution because the model is Markov.
< 1761087130 250146 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a good example is the "apply the suggestions that rustc gives you until you reach a fixed point/oscillator or compiling code" technique that beginners to Rust often try, and apparently try to work quite well
< 1761087214 980232 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one of my previous jobs was programming in OCaml, I found large refactors really easy to do, because you did the first step and then just chased compiler error messages until the refactor was finished
< 1761087246 887676 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I really enjoyed that (and Rust being OCaml-inspired, and intended to support the same basic workflow, is one of the things that initially got me to try it)
< 1761087274 780787 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is the sort of thing that seems really automatable, although I never did automate it
< 1761087351 65784 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Idris has it automated. Write a type signature without a definition, add question marks for typed holes, and let the IDE search for candidates to recursively fill the holes. It only works in the simplest cases though.
< 1761087397 556674 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I added "kamis" to Cammy as an improvement on the older solver, "djinn", which does the simply-typed equivalent. It does great on basic plumbing but can't optimize for fitness WRT a goal.
< 1761087404 746177 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right – proof languages can get away with that, when used purely for proofs, because you can't end up with a wrong value of the right type
< 1761087417 935240 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :anything of the type you want is sufficient
< 1761087460 102759 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fwiw, I have weird opinions about proof languages – I dislike tactics as a source code construct, as opposed to something you use in your IDE to generate the source of a proof
< 1761087491 794292 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because I want the proof to contain the actual reasoning, rather than a statement along the lines of "the proof is standard using these standard techniques"
< 1761087566 640664 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Makes sense to me. I'm on team Metamath; I only know Rocq, Idris, and I guess Agda for practical reasons. You'll find lots of esoteric folks agreeing; there's NQL, Metamath Zero, etc.
< 1761087605 640375 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Agda is the only one that I've used, and only for very basic things
< 1761087609 7963 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I've already tried a variety of models for generating uncompressed Metamath proofs. Totally useless, even with a constrained grammar that forces them to pick legal moves.
< 1761087649 581119 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I might as well spill the beans. One of my side projects involves the insight from the end of The Cell (2001): what if we inverted the direction in which the simulation is flowing?
< 1761087693 774961 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Rather than having a chat interface, what if we have the simulation integrate all of the available data, and only chat as an optional side-effect? Initial experiments are very promising, with the understanding that this can't be turned into exploitable labor.
< 1761087735 16112 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Wait, The Cell came out in 2000? Wow. I knew it was early 2000s, but that's early early.
< 1761087761 690241 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :now you've got me thinking "by some methods of counting, 2000 was in the 1900s"
< 1761087793 711564 :FreeFull!~freefull@79.186.201.19.ipv4.supernova.orange.pl QUIT :
< 1761089039 703776 :tromp!~textual@2001:1c00:3487:1b00:75ad:6ea9:b519:8422 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1761089142 860193 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I mentioned before attacking your ally deliberately in Pokemon, but I also remember once before I played, although I did not do so, if I was on the opponent's side, I would have deliberately attacked the ally (for damage, to attempt to knock out the ally, rather than only paralysis)
< 1761089348 841857 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :zzo38: your example of intentionally paralyzing a Clefable confused me, because Clefable is one of the Pokémon that's least useful to do it on
< 1761089380 934698 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :normally the reason I would want my own Pokémon paralyzed in competitive Pokémon is to protect them from being toxic-poisoned, but Clefable normally has Magic Guard and thus doesn't care about being toxic-poisoned as it is
< 1761089418 136208 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: The TIO behavior is WEIRD, can't explain it, not even with the old glibc version in the picture. It would have to be patched, I think.
< 1761089428 810898 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(as this conversation suggests, Pokémon status conditions don't really reflect or act like their equivalents in real life)
< 1761089453 266839 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: it's definitely running in a sandbox, which might potentially break things somehow?
< 1761089476 641068 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: But it should not be doing any system calls, just fill the buffer.
< 1761089488 503013 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right
< 1761089514 190065 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I can potentially see a sandbox breaking the output of fstat calls, which might cause glibc to act differently
< 1761089519 348487 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but acting that differently is strange
< 1761089545 966091 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :ais523: I know that, and it was a risky situation, so it might not have been the best move, but it was a risk I decided to take and it ended up helping.
< 1761089550 568972 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's also possible that TIO injects extra flushes, somehow, in order to be able to show more output if a program crashes
< 1761089677 566634 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: lol: https://github.com/TryItOnline/tiosetup/blob/master/files/system/tiopreload.cpp
< 1761089731 664325 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: I don't think that explains the weird behaviour but it's definitely worth the link
< 1761089747 691348 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: yeah it doesn't, but it's a ridiculous hack :)
< 1761089763 832025 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it isn't even hiding the output, just sending it to a different file descriptor
< 1761089803 614660 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :also I'm vaguely surprised that defining a function called __builtin_printf actually works
< 1761089810 958727 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(in that it's permitted and isn't a no-op)
> 1761089829 675472 PRIVMSG #esolangs :14[[07Mango14]]4 10 02https://esolangs.org/w/index.php?diff=166369&oldid=166349 5* 03RaiseAfloppaFan3925 5* (+0) 10Took me a while to figure out that this is a WIP and not a stub
< 1761089846 70776 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: Oh, but there's another preload: LD_PRELOAD=libstdbuf.so:tiopreload.so
< 1761089869 41436 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :both halves of that are suspicious
< 1761089879 831073 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :stdbuf is a command that changes how stdio buffering works, and tiopreload could do anything
< 1761089930 571147 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: and with LD_PRELOAD= ./t ... the behavior disappears (becomes 12/12/-1)
< 1761089942 629300 :int-e!~noone@int-e.eu PRIVMSG #esolangs :so what is that thing
< 1761089964 991260 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, tiopreload is specifically just the thing that sends assertion failures to stdout
< 1761089971 299036 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so it must be stdbuf that's causing the problem
< 1761090075 986352 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: I can reproduce locally using «stdbuf -i0 -e0 -o0 ./t 3>&2 2>&1 1>&3 | sleep 1»
< 1761090079 334418 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so it's a bug in stdbuf
< 1761090432 858980 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: well, it's a bug in glibc where setvbuf(stderr, NULL, _IONBF, 0); followed by setvbuf(stderr, NULL, _IOFBF, 4096); behaves differently from just setvbuf(stderr, NULL, _IOFBF, 4096);
< 1761090535 689938 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: and *that* I can actually reproduce locally. Isn't that fun.
< 1761090579 227851 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(with glibc-2.41)
< 1761090597 706219 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I checked the stdbuf source, and it doesn't seem to be a stdbuf bug (this conclusion is consistent with yours)
< 1761090610 143992 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in that stdbuf just calls setvbuf at program load and doesn't do anything else
< 1761090662 457168 :int-e!~noone@int-e.eu PRIVMSG #esolangs :yeah, I decided to just emulate that behavior without the preload
< 1761090773 536978 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :what if you give setvbuf an actual array as its second argument, rather than NULL?
< 1761090805 567365 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(should probably be static for lifetime reasons)
< 1761090841 760323 :int-e!~noone@int-e.eu PRIVMSG #esolangs :then it's back to 12/12/-1
< 1761090853 319886 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the info page and man page disagree about what a NULL second argument means, which isn't particularly surprising given what we know so far
< 1761090860 253877 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(although the 12/1/0 behaviour doesn't match either of them)
> 1761090875 490839 PRIVMSG #esolangs :14[[07Mango14]]4 M10 02https://esolangs.org/w/index.php?diff=166370&oldid=166369 5* 03RaiseAfloppaFan3925 5* (+502) 10Added 41 and 21