< 1767744880 691570 :sftp!~sftp@user/sftp QUIT :Read error: Connection reset by peer
< 1767745081 234974 :sftp!~sftp@79.174.36.182 JOIN #esolangs * :sftp
< 1767745081 262251 :sftp!~sftp@79.174.36.182 CHGHOST ~sftp :user/sftp
> 1767745612 289999 PRIVMSG #esolangs :14[[07GTPS14]]4 N10 02https://esolangs.org/w/index.php?oldid=172431 5* 03A() 5* (+185) 10Created page with "[[GTPS| Group Theory Programming System]] is a programming language made by [[User: A()]] with the intention of being based on [https://en.wikipedia.org/wiki/Group_theory| Group theory]"
> 1767745960 363141 PRIVMSG #esolangs :14[[07GTPS14]]4 10 02https://esolangs.org/w/index.php?diff=172432&oldid=172431 5* 03A() 5* (+70) 10
< 1767747877 126088 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I remember noticing before that Z-order is basically just the INTERCAL mingle operation
> 1767747892 911904 PRIVMSG #esolangs :14[[07User:Aadenboy/Countable14]]4 M10 02https://esolangs.org/w/index.php?diff=172433&oldid=172412 5* 03 5* (-5) 10Fixed
< 1767747907 174477 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :INTERCAL's select (i.e. PEXT) has come up in a number of contexts recently, in addition to being added as an instruction on x86, but mingle is less commonly used
> 1767748016 705559 PRIVMSG #esolangs :14[[07User talk:Aadenboy/Countable14]]4 M10 02https://esolangs.org/w/index.php?diff=172434&oldid=172414 5* 03 5* (-5) 10Fixed
< 1767749912 895336 :amby!~ambylastn@host-81-178-158-35.as13285.net QUIT :Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement
> 1767751339 986819 PRIVMSG #esolangs :14[[07GTPS14]]4 10 02https://esolangs.org/w/index.php?diff=172435&oldid=172432 5* 03A() 5* (+825) 10
< 1767752945 547768 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer
< 1767755169 621161 :ais523!~ais523@user/ais523 QUIT :Quit: quit
< 1767756577 207585 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname
< 1767757791 13487 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer
< 1767757914 700560 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan
< 1767758959 996602 :rodgort!~rodgort@static.38.6.217.95.clients.your-server.de QUIT :Ping timeout: 240 seconds
< 1767759018 219373 :rodgort!~rodgort@static.38.6.217.95.clients.your-server.de JOIN #esolangs * :rodgort
> 1767759872 690175 PRIVMSG #esolangs :14[[07Countable14]]4 10 02https://esolangs.org/w/index.php?diff=172436&oldid=172426 5* 03Aadenboy 5* (+44) 10
> 1767759907 75676 PRIVMSG #esolangs :14[[07User:Aadenboy14]]4 10 02https://esolangs.org/w/index.php?diff=172437&oldid=172422 5* 03Aadenboy 5* (+15) 10/* ESOLANGS */ add [[Countable]] to list of favorites
< 1767761278 340936 :impomatic!~impomatic@2a00:23c7:5fc6:3201:3cc5:8e33:3808:f449 JOIN #esolangs * :[https://web.libera.chat] impomatic
< 1767765794 552174 :scoofy!~scoofy@254C2329.nat.pool.telekom.hu JOIN #esolangs * :realname
< 1767765843 133759 :somefan!~somefan@208.58.192.69 QUIT :Remote host closed the connection
< 1767766999 191611 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :It is often said that ASN.1 requires the use of a schema. Whether or not this is true depends on which format you are using; it is true for OER and PER but is not true for BER and DER. DER can be used without a schema (although it can also be used with a schema, which will be helpful if you want to handle data that contains implicit types, default values, etc, since those things are specified by the schema).
< 1767770134 286505 :tromp!~textual@2001:1c00:3487:1b00:3110:dc2b:d7bb:a210 JOIN #esolangs * :Textual User
< 1767770947 5739 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer
< 1767771842 341572 :Yayimhere!~Yayimhere@2a02:aa7:464e:d550:e957:bab3:2128:292d JOIN #esolangs * :[https://web.libera.chat] Yayimhere
< 1767772176 496332 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :Now I added another type into ASN.1X, which is called ASN1_SCIENTIFIC. It is like ASN1_REAL but the number of digits (or bits) is considered to be significant, and the canonical form for decimal numbers is different (there must be exactly one digit before the decimal separator, and trailing zeros are allowed and are considered to be significant).
< 1767772202 470803 :Yayimhere!~Yayimhere@2a02:aa7:464e:d550:e957:bab3:2128:292d PRIVMSG #esolangs :hello
< 1767774051 545321 :tromp!~textual@2001:1c00:3487:1b00:3110:dc2b:d7bb:a210 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
> 1767774828 967723 PRIVMSG #esolangs :14[[07Cammy14]]4 10 02https://esolangs.org/w/index.php?diff=172438&oldid=170868 5* 03Corbin 5* (+55) 10/* Constants */ Add a constructor for ratios of nats.
< 1767775150 279649 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Sleep time.
< 1767776826 998876 :Yayimhere!~Yayimhere@2a02:aa7:464e:d550:e957:bab3:2128:292d PRIVMSG #esolangs :oh yea korvo, I dont remember you telling me about neckties, but I took your recommendation, and am working on a blog right now
< 1767776933 729264 :Yayimhere!~Yayimhere@2a02:aa7:464e:d550:e957:bab3:2128:292d PRIVMSG #esolangs :*neocities
< 1767777535 591103 :Yayimhere!~Yayimhere@2a02:aa7:464e:d550:e957:bab3:2128:292d QUIT :Quit: Client closed
< 1767777718 366080 :tromp!~textual@2001:1c00:3487:1b00:3110:dc2b:d7bb:a210 JOIN #esolangs * :Textual User
< 1767777887 340104 :Yayimhere!~Yayimhere@2a02:aa7:464e:d550:e957:bab3:2128:292d JOIN #esolangs * :[https://web.libera.chat] Yayimhere
< 1767778650 622320 :tromp!~textual@2001:1c00:3487:1b00:3110:dc2b:d7bb:a210 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1767778719 260332 :Yayimhere!~Yayimhere@2a02:aa7:464e:d550:e957:bab3:2128:292d QUIT :Quit: Client closed
< 1767778813 307549 :tromp!~textual@2001:1c00:3487:1b00:3110:dc2b:d7bb:a210 JOIN #esolangs * :Textual User
> 1767779549 441845 PRIVMSG #esolangs :14[[07Book14]]4 10 02https://esolangs.org/w/index.php?diff=172439&oldid=171856 5* 03Yoyolin0409 5* (+23) 10
> 1767779583 346935 PRIVMSG #esolangs :14[[07User:Yoyolin040914]]4 10 02https://esolangs.org/w/index.php?diff=172440&oldid=172265 5* 03Yoyolin0409 5* (+0) 10
> 1767779636 367858 PRIVMSG #esolangs :14[[07User:Yoyolin040914]]4 10 02https://esolangs.org/w/index.php?diff=172441&oldid=172440 5* 03Yoyolin0409 5* (+21) 10
> 1767779742 412267 PRIVMSG #esolangs :14[[07Do something14]]4 10 02https://esolangs.org/w/index.php?diff=172442&oldid=171609 5* 03Yoyolin0409 5* (-36) 10/* Do job */
> 1767780697 268910 PRIVMSG #esolangs :14[[07\14]]4 N10 02https://esolangs.org/w/index.php?oldid=172443 5* 03Yayimhere2(school) 5* (+1719) 10Created page with "'''\''' is a version of [[_/]], with a few simple modifications. It's based on an observation that none of the sub replacement patterns could interact with each other. It also uses another syntax. == Syntax / Semantics == A program is a list of "sub replacements", 
> 1767780731 185051 PRIVMSG #esolangs :14[[07/14]]4 10 02https://esolangs.org/w/index.php?diff=172444&oldid=168740 5* 03Yayimhere2(school) 5* (+26) 10/* examples */
> 1767782917 914124 PRIVMSG #esolangs :14[[07\14]]4 10 02https://esolangs.org/w/index.php?diff=172445&oldid=172443 5* 03Yayimhere2(school) 5* (-103) 10/* Syntax / Semantics */
> 1767783098 50406 PRIVMSG #esolangs :14[[07Rpg14]]4 10 02https://esolangs.org/w/index.php?diff=172446&oldid=172427 5* 03Yoyolin0409 5* (+487) 10
> 1767783111 550008 PRIVMSG #esolangs :14[[07Rpg14]]4 10 02https://esolangs.org/w/index.php?diff=172447&oldid=172446 5* 03Yoyolin0409 5* (+3) 10/* Minsky machine(similar) */
> 1767783185 441339 PRIVMSG #esolangs :14[[07Rpg14]]4 10 02https://esolangs.org/w/index.php?diff=172448&oldid=172447 5* 03Yoyolin0409 5* (-5) 10/* Minsky machine(similar) */
> 1767783327 155716 PRIVMSG #esolangs :14[[07User:Yayimhere14]]4 10 02https://esolangs.org/w/index.php?diff=172449&oldid=172406 5* 03Yayimhere2(school) 5* (+137) 10/* esolangs */
< 1767783370 862251 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1767785338 344692 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :Oh, interesting coincidence. In Go 1.26, they're actually planning to introduce a new standard library component to expose architecture-specific SIMD operations, kind of like how it works in C with intrinsics. But the current version of the package -- https://pkg.go.dev/simd/archsimd@go1.26rc1 -- seems to focus exclusively on actual SIMD stuff, and doesn't have BMI2 (PDEP/PEXT).
< 1767787535 340144 :somefan!~somefan@208.58.192.69 JOIN #esolangs * :[https://web.libera.chat] somefan
< 1767787660 622110 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :meanwhile Rust already has the intrinsics, but is planning to add platform-independent pdep/pext, which is interesting with respect to how well the fallback will be optimised
< 1767787676 664800 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you almost want an INTERCAL-style optimiser at that point
< 1767787703 386618 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: but nightly only?
> 1767787709 920202 PRIVMSG #esolangs :14[[07User:Yayimhere14]]4 10 02https://esolangs.org/w/index.php?diff=172450&oldid=172449 5* 03Yayimhere2(school) 5* (+82) 10
< 1767787752 329647 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: the intrinsics are stable but platform-specific, I think: the platform-independent stuff is very new and still nightly-only
< 1767787945 4770 :ais523!~ais523@user/ais523 QUIT :Quit: quit
< 1767787964 269742 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1767787969 411852 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Oh. I guess I wasn't looking in the right place when I was looking for this: https://doc.rust-lang.org/stable/core/arch/x86_64/fn._pdep_u64.html
< 1767788095 913337 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(I didn't try *too* hard to find the intrinsic; https://paste.debian.net/hidden/3755060c isn't *too* terrible)
< 1767788242 983710 :int-e!~noone@int-e.eu PRIVMSG #esolangs :same speed too :)
< 1767788317 940437 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: so thanks for making me look harder
< 1767788384 821873 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there was a bit of a discussion about Rust documentation file sizes on the Rust internals forum recently, and the documentation for core::arch::x86_64 was mentioned
< 1767788419 834452 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so I had the appropriate location in medium-term memory already
< 1767788531 923417 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html is another large ones
< 1767788536 913309 :APic!apic@apic.name PRIVMSG #esolangs :Hi *
> 1767788547 946976 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=172451&oldid=172425 5* 03HerobrineMWB 5* (+221) 10/* Introductions */
> 1767789584 654197 PRIVMSG #esolangs :14[[07User:Yayimhere14]]4 10 02https://esolangs.org/w/index.php?diff=172452&oldid=172450 5* 03Yayimhere2(school) 5* (+23) 10/* ppl i like and dont like */
> 1767790113 648543 PRIVMSG #esolangs :14[[07User:Hotcrystal0/Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=172453&oldid=171777 5* 03Hotcrystal0 5* (+223) 10
< 1767791317 347670 :ais523!~ais523@user/ais523 QUIT :Quit: quit
< 1767792177 758399 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1767793260 256851 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :Sadly you can't inline assembly in Go, and functions written entirely in assembler (which you can have) are limited to the much less performant (but stable) "ABI0" calling convention (whereas compiler-generated code can use the faster but unstable "ABIInternal"), and never get inlined, so the "just do it yourself" approach is much less feasible in terms of performance.
> 1767796415 541428 PRIVMSG #esolangs :14[[07Talk:Input hello world or else:14]]4 N10 02https://esolangs.org/w/index.php?oldid=172454 5* 03 5* (+541) 10Created page with "I came here in 14 redirects. <span style="background-color: green;">[[User:|<span style="color: white;">mario</span>]]</span><span style="background-color: yellow;">[[User talk:|<span style="color: black;">maker</span>]]</span><span style="background-col
> 1767796657 683424 PRIVMSG #esolangs :14[[07EmojiStack/Codepage14]]4 10 02https://esolangs.org/w/index.php?diff=172455&oldid=155294 5* 03 5* (-1) 10
> 1767796672 222131 PRIVMSG #esolangs :14[[07Special:Log/move14]]4 move10 02 5* 03 5*  10moved [[02EmojiStack/Codepage10]] to [[Mojifunge/Codepage]]
> 1767796685 818895 PRIVMSG #esolangs :14[[07User:Yayimhere2(school)14]]4 10 02https://esolangs.org/w/index.php?diff=172458&oldid=172270 5* 03Yayimhere2(school) 5* (-135) 10Redirected page to [[User:Yayimhere]]
< 1767796853 956920 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer
< 1767796887 389928 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan
> 1767797655 66264 PRIVMSG #esolangs :14[[07User:MihaiEso14]]4 10 02https://esolangs.org/w/index.php?diff=172459&oldid=170246 5* 03MihaiEso 5* (+71) 10
< 1767798096 647482 :amby!~ambylastn@host-81-178-158-35.as13285.net JOIN #esolangs amby :realname
> 1767799261 552528 PRIVMSG #esolangs :14[[07Unspoken14]]4 N10 02https://esolangs.org/w/index.php?oldid=172460 5* 03Yayimhere2(school) 5* (+680) 10Created page with "'''Unspoken''' is an encoding of [[Apraxia]], to be able to be used as poetry. It is directly equavilent to Apraxia, other than input.  == Encoding == In Unspoken, the "characters"/tokens of Apraxia are replaced with "words", which are strings of. When execut
> 1767799272 464952 PRIVMSG #esolangs :14[[07Unspoken14]]4 10 02https://esolangs.org/w/index.php?diff=172461&oldid=172460 5* 03Yayimhere2(school) 5* (-18) 10
> 1767799908 652318 PRIVMSG #esolangs :14[[07AddByteJump14]]4 N10 02https://esolangs.org/w/index.php?oldid=172462 5* 03Timm 5* (+215) 10Created page with " A B C do  A* =+ B*  jump C  (?) is actual value<br> -? is negation<br> -(?) you get it<br> (its low-level)<br> -1 in A make output, B input and C make halt<br> -2 has 1 always<br> -3 has -1 always<br> {{Made|Timm}}"
< 1767799960 685658 :tromp!~textual@2001:1c00:3487:1b00:3110:dc2b:d7bb:a210 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
> 1767799984 241271 PRIVMSG #esolangs :14[[07User:Timm14]]4 10 02https://esolangs.org/w/index.php?diff=172463&oldid=171289 5* 03Timm 5* (+19) 10
< 1767801774 328523 :tromp!~textual@2001:1c00:3487:1b00:3110:dc2b:d7bb:a210 JOIN #esolangs * :Textual User
< 1767802532 339026 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :riscv has mingle but not select, somewhat odd (early bitmanip drafts had both but "we need zip for 32-bit keccak" was somehow judged as a more real use case than anything presented for pext)
< 1767803099 722417 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :strange to define a SIMD interface in 2026 that doesn't have first-class support for scalable types
< 1767803763 942666 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :scalable vectors are, oddly, quite hard to handle at the programming language level
< 1767803787 410481 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :especially if you try to fit them into the same sort of programming language API as fixed-length vectors
< 1767803832 539374 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the intention of the scalable vector machine code instructions is that you write software that doesn't care about the vector length, and yet most existing explicit-vectorisation APIs expect it to be cared about by the software rather than the compiler
< 1767803905 512042 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I really don't like the current state of vectorisation, autovectorisation is too inconsistent (both in terms of whether it happens and in terms of whether the result makes sense or not) and manual vectorization is too manual
> 1767804045 968764 PRIVMSG #esolangs :14[[07Bliss14]]4 M10 02https://esolangs.org/w/index.php?diff=172464&oldid=171156 5* 03H33T33 5* (+4) 10
> 1767804176 792533 PRIVMSG #esolangs :14[[07Bliss14]]4 M10 02https://esolangs.org/w/index.php?diff=172465&oldid=172464 5* 03H33T33 5* (+25) 10
> 1767804446 694199 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Emulao 5*  10New user account
> 1767807956 67809 PRIVMSG #esolangs :14[[07C*14]]4 10 02https://esolangs.org/w/index.php?diff=172466&oldid=166807 5* 03H33T33 5* (+717) 10
< 1767808055 443580 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I do mostly like the current state of SIMD code. We write code using SIMD primitives that compilers can directly emit as instructions, while the compilers figure out register allocation and scheduling and similar. Vector scaling is limited, it exists only as much that you can write code assuming 64 byte wide vectors, some processors will run the instructions directly but with some or all operations on 
< 1767808061 689034 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :32 byte wide execution units, and the compiler can recompile the code emulating the 64 byte wide operations with 32 byte wide instructions which is not optimal but at least works. 
< 1767808102 530986 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :There are a few details that I don't like of course, but this mostly works well. Obviously there's a big delay between when the CPU instruction sets are designed and when most software adapts them, but that's fine, anything else would be premature optimization anyway.
< 1767808127 440187 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :at least on x86, 64→32 compiling is difficult because only the AVX-512 instructions support 64-byte vectors, but they also support other features like writemasks that can't be compiled down to AVX2
< 1767808159 110050 :tromp!~textual@2001:1c00:3487:1b00:3110:dc2b:d7bb:a210 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1767808434 335914 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I'm not very fond of masking and that part of the design of AVX2. It's kind of an inefficient use of CPU resources, with the completely separate mask registers and instructions for them instead of just using normal registers as masks with bitwise operations like we're doing in AVX2. 
< 1767808466 43893 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I can certainly see an argument for, e.g., using r8…r15 as mask registers
< 1767808517 534150 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but Intel seem to have decided recently that they still don't have enough registers
< 1767808809 263366 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(who needs context switches anyway)
< 1767808856 272382 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(you know, that thing where you routinely save all registers and restore another set of values from memory)
< 1767808881 566732 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :avx-512 has had 32 architectural vector registers from the beginning
< 1767808887 411523 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: right
< 1767808888 105272 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :not dependent on APX
< 1767808914 491930 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Intel announced that they were going to add new GPRs as well, though (although it doesn't seem to have hit the instruction set docs yet, so maybe it's not actually available for sale at the moment)
< 1767808916 213229 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :and the mask registers are much smaller than the vector registers, why engage a 512-bit data path if you only need one bit per element?
< 1767808946 21809 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: I think b_jonas is arguing that the masks should have been taken from GPRs rather than from their own register type
< 1767808959 459003 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :they're exactly the right size (64 bits)
< 1767808963 262760 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: no
< 1767808967 510797 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :maybe this is futureproofing for AVX-1024?
< 1767808980 879375 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I'm arguing that we should be using the XMM/YMM/ZMM registers for masks
< 1767809010 148549 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :(though there is one instruction to transfer them to a GPR, useful for condition testing in strlen and similar)
< 1767809020 318784 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :the degree of coupling between the integer and vector (hardware) scheduling that implies would be a nightmare
< 1767809062 956274 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :"maybe this is futureproofing for AVX-1024" => the futureproofing was that AVX512W already had instructions for 64-bit mask registers even though only AVX512B needs them
< 1767809077 3175 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :s/AVX512W/AVX512D/
< 1767809077 376344 :int-e!~noone@int-e.eu PRIVMSG #esolangs :> succ 'Z'
< 1767809078 414968 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esolangs : '['
< 1767809109 953385 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :there won't be an AVX1024, AVX is stopping here because cache lines are 64 bytes wide
< 1767809149 288871 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :if you want wider, there's AMX (Advanced matrix extensions) with the "tile registers"
< 1767809157 812453 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :specifically for matrix multiplication
< 1767809435 764720 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :the 3-operand 32-register integer ISA is an interesting development, much more similar to the others and A64 in particular, I think that leaves s390x as the most relevant 16-integer-register ISA?  the high-word facility can do some similar things but it's equally weird as the newest implementation of subregisters
< 1767809525 204750 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: 64-byte cache lines isn't a fundamental rule, though, right? that one could be changed
< 1767809591 459090 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :yes, but they are hard to change and would affect a lot of other things. it might reduce the performance of non-vector programs. 
< 1767809647 781144 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :glad to see that with APX, the instruction encoding still doesn't make any sense :-D
< 1767809817 711989 :tromp!~textual@2001:1c00:3487:1b00:3110:dc2b:d7bb:a210 JOIN #esolangs * :Textual User
< 1767810218 831001 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I wonder what the performance gain would be like if x86-64 had a sensible instruction encoding (the main advantage would be in saving L1c cache, and I'm not sure to what extent that matters) – my guess is that it would be small
< 1767810271 765476 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :surely that would depend on the segment
< 1767810383 674926 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :the big cores do fairly involved pre-decoding to a "µop cache" (beware that µop is a loaded term and the things in the cache aren't necessarily what might be called a µop in any other context)... but if you're trying to achieve >6 IPC you need a trace cache _anyway_ because there are too many taken branches
< 1767810474 314026 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: I think the trace/loop/µop caches probably aren't relevant to this, which is why L1c is the first relevant layer
< 1767810510 635896 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although, a sensible encoding would likely be easier to decode, meaning you could get more encoding parallelism or maybe a shorter pipeline, and both of those would give performance gains in certain contexts
< 1767810617 721222 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(by "aren't relevant" I mean that although the caches are relevant, changing the instruction format wouldn't make their performance any better or worse, so it's other parts of the processor we have to look at in order to gauge the impact)
< 1767810727 622666 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :i think I1$ mostly cares about size, and "how much does size matter" is ... intensely debated
< 1767810819 396733 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :indeed, I have seen a lot of plausible arguments in both directions but don't know what to conclude from them, and benching this is almost impossible due to alignment effects
< 1767810828 336722 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* benchmarking
< 1767810846 766264 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so although in theory there should be an objective answer, it is difficult to determine what it is
< 1767811011 207017 :ais523!~ais523@user/ais523 QUIT :Quit: quit
> 1767811240 261102 PRIVMSG #esolangs :14[[07User:FluixMakesEsolangs/Secret14]]4 N10 02https://esolangs.org/w/index.php?oldid=172467 5* 03FluixMakesEsolangs 5* (+241) 10SHHHH SEECCREEEETTT
> 1767811625 618887 PRIVMSG #esolangs :14[[07Unspoken14]]4 10 02https://esolangs.org/w/index.php?diff=172468&oldid=172461 5* 03Yayimhere2(school) 5* (+43) 10/* Encoding */
> 1767812444 866634 PRIVMSG #esolangs :14[[07User talk:FluixMakesEsolangs/Secret14]]4 N10 02https://esolangs.org/w/index.php?oldid=172469 5* 03 5* (+25) 10Created page with "how do i spoil people >:)"
> 1767812509 647660 PRIVMSG #esolangs :14[[07Talk:202614]]4 N10 02https://esolangs.org/w/index.php?oldid=172470 5* 03 5* (+43) 10Created page with "2026 is equivalnet to Python for this year."
< 1767812703 811272 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: I'm nto sure it would still count as x86 if you ripped out the current instruction encoding entirely. There were a few changes made when 64-bit mode was introduced, some of the old encodings are invalid in 64-bit mode to free up encoding space.
< 1767812721 191071 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :But if you just replace the entire encoding then you get a new architecture.
< 1767812755 430875 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :although I think ARM has like four different instruction encodings by now
< 1767812917 425145 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :3 main ones?  I don't think Streaming SVE Mode counts
> 1767812941 283042 PRIVMSG #esolangs :14[[07User talk:FluixMakesEsolangs14]]4 N10 02https://esolangs.org/w/index.php?oldid=172471 5* 03Corbin 5* (+1051) 10Created page with "Hi! Welcome to the wiki. I know you've been here for a while, but it seems that I'm the first person to greet you. '''You haven't done anything wrong''' but I wanted to let you know a few things:  * Please read [[esolang:policy]] if you haven't alrea
< 1767814445 656640 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :could be. I'm not too familiar with ARM, I'm mostly just looking at x86_64 all the time.
< 1767814531 354071 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :I think «a new architecture» means different things to different audiences
< 1767814593 819882 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord
< 1767814648 856260 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 246 seconds
< 1767814659 964227 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :yeah, I mean you could have something like x86_16 vs x86_32 protected mode where the same program can far jump between the two and share the same registers and call functions with arguments in registers and stack, in which case it wouldn't be an entirely separate architecture
< 1767814672 119729 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 NICK :Lord_of_Life
< 1767814708 111006 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :binary compatible, just link your new code together with the old code and make the processor dynamically switch decoding mode between them using a flag register
< 1767814752 339503 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :which is kind of what we have between AVX and AVX2
< 1767814884 578273 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :ia64 could dynamically switch decoding mode and had switch instructions (br.ia32 / JMPE)... not quite as seamless as 386 call gates
< 1767814931 554188 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I think 386 doesn't even need call gates to jump between 32-bit and 16-bit user-mode code, just different code segments
< 1767814949 264922 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :call gates are for jumping to kernel mode or similar
> 1767818757 994764 PRIVMSG #esolangs :14[[07A-SCP-M14]]4 10 02https://esolangs.org/w/index.php?diff=172472&oldid=125586 5* 03Scp-999 5* (+267) 10Added JMod to improve containment protocol
< 1767819030 851109 :Everything!~Everythin@172-232-54-192.ip.linodeusercontent.com JOIN #esolangs Everything :Everything
< 1767819167 552639 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1767819232 450160 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ARM has a scheme in which two of the encodings can coexist based on whether the instruction pointer is odd or even
< 1767819236 63130 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(because both of them are aligned to 2)
< 1767819265 952002 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the only existing programs that this would break would be those that assumed function pointers were always even
< 1767819303 470004 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the IP effectively points to the second byte of the instruction rather than the first in the newer encoding, so the instructions stay aligned – you can also think of it as the IP being low-bit-tagged and I think that's how it's documented)
> 1767819348 642673 PRIVMSG #esolangs :14[[07Clowder14]]4 N10 02https://esolangs.org/w/index.php?oldid=172473 5* 03Profboady 5* (+12434) 10Submit first draft of language specification for Clowder and Quantum Assembly Language.
< 1767819364 266343 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: yes, that works. The other scheme that you can do is make sure that a small part of the instruction encoding overlaps so that you can write a short polyglot that switches into the correct instruction set.
< 1767819456 609804 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess another approach would be to reserve a fraction of a bit in the page tables to specify the encoding when executing from that page (it's less than a bit of information because you can use it for something else if the NX bit is set)
> 1767819462 922159 PRIVMSG #esolangs :14[[07Language list14]]4 M10 02https://esolangs.org/w/index.php?diff=172474&oldid=172429 5* 03Buckets 5* (+14) 10/* U */
> 1767819472 898753 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=172475&oldid=172474 5* 03Profboady 5* (+14) 10I added my language clowder to the main list.
> 1767819501 225842 PRIVMSG #esolangs :14[[07User:Buckets14]]4 M10 02https://esolangs.org/w/index.php?diff=172476&oldid=172430 5* 03Buckets 5* (+13) 10
> 1767819510 633430 PRIVMSG #esolangs :14[[07Mot14]]4 N10 02https://esolangs.org/w/index.php?oldid=172477 5* 03Buckets 5* (+578) 10Created page with "Mot is an Esoteric programming language Created by [[User:Buckets]] In 2020.  {| class="wikitable" |- ! Commands !! Instructions |- | > || Output the Current number. |- | @ || Skip the next Command if The value = 0. |- | ? || Reset this line. |- | { || Goto the Next {. |- | 
< 1767819511 976659 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :x86_16 vs x86_32 protected mode does something like that but with the segment descriptor instead of the page table 
> 1767819520 959003 PRIVMSG #esolangs :14[[07Unsidue14]]4 N10 02https://esolangs.org/w/index.php?oldid=172478 5* 03Buckets 5* (+855) 10Created page with "Unsidue is an Esoteric Programming language created By [[User:Buckets]] in 2021.  {| class="wikitable" |- ! Commands !! Instructions |- | [m] || Modulo the current Number by m, if there's Residue, Move That many Times forward of A # such As a residue Of 2 would Goto the 
< 1767819534 466380 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :less of a scheme and more of an original sin
< 1767819540 17122 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :now I'm reminded of the way that Linux can emulate the system call ABIs of various old UNIXes, in order to run some of their executables without recompiling
> 1767819577 241421 PRIVMSG #esolangs :14[[07User:Profboady14]]4 N10 02https://esolangs.org/w/index.php?oldid=172479 5* 03Profboady 5* (+124) 10Created page with "I am Mark Boady, a computer science professor who works at Drexel University. More about me at [https://boady.net boady.net]"
< 1767819577 589448 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :hehe, that would be funny, making the writable bit of the page to mean an alternate instruction set, if you had previously forbidden the same page table entry to have both executable and writable (you could still write through a different page aliased to the same physical addres)
< 1767819580 113615 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :the oldest arm was limited to 26-bit address space because they decided "we don't need a saved PSR, we can just use the spare bits in the exception link register" 
< 1767819608 965459 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :they moved most of the flags out but "thumb/arm mode is bit 0 in LR" feels like a relic of that paradigm
< 1767819646 303000 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess a link register inherently has the same encoding as the instruction pointer, so that makes sense
< 1767819704 526725 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: "emulate the system call ABIs of various old UNIXes" => don't they have like three different system call ABIs for x86_32, plus two x86_64 ABIs, plus windows system calls through Wine derivatives, plus FreeBSD system calls if it's a FreeBSD kernel?
< 1767819732 445349 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :possibly multiple different Windows system call ABIs at the same time
< 1767819741 62088 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :x32 (the less commonly used x86-64 ABI) is weird
< 1767819761 926080 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :none of the windows or freebsd stuff is in linux proper, whereas mips linux _does_ pretend to be an irix kernel under certain conditons
< 1767819775 624264 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :only I think you can't really mix x86_64 and x86_32 code in the same unix process, so that limits how many of the ABIs are active at the same time
< 1767819788 163170 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :sorear: no, but the Linux ABI is in FreeBSD kernels
< 1767819788 411978 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Wine isn't built into the kernel as far as I know
< 1767819788 438717 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but I guess it technically could be!
< 1767819790 609037 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :IIRC most BSDs don't have a stable kernel interface, you have to go via libc
< 1767819808 350305 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: not the kernel, but the kernel allows Wine to catch the Windows syscall abi in userspace, right?
< 1767819822 95356 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :I believe "page table bit to select instruction encoding" is how powerpc vle works
< 1767819849 878794 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :also enables BTI on arm and epc on ia64 but those are less dramatic
< 1767819859 489956 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: thinking about that that's probably what PTRACE_SYSEMU is for
> 1767819919 374271 PRIVMSG #esolangs :14[[07User:Hotcrystal0/Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=172480&oldid=172453 5* 03Hotcrystal0 5* (+0) 10
< 1767819925 911552 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :"run this progam until the next system call, then skip the system call" doesn't have an obvious purpose for native executables, but it would be helpful on an executable for a different OS
< 1767819954 390316 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :user mode linux
< 1767819966 349664 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :that does have an obvious use for debugging and reverse-engineering a program if it may call system calls not through a libc that you're familiar with
< 1767819977 617251 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although, on Windows the standard way to make system calls is to dynamically link against a few system-provided shared libraries that make them for you, so all this time I assumed that Wine worked just by providing Linux implementations of the libraries
< 1767819983 100412 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :you can even examine the system calls that it makes
< 1767819986 800183 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :isn't that what strace does?
< 1767820005 123181 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :i think wine mostly works at the ntdll level, the ring0-ring3 ABI changes between windows builds anyway
< 1767820005 438289 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: there's a variant of that which *doesn't* skip the system call, that's what strace uses
< 1767820036 812445 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because strace still wants the system calls to happen, it just wants to observe them
< 1767820038 135179 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ok, but for a debugger it can still make sense to examine the system call before it decides to execute it or not or possibly execute a modified or emulated version. 
< 1767820052 226845 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can do that even with the version that doesn't skip by default
< 1767820064 582609 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but you have to modify the program's registers to change the system call number
< 1767820069 851762 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :wine _does_ provide linux implementations of the libraries, you can link Windows C code directly against them and bypass the EXE loader (winelib)
< 1767820077 62255 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(it halts on entry to the system call, and optionally on exit too)
< 1767820118 705113 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think there's a system call number that's guaranteed to do nothing, probably -1
< 1767820173 532472 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :29 for pause, just send a SIGCONT?
< 1767820213 638951 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :or maybe modify the system call to time(0) 
< 1767820238 972761 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :so 13 with the first argument a nullptr
< 1767820240 745402 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :I'd do NR_getpid if there isn't a dedicated skip
< 1767820259 428277 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :sorear: that works too, yes
< 1767820342 138273 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :you can give arguments to many syscalls to make them a noop, sometimes with an error
< 1767820373 293359 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :even just a read with file descriptor 0 could wrok
< 1767820386 595106 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :no, sorry, read with file descriptor -1
< 1767820467 985470 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :register handling across ptrace stops is a big mess and I'm not confident in my understanding of it
< 1767820823 821746 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I *used* to know how it worked, but haven't looked into it for ages and have forgotten many of the details
< 1767820885 466376 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh wow, this program gets silly even in the header file includes, it needs to include both struct stat from <sys/types.h> and struct stat from <asm/stat.h>, which are different structures with the same name
< 1767820895 501669 :impomatic!~impomatic@2a00:23c7:5fc6:3201:3cc5:8e33:3808:f449 QUIT :Quit: Client closed
< 1767821049 53879 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there is the classic "I want to replace one system call with two, so I will rewind the IP two bytes so that the program hits the same system call instruction again"
< 1767821073 32991 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(both syscall and int 0x80 are two bytes long and I was doing this on x86/x86-64)
< 1767821155 214180 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :things which also happen with SA_RESTART
< 1767821215 434158 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: OK, so the way it works on x86(-64) is that when you request the registers from the process, there are *two* ?ax registers: the orig_ one contains the system call number, the one with the plain name contains the system call return value (which is -ENOSYS at the point in the kernel at which the system call gets interrupted)
< 1767821228 567271 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and changing them on system call entry will change the kernel's view of them too
< 1767821332 487787 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :to disable system calls I just used an arbitrary unlikely number and then got ENOSYS back
< 1767821360 392228 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: aren't there like four different stat system calls with different types for historical reasons, but only on x86_32, and all but the last one got eliminated on x86_64?
< 1767821397 995390 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: it wouldn't surprise me, it's very common for system calls to be near-duplicated with a different ABI
< 1767821414 853801 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :the stat structure has changed several times when people decided that no, 32-bit ints aren't enough for file sizes
< 1767821418 265298 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :x86 has uname, olduname and oldolduname system calls
< 1767821446 115522 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I haven't looked into the details, I just had gdb magically do function calls in the debugged process for me
< 1767821468 683719 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :and even that was many years ago; these days I only do printf debugging, putting debugging code right into my program without any special library or debugger
< 1767821516 347782 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :most recently time_t but stat handling is a bit odd there - on the kernel side plain stat was deprecated instead of being extended so you have to migrate to statx for Y2038
< 1767821535 682883 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :but statx is not POSIX so the libcs invented a 64-bit-time struct stat that doesn't exist in the kernel
< 1767821703 198766 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I dislike the way system calls are normally done through libc – it seems preferable to me to have two libraries, one which just provides a platform-agnostic way to do things that only the kernel can do, and one which is entirely portable (maybe calling into the first library)
< 1767821708 67293 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :it gets funny, leads to situations where you have one header file that calls the system calls oldoldstat, oldstat, stat, stat64; then another header files that calls them oldstat, stat, newstat, stat64; then a third that only lets you access the last two and calls them stat and stat64 but makes stat an alias to stat64 depending on what macros are set
> 1767821747 39968 PRIVMSG #esolangs :14[[07GTPS14]]4 10 02https://esolangs.org/w/index.php?diff=172481&oldid=172435 5* 03A() 5* (+0) 10
< 1767821772 942278 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that way, non-C languages wouldn't have to depend on C baggage like printf and FILE* buffering, and the OS-portable and non-OS-portable parts of the C library seem easier to maintain separately in order to reduce duplication of effort between platforms
> 1767821779 272280 PRIVMSG #esolangs :14[[07GTPS14]]4 10 02https://esolangs.org/w/index.php?diff=172482&oldid=172481 5* 03A() 5* (+30) 10/* A+B */
< 1767821809 501352 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: sure, but libc does too many things partly for historical reasons, partly so that system calls can set errno which is a macro that emulates a thread-specific variable but from before C had first-class thread-specific variables or something like that
< 1767821847 472480 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I don't think threads even existed in the early days of errno, it was just a global
< 1767821861 490493 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and then it had to be made thread-local for correctness reasons when threads were invented
< 1767821864 121082 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :sure, errno is very old
< 1767821948 19685 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :people always use printf as the example but I think the actually painful parts wouldn't be solved by splitting the library
< 1767821991 667150 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :printf is the part that I want to have even in rust, because the floating point formatting bit is really hard to implement correctly and efficiently
> 1767822058 454258 PRIVMSG #esolangs :14[[07Error quine14]]4 M10 02https://esolangs.org/w/index.php?diff=172483&oldid=167414 5* 03Photostar 5* (+181) 10
< 1767822060 878551 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :But I don't think it's too big a deal that libc is as big as it is. You don't have to use all of it, and the parts that you don't use aren't a big expense.
< 1767822066 339180 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: the most painful to me is actually things like gethostbyname – because on glibc those are implemented using shared-library dependencies that can't be statically linked, meaning that you can't make a system call without linking in the whole dynamic linking infrastructure
< 1767822115 842365 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: yes, but if you don't want to then you don't have to use those parts.
< 1767822121 667383 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: it's totally fine to have a nice self-contained portable sprintf library, but why does it have to come with the OS?
< 1767822140 770143 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and the mere fact that it exists, whether or not you use it, causes the problem
< 1767822142 947186 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :on a reasonable platform we'd have some form of RPC dependency injection for that
< 1767822154 905138 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :it has to come with the OS so that my RAM isn't full with ten different libcs, but only one libc mmapped in every process
< 1767822189 301238 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :that's one thing that Debian does well, they're actively working on programs sharing just one copy of each library, not just libc
< 1767822196 469394 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: well this is the major argument for shared libraries in general
< 1767822209 740283 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :yes, I want shared libraries for everything. I don't like static libraries.
> 1767822237 325256 PRIVMSG #esolangs :14[[07GTPS14]]4 10 02https://esolangs.org/w/index.php?diff=172484&oldid=172482 5* 03A() 5* (+238) 10
< 1767822274 771391 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I mean, libc in particular
< 1767822289 507606 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :and yes, there will always be some code duplication, the sharing won't be perfect, but I want to tend towards sharing. that also helps make sure that when I update my system packages to fix a security bug then it's fixed in all programs, that I'm not running programs with their own obsolete and never updated copy of a library that's full of security holes.
< 1767822309 329339 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :yes, shared libc too, and ideally shared libraries for rust
> 1767822337 469703 PRIVMSG #esolangs :14[[07GTPS14]]4 10 02https://esolangs.org/w/index.php?diff=172485&oldid=172484 5* 03A() 5* (+33) 10
< 1767822392 588618 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I've been considering writing a platform (that runs alongside regular x86-64 executables on the same Linux kernel but isn't ABI-compatible with them) for which the only things you can dynamically link are the system call library, the allocators (which have to be platform-provided for some reason I can't remember right now but I think it involves address space), and major language-support libraries like libc
< 1767822416 832091 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :why would you limit what you can dynamically link?
< 1767822420 545966 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :using more shared libraries than that, in practice, doesn't seem to help in practice on anything other than Debian-like "all these versions work with all those version" curate systems
< 1767822424 977769 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* curated
< 1767822447 101471 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if install a program from outside the repositories, it normally comes with its own copies of the system's shared libraries and links to those except on the system
< 1767822468 568781 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :package formats like Snap and Flatpak come with all the shared libraries bundled, they don't use the system's
< 1767822478 608627 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* links to those instead of those on the system
< 1767822492 427638 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :yes, and I don't like those package formats, partly for the reasons that I explained above. 
< 1767822498 61424 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :how does that work with libGL?
< 1767822525 90991 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :lots of people/companies run their programs in containers, and have to put separate shared libraries into them (which could in theory be bind-mounted but in practice I think they're almost always container-specific)
> 1767822542 563700 PRIVMSG #esolangs :14[[07Confusion14]]4 M10 02https://esolangs.org/w/index.php?diff=172486&oldid=168431 5* 03Mun Hammer 5* (+21) 10shouldn't be first person
> 1767822562 100368 PRIVMSG #esolangs :14[[07GTPS14]]4 10 02https://esolangs.org/w/index.php?diff=172487&oldid=172485 5* 03A() 5* (+14) 10
< 1767822602 610364 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: I'm not sure, I'm not familiar with how that works internally
< 1767822632 445954 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(but I searched my directories of unpackaged software and didn't find any libGL, but I did find several copies of libGLEW)
< 1767822785 11294 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :communication with GPUs and windowing systems might in practice be the same sort of problem as communication with kernels
< 1767822826 812347 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: in any case, I think the reason most people don't share shared libraries is that it's too much effort to try to keep the programs compatible with them
< 1767822840 685692 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :sure
< 1767822865 169775 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Debian goes to a lot of effort in testing "this version of this program works with that version of that library" but outside a distro's package manager it's almost impossible
< 1767822871 928516 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :most libraries aren't designed to have a long-term-stable ABI
< 1767822977 472463 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :my personal reason to want to limit the number of shared libraries is that it allows you to give them fixed load addresses relative to each other and the program that links to them, making the dynamic linking step trivial – you lose a little ASLR power but ASLR is pretty easy to bypass anyway nowadays, and gain security from not having dynamic-linker-ish things happening in your executable at all
< 1767822997 571225 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I see!
< 1767823000 269744 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so many exploits that exploit parts of the memory map that only exist due to the dynamic linker
< 1767823004 491965 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :you want fixed addresses
< 1767823059 790303 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I *would* allow dlopen, but not for providing functions to call or be called directly, you would have to use a dlsym equivalent in order to get function pointers at runtime (meaning that no dynamic linking step would be needed there either)
< 1767823110 790022 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh no, I think I've hit a really stupid ambiguity in English – "providing a function to call" could be "providing a function that you can call" or "providing a function that does calling"
< 1767823182 129315 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :how does the dlopened image allocate memory, make system calls, etc?
< 1767823212 757900 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: does that mean you wouldn't allow dispatching between different versions of a library at dynamic link time without function pointers that have a runtime cost each time you call the function?
< 1767823258 542077 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :all calls between dynamic libraries are done via function pointers at the ISA level, PLT/GOT
< 1767823266 551410 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: I was considering a few different plans for that, ideally I'd like the dlopened images to use fixed offsets for that too but that doesn't work if you dlopen more than one library at a time, unless you double-map the system call library
< 1767823290 370910 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or at least that you ensure you don't dlopen two images with the same offset
< 1767823311 480987 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :I wouldn't consider double-mapping a problem but what if the dlopened image has a link-time dependency on a different version of the system call library?
< 1767823316 500107 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the main purpose of dlopen is for providing plugins and the like, if those are tied to the executable then avoiding offset clashes should be a solvable problem
< 1767823342 512671 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: this is why I would want the system call library to be as small as possible, it would make it easier to keep the ABI stable
< 1767823362 420363 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if you created a new version of a function you would have to leave the old one around
< 1767823433 10240 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: at dynamic link time, indeed – for some of those problems you can solve them at static link time instead and just generate multiple executables, but there are probably some cases that wouldn't solve
< 1767823449 29508 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(although, you have function pointer cost *anyway* in the usual current way of doing things)
< 1767823482 263863 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: my problem is that if I'm forced to use dlsym then the burden of type safety for the function calls is always on me. I'm find with allowing that for some cases, and it's almost always necessary when linking compilation units cross-language or with cyclic dependencies, but sometimes I just want the simple way when I set a dynamic library crate dependency at runtime and the rust/haskell compiler 
< 1767823488 268731 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ensures at compile time that I'm doing typesafe calls across crates.
< 1767823511 41025 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :s/find with/fine with/
< 1767823523 51862 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I would encourage people to statically link in that situation
< 1767823550 32547 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I see
< 1767823553 731821 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it is worth noting that at least the current Rust compiler is not appropriate for this situation, it will check that the types match at the source level, but does not compile them consistently at the binary level
< 1767823581 561591 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so you can have types that match in the source code but go wrong when the binaries communicate
< 1767823618 278504 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :yeah, you can probably only do that if you always compile the crates together and with the same options, at which point you might as well link them statically 
< 1767823710 223154 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :hopefully future versions of rustc will at least be able to check the typesafety at binary level and give an error when something is incompatible, even if they can't solve that
< 1767823735 485526 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :doing that on a *dynamic* link would be… interesting
< 1767823754 884550 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I guess you're making a reasonable case for why static linking is better *in practice*, even if dynamic linking is what I want in some idealized world
< 1767823760 185528 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it isn't theoretically impossible, but I don't know whether you'd implement it in the dynamic link or in the implementation of / wrapper around dlopen
< 1767823764 95908 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* in the dynamic linker
< 1767823787 780980 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :why? you just mangle the full type description (or at least a cryptographic hash of it) into the dyanmically linked symbol names
< 1767823801 585918 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, I didn't even think of that
< 1767823816 697334 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :at least as much of the type description as matters for the ABI that is
< 1767823820 835228 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, mangling the ABI (as opposed to type name) would work
< 1767823873 865273 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that technique might be useful for the typed-asm thing I've been thinking about, it'd let you do the type checking before the linker and yet still use a regular linker to link the resulting files together
< 1767823907 318675 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :by encoding the type assumptions into the name of everything that's linked across compilation units, so if the types don't match, the link fails
< 1767823915 532600 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :…isn't this just "Hungarian notation for linkers"?
< 1767823981 142996 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :rust _does_ mangle cryptographic* hashes into dynamically linked symbol names, it's weird that it doesn't include enough information to catch memory safety issues
< 1767824038 985402 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the Rust name mangling situation is complicated, and I'm not sure I fully understand it
< 1767824051 751868 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :(* not long enough to be collision-safe, but the system can't protect against attacker-controlled binaries anyway)
< 1767824094 965468 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there has been a lot of discussion about whether the hashes used by TypeId are even strong enough to be safe against *accidental* collisions
< 1767824114 194022 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but the symbol name hashes are different, I think (but might be using the same algorithm?)
< 1767824114 250377 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I have vague plans for a C interpreter that helps run untrusted code, with stronger guarantees about undefined behavior than is usual for most architectures, and that would always know the type of functions modulo compatibility. I'll probably never actually do that project. Obviously you can still get a function call incompatible at a higher semantics level, which is why it's good practice for the 
< 1767824120 253402 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :programmer to rename a function whenever its semantics changes, and possibly provide wrappers with the old name. I had series of such functions in code for my previous job.
< 1767824129 680500 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :(I'm on that thread)
< 1767824147 766263 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in any case, Rust's very slowly moving towards "v0 mangling" (which is a weird name to give the second major version of your mangling scheme), and I think that doesn't use hashes at all
< 1767824212 155440 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :semi-recently they upstreamed demanglers for v0 mangling into a lot of unusual places, including the Linux kernel repository (but I think it was upstreamed into a userspace executable that's part of it, rather than the kernel source)
> 1767824216 974986 PRIVMSG #esolangs :14[[07Esolang talk:Categorization14]]4 10 02https://esolangs.org/w/index.php?diff=172488&oldid=170626 5* 03A() 5* (+255) 10/* Proposed category: Data structures */
< 1767824226 985531 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I'd probably save the whole type description, not just a hash, though a hash may also be there for quick comparison.
< 1767824266 36230 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :does the v0 mangling encode enough information to enforce memory safety at link time and how large is it?
< 1767824289 326199 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :Sure, you want to be able to remote debug a virtualized kernel instance, and the debugger (eg. gdb) should know about mangled names in that case.
< 1767824324 849713 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I'm not big on interactive debuggers, but if you're developping the linux kernel or something else that works with hardware then it's indispensible. 
< 1767824330 343609 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :(if symbol tables had slightly more structure than just strings we could make them smaller and have much faster bulk lookup)
> 1767824339 739665 PRIVMSG #esolangs :14[[07GTPS14]]4 10 02https://esolangs.org/w/index.php?diff=172489&oldid=172487 5* 03A() 5* (+19) 10
< 1767824420 156782 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :<sorear> does the v0 mangling encode enough information to enforce memory safety at link time and how large is it? ← it won't catch situations where you compile against one version of a crate and link against a different version in which types have the same name but are defined differently
< 1767824469 786625 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :(don't think about dlsym.  if you're loading library A which has N undefined symbols and library B has M defined symbols, that is a JOIN)
< 1767824498 984819 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the format does aim to optimize size subject to a few other constraints, the ones which are in the biggest tension are probably "can demangle to produce a human-readable type name containing all relevant information" and "computationally inexpensive to encode/decode"
< 1767824558 765110 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :https://doc.rust-lang.org/nightly/rustc/symbol-mangling/v0.html seems to be the current spec
< 1767824573 420679 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: what I'd like is that when a new rustc version changes ABI and you link code compiled with different rustc versions, possibly compiled with different options, then you can't accidentally get a silent ABI mismatch from that, but you get an error at dynamic link time. 
< 1767824592 350484 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :if ELF symbols were represented as a DAG you could have all that information without repetition or slowing down links
< 1767824605 937689 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I think that's a reasonable thing to want
< 1767824652 747658 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :repr(Rust) is "unstable" but how many times has it actually changed since 1.0?
< 1767824679 4436 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :you could also catch some accidental ABI mismatches that are a fault of the person who writes the code. you can't catch all of these because the programmer can just cause deliberate UB with unsafe code, but it could catch some mistakes.
< 1767824681 609916 :tromp!~textual@2001:1c00:3487:1b00:3110:dc2b:d7bb:a210 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1767824688 370484 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorear: quite a lot I think, mostly with respect to enums
< 1767824723 725376 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :some of the changes are spec changes, though, I think
< 1767824737 36033 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :as in, they're fully binary compatible both ways, just the guarantees changed
< 1767824774 966879 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :the current solution is to just make the cross-crates ABIs a stable C ABI as if you were linking code from another language, with a thin source code wrapper on one side of the ABI boundary that contains the type same as a C header file would in C or C++
< 1767824790 443933 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there's an unstable option that randomizes field order in repr(Rust) structs, possibly subject to not having to introduce extra padding
< 1767824797 613337 :molson__!~molson@24-124-54-137-dynamic.midco.net JOIN #esolangs molson :realname
< 1767824798 737721 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :with that option, repr(Rust) changes every compile
< 1767824802 757810 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :and I think this isn't an unreasonable solution exactly because that's what you want to be able to do to link between languages, such as to link between C++ and rust
< 1767824822 499702 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :so this should always be supported, but there could be more optimized easy cases in addition to this
< 1767824822 877631 :APic!apic@apic.name PRIVMSG #esolangs :Night
< 1767824845 951125 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: right, Rust linking to itself via a C ABI is the recommended (and only reasonable corrrect) way to do it atm
< 1767824861 288989 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :night APic
< 1767824880 738249 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :this isn't just Rust, you can do this in Haskell too, it's just harder with Haskell because it's harder to write C ABIs that match the Haskell code well
< 1767824900 407775 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :or for linking a C++ library into perl or python
< 1767824954 683354 :molson_!~molson@2605-4A80-2100-2E10-545D-F23A-70BD-B668-dynamic.midco.net QUIT :Ping timeout: 260 seconds
< 1767824986 625884 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :or linking C++ code with rust code, which is the most practically relevant case for me
> 1767827502 473685 PRIVMSG #esolangs :14[[07Esolang talk:Categorization14]]4 10 02https://esolangs.org/w/index.php?diff=172490&oldid=172488 5* 03Corbin 5* (+459) 10/* Proposed category: Data structures */
> 1767827546 147022 PRIVMSG #esolangs :14[[07Esolang talk:Categorization14]]4 M10 02https://esolangs.org/w/index.php?diff=172491&oldid=172490 5* 03Corbin 5* (+1) 10/* Proposed category: Data structures */ Fix fragment.
< 1767827745 146975 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I think that "run this progam until the next system call, then skip the system call" can be useful for native programs, if you can change the effect of system calls by doing something else instead, although the way that such a thing works in Linux is perhaps not as well, due to many things including there are a lot of system calls.
< 1767827811 487239 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :My idea of a operating system design though would have the suggested way for a system call to do nothing would be "wait for all objects in a empty set to be ready", and the usual way to terminate a program is "wait for any object in a empty set of objects to be ready".
< 1767828209 204367 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname
> 1767829575 948836 PRIVMSG #esolangs :14[[07Gur yvsr14]]4 M10 02https://esolangs.org/w/index.php?diff=172492&oldid=172318 5* 03Placeholding 5* (+2) 10fixed mistake in first bad example