00:04:47 -!- Celeo has quit (Quit: Celeo).
00:13:38 -!- Noisytoot has quit (Quit: ZNC 1.9.1 - https://znc.in).
00:14:39 -!- Noisytoot has joined.
00:19:35 <esolangs> [[Special:Log/newusers]] create * Luihum * New user account
00:24:11 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=151831&oldid=151800 * Luihum * (+176) introduction
00:43:22 <zzo38> On GitHub, why is payload.preloadedQueries[0].result.data.repository.search.pageInfo.hasNextPage is always true and hasPreviousPage is always false, regardless of the page number?
00:57:22 -!- amby has quit (Remote host closed the connection).
01:19:59 <esolangs> [[TMIDL]] N https://esolangs.org/w/index.php?oldid=151832 * Luihum * (+1531) created the page, with infobox and interpreter directive list
01:23:41 -!- ais523 has quit (Quit: quit).
03:29:49 <esolangs> [[TMIDL]] https://esolangs.org/w/index.php?diff=151833&oldid=151832 * Luihum * (+604) added more stuff about extensions
04:14:40 <esolangs> [[UserEdited]] https://esolangs.org/w/index.php?diff=151834&oldid=150935 * I am islptng * (+607) /* Commands */
04:17:22 <esolangs> [[UserEdited]] https://esolangs.org/w/index.php?diff=151835&oldid=151834 * I am islptng * (+239)
04:29:32 <esolangs> [[Special:Log/newusers]] create * Yunasha Hotora * New user account
04:56:52 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=151836&oldid=151831 * Yunasha Hotora * (+217) /* Introductions */
05:16:25 -!- Celeo has joined.
05:17:21 -!- Celeo has quit (Client Quit).
05:17:52 -!- Celeo has joined.
05:42:39 <esolangs> [[Translated ZhongWen/PSTF Again Chapter VIII]] https://esolangs.org/w/index.php?diff=151837&oldid=151797 * MihaiEso * (+56)
05:42:58 <esolangs> [[Translated ZhongWen/PSTF Again Chapter VIII]] https://esolangs.org/w/index.php?diff=151838&oldid=151837 * MihaiEso * (+0)
05:50:30 <esolangs> [[Translated ZhongWen/Mihai Again Chapter IX]] N https://esolangs.org/w/index.php?oldid=151839 * MihaiEso * (+6376) Created page with "1. Put this: [[Translated ZhongWen/PSTF Again Chapter VIII|]] in the machine <pre> ..."
05:50:55 <esolangs> [[Translated ZhongWen/Mihai Again Chapter IX]] https://esolangs.org/w/index.php?diff=151840&oldid=151839 * MihaiEso * (+17)
05:54:26 -!- Celeo has quit (Quit: Celeo).
06:04:43 -!- Celeo has joined.
06:15:06 <esolangs> [[Translated ZhongWen/Mihai Again Chapter IX]] https://esolangs.org/w/index.php?diff=151841&oldid=151840 * I am islptng * (-33) Translation
06:15:24 <esolangs> [[Nya~*kwrgsfish+-HQ9`:'"rbtAzxdi8]] N https://esolangs.org/w/index.php?oldid=151842 * PrySigneToFry * (+3038) Created 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
06:16:32 <esolangs> [[Language list]] https://esolangs.org/w/index.php?diff=151843&oldid=151821 * PrySigneToFry * (+62)
06:47:34 <b_jonas> 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.
06:48:20 <korvo> b_jonas: That's very close to a real example for me!
06:48:23 <b_jonas> 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
06:48:58 <b_jonas> you write "long" and windows will use a 32-bit integer while linux will use a 64-bit integer
06:49:12 <korvo> 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.
06:50:06 <korvo> 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.
06:50:30 <korvo> ...RPython also has its own idea of "long". They support Win32, you see.
06:52:11 <b_jonas> 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
06:54:13 <b_jonas> 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
06:56:09 <b_jonas> 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)
06:56:49 <b_jonas> I mean there is, but it would require relaxing the C++-only rules a lot too
06:57:57 <b_jonas> 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
06:58:10 <b_jonas> I was wondering about this recently
07:02:09 <korvo> That's actually a really nasty example, because IIRC Rust and C have different ideas of what an "enum" looks like.
07:26:43 <b_jonas> 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.
07:30:40 <korvo> b_jonas: Sure. All types are ctypes, etc.
07:30:48 <korvo> ...Sorry. I'm not sour at you. I'm sour at C.
07:40:56 -!- tromp has joined.
07:47:33 <lisbeths> https://github.com/memesmith0/mcr3sh
07:50:02 <korvo> Lovely art, thanks.
07:54:41 <esolangs> [[Translated ZhongWen/PSTF Again Chapter IX]] N https://esolangs.org/w/index.php?oldid=151844 * PrySigneToFry * (+6285) Created page with "Translated ZhongWen/Mihai Again Chapter IX|<span style='font-family:Unifont;'>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$(
07:55:19 <esolangs> [[Translated ZhongWen/Mihai Again Chapter IX]] https://esolangs.org/w/index.php?diff=151845&oldid=151841 * PrySigneToFry * (+49)
07:58:10 -!- Celeo has quit (Quit: Celeo).
08:25:06 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
08:32:06 <esolangs> [[User:PrySigneToFry/Sandbox/Users that is also on other place]] N https://esolangs.org/w/index.php?oldid=151846 * PrySigneToFry * (+1314) Created 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
08:40:18 <esolangs> [[User:PrySigneToFry/Sandbox]] https://esolangs.org/w/index.php?diff=151847&oldid=151461 * PrySigneToFry * (+330)
08:42:07 -!- Sgeo has quit (Read error: Connection reset by peer).
08:55:31 <esolangs> [[Translated ZhongWen/PSTF Again Chapter IX]] https://esolangs.org/w/index.php?diff=151848&oldid=151844 * MihaiEso * (+46)
09:00:12 <esolangs> [[Translated ZhongWen/Mihai Again Chapter X]] N https://esolangs.org/w/index.php?oldid=151849 * MihaiEso * (+5510) Created page with "Translated ZhongWen/Mihai Again Chapter IX|<span style='font-family:Unifont;'>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$$
09:01:05 <esolangs> [[Translated ZhongWen/Mihai Again Chapter X]] https://esolangs.org/w/index.php?diff=151850&oldid=151849 * MihaiEso * (-1)
09:03:29 <esolangs> [[User:PrySigneToFry/Sandbox/Users that is also on other place]] https://esolangs.org/w/index.php?diff=151851&oldid=151846 * I am islptng * (+33)
09:15:45 <esolangs> [[Translated ZhongWen/islptng Zwei]] N https://esolangs.org/w/index.php?oldid=151852 * I am islptng * (+5412) Created page with "Translated ZhongWen/PSTF Again Chapter IX|<span style='font-family:Unifont;'>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$$(..."
09:16:41 <esolangs> [[Translated ZhongWen/islptng Zwei]] https://esolangs.org/w/index.php?diff=151853&oldid=151852 * I am islptng * (-4)
09:17:36 <esolangs> [[Translated ZhongWen/islptng Zwei]] https://esolangs.org/w/index.php?diff=151854&oldid=151853 * I am islptng * (-18)
09:18:49 <esolangs> [[Translated ZhongWen/Mihai Again Chapter X]] https://esolangs.org/w/index.php?diff=151855&oldid=151850 * I am islptng * (+97)
10:31:40 <esolangs> [[Translated ZhongWen/islptng Zwei]] https://esolangs.org/w/index.php?diff=151856&oldid=151854 * MihaiEso * (+47)
10:36:36 <esolangs> [[Translated ZhongWen/Mihai Again Chapter XI]] N https://esolangs.org/w/index.php?oldid=151857 * MihaiEso * (+5624) Created page with "1. [[Translated ZhongWen/islptng Zwei|]]Esolang:undefined1234|<span style='font-family:Unifont;'>You computer has a severe errL$D3h$&% ?' L$H3h(*) ?+ L$L3h,.- ?/ L$P3h021 ?3 ?6$T3h45 ?7 ?:$X3h89 ?; ?p<=? ? F ?~#?~nDl$ ? ?\$#\$ 3\$?D$
10:51:19 <esolangs> [[MSFE++]] https://esolangs.org/w/index.php?diff=151858&oldid=151760 * Cycwin * (+1) /* Interpreter */
11:02:16 -!- tromp has joined.
11:12:10 <esolangs> [[User:Yayimhere/an esolang for my puter]] N https://esolangs.org/w/index.php?oldid=151859 * Yayimhere * (+788) Created 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
11:38:51 <lisbeths> there seems to be alot of bots in this channel
11:40:11 <HackEso> Bot prefixes: fungot ^, HackEso `, EgoBot !, lambdabot @ or ? or > , thutubot +, metasepia ~, idris-bot ( , jconn ) , j-bot [ , bfbot =, velik \.
11:40:47 <int-e> (half of those are gone, and some of the bots don't have commands)
11:41:11 <lisbeths> I have implemented a full reader macro system in posix shell in 3 lines
11:41:27 <lisbeths> and so you can change the notation of your posix shell at will in the middle of writing your programs
11:41:47 <lisbeths> as far as i know it works on a read only filesystem
11:41:58 <lisbeths> so it should run on many routers
11:58:49 <int-e> related: https://www.ioccc.org/1987/biggar/index.html /home/bf3/bat/space/esoteric/ioccc/ https://www.ioccc.org/1993/lmfjyh/index.html
11:59:11 <int-e> 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
12:07:38 -!- craigo has joined.
12:24:12 -!- chiselfuse has quit (Ping timeout: 264 seconds).
12:25:26 -!- wib_jonas has joined.
12:25:58 -!- chiselfuse has joined.
12:34:34 <wib_jonas> 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.
12:36:47 <wib_jonas> 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.
12:37:48 <wib_jonas> 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).
12:40:43 <wib_jonas> 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
12:40:44 <wib_jonas> 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.
12:41:56 <wib_jonas> 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
12:41:57 <wib_jonas> call or the function definition, you can cast the pointer to struct into a pointer to another struct.
12:42:57 <wib_jonas> 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. \
12:47:50 <wib_jonas> 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
12:47:50 <wib_jonas> 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.
12:50:11 <wib_jonas> The C standard has very different rules, and those rules work better with non-C compilation units.
12:51:42 <int-e> 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.
12:51:50 <wib_jonas> 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
12:51:51 <wib_jonas> compilation units are the same in C), they only have to be similar enough.
12:52:03 -!- ais523 has joined.
12:52:33 <int-e> And that's supported by things like the System V ABI which defines representations and calling conventions for C.
12:52:36 <wib_jonas> 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.
12:54:03 <ais523> <b_jonas> 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
12:54:04 <ais523> compatible with each other and thus it's unclear what Rust should do to be compatible with them
12:54:09 <ais523> I vaguely remember something about the alignment of u128
12:54:26 <wib_jonas> 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.
12:56:38 <ais523> https://blog.rust-lang.org/2024/03/30/i128-layout-update.html
12:56:48 <wib_jonas> 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
12:56:49 <wib_jonas> 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.
12:56:54 <ais523> apparently it was fixed by persuading clang to change to be compatible with gcc, then making Rust compatible with the new stanadrd
12:57:34 <ais523> 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
12:58:54 <ais523> 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
12:59:01 <ais523> so I didn't bother learning the situations in which it's allowed to be slightly different
13:00:00 <wib_jonas> 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
13:00:00 <wib_jonas> different overloaded functions to the same name which is a bug.
13:00:45 <wib_jonas> 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.
13:01:48 <ais523> most language's FFIs are defined in terms of C types in an attempt to make the problem manageable
13:02:11 <ais523> 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)
13:03:14 <wib_jonas> 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
13:03:15 <wib_jonas> try to guarantee even in future ABIs.
13:04:15 <ais523> hmm, does C++ allow equivalent-but-not-token-identical multiple definitions of extern "C" structs?
13:05:01 <wib_jonas> 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
13:05:27 <wib_jonas> ais523: extern "C" structs don't exist. extern "C" only applies to function definitions and *maybe* function pointer types.
13:06:04 <ais523> huh, I thought it was more general than that
13:06:07 <wib_jonas> 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
13:06:58 <wib_jonas> 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.
13:07:04 <ais523> 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")
13:07:16 <wib_jonas> in rust this is a thing by the way, function pointers carry their ABI.
13:07:46 <ais523> right, any use of the function pointer has to know the ABI to be usable
13:07:46 -!- wib_jonas has quit (Quit: Client closed).
13:08:11 -!- wib_jonas has joined.
13:08:17 <wib_jonas> 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.
13:15:29 <ais523> 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
13:16:24 <ais523> 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
13:16:29 <wib_jonas> 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
13:17:38 <ais523> 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
13:18:27 <ais523> 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
13:18:38 <ais523> I guess making extra guarantees is a function-pointer-compatible ABI change, though
13:18:49 <wib_jonas> 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
13:18:50 <wib_jonas> struct to have a definite ABI, and some other attribute for a function.
13:19:13 <ais523> wib_jonas: in Rust, yes, the spec does that (although I'm not convinced the implementation actually does yet)
13:19:17 <ais523> I was thinking about langauges in general though
13:19:30 <esolangs> [[]] https://esolangs.org/w/index.php?diff=151860&oldid=132471 * Allen123456hello * (+131) /* Example */
13:20:08 <ais523> I am still upset about the &T as *const T cast, though – it is mostly useless and blocks a significant optimisation
13:20:22 <wib_jonas> 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.
13:20:29 <ais523> (it isn't so useless that you can backwards-compatibly remove it, but it is normally possible to write programs to avoid it)
13:20:42 <ais523> (especially now that we have the &raw operator)
13:21:44 <ais523> <wib_jonas> 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?
13:22:25 <ais523> 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)
13:22:53 <wib_jonas> 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.
13:23:07 <ais523> wib_jonas: what if you pass a static function to qsort or the like?
13:23:55 <ais523> 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
13:23:59 <wib_jonas> 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
13:24:00 <ais523> you can fix that using static inline, but then you still have a static
13:24:20 <ais523> so I think it's specifically static (+ compiler-specific attributes) that matter there
13:24:44 <int-e> 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 ?
13:25:12 <wib_jonas> 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
13:25:17 <ais523> gcc has __attribute__(visibility(internal)) which does what we want, I think
13:25:26 <int-e> (and, I guess, most other 64 bit ABIs, as far as Linux is concerned)
13:25:40 <ais523> (the semantics being "this function is never called from another module, not even by function pointer")
13:25:57 <ais523> the more common visibility(hidden) does not ban indirect calls by function pointer, so wouldn't allow an ABI change
13:26:02 <wib_jonas> 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
13:26:04 <int-e> But I think it's still fair to say that the *intent* of standard-layout types is that their representation matches that of C.
13:26:18 <ais523> and in fact, the documentation for visibility(internal) says that it's primarily useful to allow the optimiser to change the ABI
13:26:34 <int-e> wib_jonas: that's fair but what's there is enough for interoperability
13:27:11 -!- amby has joined.
13:28:43 <ais523> 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"
13:29:39 <wib_jonas> 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
13:29:40 <wib_jonas> 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.
13:31:11 <wib_jonas> 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.
13:31:35 <int-e> rust is working on it, https://github.com/rust-lang/rust/issues/76314
13:32:02 <wib_jonas> 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.
13:32:14 <esolangs> [[ToArrowScript]] N https://esolangs.org/w/index.php?oldid=151861 * Cycwin * (+3920) Created 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
13:33:00 <ais523> 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."
13:33:38 <wib_jonas> 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.
13:33:42 <esolangs> [[User:Cycwin]] https://esolangs.org/w/index.php?diff=151862&oldid=151442 * Cycwin * (+17)
13:34:28 <ais523> 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
13:34:33 <int-e> wib_jonas: well if you're paranoid about it, you have to do it all in C and access it through FFI.
13:34:55 <int-e> because there's no guarantees that link atomic access in C to atomic access in the other languages
13:35:22 <int-e> but realistically, you can share locations by going through a pointer to the underlying non-atomic value and it'll work
13:35:43 <int-e> And that RFC / nightly feature allows you to do that.
13:36:50 <int-e> (if there are such guarantees and I've missed them I'm all ears)
13:37:51 <wib_jonas> 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<std::uintptr_t>, and similar for atomic bools and atomic 32-bit integers.
13:37:51 <ais523> this comment explains what's incompatible on the C++ side: https://github.com/rust-lang/rust/issues/76314#issuecomment-955150595
13:38:20 <ais523> it does not reasonably seem possible to be compatible with that behaviour while maintaining a reasonable API
13:41:36 <ais523> 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
13:41:50 <ais523> (raw pointers work too, obviously)
13:42:22 <int-e> 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."
13:43:06 <wib_jonas> 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
13:44:07 <ais523> ah, C++ changes the official way to do things so often that I just assumed it was the only/standard way nowadays
13:44:37 <wib_jonas> it might be convenient, I don't know that
13:45:29 <wib_jonas> 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.
13:46:08 <ais523> 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)
13:46:44 <ais523> 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
13:46:59 <wib_jonas> 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)
13:47:11 <ais523> 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
13:47:23 <ais523> I don't think it's possible to do that in Rust atm without UB or inline asm
13:47:36 <int-e> Anyway. I doubt this will ever happen for C++'s atomic types, but maybe C's atomic types have a chance.
13:48:31 <ais523> 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
13:48:43 <int-e> 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.
13:49:01 <int-e> ais523: Yeah, that too.
13:49:36 <ais523> this makes it likely that Rust atomics can be made compatible with C atomics, although it'll probably rely on a lot of unsafe
13:49:45 <wib_jonas> 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++
13:50:21 <wib_jonas> 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;
13:51:06 <wib_jonas> 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\
13:53:07 <wib_jonas> 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
13:55:48 <wib_jonas> ais523: is that read_race thing that you mention possible in C or C++ with their modern memory models?
13:56:15 <ais523> wib_jonas: I assumed it would be legal in C with just a regular read, but am not 100% certain
13:56:35 <ais523> obviously C doesn't care about the value being mutably referenced, but it might care about it being changed by another thread
13:56:45 <ais523> actually I think that probably is UB in C
13:57:16 <ais523> which doesn't really have a distinction between "you get UB" and "this isn't undefined behaviour but you read garbage data"
13:59:05 <ais523> 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
13:59:41 <ais523> 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
14:00:00 <ais523> you can probably get reasonable guarantees for unsigned integer types, but likely not anything else
14:04:01 <wib_jonas> 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?
14:16:28 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
14:16:33 <int-e> 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."
14:19:25 <wib_jonas> 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
14:19:27 <int-e> And "undefined behavior" is basically limitless.
14:23:47 <ais523> 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)
14:24:18 <ais523> 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
14:25:09 <ais523> 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
14:26:01 <ais523> (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)
14:27:45 <ais523> 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"
14:29:37 <wib_jonas> that could even depend on whether you're reading or writing
14:30:24 <ais523> 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
14:32:28 <ais523> I usually program in fields where fail-fast is definitely what you want, though
14:35:48 <int-e> 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.
14:50:15 <esolangs> [[Pointing]] https://esolangs.org/w/index.php?diff=151863&oldid=151693 * Calculus is fun * (-2) Changed xor symbol
14:54:14 <esolangs> [[ToArrowScript]] M https://esolangs.org/w/index.php?diff=151864&oldid=151861 * Cycwin * (+28) /* Syntax of TAS */
15:00:21 <esolangs> [[ToArrowScript]] M https://esolangs.org/w/index.php?diff=151865&oldid=151864 * Cycwin * (+26) /* Syntax of TAS */
15:00:30 <fizzie> 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.
15:00:40 <fizzie> (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.")
15:01:16 <fizzie> 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.
15:01:32 <fizzie> (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.")
15:02:10 <fizzie> 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.
15:02:18 <fizzie> (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.")
15:02:36 <esolangs> [[Pointing]] M https://esolangs.org/w/index.php?diff=151866&oldid=151863 * Calculus is fun * (-3) /* Instructions */
15:03:16 <wib_jonas> fizzie: which one is it when you convert an integer to a smaller signed integer type that it overflows?
15:04:51 <fizzie> 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.
15:04:55 <fizzie> (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.")
15:05:21 -!- tromp has joined.
15:06:12 <fizzie> 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.
15:06:17 <wib_jonas> 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
15:06:18 <wib_jonas> unsigned type, because both of those steps are well-defined with the expected result.
15:08:40 <lambdabot> I saw fungot leaving #esolangs 1d 14h 43m 43s ago.
15:09:14 <fizzie> 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.
15:09:31 <int-e> . o O ( you're playing with fire if you're mixing singed types with unsinged types )
15:09:52 <wib_jonas> 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.
15:10:23 <ais523> wib_jonas: hmm, which workaround are you thinking of?
15:10:25 <fizzie> Oh, right, I forgot about fungot. There was a brief internet outage at home the other day.
15:10:47 <ais523> I cam think of a few possibilities but am not 100% confident in which of them would be legal
15:10:53 <fizzie> (Or technically it was "planned maintenance", though they didn't actually bother to let me know in advance.)
15:11:03 <wib_jonas> 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
15:11:36 <wib_jonas> this is assuming that x is an integer type
15:12:19 <ais523> wib_jonas: big-unsigned-to-small-signed casts are defined even if they overflow?
15:12:30 <ais523> oh, wait, other way roudn
15:12:38 <ais523> you're casting to small unsigned and then to small signed
15:12:42 <ais523> yep, that works I think
15:12:54 <ais523> (assuming 2's complement)
15:13:43 <wib_jonas> 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.
15:13:49 -!- fungot has joined.
15:15:05 <fungot> ais523: you press f7 to use it,
15:16:04 <fizzie> Hmm, I do wonder what "it" was in that.
15:17:17 <fizzie> <yome> You press F7 to use it, F6 to resotre the keybindings.
15:18:39 <fizzie> Apparently some sort of ELisp module for structural editing of Scheme code (or S-expressions in general, perhaps).
15:19:27 <wib_jonas> 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)
15:23:24 <wib_jonas> 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.
15:25:34 -!- wib_jonas80 has joined.
15:28:10 -!- wib_jonas has quit (Ping timeout: 240 seconds).
15:35:17 -!- b_jonas has quit (Killed (NickServ (GHOST command used by wib_jonas80!~wib_jonas@business-37-191-60-209.business.broadband.hu))).
15:35:21 -!- wib_jonas80 has changed nick to wib_jonas.
15:36:47 -!- craigo has quit (Quit: Leaving).
15:41:43 <wib_jonas> 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
15:41:43 <wib_jonas> 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.
15:43:27 <wib_jonas> 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.
15:46:11 <wib_jonas> this will be partly solved in future x86 by AVX512 providing a higher variety of floating point to integer conversion instructions.
15:46:25 <wib_jonas> but apparently floating point to integer conversion is still a partly unsolved problem.
15:48:58 <fizzie> 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).
15:49:01 <fizzie> Got a little confused by this file that was alternatingly showing up as 743243776 and "407M".
15:49:48 <wib_jonas> 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)
15:52:33 <ais523> <wib_jonas> 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
15:53:32 <wib_jonas> yes, it uses INT_MIN to indicate overflow in either direction
15:54:01 <ais523> 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
15:57:09 <wib_jonas> 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
15:57:43 <ais523> maybe that's what I was thinking of
15:58:44 <wib_jonas> 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.
15:59:03 <wib_jonas> I think that's still the case in AVX512 but I'm not entirely sure
15:59:48 <wib_jonas> 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?
16:03:40 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=151867&oldid=151836 * H33T33 * (+154) /* Introductions */
16:04:43 <ais523> is there an easy way to print a float as a hexfloat in Perl?
16:04:57 <ais523> I could probably figure out a difficult way involving multiple calls to pack and unpack
16:05:20 <wib_jonas> I was wrong above. so the SSE2 instruction CVTPD2DQ actually gives not INT_MIN but -1 on an onverflow.
16:05:55 <ais523> -1 isn't a very sensible overflow result unless it is outputting unsigned integers
16:07:33 <ais523> the docs do say that the result is all-bits-1 if a floating-point invalid exception is raised and masked, though
16:07:39 <wib_jonas> 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
16:07:50 <ais523> you do have CVTPS2SQ for converting single-precision floats, though
16:08:13 <ais523> wib_jonas: for floats, -1 or all-bits-1? those are different for floats I think
16:08:35 <wib_jonas> I'm talking about floating point to integer conversion, you get an integer -1
16:09:25 <ais523> ah, you said "in any direction" but you were talking about positive vs. negative overflow, not float-to-int vs. int-to-float
16:09:57 <wib_jonas> 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
16:10:05 <wib_jonas> yes, sorry, it's overflow with any sign
16:10:46 -!- wib_jonas29 has joined.
16:10:52 <ais523> there's also CVTTPD2DQ which appears to be the same instruction with more sensible overflow behaviour?
16:11:04 -!- wib_jonas29 has changed nick to b_jonas.
16:12:13 <b_jonas> ais523: not as far as I understand.
16:13:06 <ais523> well, the differences are a) overflow behaviour, b) CVTT is always round-to-zero and ignores the floating-point status word
16:14:06 <ais523> I am wondering if CVTPD2DQ's overflow behaviour is a typo that ended up getting implemented, it says 2<sup>w</sup>-1 but that may have originally been a typo for 2<sup>w-1</sup>
16:14:12 <b_jonas> 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
16:14:12 <b_jonas> always rounds towards zero, but that's only when there's no overflow
16:14:40 -!- wib_jonas has quit (Ping timeout: 240 seconds).
16:14:53 -!- b_jonas has changed nick to wib_jonas.
16:15:06 <wib_jonas> I'm not supposed to be b_jonas from this connection
16:15:12 <ais523> <CVTTPS2DQ> 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.
16:16:11 <ais523> CVTPD2DQ also specifies its error return value as "the indefinite integer value", but defines it as 2<sup>w</sup>-1
16:16:24 <ais523> which would be a weird use of "the" if they're both intentional
16:16:46 <wib_jonas> so out of the eight instructions that convert from double to some integer type, *one* gives a different result on overflow?
16:17:25 <ais523> CVTTPD2DQ also uses the 0x80000000 return
16:17:36 <ais523> in addition to CVTTPS2DQ
16:18:04 <wib_jonas> yes, I said the eight instructions that convert from double, so I didn't look at CVTTPS2DQ
16:18:13 <wib_jonas> eight conversions from double was already enough to look up in the manual
16:18:17 <ais523> the others are documented as 2<sup>w</sup>-1
16:18:33 <wib_jonas> I do care about the float to integer conversions too but I can't turn the virtual pages of the manual fast enough
16:18:41 <ais523> I think it's probably worth trying these out on an actual processor (but I don't have one that runs AVX-512)
16:19:14 <ais523> it's a little nontrivial to run arbitrary asm and print the result, maybe a C wrapper would be easiest
16:19:38 <esolangs> [[User:PrySigneToFry/Sandbox/Users that is also on other place]] https://esolangs.org/w/index.php?diff=151868&oldid=151851 * Ractangle * (+18)
16:20:01 <ais523> anyway, to me, the only logical explanation is that the documentation is a typo for 2<sup>w-1</sup> but I don't know whether the typoed version got implemented or not
16:20:12 <wib_jonas> 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?
16:23:09 <esolangs> [[User:PrySigneToFry/Sandbox/Users that is also on other place]] https://esolangs.org/w/index.php?diff=151869&oldid=151868 * Ractangle * (+54)
16:23:10 <wib_jonas> if gcc/clang doesn't know then the other place to look at is in an AMD manual
16:23:56 <wib_jonas> in theory qemu should know too but I know it has bugs about modern x86 floating-point operations so I don't trust it
16:26:04 <esolangs> [[User:PrySigneToFry/Sandbox/Users that is also on other place]] https://esolangs.org/w/index.php?diff=151870&oldid=151869 * Ractangle * (+26)
16:26:15 <ais523> wib_jonas: cvtpd2dq returns INT_MIN on overflow (despite the documentation), I just tested
16:27:35 <ais523> OK, tested with both signs, INT_MIN in both cases
16:27:35 <esolangs> [[User:PrySigneToFry/Sandbox/Users that is also on other place]] https://esolangs.org/w/index.php?diff=151871&oldid=151870 * Ractangle * (+0)
16:27:43 <ais523> I would have been surprised if they were different
16:27:53 <ais523> I think the documentation is just typoed
16:28:13 <wib_jonas> hmm, we should download the latest update to the manual first
16:28:48 <wib_jonas> webpage is https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html
16:29:44 <ais523> something else is bothering me a lot – the conversion produces 32-bit numbers, so why does the name end in DQ?
16:30:13 <ais523> I guess it's D for 32-bit and the Q means something else?
16:30:55 <esolangs> [[Topple]] N https://esolangs.org/w/index.php?oldid=151872 * H33T33 * (+3681) Created 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
16:31:04 -!- Lykaina has joined.
16:32:37 <Lykaina> i just thought up a funge/forth hybrid with 8836 possible commands
16:32:56 <Lykaina> need to learn forth first though
16:33:01 <ais523> I was impressed with gcc allowing me to take an integer from an xmm register, anyway
16:33:29 <ais523> 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); }
16:34:45 <lisbeths> https://github.com/memesmith0/mcr4
16:35:08 <ais523> Lykaina: I have a suspicion that esolang ideas that require learning Forth first are likely to be interesting
16:36:01 <Lykaina> I meant I need to learn Forth
16:36:50 <wib_jonas> 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.
16:37:42 <ais523> having some lane-crossing instructions is useful, but they are slower so it generally makes sense to only lane-cross when explicitly requested to
16:37:44 <wib_jonas> it's possible that I'm reading the ZMM case wrong, the description is confusing, so don't trust me
16:38:55 <wib_jonas> 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
16:40:42 <wib_jonas> "allowing me to take an integer from an xmm register" => SSE2 is actually designed to try to make that easy and I like that
16:42:15 <ais523> I'm not surprised that the processor allows it (I knew it did), but i was surprised that gcc inserted the conversion for me
16:43:16 -!- Celeo has joined.
16:43:31 <Lykaina> i can't believe raspberry pi thinks they will be making the 32-bit rp2350 in 2045. nothing 32-bit will survive 2038
16:43:59 -!- Celeo has quit (Client Quit).
16:44:14 -!- Celeo has joined.
16:44:35 -!- Celeo has quit (Client Quit).
16:44:54 -!- Celeo has joined.
16:45:12 <ais523> Lykaina: you can (and should) use 64-bit time_t on 32-bit systems
16:45:33 <ais523> I don't know whether that's the default yet, but it really should be
16:47:00 <Lykaina> so many programming languages will have to have their time libraries changed from outputting a long to outputting a long long
16:48:57 <Lykaina> if they haven't done so already
16:50:45 <ais523> glibc has a _TIME_BITS define that controls the size of time_t
16:53:52 <esolangs> [[Topple]] https://esolangs.org/w/index.php?diff=151873&oldid=151872 * H33T33 * (-54) Topple Esolang Info
16:56:16 <esolangs> [[Scoop]] https://esolangs.org/w/index.php?diff=151874&oldid=96633 * Anthonykozar * (-2) Remove the header before the introduction plus some light editing for readability.
16:56:26 <int-e> hmm no avx512 here to test
16:56:29 <wib_jonas> 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
16:59:54 <Lykaina> out of an N100 w/ 16 GiB ram and OpenWRT's x86-64 build
17:00:17 <Lykaina> got sick of replacing them
17:00:31 <wib_jonas> 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
17:05:59 <int-e> But I can conclude that the documentation of CVTSS2SI with a 64 bit target is wrong.
17:06:25 <int-e> These instruction sets are such a mess.
17:08:37 <wib_jonas> int-e: isn't CVTSS2SI an mmx-only instruction and so almost obsolete now?
17:09:34 <wib_jonas> I'm more interested about the SSE2/AVX512 instructions like CVT{,T}{PS,PD}2{DQ,UDQ,QQ,UQQ}
17:15:28 <esolangs> [[User:PrySigneToFry/Sandbox/Users that is also on other place]] https://esolangs.org/w/index.php?diff=151875&oldid=151871 * Ractangle * (+19)
17:15:46 <wib_jonas> I'm almost happy to let MMX die, and I think its only remaining applications are esoteric only
17:20:51 <fizzie> Debian had a big "t64 transition" to move to 64-bit `time_t` on 32-bit platforms last year.
17:22:09 <fizzie> 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.
17:22:52 <fizzie> https://wiki.debian.org/ReleaseGoals/64bit-time has some details in case anyone's curious.
17:24:08 <fizzie> 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).
17:25:40 <wib_jonas> 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
17:25:48 <int-e> wib_jonas: It's the only instruction with a 64 bit target that I have :P CVTPS2DQ also uses 0x80...00
17:25:57 <wib_jonas> but x86_64 at least had 64-bit time_t from the start, right?
17:28:00 <int-e> and VCVTPS2DQ is the same too
17:28:21 <int-e> (tbh it would be insane to change that between sse2 and avx)
17:28:24 <fizzie> Yes, x86-64 (or amd64 as Debian calls it) was 64-bit from the start.
17:28:56 <fizzie> 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."
17:29:02 <fizzie> (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
17:29:30 <wib_jonas> 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,
17:29:30 <wib_jonas> 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.
17:29:51 <int-e> wib_jonas: basically all the rest you're asking abouyt are avx512 so not available to me :P
17:30:12 <int-e> wib_jonas: I imagine the U version actually use 2^w - 1.
17:30:22 <int-e> rather than 2^(w-1)
17:30:34 <wib_jonas> I may try to look at that floating point to integer thing later, I can't at the moment
17:31:41 <int-e> and meh I hate piecing together compiler intrinsics for these things
17:32:03 <wib_jonas> we'll be able to find someone on the internet who has a new enough intel CPU
17:33:28 <ais523> 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
17:35:34 <esolangs> [[User:Anthonykozar/Sandbox]] N https://esolangs.org/w/index.php?oldid=151876 * Anthonykozar * (+145) Testing for Markdown support
17:37:39 <wib_jonas> 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
17:37:39 <wib_jonas> CPU that's designed with 512-bit vectors from the start.
17:37:50 <wib_jonas> I mean AVX512 is divided into three tiers
17:40:17 <wib_jonas> 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
17:40:44 <wib_jonas> obviously there must be for the SSE2 instructions at least
17:42:30 <int-e> wib_jonas: https://int-e.eu/~bf3/tmp/avx512%3f.png -- it's even more complicated, see the footnote
17:43:27 <int-e> (fairly recent SDM, I downloaded it in December)
17:49:32 <wib_jonas> 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
17:50:08 <int-e> sure. this was about the three tiers
17:52:33 <wib_jonas> "I hate piecing together compiler intrinsics for these things" => you could use inline assembly
17:56:07 -!- wib_jonas has quit (Quit: Client closed).
18:19:39 -!- chomwitt_alt has joined.
18:27:44 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
18:41:58 -!- Lord_of_Life has quit (Ping timeout: 252 seconds).
18:42:00 -!- Lord_of_Life_ has joined.
18:43:26 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
18:45:15 -!- tromp has joined.
18:55:03 -!- ais523 has quit (Quit: quit).
19:08:48 <korvo> Go for it. I'd be interested in understanding the bigger picture.
19:15:19 -!- b_jonas has joined.
19:39:43 -!- Sgeo has joined.
20:15:44 <lisbeths> 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
20:16:14 <lisbeths> it was designed so that I could extend the notation of bash
20:16:26 <lisbeths> I spent 12 years researching to develop it
20:22:44 <lisbeths> 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
20:23:12 <lisbeths> 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
20:24:18 <zzo38> Is there a document?
20:24:51 <lisbeths> no but I can answer questions about it
20:25:08 <lisbeths> I have alot of experience tutoring in code I was a c++ tutor at everett community college
20:25:26 <lisbeths> i teach people to code for fun
20:25:39 <lisbeths> https://github.com/memesmith0/mcr4/blob/main/README.md
20:26:43 -!- chomwitt_alt has quit (Ping timeout: 244 seconds).
20:27:12 <lisbeths> theres also this bad boy https://github.com/memesmith0/mcr
20:27:54 <lisbeths> mcr is alot easier to grok than mcr4 but it isnt as performant or safe
20:33:48 -!- Lykaina has quit (Quit: Leaving).
20:34:42 <lisbeths> 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
20:35:14 <lisbeths> 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
20:38:15 <int-e> 12 years of research and not a single example
20:38:17 <b_jonas> lisbeths: you should probably write something about this on the esolangs wiki
20:38:35 <int-e> but 4 versions in 2 days
20:38:50 <lisbeths> if I write something I can give you license to use my text on the wiki
20:39:14 <lisbeths> ive been codding all day every day for 4 weeks
20:39:24 <lisbeths> i havent showered or shaved or changed my clothes
20:39:47 <b_jonas> that sounds like a bad idea
20:40:28 <lisbeths> eh i am just focused on getting fastlisp done
20:40:39 <lisbeths> it has thrown a wrench in my plants because I didnt expect to implement mcr
20:40:55 <lisbeths> fastlisp is a lisp written in pure lambda calculus
20:41:05 <lisbeths> it only consits of lambdas, strings, and comments
20:41:17 <lisbeths> the specification fits into a qr code
20:41:23 <lisbeths> the interpreter fits into the boot sector of a floppy disc
20:41:36 <lisbeths> no there are only constants. but there is a way to simulate variables
20:41:58 <b_jonas> that sounds like https://esolangs.org/wiki/Sectorlisp
20:42:17 <lisbeths> its based on sectorlisp and is designed to be fully compatible with sectorlisp
20:42:25 <b_jonas> wait, how do the lambda expressions work if there are no variables? that doesn't sound like lambda calculus
20:42:43 <lisbeths> lambdas dont have variabesl they have constants
20:43:19 <lisbeths> i guess you could think of them like variables
20:43:27 <b_jonas> 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?
20:43:33 <b_jonas> that sounds more reasonable
20:43:34 <int-e> nah, the standard terminology is that lambda terms have variables; they can be bound or unbound; closed lambda terms only have bound variables
20:43:56 <b_jonas> but I'm still confused about the "only consits of lambdas, strings, and comments"
20:44:15 <int-e> this comes from mathematics where variables aren't mutable
20:44:33 <lisbeths> there is a sectorlisp-like way to code with lambdas where it works alot like scheme
20:44:48 <b_jonas> 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?
20:46:02 <lisbeths> in fastlisp version 5 comments are just lines that begin with #
20:46:11 <b_jonas> are there any birds involved?
20:46:25 <lisbeths> yeah I have the iota combinator tattoed on my arm
20:47:36 <lisbeths> fastlisp isnt really ready to show whereas mcr and mcr4 are working 2day
20:47:51 <lisbeths> I can show you some fastlisp sources
20:47:56 <b_jonas> ``` welcome lisbeths # wow we really are magnets for strange people here
20:47:58 <HackEso> lisbeths: Welcome to the international hub for esoteric programming language design and deployment! For more information, check out our wiki: <https://esolangs.org/>. (For the other kind of esoterica, try #esoteric on EFnet or DALnet.)
20:48:24 <lisbeths> https://github.com/memesmith0/fastlisp/blob/main/celestial/holy9.fastlisp
20:49:03 <lisbeths> fastlisp code fits into one of four categories; subterranian, terrestrial, telestial, and celestial
20:49:45 <lisbeths> the entire haskell compiler should be dumpable directly into fastlisp
20:50:27 <lisbeths> 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
20:58:08 <lisbeths> i would sho u my website which has some very homeschooled code but it is problematic
21:02:32 <lisbeths> eh I guess i dont care view-source:https://podlife.neocities.org/
21:11:52 <zzo38> Is a remote proxy server available for connecting to TLS 1.3 from clients that do not support TLS?
21:23:49 <korvo> 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.
21:24:33 <korvo> ...Wait, I was going to phrase that as a question. But I don't remember how I was going to ask it.
21:25:15 -!- Celeo has quit (Ping timeout: 260 seconds).
21:27:01 <korvo> zzo38: Like stunnel? Or the other direction?
21:30:20 <zzo38> 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.
21:31:29 <korvo> Ah, I don't know of any public proxies like that.
21:47:20 <JAA> IIRC, some HTTP proxy softwares support remote GET requests like 'GET https://example.org/ HTTP/1.1'. I haven't seen raw TLS though.
22:00:32 <esolangs> [[User:PrySigneToFry/Sandbox/Users that is also on other place]] https://esolangs.org/w/index.php?diff=151877&oldid=151875 * Aadenboy * (+130) add various places
22:06:42 <esolangs> [[User:Buckets]] M https://esolangs.org/w/index.php?diff=151878&oldid=151825 * Buckets * (+10)
22:06:52 <esolangs> [[Language list]] M https://esolangs.org/w/index.php?diff=151879&oldid=151843 * Buckets * (+11)
22:07:09 <esolangs> [[!@a*]] N https://esolangs.org/w/index.php?oldid=151880 * Buckets * (+1073) Created 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
22:09:41 <esolangs> [[User talk:PrySigneToFry/Sandbox/Users that is also on other place]] N https://esolangs.org/w/index.php?oldid=151881 * Ractangle * (+199) Created page with "THERE IS A LITERAL BEEPBOX WIKI?~~~"
22:11:20 <esolangs> [[User talk:PrySigneToFry/Sandbox/Users that is also on other place]] https://esolangs.org/w/index.php?diff=151882&oldid=151881 * Aadenboy * (+338) yep!
22:22:20 <esolangs> [[User:PrySigneToFry/Sandbox/Users that is also on other place]] M https://esolangs.org/w/index.php?diff=151883&oldid=151877 * Aadenboy * (-42) might as well remove those if I don't use them
22:30:41 <esolangs> [[Topple]] M https://esolangs.org/w/index.php?diff=151884&oldid=151873 * H33T33 * (+0)
22:47:01 <esolangs> [[Special:Log/newusers]] create * Hotcrystal0 * New user account
22:49:13 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
22:50:13 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=151885&oldid=151867 * Hotcrystal0 * (+285)
22:50:45 <esolangs> [[User:Hotcrystal0]] N https://esolangs.org/w/index.php?oldid=151886 * Hotcrystal0 * (+225) Created 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."
22:52:01 <esolangs> [[UserEdited]] https://esolangs.org/w/index.php?diff=151887&oldid=151835 * Hotcrystal0 * (-40) I have an account now.
22:52:43 <esolangs> [[UserEdited]] https://esolangs.org/w/index.php?diff=151888&oldid=151887 * Hotcrystal0 * (+2)
22:54:22 <esolangs> [[Anti-Plushie language]] https://esolangs.org/w/index.php?diff=151889&oldid=150738 * Hotcrystal0 * (+34) Adding a missing category
22:56:21 -!- Celeo has joined.
22:59:42 -!- ais523 has joined.
23:11:43 <esolangs> [[UserEdited]] https://esolangs.org/w/index.php?diff=151890&oldid=151888 * Hotcrystal0 * (+569) Added more commands
23:44:16 <esolangs> [[UserEdited]] https://esolangs.org/w/index.php?diff=151891&oldid=151890 * Hotcrystal0 * (-2)
23:49:29 <esolangs> [[UserEdited]] https://esolangs.org/w/index.php?diff=151892&oldid=151891 * Hotcrystal0 * (+475)
23:57:28 <esolangs> [[UserEdited]] https://esolangs.org/w/index.php?diff=151893&oldid=151892 * Hotcrystal0 * (+126)
23:57:52 <esolangs> [[UserEdited]] https://esolangs.org/w/index.php?diff=151894&oldid=151893 * Hotcrystal0 * (-6)
23:58:03 -!- Celeo has left.