..."
> 1739425855 991052 PRIVMSG #esolangs :14[[07Translated ZhongWen/Mihai Again Chapter IX14]]4 10 02https://esolangs.org/w/index.php?diff=151840&oldid=151839 5* 03MihaiEso 5* (+17) 10
< 1739426066 500767 :Celeo!~Celeo@user/celeo QUIT :Quit: Celeo
< 1739426683 464864 :Celeo!~Celeo@user/celeo JOIN #esolangs Celeo :Celeo
> 1739427306 277975 PRIVMSG #esolangs :14[[07Translated ZhongWen/Mihai Again Chapter IX14]]4 10 02https://esolangs.org/w/index.php?diff=151841&oldid=151840 5* 03I am islptng 5* (-33) 10Translation
> 1739427324 710156 PRIVMSG #esolangs :14[[07Nya~*kwrgsfish+-HQ9`:'"rbtAzxdi814]]4 N10 02https://esolangs.org/w/index.php?oldid=151842 5* 03PrySigneToFry 5* (+3038) 10Created page with "Nya~*kwrgsfish+-HQ9`:'"rbtAzxdi8, or Nya~-r%23kcd#TbjSV\d\\\\zESGmcdips is designed by PSTF.  = Language Overview = Nya~*kwrgsfish+-HQ9`:'"rbtAzxdi8 is turing complete, uses an accumulator, a tape with 114514 cells, a stack, a buffer, and 
> 1739427392 767110 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=151843&oldid=151821 5* 03PrySigneToFry 5* (+62) 10
< 1739429254 353565 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :korvo: yes, you could have a language where in the memory safe dynamically typed version adding an offset to a pointer calls a different function than adding integers, while in another untyped version they call the same function since there's no way to tell if the input is an integer or pointer.
< 1739429300 384060 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: That's very close to a real example for me!
< 1739429303 869328 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :or similarly you can have a language like C where the same integer (used as an array index) or pointer type can have different sizes on different implementations, 32-bit on one and 64 bits on another
< 1739429338 298882 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :you write "long" and windows will use a 32-bit integer while linux will use a 64-bit integer
< 1739429352 24369 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :RPython has its own type system which checks that the FFI is internally sane and that the foreign primitives are C-compilable. But that's not the same thing as the C linker's type system which is used during the final compilation step.
< 1739429352 746041 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :similarly for long double
< 1739429406 132899 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :And neither of those are Pyflakes' name-oriented syntax checker, which I used up until it broke Python 2.7 support a few years ago. So much more useful than any other linter IMO.
< 1739429430 973566 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :...RPython also has its own idea of "long". They support Win32, you see.
< 1739429531 806751 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :also C++ and Rust allow calling C functions natively, but they and C have three different ideas of the type restrictions on what function types are equal and what type you are allowed to use to call a function, and their interactions are not really well documented
< 1739429653 696405 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :in the case of C and C++ this is because both the C and C++ language standard committees refuse to try to document the interactions, so the only documentation there is are the non-portable ones for ABIs of specific implementations; in the case of Rust the specification is still somewhat lacking but that probably will get fixed in time
< 1739429769 143859 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I'm not even sure there's a sane consistent description of how C and C++ function calls should work at the language typing level (as opposed to what actually happens at ABI level after the compiler discards the detailed type information and the linker links C and C++ compilation units) 
< 1739429809 317378 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I mean there is, but it would require relaxing the C++-only rules a lot too
< 1739429877 72914 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :so if you want to write a type-checking linker (which could be useful to check if your program is portable to possible future implementations with strange ABI rules) you'd have to figure this out
< 1739429890 264756 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I was wondering about this recently
< 1739430129 355239 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :That's actually a really nasty example, because IIRC Rust and C have different ideas of what an "enum" looks like.
< 1739431603 282678 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :korvo: I think enums are mostly fine. Rust now allows the repr attribute for enums which gives a specific representation for them, while C enums are just of an ordinary integer type. C++ class enums would be a problem, but then C++ has lots of other non-C types that don't have a representation fixed enough that you could interact with it through a C abi, so that's also fine.
< 1739431840 726184 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: Sure. All types are ctypes, etc.
< 1739431848 757933 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :...Sorry. I'm not sour at you. I'm sour at C.
< 1739432456 883960 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User
< 1739432853 560053 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :https://github.com/memesmith0/mcr3sh
< 1739433002 643195 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Lovely art, thanks.
> 1739433281 749742 PRIVMSG #esolangs :14[[07Translated ZhongWen/PSTF Again Chapter IX14]]4 N10 02https://esolangs.org/w/index.php?oldid=151844 5* 03PrySigneToFry 5* (+6285) 10Created page with "Translated ZhongWen/Mihai Again Chapter IX|You computer has a severe errL$D3h$&% ?' L$H3h(*) ?+ L$L3h,.- ?/ L$P3h021 ?3 ?6$T3h45 ?7 ?:$X3h89 ?; ?p<=? ? F  ?~#?~nDl$ ? ?\$#\$ 3\$?D$$H$$  ??D$03D$(
> 1739433319 890968 PRIVMSG #esolangs :14[[07Translated ZhongWen/Mihai Again Chapter IX14]]4 10 02https://esolangs.org/w/index.php?diff=151845&oldid=151841 5* 03PrySigneToFry 5* (+49) 10
< 1739433490 53849 :Celeo!~Celeo@user/celeo QUIT :Quit: Celeo
< 1739435106 532370 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
> 1739435526 93109 PRIVMSG #esolangs :14[[07User:PrySigneToFry/Sandbox/Users that is also on other place14]]4 N10 02https://esolangs.org/w/index.php?oldid=151846 5* 03PrySigneToFry 5* (+1314) 10Created page with "Here shows users that is also on other place.  # PrySigneToFry: PrySigneToFry(Backrooms Fandom, Esolang Wiki), LittleLWSS(Conway's game of life Wiki/Forum), Xdi8Loverian(Xdi8 Wiki), (Whole Miraheze, including Mu
> 1739436018 850008 PRIVMSG #esolangs :14[[07User:PrySigneToFry/Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=151847&oldid=151461 5* 03PrySigneToFry 5* (+330) 10
< 1739436127 630704 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer
> 1739436931 655061 PRIVMSG #esolangs :14[[07Translated ZhongWen/PSTF Again Chapter IX14]]4 10 02https://esolangs.org/w/index.php?diff=151848&oldid=151844 5* 03MihaiEso 5* (+46) 10
> 1739437212 36446 PRIVMSG #esolangs :14[[07Translated ZhongWen/Mihai Again Chapter X14]]4 N10 02https://esolangs.org/w/index.php?oldid=151849 5* 03MihaiEso 5* (+5510) 10Created page with "Translated ZhongWen/Mihai Again Chapter IX|You computer has a severe errL$D3h$&% ?' L$H3h(*) ?+ L$L3h,.- ?/ L$P3h021 ?3 ?6$T3h45 ?7 ?:$X3h89 ?; ?p<=? ? F  ?~#?~nDl$ ? ?\$#\$ 3\$?D$$H$$  ??D$03D$(? D$$
> 1739437265 950132 PRIVMSG #esolangs :14[[07Translated ZhongWen/Mihai Again Chapter X14]]4 10 02https://esolangs.org/w/index.php?diff=151850&oldid=151849 5* 03MihaiEso 5* (-1) 10
> 1739437409 741153 PRIVMSG #esolangs :14[[07User:PrySigneToFry/Sandbox/Users that is also on other place14]]4 10 02https://esolangs.org/w/index.php?diff=151851&oldid=151846 5* 03I am islptng 5* (+33) 10
> 1739438145 511896 PRIVMSG #esolangs :14[[07Translated ZhongWen/islptng Zwei14]]4 N10 02https://esolangs.org/w/index.php?oldid=151852 5* 03I am islptng 5* (+5412) 10Created page with "Translated ZhongWen/PSTF Again Chapter IX|You computer has a severe errL$D3h$&% ?' L$H3h(*) ?+ L$L3h,.- ?/ L$P3h021 ?3 ?6$T3h45 ?7 ?:$X3h89 ?; ?p<=? ? F  ?~#?~nDl$ ? ?\$#\$ 3\$?D$$H$$  ??D$03D$(? D$$(..."
> 1739438201 860667 PRIVMSG #esolangs :14[[07Translated ZhongWen/islptng Zwei14]]4 10 02https://esolangs.org/w/index.php?diff=151853&oldid=151852 5* 03I am islptng 5* (-4) 10
> 1739438256 121399 PRIVMSG #esolangs :14[[07Translated ZhongWen/islptng Zwei14]]4 10 02https://esolangs.org/w/index.php?diff=151854&oldid=151853 5* 03I am islptng 5* (-18) 10
> 1739438329 576984 PRIVMSG #esolangs :14[[07Translated ZhongWen/Mihai Again Chapter X14]]4 10 02https://esolangs.org/w/index.php?diff=151855&oldid=151850 5* 03I am islptng 5* (+97) 10
> 1739442700 125309 PRIVMSG #esolangs :14[[07Translated ZhongWen/islptng Zwei14]]4 10 02https://esolangs.org/w/index.php?diff=151856&oldid=151854 5* 03MihaiEso 5* (+47) 10
> 1739442996 904456 PRIVMSG #esolangs :14[[07Translated ZhongWen/Mihai Again Chapter XI14]]4 N10 02https://esolangs.org/w/index.php?oldid=151857 5* 03MihaiEso 5* (+5624) 10Created page with "1. [[Translated ZhongWen/islptng Zwei|]]Esolang:undefined1234|You computer has a severe errL$D3h$&% ?' L$H3h(*) ?+ L$L3h,.- ?/ L$P3h021 ?3 ?6$T3h45 ?7 ?:$X3h89 ?; ?p<=? ? F  ?~#?~nDl$ ? ?\$#\$ 3\$?D$
> 1739443879 190838 PRIVMSG #esolangs :14[[07MSFE++14]]4 10 02https://esolangs.org/w/index.php?diff=151858&oldid=151760 5* 03Cycwin 5* (+1) 10/* Interpreter */
< 1739444536 411678 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User
> 1739445130 376041 PRIVMSG #esolangs :14[[07User:Yayimhere/an esolang for my puter14]]4 N10 02https://esolangs.org/w/index.php?oldid=151859 5* 03Yayimhere 5* (+788) 10Created page with "{{WIP}} SOOOOO i had this idea. whats the simplest computer i can make. like what parts do i need to make a turing machine(technically it would never be a turing machine cuz memory but uknow), and so i set out for a quest. can u build a l
< 1739446731 530210 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :there seems to be alot of bots in this channel
< 1739446807 90787 :APic!apic@apic.name PRIVMSG #esolangs :Hi
< 1739446809 313952 :APic!apic@apic.name PRIVMSG #esolangs :True
< 1739446809 772899 :int-e!~noone@int-e.eu PRIVMSG #esolangs :`? prefixes
< 1739446811 629366 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :Bot prefixes: fungot ^, HackEso `, EgoBot !, lambdabot @ or ? or > , thutubot +, metasepia ~, idris-bot ( , jconn ) , j-bot [ , bfbot =, velik \.
< 1739446847 478909 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(half of those are gone, and some of the bots don't have commands)
< 1739446871 523862 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :I have implemented a full reader macro system in posix shell in 3 lines
< 1739446887 160447 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :and so you can change the notation of your posix shell at will in the middle of writing your programs
< 1739446907 844842 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :as far as i know it works on a read only filesystem
< 1739446918 484461 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :so it should run on many routers
< 1739447929 326577 :int-e!~noone@int-e.eu PRIVMSG #esolangs :related: https://www.ioccc.org/1987/biggar/index.html /home/bf3/bat/space/esoteric/ioccc/ https://www.ioccc.org/1993/lmfjyh/index.html
< 1739447936 749106 :int-e!~noone@int-e.eu PRIVMSG #esolangs :grmbl
< 1739447951 425466 :int-e!~noone@int-e.eu PRIVMSG #esolangs :related: https://www.ioccc.org/1987/biggar/index.html https://www.ioccc.org/1988/spinellis/index.html https://www.ioccc.org/1993/lmfjyh/index.html
< 1739448458 978316 :craigo!~craigo@user/craigo JOIN #esolangs craigo :realname
< 1739449452 107068 :chiselfuse!~chiselfus@user/chiselfuse QUIT :Ping timeout: 264 seconds
< 1739449526 635263 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas
< 1739449558 943074 :chiselfuse!~chiselfus@user/chiselfuse JOIN #esolangs chiselfuse :chiselfuse
< 1739450074 295069 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :korvo: so I actually think C is the one that handles this the best, while C++ is the evil one, and rust is on the good path and will probably be fine in the future but there are some holes still. let me try to explain.
< 1739450207 516826 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :what the C++ standard says is that you are allowed to call a function only if where you're calling it it has the exact same function type as where it was defined. that means if a struct type is mentioned in the function type, even through pointer indirection, then it has to be the same struct type, with the same name in the same namespace.
< 1739450268 461606 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but the standard also says that if the same struct type is defined in multiple compilation units, then its two definitions must be exactly the same, token by token, and they must reference the same thing in both definitions (eg. if it mentions another type then that has to be the same type).
< 1739450443 705142 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :now if you want to pass/return a struct by value to/from a function, then that struct type must be defined in both compilation units. this makes it effectively impossible to call such a function if it's not defined in C++, but in eg. rust or haskell FFI or anything else, because you can't have the exact same function type with the same definition
< 1739450444 205284 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :in those languages. and depending on how the definitions work, it's probably close to impossible to even call such a function if it's defined in C or zig or an older version of the C++ standard or C++ with certain compiler options different, because those can change the meaning of the struct definition.
< 1739450516 979309 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :the situation is slightly better if you are only passing/returning a pointer to a struct when you're calling a function in C++, but it's still not good. in this case what you can do is to make sure that one of the two compilation units has the struct type declared but not defined, in which case the definition needn't be the same. and at either the
< 1739450517 481571 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :call or the function definition, you can cast the pointer to struct into a pointer to another struct.
< 1739450577 12753 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :casting the pointer is fine, though I don't quite understand the arcane C++ rules of when exactly you can use one C++ struct type to access the contents of a struct of another C++ struct type, but I think you can mostly make this work. \
< 1739450870 262214 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but that still involves a cast (however safe) to a different pointer type, which kind of breaks type safety, plus it's not even clear if it still works if the function is defined in rust or some other non-C-like language. C and rust can access or define variables and functions in the global C namespace, but C doesn't have a concept of structure
< 1739450870 770675 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :types whose names are valid outside of a source file, and while rust has global struct types matching between compilation units, they can only have names in the rust namespace. so if you define a function in rust or C that takes a pointer to a struct, that struct can't be the same at the definition and the caller.
< 1739451011 637677 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :The C standard has very different rules, and those rules work better with non-C compilation units.
< 1739451102 971447 :int-e!~noone@int-e.eu PRIVMSG #esolangs :C++ and Rust do basically the same thing here, don't they, namely, they treat C as an FFI target... extern "C" for C++; repr(C) and #[link(name = ...)] extern { ... } for Rust.
< 1739451110 724910 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :So C says that when you call a function, the call site and the definition site only needs similar enough types for that function, they don't need to be the same type. Crucially, if the function takes/returns a structure by value, they don't have to be of the same type (it's probably not even meaningful to ask if two struct types from two
< 1739451111 224450 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :compilation units are the same in C), they only have to be similar enough.
< 1739451123 60419 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1739451153 550872 :int-e!~noone@int-e.eu PRIVMSG #esolangs :And that's supported by things like the System V ABI which defines representations and calling conventions for C.
< 1739451156 997173 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :The names of those structs don't matter for this, because the struct names in C are necessarily local to the compilation units, only the list of types of the members and stuff like that matters.
< 1739451243 222960 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : in the case of C and C++ this is because both the C and C++ language standard committees refuse to try to document the interactions, so the only documentation there is are the non-portable ones for ABIs of specific implementations; in the case of Rust the specification is still somewhat lacking but that probably will get fixed in time ← this has been something of a problem for Rust because in some cases the C and C++ implementations aren't 
< 1739451244 802519 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :compatible with each other and thus it's unclear what Rust should do to be compatible with them
< 1739451249 756417 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I vaguely remember something about the alignment of u128
< 1739451266 772132 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :And if you pass/return a struct by pointer then you don't even need similar struct types, all pointers to struct are represented the same (pointers to void/char can differ from that, that's on purpose), so as long as the layout of the two structs are the same this will just work.
< 1739451398 938613 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :https://blog.rust-lang.org/2024/03/30/i128-layout-update.html
< 1739451408 770171 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :What C is trying to do is to give a portable enough definition to say when the ABI of the two function types must be the same on all implementations, while they obviously don't try to fix the same ABI. This can be subtle but I think they got it right: you can access a float through a struct{unsigned char[sizeof float]c;} and that preserves its
< 1739451409 271414 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :value, but if a function parameter is float then you can't call that function with a struct{unsigned char[sizeof float]c;} instead, which makes sense because on real ABIs the float can be passed in a floating-point hardware register.
< 1739451414 138787 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :apparently it was fixed by persuading clang to change to be compatible with gcc, then making Rust compatible with the new stanadrd
< 1739451454 625667 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the persuasion wasn't too hard because clang was trying to be compatible with gcc anyway, so from their point of view it was a bugfix
< 1739451534 629151 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: in practice, "the function pointer type must match exactly" is normally a fairly easy rule for programmers to stick to and sufficient to meet the C requirements
< 1739451541 576291 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so I didn't bother learning the situations in which it's allowed to be slightly different
< 1739451600 57089 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: yeah, that reminds me of how gcc at one point had to change the C++ linux name mangling of certain functions whose type involve an xmm/ymm vector type. that means C++ programs compiled with the new rules may be ABI-incompatible with ones compiled with the old rules, but this had to happen because the old rules were broken and could mangle
< 1739451600 560864 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :different overloaded functions to the same name which is a bug.
< 1739451645 588321 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: it's an easy rule if all your source code is in the same language, but it gets much harder if the function definition and call are in different languages.
< 1739451690 790522 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah right, I see
< 1739451708 987662 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :most language's FFIs are defined in terms of C types in an attempt to make the problem manageable
< 1739451731 547673 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that might potentially be a mistake, although I'm not sure (I'm pretty sure the reliance on libc for all OS interaction is a mistake, but am less sure about the FFI ABI situation)
< 1739451794 469579 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: yes, rust and haskell is doing that, though there are some gaps that aren't handle yet. but C++ is not doing this in theory. specific C++ ABIs do, but you can't write a C++-C combo in a way that's guaranteed to be portable to future implementations because the general rules aren't written down in a way that C and rust writes down what they
< 1739451795 1390 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :try to guarantee even in future ABIs.
< 1739451855 622824 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, does C++ allow equivalent-but-not-token-identical multiple definitions of extern "C" structs?
< 1739451901 117240 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :rust has in particular improved this recently (like in the last two years): they wrote a new document that talks about when function types are compatible (similar to C), and added new ABI guarantees to certain library types, most importantly UnsafeCell and Cell
< 1739451927 805149 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: extern "C" structs don't exist. extern "C" only applies to function definitions and *maybe* function pointer types.
< 1739451964 36605 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :huh, I thought it was more general than that
< 1739451967 606670 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :for function definitions what it does is put the (declared external or defined) function into the non-mangled C namespace, so it can be the same *function* as a C function
< 1739452018 400578 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and the standard either says or used to say that this can also change the ABI of that function, which is why it could technically modify the type of a function pointer, but I think that was never a thing in popular C++ implementations, mostly because the same people write the C and C++ compilers for any one ABI.
< 1739452024 537644 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess maybe C++ needs a "C-like structure" concept, the same way that Rust has a "C-like enum" concept (i.e. "the subset of C++ structures that are valid C", just like Rust has "the subset of Rust enums that are valid C")
< 1739452036 381722 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :in rust this is a thing by the way, function pointers carry their ABI.
< 1739452043 920993 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :carry the function's call  ABI.
< 1739452066 375360 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, any use of the function pointer has to know the ABI to be usable
< 1739452066 667581 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu QUIT :Quit: Client closed
< 1739452091 663833 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas
< 1739452097 715625 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :oh by the way it's also a thing in C/C++, with the stdcall ABI for some windows architecture, it was just not a thing where C++ has a different default ABI or available ABIs from C.
< 1739452529 106241 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I was going to say that it is quite common in practice for C compilers to support multiple ABIs and for function pointers to carry the ABI, even though that behaviour isn't required by the standard
< 1739452584 923891 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :incidentally, I think it is a mistake for compilers to have observable ABIs for all functions by default – it would be more efficient for the programmer to manually mark functions they wanted to be able to take a pointer to, and for the ABIs of the others to be adjusted by the optimiser as necessary, without necessarily being a standard ABI
< 1739452589 116510 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :one small hole is that the new rust document forgot to mention that passing a MaybeUninit by value to a foreign function is safe, and you may need that for passing/returning a structure by value in a typesafe way if some struct members may be uninitialized, which is fine for C and a C ABI can reasonably require it, especially if it's in a more
< 1739452589 617862 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :typesafe C++ style library.
< 1739452658 195871 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a simple example is that leaf functions can often be compiled to preserve more registers than the ABI says they should, which could be relied on by the calling function to reduce the need to spill
< 1739452707 945139 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in particular, it usually doesn't cost anything for a leaf function to preserve the argument registers, and the caller often cares about the values it provided as arguments
< 1739452718 985597 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess making extra guarantees is a function-pointer-compatible ABI change, though
< 1739452729 590459 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: that is already effectively done. in rust by default the ABI of functions and even user-defined structs can change between compiler versions, so you might not be able to pass a struct or call a function from a file compiled in one version of rust to a file compiled in another. you usually need an explicit repr attribute for a user-defined
< 1739452730 99916 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :struct to have a definite ABI, and some other attribute for a function.
< 1739452753 550469 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: in Rust, yes, the spec does that (although I'm not convinced the implementation actually does yet)
< 1739452757 705363 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I was thinking about langauges in general though
> 1739452770 39079 PRIVMSG #esolangs :14[[0714]]4 10 02https://esolangs.org/w/index.php?diff=151860&oldid=132471 5* 03Allen123456hello 5* (+131) 10/* Example */
< 1739452808 326147 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I am still upset about the &T as *const T cast, though – it is mostly useless and blocks a significant optimisation
< 1739452822 598635 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and both modern C and C++ and rust can often prove that you can't access a certain function from another compilation unit, in which case it can use a different ABI, and the compilers can even specialize an exported function with a different ABI for local calls as long as it exports a suitable wrapper.
< 1739452829 875396 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(it isn't so useless that you can backwards-compatibly remove it, but it is normally possible to write programs to avoid it)
< 1739452842 594592 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(especially now that we have the &raw operator)
< 1739452904 984180 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : and both modern C and C++ and rust can often prove that you can't access a certain function from another compilation unit ← I disagree, don't default settings export basically every function, at least on Linux?
< 1739452945 713536 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you at least need a default visibility option (together with options to override it for any functions that are actually used by other shared objects)
< 1739452973 979351 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :in C functions are exported by default, but you can declare them static or, in non-old versions of C, declare them inline, in which case they're not exported.
< 1739452987 48937 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: what if you pass a static function to qsort or the like?
< 1739453035 2190 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :also the inline declaration doesn't help – by default inline functions also need an out-of-line version so that code calling from outside has something to call
< 1739453039 281745 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :you can do that, and then the compiler knows that you are taking the address of the function at that call site and will either compiler the function with the standard ABI, or, for a more complicated compiler, at least emit a wrapper function with the standard ABI
< 1739453040 574778 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can fix that using static inline, but then you still have a static
< 1739453060 544415 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so I think it's specifically static (+ compiler-specific attributes) that matter there
< 1739453084 290004 :int-e!~noone@int-e.eu PRIVMSG #esolangs :oh hmm, C++ has "standard layout types" but the link to C ABI is that the x86_64 SysV ABI refers to https://itanium-cxx-abi.github.io/cxx-abi/abi.html#pod ?
< 1739453112 128821 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :it's kind of the same as when you take the address of a local variable and pass it to a function from another compilation unit: the compiler has to notice that and know that the value of that variable can change later from a different function call
< 1739453117 41519 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :gcc has __attribute__(visibility(internal)) which does what we want, I think
< 1739453126 485448 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(and, I guess, most other 64 bit ABIs, as far as Linux is concerned)
< 1739453140 261745 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the semantics being "this function is never called from another module, not even by function pointer")
< 1739453157 163063 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the more common visibility(hidden) does not ban indirect calls by function pointer, so wouldn't allow an ABI change
< 1739453162 417449 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :int-e: yes, and those help with accessing a struct by the wrong type of pointer, they aren't enough to pass structs by value, only for passing structs by pointer
< 1739453164 506095 :int-e!~noone@int-e.eu PRIVMSG #esolangs :But I think it's still fair to say that the *intent* of standard-layout types is that their representation matches that of C.
< 1739453178 917086 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and in fact, the documentation for visibility(internal) says that it's primarily useful to allow the optimiser to change the ABI
< 1739453194 138183 :int-e!~noone@int-e.eu PRIVMSG #esolangs :wib_jonas: that's fair but what's there is enough for interoperability
< 1739453198 936151 :int-e!~noone@int-e.eu PRIVMSG #esolangs :barely.
< 1739453231 942889 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net JOIN #esolangs amby :realname
< 1739453323 638659 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: I guess the principle here is "what we have already necessarily works at least well enough to make writing software possible, otherwise we wouldn't have any software – but there is no guarantee that it works any better than that"
< 1739453379 904022 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :meanwhile, a bigger hole is atomic types. there are at least three sets of these, possibly more: the C atomics, the C++ atomics, and the rust atomics. the C++ and rust folks both always insist that you can do atomic access only on atomic types, don't even try to think of doing it on a value declared with an ordinary type. but the at least three
< 1739453380 421628 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :atomic types are different. so from rust code you can't directly access a C or C++ atomic variable, even though this is exactly the kind of low-level operation that you want to be able to do directly without calling an opaque wrapper function.
< 1739453471 831227 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :now admittedly the C++ atomics have different semantics in that std::atomic is a wrapper template that for sufficiently complicated values isn't lock-safe and basically translates to locking a value with an inter-thread mutex. but most of the time you use it for actual lock-safe atomics, and there's still no way to share those between C++ and rust.
< 1739453495 194427 :int-e!~noone@int-e.eu PRIVMSG #esolangs :rust is working on it, https://github.com/rust-lang/rust/issues/76314
< 1739453522 100712 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ideally I'd want not only that but inter-thread mutexes and condition variables that you can access between languages, but that's harder to solve.
< 1739453526 796680 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :int-e: ooh, let me look at that
> 1739453534 359364 PRIVMSG #esolangs :14[[07ToArrowScript14]]4 N10 02https://esolangs.org/w/index.php?oldid=151861 5* 03Cycwin 5* (+3920) 10Created page with "ToArrowScript(or TAS, AS) is a language created by [[User:Cycwin]].This language is partly inspired by the => (arrow) symbol in JavaScript. == Syntax of TAS == Use the ampersand symbol to separate each line of command.  Each command is composed in a format similar 
< 1739453580 648014 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :from the Rust documentation, this seems to be the incompatibility: "Since atomic loads might be implemented using compare-exchange operations, even a load can fault on read-only memory."
< 1739453618 522602 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :int-e: ah yes, they're working on accessing non-atomic variables atomically. but that's still some low-level magic that I rarely want to touch, I'd prefer to just have, uh, "high level" atomic types that I can use from both C++ and rust.
> 1739453622 128904 PRIVMSG #esolangs :14[[07User:Cycwin14]]4 10 02https://esolangs.org/w/index.php?diff=151862&oldid=151442 5* 03Cycwin 5* (+17) 10
< 1739453662 715835 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: I see
< 1739453668 806528 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's unclear to me how a load could be implemented using compare-exchange unless you have a separate version number / timestamp field that acts as the atomic version of a lock, to ensure that the value hasn't changed, and even then I'm not sure how writes would work
< 1739453673 583386 :int-e!~noone@int-e.eu PRIVMSG #esolangs :wib_jonas: well if you're paranoid about it, you have to do it all in C and access it through FFI.
< 1739453695 943910 :int-e!~noone@int-e.eu PRIVMSG #esolangs :because there's no guarantees that link atomic access in C to atomic access in the other languages
< 1739453722 283686 :int-e!~noone@int-e.eu PRIVMSG #esolangs :but realistically, you can share locations by going through a pointer to the underlying non-atomic value and it'll work
< 1739453743 383883 :int-e!~noone@int-e.eu PRIVMSG #esolangs :And that RFC / nightly feature allows you to do that.
< 1739453810 937882 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(if there are such guarantees and I've missed them I'm all ears)
< 1739453871 58382 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :int-e: yes, no guarantees so it's fine if the current types can be different. but rust could define a new library type that is guaranteed to be the same as C atomic_uintptr_t, and another library type that's the same as C++ std::atomic, and similar for atomic bools and atomic 32-bit integers.
< 1739453871 779156 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this comment explains what's incompatible on the C++ side: https://github.com/rust-lang/rust/issues/76314#issuecomment-955150595
< 1739453900 586228 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it does not reasonably seem possible to be compatible with that behaviour while maintaining a reasonable API
< 1739454096 715111 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ooh, a discussion lower down there possibly answered a question I've been wondering about for a while: how to safely read from map-shared memory in Rust, RalfJung said you can do it via an &UnsafeCell which is an option I hadn't thought of but makes a lot of sense
< 1739454110 59758 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(raw pointers work too, obviously)
< 1739454142 434893 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Goddamnit Firefox. Please say that the certificate is expired (and when) instead of "The website is either misconfigured or your computer clock is set to the wrong time."
< 1739454186 771411 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: that comment is talking about the C++ library type atomic_ref which is so new that I hadn't even heard of, and you C++ already had way to handle atomic pointers before that, with std::atomic
< 1739454247 526272 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah, C++ changes the official way to do things so often that I just assumed it was the only/standard way nowadays
< 1739454277 954968 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :it might be convenient, I don't know that
< 1739454329 488111 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I don't even insist on the specific C and C++ types that I mentioned earlier. Figure out some semantics that you can support natively in all three, and if it needs to use new types that's fine too.
< 1739454368 587554 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one of my desires for Rust is a function read_race that takes in a raw pointer, and reads the value there into a MaybeUninit, but is not UB if the memory is mutably referenced or being concurrently changed by another thread (rather, it returns uninitialised data in that case)
< 1739454404 326385 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think this is required for certain atomic algorithms to work correctly – if your algorithm is lock-free you can't make any guarantees about what other threads might do with the memory, but you can check after you read it to see if any other thread wrote it or not
< 1739454419 774149 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :But the plus side is that a few years ago we had the same problem if you want to pass xmm/ymm vector types by value to a function, but that is now solved, rust has a stable way to represent those (with possibly some remaining issue concerning the two bits concerning denormals in the xmm floating-point status registers)
< 1739454431 926367 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so the idea is, you read it first (without looking at the value), then do some checks of atomic variables to see whether or not you read a usable value or not, if you didn't you discard it
< 1739454443 263392 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I don't think it's possible to do that in Rust atm without UB or inline asm
< 1739454456 550608 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Anyway. I doubt this will ever happen for C++'s atomic types, but maybe C's atomic types have a chance.
< 1739454490 694367 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: hmm...
< 1739454511 206473 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: fwiw, Rust doesn't appear to have a rule against doing atomic accesses to non-atomic memory – just to have a rule against mixing atomic and non-atomic accesses to the same memory, which is currently enforced by making atomic and non-atomic memory different
< 1739454523 932384 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Rust is still fairly young (quite a few details aren't fully fleshed out), and from what I've seen they care about interoperability with C.
< 1739454541 496308 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: Yeah, that too.
< 1739454576 806445 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this makes it likely that Rust atomics can be made compatible with C atomics, although it'll probably rely on a lot of unsafe
< 1739454585 780051 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :int-e: C's atomic types could be kind of fine, because I think you can access those from C++, even if it's not quite standard C++, but it works just as well as accessing unix system calls from C++
< 1739454621 185063 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :int-e: exactly, I see lots of examples of rust getting improved, which is what makes me want to invest more in it, because I know it will be better in the future;
< 1739454666 584404 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and they care about compatibility between versions of rust, even when this costs significant time for the compiler developers, so they can actually improve a lot of things that aren't currently supported even when they seem to require breaking changes\
< 1739454787 619261 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: re access any memory atomically as long as all accesses to it are atomic => that does actually sound similar to the other parts of rust memory model
< 1739454948 522819 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: is that read_race thing that you mention possible in C or C++ with their modern memory models?
< 1739454975 466268 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: I assumed it would be legal in C with just a regular read, but am not 100% certain
< 1739454995 794522 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :obviously C doesn't care about the value being mutably referenced, but it might care about it being changed by another thread
< 1739455004 353212 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yeah
< 1739455005 959099 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :actually I think that probably is UB in C
< 1739455036 706329 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which doesn't really have a distinction between "you get UB" and "this isn't undefined behaviour but you read garbage data"
< 1739455084 654034 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :C doesn't have that distinction?
< 1739455145 806199 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, it does to some extent, I think there are places in the C standard where it says "the value might be a trap representation", which is very close
< 1739455181 203827 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but it doesn't like making assumptions about, e.g., which values for pointers might crash the program merely by being stored in a pointer register, even if you don't use them
< 1739455200 199095 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can probably get reasonable guarantees for unsigned integer types, but likely not anything else
< 1739455441 918533 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I see, so you're saying that C doesn't like to say that you get garbage data, it says either that you get UB, or that you get a valid but unpredictable value?
< 1739456188 794051 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1739456193 492499 :int-e!~noone@int-e.eu PRIVMSG #esolangs :wib_jonas: you have language like "If there is ambiguity about which side effect to a non-atomic object is visible, then there is a data race and the behavior is undefined." or "Any [...] data race results in undefined behavior."
< 1739456365 451213 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :oh I see! so that discussion thread that ais523 linked to about rust atomics, what it says is that on x86_32, u64 is only aligned to 4 bytes, but atomic u64 must be aligned to 8 bytes, so you can't have an API that lets you access any &mut u64 atomically, even if you guarantee that that's not concurrent with normal non-atomic accesses. that makes
< 1739456365 951562 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :sense.
< 1739456367 161161 :int-e!~noone@int-e.eu PRIVMSG #esolangs :And "undefined behavior" is basically limitless.
< 1739456627 760661 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: right, "atomic u64 must be 8-byte aligned" is a processor rule on the x86 series (this affects both x86 and x86-64, but it doesn't matter on typical x86-64 ABIs because u64 is 8-byte-aligned there anyway)
< 1739456658 671555 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and the rule makes sense because the processor is only able to atomically access a single cache line at a time, so it requires the data to be naturally aligned to guarantee that it exists within a single cache line
< 1739456709 822868 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :atomic u128 is 16-byte aligned on x86-64 for the same reason, and is one of the only commands that requires aligned data and doesn't have a matching command that works on unaligned data
< 1739456761 782494 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(x86-64 has some aligned-only memory copy instructions for backwards compatibility, but they're no more efficient than the unaligned memory copy instructions are at operating on aligned data)
< 1739456846 599607 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yeah
< 1739456865 589521 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's actually an interesting question as to whether compilers should generate aligned or unaligned memory copy instructions; I think the current consensus is "if you know it's aligned, generate an aligned instruction as a free assert"
< 1739456977 291529 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :that could even depend on whether you're reading or writing
< 1739456997 211071 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ok, maybe not
< 1739457024 595558 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, it's usually desirable for a program to crash on invalid inputs, rather than try to process them anyway, although it depends somewhat on the purpose of the program
< 1739457148 314427 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I usually program in fields where fail-fast is definitely what you want, though
< 1739457348 202388 :int-e!~noone@int-e.eu PRIVMSG #esolangs :wib_jonas: Oh I should've mentioned that the second quote about data races was about mixing atomic and non-atomic operations on atomic types. So rather than "one of the written values" or "an unspecified value" you potentially get arbitrary behavior from the program.
> 1739458215 659851 PRIVMSG #esolangs :14[[07Pointing14]]4 10 02https://esolangs.org/w/index.php?diff=151863&oldid=151693 5* 03Calculus is fun 5* (-2) 10Changed xor symbol
> 1739458454 837726 PRIVMSG #esolangs :14[[07ToArrowScript14]]4 M10 02https://esolangs.org/w/index.php?diff=151864&oldid=151861 5* 03Cycwin 5* (+28) 10/* Syntax of TAS */
> 1739458821 259981 PRIVMSG #esolangs :14[[07ToArrowScript14]]4 M10 02https://esolangs.org/w/index.php?diff=151865&oldid=151864 5* 03Cycwin 5* (+26) 10/* Syntax of TAS */
< 1739458830 500155 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :The C standard does make the distinction between /undefined behavior/ ("this International Standard imposes no requirements") and /unspecified behavior/ ("this International Standard provides two or more possibilities and imposes no further requirements on which is chosen"). And there are some instances when you get an /unspecified value/, which cannot be a trap representation.
< 1739458840 278567 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :(Such as C11 6.2.6.1p6: "When a value is stored in an object of structure or union type -- the bytes of the object representation that correspond to any padding bytes take unspecified values.")
< 1739458876 831576 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Trap representations themselves are technically only "safe" (i.e., not undefined) for character types; other integer types (even unsigned) would be allowed to have combinations of padding bits that would trigger fully undefined behavior when accessed.
< 1739458892 867496 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :(C11 6.2.6.1p5: "If the stored value of an object has [a trap] representation and is read by an lvalue expression that does not have character type, the behavior is undefined.")
< 1739458930 376622 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :There's also an interesting quirk in that reading an uninitialized variable doesn't merely produce something that might be a trap representation (which would render it "okay" for character types), but is explicitly undefined behavior, but only for a subset of situations.
< 1739458938 123421 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :(C11 6.3.2.1p2: "If the lvalue [undergoing lvalue conversion] designates an object of automatic storage duration that could have been declared with the `register` storage class (never had its address taken), and that object is uninitialized --, the behavior is undefined.")
> 1739458956 137757 PRIVMSG #esolangs :14[[07Pointing14]]4 M10 02https://esolangs.org/w/index.php?diff=151866&oldid=151863 5* 03Calculus is fun 5* (-3) 10/* Instructions */
< 1739458996 226363 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :fizzie: which one is it when you convert an integer to a smaller signed integer type that it overflows?
< 1739459091 304784 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :That's the *third* kind, /implementation-defined/, which is the same as unspecified except that the implementation is required to document how the choice is made.
< 1739459095 39517 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :(C11 6.3.1.3p3: "Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised.")
< 1739459121 255628 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User
< 1739459172 237294 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :That's also an interesting edge case in itself: a *conversion* result that cannot be represented is implementation-defined, while a result of an arithmetic operation (of a signed integer type) that cannot be represented in its type is undefined behavior.
< 1739459177 962113 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :some arithmetic like those integer conversions, shifts, and float to integer conversions get tricky. I think there are differences between C and C++ and between older and newer versions of C++. Conversion to a smaller integer type at least has an easy workaround: I always just convert to the same sized unsigned type first, and from that to the
< 1739459178 461931 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :unsigned type, because both of those steps are well-defined with the expected result.
< 1739459320 872766 :int-e!~noone@int-e.eu PRIVMSG #esolangs :@seen fungot
< 1739459320 947482 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esolangs :I saw fungot leaving #esolangs 1d 14h 43m 43s ago.
< 1739459354 20489 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :There's a similar implementation-defined vs. undefined dichotomy in (C) bitwise shift operations, where `E1 << E2` is undefined behavior if E1 has a signed type but a negative value, but `E1 >> E2` has an implementation-defined result.
< 1739459371 147910 :int-e!~noone@int-e.eu PRIVMSG #esolangs :. o O ( you're playing with fire if you're mixing singed types with unsinged types )
< 1739459392 435306 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :so C++20 changed conversion to a smaller signed type well-defined, probably because they already started to require two's complement types, and every two's complement implementation already does this, and there's an easy but silly workaround already.
< 1739459423 498548 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: hmm, which workaround are you thinking of?
< 1739459425 419496 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Oh, right, I forgot about fungot. There was a brief internet outage at home the other day.
< 1739459447 766463 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I cam think of a few possibilities but am not 100% confident in which of them would be legal
< 1739459450 438320 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* I can
< 1739459453 332701 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :(Or technically it was "planned maintenance", though they didn't actually bother to let me know in advance.)
< 1739459463 677577 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: convert to the same sized unsigned type first. so instead of (int32_t)x write (int32_t)(uint32_t)x, and similarly for 16-bit or 8-bit
< 1739459496 580856 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :this is assuming that x is an integer type
< 1739459539 998945 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: big-unsigned-to-small-signed casts are defined even if they overflow?
< 1739459550 911674 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, wait, other way roudn
< 1739459558 71089 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you're casting to small unsigned and then to small signed
< 1739459562 238685 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yep, that works I think
< 1739459574 71191 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(assuming 2's complement)
< 1739459623 968270 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yes, x can be either signed or unsigned. it needn't be bigger, but the hard case is when it's bigger, sometimes I just want to write code that works regardless of what size long x is.
< 1739459629 250388 :fungot!~fungot@2a01:4b00:82bb:1341::a JOIN #esolangs fungot :fungot-0.1
< 1739459704 852665 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fungot: welcome back
< 1739459705 50236 :fungot!~fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :ais523: you press f7 to use it,
< 1739459764 243538 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Hmm, I do wonder what "it" was in that.
< 1739459837 548856 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs : You press F7 to use it, F6 to resotre the keybindings.
< 1739459919 495455 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Apparently some sort of ELisp module for structural editing of Scheme code (or S-expressions in general, perhaps).
< 1739459967 181347 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :also the standards say that if you convert from floating-point type to integer type then an overflow is undefined behavior. the partial workaround for that is to call the lrint or llrint functions. but that doesn't let you convert to an unsigned integer type, and doesn't let you convert to int32_t when long is 64 bits long (as in on linux x86_64)
< 1739460204 913114 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :this does come up kind of often and is annoying. another workaround is to clamp the floating point value to some range before I convert.
< 1739460334 634215 :wib_jonas80!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas
< 1739460490 635315 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu QUIT :Ping timeout: 240 seconds
< 1739460917 489625 :b_jonas!~x@88.87.242.184 QUIT :Killed (NickServ (GHOST command used by wib_jonas80!~wib_jonas@business-37-191-60-209.business.broadband.hu))
< 1739460921 996310 :wib_jonas80!~wib_jonas@business-37-191-60-209.business.broadband.hu NICK :wib_jonas
< 1739461007 44854 :craigo!~craigo@user/craigo QUIT :Quit: Leaving
< 1739461303 389998 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :hmm. lrint and llrint has the semantics that if there would be an overflow then you get a valid but implementation-defined value. this can be useful. I wonder if there's an interface to do the same in rust. rust has changed the `as` operator so that if you use it to convert from floating-point to integer it guarantees correct rounding towards zero
< 1739461303 889640 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :even on an overflow, which is nice, but it can come with a runtime penalty. x86 has the SSE2 instruction CVTPD2DQ to convert double to int64_t but it doesn't have this semantics: a positive overflow returns INT64_MIN rather than the correctly rounded INT64_MAX.
< 1739461407 224293 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :oh, and the CVTPD2DQ instruction also rounds according to the rounding mode in the XMM status word, while the rust `as` conversion rounds towards zero, so they're different even without underflow.
< 1739461571 333307 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :this will be partly solved in future x86 by AVX512 providing a higher variety of floating point to integer conversion instructions.
< 1739461585 137558 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but apparently floating point to integer conversion is still a partly unsolved problem.
< 1739461738 679590 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :TIL (I think I knew this, but had forgotten): while `ls -l` lists the logical file sizes, `ls -sh` lists the size required on disk, which may be quite different (with holes, but also with ZFS datasets with compression enabled).
< 1739461741 670155 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Got a little confused by this file that was alternatingly showing up as 743243776 and "407M".
< 1739461788 410094 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yes, and du -a also lists the size required on disk (or at least what the file system driver lies about it, I think for modern file systems the size required on disk isn't really well-defined)
< 1739461953 621944 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : a positive overflow returns INT64_MIN rather than the correctly rounded INT64_MAX ← does a negative overflow do that too? if so, it almost looks like it's using the "INT_MIN Is a sentinel value and not part of the integer range" convention
< 1739462012 127674 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yes, it uses INT_MIN to indicate overflow in either direction
< 1739462041 481525 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm reminded of a (separate) discussion about float-to-smaller-float conversions, talking about whether the rounding mode should affect whether an out-of-range finite value rounds to the largest finite value or +inf
< 1739462229 499193 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :slightly related but more obscure is https://www.exploringbinary.com/numbers-greater-than-dbl-max-should-convert-to-dbl-max-when-rounding-toward-zero/ about scanning a decimal string to floating-point and how it handles an overflow
< 1739462263 523815 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :maybe that's what I was thinking of
< 1739462324 485594 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :the other way you can get wrong results for overflow faster is when you want to convert from double to 32-bit int but the CPU only has instructions to convert double to 64-bit int, so you just use that and then truncate the integer.
< 1739462343 154350 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I think that's still the case in AVX512 but I'm not entirely sure
< 1739462388 608312 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I also don't understand how you're supposed to convert from float to int64_t on x86. do you have to upgrade to double?
> 1739462620 817964 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=151867&oldid=151836 5* 03H33T33 5* (+154) 10/* Introductions */
< 1739462666 130159 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :hold on!
< 1739462683 153635 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :is there an easy way to print a float as a hexfloat in Perl?
< 1739462697 552603 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I could probably figure out a difficult way involving multiple calls to pack and unpack
< 1739462720 110415 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I was wrong above. so the SSE2 instruction CVTPD2DQ actually gives not INT_MIN but -1 on an onverflow.
< 1739462731 984880 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :overflow
< 1739462755 820335 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :-1 isn't a very sensible overflow result unless it is outputting unsigned integers
< 1739462853 952964 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the docs do say that the result is all-bits-1 if a floating-point invalid exception is raised and masked, though
< 1739462859 777295 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and the AVX512 floating point to integer instructions also all give -1 on overflow in any direction if I am reading the intel manual right
< 1739462870 239842 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you do have CVTPS2SQ for converting single-precision floats, though
< 1739462893 739902 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: for floats, -1 or all-bits-1? those are different for floats I think
< 1739462915 853527 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I'm talking about floating point to integer conversion, you get an integer -1
< 1739462965 479561 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah, you said "in any direction" but you were talking about positive vs. negative overflow, not float-to-int vs. int-to-float
< 1739462997 258021 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and I think I'm fine with this, because I think most of the time when I want a floating point to integer conversion I'm okay with an implementation-defined result (but not an UB) for overflow. if I want a well-defined result then I'm probably going to clamp the floating-point to some specific range that is usually smaller than the size of the
< 1739462997 757273 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :integer type that I'm using
< 1739463005 867698 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yes, sorry, it's overflow with any sign
< 1739463046 655386 :wib_jonas29!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas
< 1739463052 779356 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there's also CVTTPD2DQ which appears to be the same instruction with more sensible overflow behaviour?
< 1739463064 993577 :wib_jonas29!~wib_jonas@business-37-191-60-209.business.broadband.hu NICK :b_jonas
< 1739463133 512899 :b_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: not as far as I understand.
< 1739463186 10200 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, the differences are a) overflow behaviour, b) CVTT is always round-to-zero and ignores the floating-point status word
< 1739463246 108670 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I am wondering if CVTPD2DQ's overflow behaviour is a typo that ended up getting implemented, it says 2w-1 but that may have originally been a typo for 2w-1
< 1739463252 123075 :b_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :as I see, there's a full set CVT{T,}PD2{DQ,UDQ,QQ,UQQ} to convert double to any of those four integer types, and they all give integer -1 result on an overflow. CVT{T,}PD2DQ is old, it's from SSE2, while the other six are from AVX512 but they form a consistent full set. the extra T means that it ignores the rounding mode from the status bit and
< 1739463252 655152 :b_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :always rounds towards zero, but that's only when there's no overflow
< 1739463280 663729 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu QUIT :Ping timeout: 240 seconds
< 1739463293 33967 :b_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu NICK :wib_jonas
< 1739463300 497609 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :oops
< 1739463306 688421 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I'm not supposed to be b_jonas from this connection
< 1739463312 467109 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned.
< 1739463371 604130 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :CVTPD2DQ also specifies its error return value as "the indefinite integer value", but defines it as 2w-1
< 1739463381 226577 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :what the
< 1739463384 156614 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which would be a weird use of "the" if they're both intentional
< 1739463406 5968 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :so out of the eight instructions that convert from double to some integer type, *one* gives a different result on overflow?
< 1739463445 717695 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :CVTTPD2DQ also uses the 0x80000000 return
< 1739463456 662181 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in addition to CVTTPS2DQ
< 1739463484 17571 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yes, I said the eight instructions that convert from double, so I didn't look at CVTTPS2DQ
< 1739463490 386551 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah, right
< 1739463493 976451 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :eight conversions from double was already enough to look up in the manual
< 1739463497 259523 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the others are documented as 2w-1
< 1739463513 149226 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I do care about the float to integer conversions too but I can't turn the virtual pages of the manual fast enough
< 1739463521 786748 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think it's probably worth trying these out on an actual processor (but I don't have one that runs AVX-512)
< 1739463554 526831 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's a little nontrivial to run arbitrary asm and print the result, maybe a C wrapper would be easiest
> 1739463578 992672 PRIVMSG #esolangs :14[[07User:PrySigneToFry/Sandbox/Users that is also on other place14]]4 10 02https://esolangs.org/w/index.php?diff=151868&oldid=151851 5* 03Ractangle 5* (+18) 10
< 1739463601 887255 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :anyway, to me, the only logical explanation is that the documentation is a typo for 2w-1 but I don't know whether the typoed version got implemented or not
< 1739463612 158714 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :gcc and clang might know anyway, don't they compile intrinsics for future AVX512 code into equivalent (but possibly slow) code that works on the older target CPU?
> 1739463789 923052 PRIVMSG #esolangs :14[[07User:PrySigneToFry/Sandbox/Users that is also on other place14]]4 10 02https://esolangs.org/w/index.php?diff=151869&oldid=151868 5* 03Ractangle 5* (+54) 10
< 1739463790 926955 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :if gcc/clang doesn't know then the other place to look at is in an AMD manual
< 1739463836 862991 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :in theory qemu should know too but I know it has bugs about modern x86 floating-point operations so I don't trust it
> 1739463964 164283 PRIVMSG #esolangs :14[[07User:PrySigneToFry/Sandbox/Users that is also on other place14]]4 10 02https://esolangs.org/w/index.php?diff=151870&oldid=151869 5* 03Ractangle 5* (+26) 10
< 1739463975 485600 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: cvtpd2dq returns INT_MIN on overflow (despite the documentation), I just tested
< 1739463991 548551 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :did you test with both signs?
< 1739464035 551440 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :no, give me a moment
< 1739464055 183919 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :OK, tested with both signs, INT_MIN in both cases
> 1739464055 751242 PRIVMSG #esolangs :14[[07User:PrySigneToFry/Sandbox/Users that is also on other place14]]4 10 02https://esolangs.org/w/index.php?diff=151871&oldid=151870 5* 03Ractangle 5* (+0) 10
< 1739464063 463656 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I would have been surprised if they were different
< 1739464073 629442 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think the documentation is just typoed
< 1739464093 367266 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :hmm, we should download the latest update to the manual first
< 1739464108 245123 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I'm looking at one from 2023-12
< 1739464128 593376 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :webpage is https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html
< 1739464184 277718 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :something else is bothering me a lot – the conversion produces 32-bit numbers, so why does the name end in DQ?
< 1739464213 870017 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess it's D for 32-bit and the Q means something else?
< 1739464241 155309 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :huh... good question
> 1739464255 833578 PRIVMSG #esolangs :14[[07Topple14]]4 N10 02https://esolangs.org/w/index.php?oldid=151872 5* 03H33T33 5* (+3681) 10Created page with "Topple is developed in C. The entire language is made up of single characters.  Topple (conditionally) ignores whitespace, which means you can cram everything into one line. Good luck with that though. ==Overview==  {| class="wikitable" !Command !Description !Example !Out
< 1739464264 513989 :Lykaina!~lykaina@user/lykaina JOIN #esolangs Lykaina :Lykaina Wolfe
< 1739464357 758730 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :i just thought up a funge/forth hybrid with 8836 possible commands
< 1739464376 837438 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :need to learn forth first though
< 1739464381 569056 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I was impressed with gcc allowing me to take an integer from an xmm register, anyway
< 1739464409 178813 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm testing using this (+ a stdio.h include): int main(void) { double d=-1e10; unsigned long long i; asm("cvtpd2dq %1, %0" : "=x" (i) : "x" (d)); printf("%llu\n", i); }
< 1739464485 41252 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :https://github.com/memesmith0/mcr4
< 1739464508 148182 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Lykaina: I have a suspicion that esolang ideas that require learning Forth first are likely to be interesting
< 1739464561 993912 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :I meant I need to learn Forth
< 1739464610 633953 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and the other weird part is that the double to int32_t conversion instructions are lane-crossing, they convert four doubles in a YMM register to four int32_t in the bottom half of a YMM register, or eight doubles in a ZMM register to eight int32_t in the bottom half of a ZMM register. x86 usually tries to avoid that.
< 1739464629 370934 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :OK, that is weird
< 1739464654 346726 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :8836 = 94^2
< 1739464662 338795 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :having some lane-crossing instructions is useful, but they are slower so it generally makes sense to only lane-cross when explicitly requested to
< 1739464664 170161 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :it's possible that I'm reading the ZMM case wrong, the description is confusing, so don't trust me
< 1739464735 329461 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and I haven't checked all the tons of instructions -- apparently all combinations of {float16, float, double} to {int32, uint32, int64, uint64} with {current rounding mode, truncated} exist, plus AVX512 adds its stupid extra tricks over that
< 1739464842 160351 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :"allowing me to take an integer from an xmm register" => SSE2 is actually designed to try to make that easy and I like that
< 1739464935 891051 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm not surprised that the processor allows it (I knew it did), but i was surprised that gcc inserted the conversion for me
< 1739464996 32387 :Celeo!~Celeo@user/celeo JOIN #esolangs Celeo :Celeo
< 1739465011 59942 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :i can't believe raspberry pi thinks they will be making the 32-bit rp2350 in 2045. nothing 32-bit will survive 2038
< 1739465039 244819 :Celeo!~Celeo@user/celeo QUIT :Client Quit
< 1739465054 39911 :Celeo!~Celeo@user/celeo JOIN #esolangs Celeo :Celeo
< 1739465075 740204 :Celeo!~Celeo@user/celeo QUIT :Client Quit
< 1739465094 31527 :Celeo!~Celeo@user/celeo JOIN #esolangs Celeo :Celeo
< 1739465112 228464 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Lykaina: you can (and should) use 64-bit time_t on 32-bit systems
< 1739465128 758024 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :point taken
< 1739465133 101787 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I don't know whether that's the default yet, but it really should be
< 1739465220 309675 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :so many programming languages will have to have their time libraries changed from outputting a long to outputting a long long
< 1739465337 715825 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :if they haven't done so already
< 1739465418 899762 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :brb
< 1739465445 899907 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :glibc has a _TIME_BITS define that controls the size of time_t
< 1739465539 805488 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :back
> 1739465632 913830 PRIVMSG #esolangs :14[[07Topple14]]4 10 02https://esolangs.org/w/index.php?diff=151873&oldid=151872 5* 03H33T33 5* (-54) 10Topple Esolang Info
> 1739465776 36779 PRIVMSG #esolangs :14[[07Scoop14]]4 10 02https://esolangs.org/w/index.php?diff=151874&oldid=96633 5* 03Anthonykozar 5* (-2) 10Remove the header before the introduction plus some light editing for readability.
< 1739465786 946909 :int-e!~noone@int-e.eu PRIVMSG #esolangs :hmm no avx512 here to test
< 1739465789 783171 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :64-bit time_t is the default for newer distributions, but I think the kernel and libc folks had to do the transition without having to recompile every program and library immediately
< 1739465942 45399 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :i built a router
< 1739465994 705503 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :out of an N100 w/ 16 GiB ram and OpenWRT's x86-64 build
< 1739466017 452998 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :got sick of replacing them
< 1739466031 937749 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :it's kind of a similar problem to what largefiles (64-bit file offsets for seeking and 64-bit file sizes for statting) used to be
< 1739466359 971615 :int-e!~noone@int-e.eu PRIVMSG #esolangs :But I can conclude that the documentation of CVTSS2SI with a 64 bit target is wrong.
< 1739466362 977662 :int-e!~noone@int-e.eu PRIVMSG #esolangs :
ACTION shrugs

< 1739466385 760144 :int-e!~noone@int-e.eu PRIVMSG #esolangs :These instruction sets are such a mess.
< 1739466517 444358 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :int-e: isn't CVTSS2SI an mmx-only instruction and so almost obsolete now?
< 1739466574 750271 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I'm more interested about the SSE2/AVX512 instructions like CVT{,T}{PS,PD}2{DQ,UDQ,QQ,UQQ}
> 1739466928 537010 PRIVMSG #esolangs :14[[07User:PrySigneToFry/Sandbox/Users that is also on other place14]]4 10 02https://esolangs.org/w/index.php?diff=151875&oldid=151871 5* 03Ractangle 5* (+19) 10
< 1739466946 600634 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I'm almost happy to let MMX die, and I think its only remaining applications are esoteric only
< 1739467251 380485 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Debian had a big "t64 transition" to move to 64-bit `time_t` on 32-bit platforms last year.
< 1739467329 411886 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :It generated a lot of noise also on 64-bit platforms because of some quirk of Debian package management, something around library sonames having to be identical across ports and needing them to change on the 32-bit ones to enable a more gradual migration.
< 1739467372 443316 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :https://wiki.debian.org/ReleaseGoals/64bit-time has some details in case anyone's curious.
< 1739467448 134208 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Oh, they didn't actually do it for i386 (on the basis that it exists mostly to run old 32-bit binaries, and that wouldn't really work if they made a big ABI change like that).
< 1739467540 414400 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :fizzie: really? I assumed they did it for x86_32 but in a way where macros or other magic dispatch everything to either 32-bit or 64-bit time depending on some compile-time options
< 1739467548 325421 :int-e!~noone@int-e.eu PRIVMSG #esolangs :wib_jonas: It's the only instruction with a 64 bit target that I have :P CVTPS2DQ also uses 0x80...00
< 1739467557 799575 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but x86_64 at least had 64-bit time_t from the start, right?
< 1739467680 241392 :int-e!~noone@int-e.eu PRIVMSG #esolangs :and VCVTPS2DQ is the same too
< 1739467701 455839 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(tbh it would be insane to change that between sse2 and avx)
< 1739467704 22359 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Yes, x86-64 (or amd64 as Debian calls it) was 64-bit from the start.
< 1739467736 403937 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :As for i386, what they say is: "The i386 port will be left with the existing 32-bit time_t, as a compatibility architecture for existing x86 binaries. A new 'i686' x86 ABI/architecture using 64-bit time, and potentially newer ISA features, could be created if there was sufficient enthusiasm for dragging 32-bit x86 into its now very limited future."
< 1739467742 716105 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :(And also: "i386 is 32-bit but has been excluded from the 64-bit time_t transition because its major purpose this decade is running legacy 32-bit binaries, a purpose that would no longer be possible if it broke ABI"0
< 1739467770 116681 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I'm kind of expecting that by the time time_t overflows 31 bits there won't be any x86_32 systems around, but there will still be file system formats and other binary formats that have 32-bit time_t type fields, or other representations of time that will overflow. In particular FAT has a time that will overflow several decades after this problem,
< 1739467770 592310 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but I'm not sure when FAT will ever be gone, because all the cameras and mobile phones and cash registers etc still use FAT, but then that rollover is far enough in the future that it might not matter by that time.
< 1739467791 426889 :int-e!~noone@int-e.eu PRIVMSG #esolangs :wib_jonas: basically all the rest you're asking abouyt are avx512 so not available to me :P
< 1739467812 822508 :int-e!~noone@int-e.eu PRIVMSG #esolangs :wib_jonas: I imagine the U version actually use 2^w - 1.
< 1739467822 257045 :int-e!~noone@int-e.eu PRIVMSG #esolangs :rather than 2^(w-1)
< 1739467834 688878 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I may try to look at that floating point to integer thing later, I can't at the moment
< 1739467901 302234 :int-e!~noone@int-e.eu PRIVMSG #esolangs :and meh I hate piecing together compiler intrinsics for these things
< 1739467906 102062 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(it's so slow)
< 1739467923 313294 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :we'll be able to find someone on the internet who has a new enough intel CPU
< 1739468008 40247 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: I'm not sure it's just "new enough", IIRC Intel aren't putting AVX-512 into even most of their new CPUs
> 1739468134 746392 PRIVMSG #esolangs :14[[07User:Anthonykozar/Sandbox14]]4 N10 02https://esolangs.org/w/index.php?oldid=151876 5* 03Anthonykozar 5* (+145) 10Testing for Markdown support
< 1739468259 34867 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I think it's divided to three tiers, and some of these instructions, namely those that use YMM registers rather than ZMM, are available in the lowest tier, and new enough CPUs support those. Perhaps even more, just not at the full speed, in that the instructions with ZMM instructions work but you can't get the full speedup that you'd expect from a
< 1739468259 535927 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :CPU that's designed with 512-bit vectors from the start.
< 1739468270 367151 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I mean AVX512 is divided into three tiers
< 1739468417 452406 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but first I'll want to double-check the latest version of the intel manual, and look at whether there's an AMD manual that talks about this
< 1739468444 527776 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :obviously there must be for the SSE2 instructions at least
< 1739468550 947323 :int-e!~noone@int-e.eu PRIVMSG #esolangs :wib_jonas: https://int-e.eu/~bf3/tmp/avx512%3f.png -- it's even more complicated, see the footnote
< 1739468607 638362 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(fairly recent SDM, I downloaded it in December)
< 1739468972 257798 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :int-e: yeah, it's complicated and the CPU architecture manual has to support the worst most complicated cases too, but I don't think that's a problem for such a test
< 1739469008 269237 :int-e!~noone@int-e.eu PRIVMSG #esolangs :sure. this was about the three tiers
< 1739469061 562757 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yeah
< 1739469153 804851 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :"I hate piecing together compiler intrinsics for these things" => you could use inline assembly
< 1739469367 310036 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu QUIT :Quit: Client closed
< 1739470779 621126 :chomwitt_alt!~alex@2a02:587:7a13:5400:42b0:76ff:fe46:a5fd JOIN #esolangs chomwitt :realname
< 1739471264 980679 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1739472118 503343 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 252 seconds
< 1739472120 484164 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord
< 1739472206 236823 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 NICK :Lord_of_Life
< 1739472315 197274 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User
< 1739472903 820372 :ais523!~ais523@user/ais523 QUIT :Quit: quit
< 1739473660 64101 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :I gotta talk about mcr4
< 1739473728 17069 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Go for it. I'd be interested in understanding the bigger picture.
< 1739474119 793723 :b_jonas!~x@88.87.242.184 JOIN #esolangs b_jonas :b_jonas
< 1739475583 467737 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname
< 1739477744 700420 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :mcr4 is a very lightweight reader macro system that lets you change the notation of languages like c# while the language is runnign live on the machine
< 1739477774 474128 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :it was designed  so that I could extend the notation of bash
< 1739477786 127213 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :I spent 12 years researching to develop it
< 1739478164 15582 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :mcr4 is based in posix compliant sh and awk so it runs on almost any machine out in the wild even routers with read only file systems and even in some bioses
< 1739478192 129367 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :it is similar to the idea of a very lightweight very portable version of gnu m4 only it has features that m4 seemingly does not
< 1739478258 184705 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :Is there a document?
< 1739478291 287348 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :no but I can answer questions about it
< 1739478308 458587 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :I have alot of experience tutoring in code I was a c++ tutor at everett community college
< 1739478326 530924 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :i teach people to code for fun
< 1739478339 876444 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :https://github.com/memesmith0/mcr4/blob/main/README.md
< 1739478401 182558 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :very very smol system
< 1739478403 620946 :chomwitt_alt!~alex@2a02:587:7a13:5400:42b0:76ff:fe46:a5fd QUIT :Ping timeout: 244 seconds
< 1739478432 913556 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :theres also this bad boy https://github.com/memesmith0/mcr
< 1739478474 895207 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :mcr is alot easier to grok than mcr4 but it isnt as performant or safe
< 1739478828 653719 :Lykaina!~lykaina@user/lykaina QUIT :Quit: Leaving
< 1739478882 655062 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :what the first mcr does is put a line of awk between you and the terminal so that every line you type into the terminal passes through a line of awk before the terminal executes it
< 1739478914 455127 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :you can call mcr multiple times to cause your input to pass through awk multiple times. thus you can transform how the interpreter interprets things while ti is running
< 1739479095 304315 :int-e!~noone@int-e.eu PRIVMSG #esolangs :12 years of research and not a single example
< 1739479097 467642 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :lisbeths: you should probably write something about this on the esolangs wiki
< 1739479115 659542 :int-e!~noone@int-e.eu PRIVMSG #esolangs :but 4 versions in 2 days
< 1739479130 513985 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :if I write something I can give you license to use my text on the wiki
< 1739479145 807649 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :sure, that can work too
< 1739479154 520738 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :ive been codding all day every day for 4 weeks
< 1739479164 257347 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :i havent showered or shaved or changed my clothes
< 1739479177 832589 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :i havent slept in 2 days
< 1739479187 979953 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that sounds like a bad idea
< 1739479228 700191 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :eh i am just focused on getting fastlisp done
< 1739479239 548382 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :it has thrown a wrench in my plants because I didnt expect to implement mcr
< 1739479242 473735 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :sorry? what is fastlisp
< 1739479250 306745 :int-e!~noone@int-e.eu PRIVMSG #esolangs :those poor plants
< 1739479255 537112 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :fastlisp is a lisp written in pure lambda calculus
< 1739479265 247412 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :it only consits of lambdas, strings, and comments
< 1739479277 49415 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :the specification fits into a qr code
< 1739479283 432379 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :the interpreter fits into the boot sector of a floppy disc
< 1739479285 362232 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :are there variables?
< 1739479296 196700 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :no there are only constants. but there is a way to simulate variables
< 1739479318 485878 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that sounds like https://esolangs.org/wiki/Sectorlisp
< 1739479337 702684 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :its based on sectorlisp and is designed to be fully compatible with sectorlisp
< 1739479343 333564 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :it compiles to sectorlambda
< 1739479345 562849 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :wait, how do the lambda expressions work if there are no variables? that doesn't sound like lambda calculus
< 1739479363 77743 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :lambdas dont have variabesl they have constants
< 1739479399 220811 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :i guess you could think of them like variables
< 1739479407 164949 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :wait, so you do have variables that the lambdas abstract over, and functions that are closed over upvalues, you're just using strange terminology for them?
< 1739479413 422469 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that sounds more reasonable
< 1739479414 708127 :int-e!~noone@int-e.eu PRIVMSG #esolangs :nah, the standard terminology is that lambda terms have variables; they can be bound or unbound; closed lambda terms only have bound variables
< 1739479436 156426 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but I'm still confused about the "only consits of lambdas, strings, and comments"
< 1739479449 326192 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :yeah so
< 1739479455 812545 :int-e!~noone@int-e.eu PRIVMSG #esolangs :this comes from mathematics where variables aren't mutable
< 1739479473 209073 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :there is a sectorlisp-like way to code with lambdas where it works alot like scheme
< 1739479479 313275 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :its hard to describe in irc
< 1739479488 95095 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I mean you could have a language that the value of an expression can only be a function or a string, but then how do comments come up?
< 1739479562 867358 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :in fastlisp version 5 comments are just lines that begin with #
< 1739479571 142530 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :are there any birds involved?
< 1739479585 822176 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :yeah I have the iota combinator tattoed on my arm
< 1739479656 949350 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :fastlisp isnt really ready to show whereas mcr and mcr4 are working 2day
< 1739479671 849146 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :I can show you some fastlisp sources
< 1739479676 285624 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :``` welcome lisbeths # wow we really are magnets for strange people here
< 1739479678 781058 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :lisbeths: Welcome to the international hub for esoteric programming language design and deployment! For more information, check out our wiki: . (For the other kind of esoterica, try #esoteric on EFnet or DALnet.)
< 1739479704 983603 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :https://github.com/memesmith0/fastlisp/blob/main/celestial/holy9.fastlisp
< 1739479743 56245 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :fastlisp code fits into one of four categories; subterranian, terrestrial, telestial, and celestial
< 1739479785 817733 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :the entire haskell compiler should be dumpable directly into fastlisp
< 1739479827 934173 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :fastlisp has some of the smallest compiled file sizes in the world, so its kind of good as like an embedded haskell although thats not what its for
< 1739480288 744760 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :i would sho u my website which has some very homeschooled code but it is problematic
< 1739480552 727888 :lisbeths!uid135845@id-135845.lymington.irccloud.com PRIVMSG #esolangs :eh I guess i dont care view-source:https://podlife.neocities.org/
< 1739481112 961695 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :Is a remote proxy server available for connecting to TLS 1.3 from clients that do not support TLS?
< 1739481829 625111 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :int-e: Tangent: English doesn't have a good way to express the idea that an idea might have been slowly developing over the course of a long time, in small increments, without constant effort, I think.
< 1739481873 598618 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :...Wait, I was going to phrase that as a question. But I don't remember how I was going to ask it.
< 1739481915 1586 :Celeo!~Celeo@user/celeo QUIT :Ping timeout: 260 seconds
< 1739482021 814427 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :zzo38: Like stunnel? Or the other direction?
< 1739482220 864948 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :korvo: I don't know what direction you mean. What I mean is that a remote computer might accept a unencrypted connection and then communicate with another remote computer securely, that requires TLS 1.3 (or other versions of TLS, or if they require older versions of SSL), even if the client does not support it.
< 1739482289 277981 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Ah, I don't know of any public proxies like that.
< 1739483240 601861 :JAA!~JAA@user/meow/JAA PRIVMSG #esolangs :IIRC, some HTTP proxy softwares support remote GET requests like 'GET https://example.org/ HTTP/1.1'. I haven't seen raw TLS though.
> 1739484032 36699 PRIVMSG #esolangs :14[[07User:PrySigneToFry/Sandbox/Users that is also on other place14]]4 10 02https://esolangs.org/w/index.php?diff=151877&oldid=151875 5* 03Aadenboy 5* (+130) 10add various places
> 1739484402 748379 PRIVMSG #esolangs :14[[07User:Buckets14]]4 M10 02https://esolangs.org/w/index.php?diff=151878&oldid=151825 5* 03Buckets 5* (+10) 10
> 1739484412 236675 PRIVMSG #esolangs :14[[07Language list14]]4 M10 02https://esolangs.org/w/index.php?diff=151879&oldid=151843 5* 03Buckets 5* (+11) 10
> 1739484429 327003 PRIVMSG #esolangs :14[[07!@a*14]]4 N10 02https://esolangs.org/w/index.php?oldid=151880 5* 03Buckets 5* (+1073) 10Created page with "!@a* (Pronounced Bang-at-a-star) is an Esoteric programming language created by [[User:Buckets]] in 2020 about shooting stars with guns. (Extinguished Stars = 0.) {| class="wikitable" |- ! Commands !! Instructions |- | ^ || Moves up the pointer of the list of Every single 
> 1739484581 64735 PRIVMSG #esolangs :14[[07User talk:PrySigneToFry/Sandbox/Users that is also on other place14]]4 N10 02https://esolangs.org/w/index.php?oldid=151881 5* 03Ractangle 5* (+199) 10Created page with "THERE IS A LITERAL BEEPBOX WIKI?~~~"
> 1739484680 650893 PRIVMSG #esolangs :14[[07User talk:PrySigneToFry/Sandbox/Users that is also on other place14]]4 10 02https://esolangs.org/w/index.php?diff=151882&oldid=151881 5* 03Aadenboy 5* (+338) 10yep!
> 1739485340 914222 PRIVMSG #esolangs :14[[07User:PrySigneToFry/Sandbox/Users that is also on other place14]]4 M10 02https://esolangs.org/w/index.php?diff=151883&oldid=151877 5* 03Aadenboy 5* (-42) 10might as well remove those if I don't use them
> 1739485841 843248 PRIVMSG #esolangs :14[[07Topple14]]4 M10 02https://esolangs.org/w/index.php?diff=151884&oldid=151873 5* 03H33T33 5* (+0) 10
> 1739486821 611490 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Hotcrystal0 5*  10New user account
< 1739486953 45180 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
> 1739487013 20211 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=151885&oldid=151867 5* 03Hotcrystal0 5* (+285) 10
> 1739487045 879133 PRIVMSG #esolangs :14[[07User:Hotcrystal014]]4 N10 02https://esolangs.org/w/index.php?oldid=151886 5* 03Hotcrystal0 5* (+225) 10Created page with "I'm User:Hotcrystal0. I have lurked the wiki without an account for some time, and several people I know from [https://conwaylife.com/forums/index.php the CGoL forums] are here. I want to create and add esolangs to this wiki."
> 1739487121 970485 PRIVMSG #esolangs :14[[07UserEdited14]]4 10 02https://esolangs.org/w/index.php?diff=151887&oldid=151835 5* 03Hotcrystal0 5* (-40) 10I have an account now.
> 1739487163 307686 PRIVMSG #esolangs :14[[07UserEdited14]]4 10 02https://esolangs.org/w/index.php?diff=151888&oldid=151887 5* 03Hotcrystal0 5* (+2) 10
> 1739487262 882713 PRIVMSG #esolangs :14[[07Anti-Plushie language14]]4 10 02https://esolangs.org/w/index.php?diff=151889&oldid=150738 5* 03Hotcrystal0 5* (+34) 10Adding a missing category
< 1739487381 899864 :Celeo!~Celeo@user/celeo JOIN #esolangs Celeo :Celeo
< 1739487582 26735 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
> 1739488303 64095 PRIVMSG #esolangs :14[[07UserEdited14]]4 10 02https://esolangs.org/w/index.php?diff=151890&oldid=151888 5* 03Hotcrystal0 5* (+569) 10Added more commands
> 1739490256 782923 PRIVMSG #esolangs :14[[07UserEdited14]]4 10 02https://esolangs.org/w/index.php?diff=151891&oldid=151890 5* 03Hotcrystal0 5* (-2) 10
> 1739490569 592680 PRIVMSG #esolangs :14[[07UserEdited14]]4 10 02https://esolangs.org/w/index.php?diff=151892&oldid=151891 5* 03Hotcrystal0 5* (+475) 10
> 1739491048 553225 PRIVMSG #esolangs :14[[07UserEdited14]]4 10 02https://esolangs.org/w/index.php?diff=151893&oldid=151892 5* 03Hotcrystal0 5* (+126) 10
> 1739491072 455206 PRIVMSG #esolangs :14[[07UserEdited14]]4 10 02https://esolangs.org/w/index.php?diff=151894&oldid=151893 5* 03Hotcrystal0 5* (-6) 10
< 1739491083 462469 :Celeo!~Celeo@user/celeo PART :#esolangs