00:58:31 <esolangs> [[APGsembly]] N https://esolangs.org/w/index.php?oldid=158080 * I am islptng * (+11920) Just want to port this here.
01:19:46 <esolangs> [[Mlatu-6]] https://esolangs.org/w/index.php?diff=158081&oldid=157857 * Dadsdy * (+111) /* External Resources */
01:49:56 <esolangs> [[Burnlike]] M https://esolangs.org/w/index.php?diff=158082&oldid=157417 * PkmnQ * (+3) /* Ruleset */ this seems more fitting
01:56:54 -!- Guest66 has joined.
02:07:55 -!- impomatic has joined.
02:12:55 -!- Guest66 has quit (Quit: Client closed).
02:58:05 -!- Oj742 has joined.
03:08:00 <zzo38> I had read about reversible computing that they will save power compared with other computers. However, maybe there might also be possibility making a kind of hybrid computing if it helps.
03:08:26 <zzo38> ChaCha20 has a reversible part and then a final part that is not reversible.
03:10:11 <zzo38> If you have C operators += -= ^= then you can also have locking, with shared locking for each use of each variable on the right, and exclusive locking for each use of each variable on the left (but, you would also have array bound checking and without using other kind of pointers). A counted loop will have shared locking on the repeat count and on the variable to count each iteration.
03:10:31 <zemhill> Oj742.quicklock: points -7.71, score 14.82, rank 36/47 (+7)
03:27:03 <esolangs> [[Special:Log/newusers]] create * Noewaeda * New user account
04:18:00 <zemhill> Oj742.maddash: points -9.31, score 13.08, rank 46/47
04:42:13 <esolangs> [[Wheddo]] N https://esolangs.org/w/index.php?oldid=158083 * Rombito * (+2080) Created page with "'''Wheddo''' is an esolang made and posted onto this wiki by [[user:Rombito]]. ==The Languages== A singular line in a Wheddo Program is structured into 2 parts: # The ID # and the Code Here, there will only be an explanation of the ID since the code is self-explanatory.
04:45:00 <esolangs> [[Wheddo]] https://esolangs.org/w/index.php?diff=158084&oldid=158083 * Rombito * (+72)
04:45:23 <esolangs> [[Wheddo]] https://esolangs.org/w/index.php?diff=158085&oldid=158084 * Rombito * (-21)
04:47:14 <esolangs> [[Wheddo]] https://esolangs.org/w/index.php?diff=158086&oldid=158085 * Rombito * (+7)
04:49:02 <esolangs> [[Wheddo]] https://esolangs.org/w/index.php?diff=158087&oldid=158086 * Rombito * (+22)
04:49:46 <esolangs> [[User:Rombito]] N https://esolangs.org/w/index.php?oldid=158088 * Rombito * (+63) Created page with "<b style="color:blue">I am rombito, and I do rombito things</b>"
04:50:03 -!- Oj742 has quit (Quit: Client closed).
04:56:01 -!- Lord_of_Life has quit (Ping timeout: 265 seconds).
04:56:25 -!- Lord_of_Life has joined.
05:27:47 <esolangs> [[Wheddo]] https://esolangs.org/w/index.php?diff=158089&oldid=158087 * Rombito * (-6)
05:28:47 <esolangs> [[Wheddo]] https://esolangs.org/w/index.php?diff=158090&oldid=158089 * Rombito * (+24)
05:39:11 <esolangs> [[User talk:PrySigneToFry]] https://esolangs.org/w/index.php?diff=158091&oldid=157938 * Cycwin * (+366) /* Any interests on joining our Esolang Tencent QQ group? */
05:40:47 <esolangs> [[Language list]] https://esolangs.org/w/index.php?diff=158092&oldid=158064 * Rombito * (+13) /* W */
05:50:29 <esolangs> [[User talk:Hotcrystal0]] https://esolangs.org/w/index.php?diff=158093&oldid=157966 * Cycwin * (+29) /* Where are you from, and how can you understand Chinese? */
06:08:46 <esolangs> [[Wheddo]] https://esolangs.org/w/index.php?diff=158094&oldid=158090 * Rombito * (+246)
06:08:49 -!- tromp has joined.
06:09:07 <esolangs> [[Wheddo]] https://esolangs.org/w/index.php?diff=158095&oldid=158094 * Rombito * (-2)
06:09:22 <esolangs> [[Wheddo]] https://esolangs.org/w/index.php?diff=158096&oldid=158095 * Rombito * (+0)
06:50:15 -!- Sgeo has quit (Read error: Connection reset by peer).
07:17:08 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
07:17:47 -!- tromp has joined.
07:32:27 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
07:41:06 <esolangs> [[Fn]] https://esolangs.org/w/index.php?diff=158097&oldid=156970 * C0ffee * (-1) /* Examples */
08:05:26 -!- impomatic has quit (Quit: Client closed).
08:14:55 <esolangs> [[Brafunge]] N https://esolangs.org/w/index.php?oldid=158098 * C0ffee * (+1324) Created page with "'''Brafunge''' is a cell-based language inspired by [[brainfuck]] and [[Befunge]]. == Commands == {| class="wikitable" !Commands !Description |- | <code>></code> || Move the pointer to right. |- | <code><</code> || Move the pointer to left. |- | <code>+</code> || Incr
08:15:09 <esolangs> [[Brafunge]] https://esolangs.org/w/index.php?diff=158099&oldid=158098 * C0ffee * (-8)
08:38:06 <esolangs> [[Brafunge]] https://esolangs.org/w/index.php?diff=158100&oldid=158099 * C0ffee * (+192)
08:38:23 <esolangs> [[Brafunge]] https://esolangs.org/w/index.php?diff=158101&oldid=158100 * C0ffee * (+1) /* Examples */
08:41:02 <esolangs> [[Brafunge]] https://esolangs.org/w/index.php?diff=158102&oldid=158101 * C0ffee * (+27) /* Commands */
08:41:28 <esolangs> [[User:C0ffee]] https://esolangs.org/w/index.php?diff=158103&oldid=156973 * C0ffee * (+15)
08:42:16 <esolangs> [[Brafunge]] https://esolangs.org/w/index.php?diff=158104&oldid=158102 * C0ffee * (-3) /* Examples */
08:57:10 -!- ais523 has joined.
09:00:39 <ais523> <int-e> woah something has gone seriously wrong with clang's register allocation in this case: https://paste.rs/ca13U.txt ← if this is hot code, I would seriously consider moving the movabs-es outside the loop, although I *think* they're not the limiting factor here (a good approximation is that you can decode 12 instructions while doing a multiplication nowadays, and there are 10 instructions in the body of the loop if you count cmp+je and cmp+jb as one
09:00:41 <ais523> instruction each, so it shouldn't be blocked on decode)
09:01:29 <ais523> but gcc's move into %rdx is clearly movable outside the loop except in cases where %rdx needs to be preserved if the first iteration does the jump to .L24
09:07:48 <ais523> int-e: was the clang code compiled without optimisation? it moves a constant into %rax then immediately adds a constant to %rax, and I'd expect just about any compiler to be able to optimise that
09:33:14 -!- chiselfu1e has joined.
09:35:00 -!- chiselfuse has quit (Ping timeout: 264 seconds).
09:35:56 <ais523> b_jonas: I think many modern languages have been avoiding postfix [] for naming array types because they have a prefix operator that acts on types (e.g. pointer/reference formation), and it can make types hard to read and write unambiguously if you have both prefix and postfix operators
09:36:35 <ais523> Rust's [T; LENGTH] notation is clever because being circumfix, it's unambiguous no matter what operators you put inside or around it
09:38:25 -!- wib_jonas has joined.
09:40:12 <ais523> now I'm thinking about how array formation is one of the few two-argument operators that acts on types, but I'm not sure I've seen an infix syntax for it in any remotely recent language
09:40:28 <ais523> I think there's some really old language where you can do INTEGER*100 or the like to make an array, but forget which one, and doubt it nests
09:41:12 <ais523> forming product types is also a two-argument operator that acts on types, that's normally called (T, U) but I think I've seen * for it
09:41:45 <ais523> and forming sum types is interesting as that often doesn't have syntax at all, even in languages with sum types
09:41:52 <wib_jonas> ais523: well C++ kind of has std::array<mytype, mylength>
09:42:15 <ais523> wib_jonas: that's similar to the Rust way of doing things
09:43:21 <ais523> I guess you don't want to be able to declare something as "Int + String" (disjoint union) as that makes actual uses of the type difficult; because it could be "Int + Int" the syntax for accessing cases would have to be written by index
09:44:54 <ais523> OCaml lets you do [`I of int | `S of string] to create a disjoint union on the fly, with custom names for the variants
09:46:30 <ais523> I have been thinking for a while that possibly a good solution to this is to have newtypes that can be created on the fly, plus unions where all the options have to be different newtypes
09:54:48 <strerror> T*N would be a confusing array syntax as it isn't associative: (T*N)*M ≠ T*(N*M)
09:56:35 <ais523> it's sort-of associative, the former gives you a two-dimensional array, the latter gives you a one-dimensional array with the same total number of elements
09:56:45 <ais523> the types would be identical in a language that indexed by byte count rather than element count
09:57:07 <ais523> err, if it were weakly typed enough
10:09:08 <wib_jonas> ais523: so in naming types, the problem with the C syntax is that the variable name goes in the middle. everyone realized that this was a bad idea, so in a variable declaration, digitalmars D always puts the variable name after the whole type name, while Rust and golang and ziglang put the variable name before the whole type name. IIUC digitalmars
10:09:08 <wib_jonas> D and golang still uses the order return type then function name then argument list to define functions, but this only applies at the top nesting level, and for declaring function pointers a different syntax is used that keeps the whole typename together with the variable name still after the type in D and before the type in golang.
10:11:58 <fizzie> FORTRAN has a `TYPE*n` syntax, but it's not for arrays, it's for indicating different "variants" of the same type. So you have (standard) `CHARACTER*n` for any n > 0 for a fixed-length string; and you have (nonstandard) `INTEGER*2`, `INTEGER*4` and `INTEGER*8` types for different-sized integers; and you have `REAL*4` and `REAL*8` for two kinds of floats.
10:13:35 <ais523> wib_jonas: right, in general I think it is useful to be able to name a type without having a specific identifier representing the type name in the middle of the syntax
10:13:47 <ais523> this comes up in C with function pointers – they need an argument list but the arguments aren't named
10:15:55 <fizzie> (Looks like Fortran 90 changed `CHARACTER*123` into `character(len=123)`, too.)
10:17:58 <ais523> ooh, I just realised that maybe type * type should be a syntax for declaring a map type (value * key)
10:18:08 <wib_jonas> but there's a something strange here: in digitalmars D type operators go on the right of the base type like `double[8] v;` or around it; in Rust and golang and zig type operators go on the left of the base type like `v: &mut double` in rust and `v [8]f64` in golang and `v: [8]f64` in ziglang, or around it. so the simple type operators always go in
10:18:08 <wib_jonas> the middle. how come nobody is using a syntax where there are simple type operators that go only on one side of the type, but they're on the far side of the variable name?
10:18:26 <ais523> that generalizes the idea of type * int being an array, because an array is a map from indexes to values
10:19:26 <ais523> wib_jonas: I'm almost wondering if there's some parser ambiguity in doing that, but I can't immediately think of one
10:19:51 <ais523> (also, "double" isn't a Rust type)
10:20:25 <wib_jonas> so `v: &mut f64` in rust and `v [8]dobule` in golang and `v: [8]f64` in ziglang
10:20:48 <fizzie> C++ `std::tuple` has that property where you can access the individual fields by type if but only if they're distinct types, and have to fall back to indices if not.
10:21:13 <fizzie> `double` isn't a Go type either, the types are `float32` and `float64`.
10:21:16 <HackEso> double`? No such file or directory
10:23:07 <ais523> I think using lowercase names for primitive types in Rust was a mistake, given that all the standard-library-defined types are upper-camelcase
10:23:31 <ais523> I've definitely written code that had a bunch of temporary variables i1, i2, i3, etc.
10:23:52 <ais523> and although you can name a variable the same thing as a primitive type in Rust, so when I reached i8 the code still worked, it looked weird in an editor
10:24:33 <ais523> (Rust always needs to know whether it's parsing a type or a value so that it can work out whether >> is a bitshift or two closing brackets, so it allows types and values to have the same name as each other)
10:25:17 <wib_jonas> ok hold on, doesn't standard ML put the type constructor on the right and its argument on the left, and the name before the type, so you effectively end up with an order like `v: int list` which is similar to putting type operators on the outside?
10:26:10 <strerror> I guess Rust's `t: &mut T` was chosen to mimic the operator `&mut t`. (Just like in C, `T t[N];` was chosen to mimic the operator `t[n]`. Why would anyone find that confusing?)
10:26:51 <wib_jonas> so now we just need to find a language that can put the type modifier first, then the type, then the variable name.
10:28:06 <wib_jonas> and if there's no such language yet then we have to make one
10:28:06 <ais523> wib_jonas: OCaml uses that order too
10:28:10 <strerror> Speaking of parsing, the normal way round might be easier because there's usually not many ways to write a variable name
10:28:15 <ais523> which isn't surprising, also being an ML
10:29:00 <ais523> but, I think you're misinterpreting the ML order
10:29:17 <ais523> because for two-argument type constructors the syntax is IIRC dict: (string, int) map
10:29:26 <ais523> so, "int" is modifying "list" here rather than vice versa
10:30:14 <ais523> I guess you could compare to Haskell, which uses a similar syntax but in reverse: dict :: Map String Int
10:31:33 <fizzie> Go's map types are named `map[K]V`, is that a circumfix or a prefix operator, or both, or neither?
10:32:49 <ais523> postcircumfix is fairly common (object.method(args)), but I don't think I've seen a precircumfix operator before
10:35:28 <ais523> I guess [8]f64 is precircumfix too, so Go is being consistent there
10:35:58 <wib_jonas> huh, http://rosettacode.org/ is not reachable. that would be a useful way to look for various syntax.
10:37:42 <ais523> Wikipedia says it's www.rosettacode.org but that isn't reachable either
10:38:11 <fizzie> cppreference.com was being unusuably slow for me as well (wanted to double-check the std::tuple thing).
10:38:59 <ais523> I wonder whether these are side effects of the scraperbots
10:39:17 <ais523> although Rosetta Code was acting like it was intentionally down rather than overloaded
10:39:19 <wib_jonas> ais523: I think precircumfix for declaring arrays, with the type on the right and the size in the middle, is used in algol and pascal, so it's very old
10:39:31 <fizzie> I _think_ std::variant does the same thing as std::tuple w.r.t. allowing std::get<type>(x) if `type` uniquely determines the member.
10:39:46 <fizzie> (And std::get<N>(x) with an index in any case.)
10:40:37 -!- wib_jonas70 has joined.
10:40:53 -!- wib_jonas has quit (Killed (NickServ (GHOST command used by wib_jonas70))).
10:40:58 -!- wib_jonas70 has changed nick to wib_jonas.
10:41:03 <wib_jonas> fizzie: I think I have a downloaded copy of the important parts of cppreference.com at home, in case it disappears
10:41:42 <ais523> oddly I don't think I've used it
10:41:50 <ais523> generally for reading up on C and C++ I use draft standards
10:42:13 <ais523> that said, I don't program in C++ much – mostly it's just to modify pre-existing C++ programs, and the ones I work with are generally written in very old dialects of C++
10:44:35 <fizzie> It's convenient for (informally) checking which standard version introduced a thing, since they're pretty good at having "since C++17" style annotations where appropriate.
10:45:22 <wib_jonas> ais523: in Haskell, `let { DECLARATIONS } in EXPRESSION` is a postcircumfix operator that gives an expression
10:45:57 <ais523> you mean precircumfix?
10:46:07 <ais523> OCaml does that too, let a = b in c
10:46:52 <wib_jonas> also C typecasts are precircumfix like (double)4
10:47:00 <ais523> I should probably learn C23 at some point, primarily out of curiosity – newer versions of C don't seem so useful given that I expect most newer programs to be written in some safer language nowadays
10:49:10 <wib_jonas> I'm trying to understand something about the library interface of inter-thread synchronization, I asked yesterday starting from https://logs.esolangs.org/libera-esolangs/2025-05-19.html#l3 , I think some of you might be able to help because I think I'm missing something here
10:53:23 <wib_jonas> also, the SIGBOVIK 2025 proceedings have been released for like a week now. I have read only little of it so far, but it's SIGBOVIK so there'll probably be parts interesting or inspiring to this community in there
10:53:49 <ais523> it wouldn't surprise me if the pthreads API fundamentally didn't make sense
10:55:12 <ais523> wib_jonas: <POSIX> The pthread_mutex_destroy() function shall destroy the mutex object referenced by mutex; the mutex object becomes, in effect, uninitialized.
10:55:38 <ais523> I think this explains it: it *uninitialises* a mutex obejct, which is why calling it twice is UB (because you're calling it on an uninitialised variable)
10:56:50 <ais523> I can imagine a pthreads implementation where statically initialised mutexes are pointers to static variables that store mutex state, whereas pthread_mutex_init()ed mutexes are pointers to dynamically allocated memory
10:57:05 <ais523> I'm not sure that that's necessarily a sensible implementation, but it seems to be consistent with the standard
10:57:29 <wib_jonas> ais523: pthread_mutex_destroy twice is an undefined behavior makes sense, sure, my problem is why the manual says that pthread_mutex_init twice is an undefined behavior instead of just a resource leak. unless there is some pre-initialization that I must do before I call pthread_mutex_init, but if there is I don't know of it
10:58:11 <ais523> the POSIX rationale talks about machines which have a special sort of memory for storing mutexes, and where statically initialised mutexes allocate it lazily
10:59:29 <ais523> oh, it does mention why double-initialising is UB – it's to allow the implementation to return an unlisted error code in cases where it detects that that happens, rather than silently accepting it and leaking memory
10:59:49 <ais523> this would be better off as unspecified behaviour, I think: "either leaks memory or returns EBUSY"
11:00:38 <ais523> that said, I can see potential anything-happens UB if it ends up unlocking the mutex in the process of reinitialising it
11:01:14 <wib_jonas> oh, so you mean there'd be a separate table that has the mutex insides, and this has pointers back to the pthread_mutex_init handles that points into it, and pthread_mutex_init would look up what the existing handle points to with bounds checking and checks if the back pointer points back, and that way it can detect double initialization which is
11:02:35 <ais523> the Rationale doesn't explain how they expected implementations to check for double-initialisation, just that they were expecting that some could
11:03:11 <ais523> scanning a list of allocated mutexes seems like the only possibility?
11:04:06 <ais523> or, well, wouldn't have to be a linear scan, you could have a hashmap of them or something
11:04:28 <wib_jonas> no, it's not the only possibility. if you can rely on reading uninitialized memory as an integer array index without UB then you can do the back pointer thing.
11:04:54 <ais523> ah right – that's a sort of map in its own way, of course
11:05:08 <ais523> I forget what it's called
11:06:10 <wib_jonas> yeah, it's just one that's hard to use with the way current language standards handle reading from uninitialized memory. but if you're implementing a mutex you can probably able to rely on some machine-specific low-level detail that can bypass that.
11:06:26 <ais523> it has lead to a lot of acrimony in the Rust community because it can't be correctly implemented in Rust atm, not even by (e.g.) reading the potentially uninitialised memory with inline asm
11:07:27 <ais523> and the Rust developers don't want to add a way to do it until someone can prove it correct, which would probably need documenting the exact assumptions the optimiser was allowed to make in every possible scenario, which is a lot of work
11:08:21 <wib_jonas> yes, but even if you don't want to do this in a new library, an existing old library could be doing this and someone wanted to implement a pthreads interface over it
11:08:23 <ais523> the issue is that it's fine at the hardware level, but very difficult to prove that you aren't violating some assumption that the optimiser might theoretically be able to rely on in future, even if it doesn't at the moment
11:09:26 <wib_jonas> even if it's possible, I don't like this restriction in the library interface though.
11:09:29 <ais523> (partly because what the optimiser is and isn't allowed to do isn't specified anywhere)
11:10:11 <ais523> I got as far as proving that it's safe if the optimiser doesn't assume anything based about program executions that actually occurred based on program executions that could have occurred, but didn't
11:10:56 <ais523> or, well, not that exactly, it was a related operation (reading from memory that might be racily updated in paralle,)
11:11:13 <ais523> * in parallel, but ignoring the read value unless you can prove after that fact that no race happened
11:13:13 <wib_jonas> you can still use that sort of "uninitialized" structure if you only do it on memory that's low-level initialized earlier and you're just reusing such memory for a new array without reinitializing it, but that doesn't work in this weird mutex case
11:18:49 <ais523> in any case, this has convinced me that the POSIX decisions aren't completely ridiculous
11:19:02 <ais523> but I suspect it'd make more sense to use something Valgrindish than trying to do it from within the program
11:19:57 <ais523> I guess some sort of asan-like thing would make sense, but if it's defined as UB then detected UB should core dump rather than just returning an error code
11:20:18 <wib_jonas> I can see why the language definition people are worried about reading uninitialized memory because it could be a problem for future optimizations. If it's ever allowed I think it would be better to use some special primitive operation that copies bytes from potentially uninitialized memory, rather than allow it for ordinary reads.
11:21:59 <ais523> wib_jonas: the debate is about adding such a primitive
11:22:20 <ais523> I agree it should definitely be a separate primitive – but the Rust developers don't want to commit to the primitive even being possible to implement
11:22:27 <wib_jonas> yeah, and that'd have to be done on the llvm side
11:22:33 <ais523> LLVM already has such a primitive
11:23:04 <ais523> although it's awkward naming because the word "freeze" is also used in other contexts
11:23:44 <ais523> but the semantics are "given an uninitialised/poisoned/undef input, return an arbitrary bit pattern, otherwise return the value of the input"
11:25:57 <wib_jonas> I wonder if there also exists some old or exotic hardware where reading a word of memory that hasn't been initialized since poweron causes actual hardware level undefined behavior because an unclear signal from the bus can poison the CPU. Of course on such hardware you'd typically low-level initialize all the memory before you start to do anything
11:25:58 <wib_jonas> useful, so it wouldn't come up in practice.
11:26:05 <ais523> that said, I am somewhat unconvinced by the way LLVM makes decisions about optimiser semantics
11:26:18 -!- amby has joined.
11:27:21 <ais523> there was a bug a while ago where two optimisations conflicted with each other, optimising a correct program into an incorrect one, and LLVM decided to work around the problem by changing the semantics of load operations so that they would load undef if racing with a write (rather than doing UB) in order to make one of the optimisations valid
11:27:44 <ais523> but I'm not sure they checked all the other optimisations to make sure they were consistent with the change (rather than just the optimisation that was assuming that it would be UB)
11:48:52 <wib_jonas> how does that even work? is it not UB only if the load or the conflicting store is done from code compiled with llvm as opposed to code compiled by something else and linked?
11:57:00 <wib_jonas> and then there's the whole thing about how the language lets the programmer do floating-point arithmetic with the floating-point control bits changed. most code is compiled assuming that the control bits must be at the default as the ABI requires. so C introduced a new pragma for this, to say that a part of your code doesn't assume that. then in
11:57:01 <wib_jonas> code surrounded with such a pragma, you can change the control bits. that's the rounding mode, the bit for input operand denormals are zeros, the bit for output operand denormals are zeros, and the floating point exception mask. I personally don't care much about the last one, and the rounding modes are probably best handled by new built-in and
11:57:01 <wib_jonas> library functions that do operations with a certain rounding mode. but the two denormal flags are harder, you do often want to run a longer calculation with those enabled, and it would be inconvenient to write all code that works that way without some more convenient syntax than named library functions, but the code doing that still has a different
11:57:02 <wib_jonas> ABI from normal so the pragma seems like the best solution. IIRC rust doesn't seem to have an equivalent of the pragma yet.
11:58:14 <wib_jonas> and this can be tricky on the compiler and optimizer, because they suddenly have to know a lot specifically about the floating-point control flags, like what commutes with changing them because it does no floating-point operations etc.
12:05:49 <esolangs> [[User:Cycwin/sandbox]] N https://esolangs.org/w/index.php?oldid=158105 * Cycwin * (+221) Created page with " There will be my ideas there. You can edit them any time(please let me know who you edited this page are). ==About onechar== in onechar we only have <pre>:loop a (b) jp loop</pre> So how can we jump above >2 lines code?"
12:20:41 <esolangs> [[User:Cycwin/sandbox]] https://esolangs.org/w/index.php?diff=158106&oldid=158105 * Cycwin * (+0) /* About onechar */
12:57:47 -!- impomatic has joined.
12:59:34 <impomatic> ais523: basic scissors can be done in 5 instructions.
13:00:07 <ais523> that's actually quite impressive
13:01:23 <ais523> <wib_jonas> how does that even work? is it not UB only if the load or the conflicting store is done from code compiled with llvm as opposed to code compiled by something else and linked? ← it's not UB in general, it just reads an undefined value – all the hardware LLVM supports will return *some* value upon a racy read, even if it has no connection to reality, rather than (e.g.) crashing
13:02:52 <impomatic> There's actually quite a good spread of strategies, and the settings are pretty good if you want to evolve a competitor using genetic algorithms.
13:15:07 -!- impomatic has quit (Quit: Client closed).
13:24:37 -!- impomatic has joined.
13:32:18 -!- impomatic has quit (Quit: Client closed).
13:33:14 <esolangs> [[Irma]] https://esolangs.org/w/index.php?diff=158107&oldid=157944 * Neon * (+2282)
14:03:47 -!- molson has quit (Remote host closed the connection).
14:03:57 -!- molson has joined.
14:09:47 <esolangs> [[Special:Log/newusers]] create * Bits bytes * New user account
14:12:42 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=158108&oldid=157973 * Bits bytes * (+169)
14:35:03 -!- visilii_ has quit (Ping timeout: 265 seconds).
14:41:35 -!- isabella has changed nick to iza.
14:43:42 -!- wib_jonas has quit (Ping timeout: 240 seconds).
14:48:53 <esolangs> [[User talk:I am islptng]] https://esolangs.org/w/index.php?diff=158109&oldid=158022 * Hotcrystal0 * (+334)
15:29:51 -!- impomatic has joined.
15:33:41 -!- tromp has joined.
15:34:35 -!- tromp has quit (Client Quit).
15:37:17 -!- tromp has joined.
15:50:24 -!- visilii has joined.
16:04:01 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
16:27:02 -!- tromp has joined.
16:29:17 -!- FreeFull has quit (Quit: Lost terminal).
16:46:12 <esolangs> [[User programmed]] https://esolangs.org/w/index.php?diff=158110&oldid=158078 * Hotcrystal0 * (+47)
16:48:22 <esolangs> [[User programmed]] https://esolangs.org/w/index.php?diff=158111&oldid=158110 * Hotcrystal0 * (+0)
17:00:58 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
17:02:36 <esolangs> [[Nya~*kwrgsfish+-HQ9`:'"rbtAzxdi8]] https://esolangs.org/w/index.php?diff=158112&oldid=151994 * Qawtykit * (+695) laying out the commands into tables so its easier to read
17:21:50 <esolangs> [[User programmed]] https://esolangs.org/w/index.php?diff=158113&oldid=158111 * Helpeesl * (+88)
17:27:03 -!- tromp has joined.
17:33:29 <esolangs> [[User:TenBillionPlusOne/Draft]] https://esolangs.org/w/index.php?diff=158114&oldid=158012 * TenBillionPlusOne * (+502)
17:42:29 -!- Melvar has quit (Quit: WeeChat 4.6.0).
17:47:46 <esolangs> [[Burn]] https://esolangs.org/w/index.php?diff=158115&oldid=134283 * Aadenboy * (+31) /* see also */
17:55:12 <esolangs> [[User:TenBillionPlusOne/Draft]] https://esolangs.org/w/index.php?diff=158116&oldid=158114 * TenBillionPlusOne * (+316)
17:58:03 -!- Melvar has joined.
18:08:18 -!- impomatic has quit (Quit: Client closed).
18:08:38 -!- impomatic has joined.
18:38:20 <esolangs> [[Main Page/lex]] N https://esolangs.org/w/index.php?oldid=158117 * Neon * (+1810) Created page with "==Introduction== Lex is a variant of pseudocode consisting of mainly letters and symbols. It was inspired by the P" (P double prime) primitive programming language created by Corrado Bohm. It is not meant to have be executed and is instead meant to illustrate the str
18:56:15 <esolangs> [[Talk:Main Page/lex]] N https://esolangs.org/w/index.php?oldid=158118 * Aadenboy * (+322) Created page with "why is this a subpage of the main page? ~~~~"
18:57:08 <esolangs> [[Special:Log/newusers]] create * TheKillerBunny * New user account
19:01:07 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=158119&oldid=158108 * TheKillerBunny * (+131)
19:01:26 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=158120&oldid=158119 * TheKillerBunny * (+78)
19:03:49 -!- impomatic has quit (Quit: Client closed).
19:13:01 <esolangs> [[User programmed]] https://esolangs.org/w/index.php?diff=158121&oldid=158113 * Hotcrystal0 * (+132)
19:14:08 -!- impomatic has joined.
19:14:27 <esolangs> [[User programmed]] https://esolangs.org/w/index.php?diff=158122&oldid=158121 * Hotcrystal0 * (+36)
19:15:54 <esolangs> [[User:TenBillionPlusOne/Draft]] https://esolangs.org/w/index.php?diff=158123&oldid=158116 * TenBillionPlusOne * (+153) /* Examples */
19:19:56 <esolangs> [[User:TenBillionPlusOne/Draft]] https://esolangs.org/w/index.php?diff=158124&oldid=158123 * TenBillionPlusOne * (+198)
19:20:49 <esolangs> [[User:TenBillionPlusOne/Draft]] https://esolangs.org/w/index.php?diff=158125&oldid=158124 * TenBillionPlusOne * (+8) /* Examples */
19:22:18 <esolangs> [[Special:Log/move]] move * TenBillionPlusOne * moved [[User:TenBillionPlusOne/Draft]] to [[Transformation is complete]]: Finished the esolang
19:22:42 -!- HackEso has quit (Ping timeout: 252 seconds).
19:22:56 <esolangs> [[Transformation is complete]] https://esolangs.org/w/index.php?diff=158128&oldid=158126 * TenBillionPlusOne * (+65)
19:23:28 -!- HackEso has joined.
19:24:57 <esolangs> [[User:TenBillionPlusOne]] https://esolangs.org/w/index.php?diff=158129&oldid=157834 * TenBillionPlusOne * (-34)
19:25:44 <esolangs> [[User:TenBillionPlusOne/Draft]] https://esolangs.org/w/index.php?diff=158130&oldid=158127 * TenBillionPlusOne * (-40) Blanked the page
19:28:10 <esolangs> [[User:TenBillionPlusOne/Sandbox]] https://esolangs.org/w/index.php?diff=158131&oldid=157984 * TenBillionPlusOne * (-1020) /* Transformation is complete */
19:29:02 <esolangs> [[User:TenBillionPlusOne/Sandbox]] https://esolangs.org/w/index.php?diff=158132&oldid=158131 * TenBillionPlusOne * (+67)
19:29:54 <esolangs> [[Transformation is complete]] M https://esolangs.org/w/index.php?diff=158133&oldid=158128 * TenBillionPlusOne * (+13)
20:00:27 <esolangs> [[Transformation is complete]] https://esolangs.org/w/index.php?diff=158134&oldid=158133 * TenBillionPlusOne * (-23) /* Natural numbers */
20:19:16 <esolangs> [[Wheddo]] https://esolangs.org/w/index.php?diff=158135&oldid=158096 * Rombito * (-1)
20:25:03 <esolangs> [[Wheddo]] https://esolangs.org/w/index.php?diff=158136&oldid=158135 * Rombito * (+26)
20:32:14 <esolangs> [[Wheddo]] https://esolangs.org/w/index.php?diff=158137&oldid=158136 * Rombito * (-30)
20:41:39 <esolangs> [[Caca]] https://esolangs.org/w/index.php?diff=158138&oldid=156783 * Mari * (+175) Cell-based, unknown computational class, rather than all relative increments or decrements
21:03:35 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
21:06:42 <esolangs> [[User:XKCD Random Number]] https://esolangs.org/w/index.php?diff=158139&oldid=153906 * Mari * (+463) add Caca
21:21:06 <esolangs> [[Language list]] M https://esolangs.org/w/index.php?diff=158140&oldid=158092 * Buckets * (+11)
21:21:32 <esolangs> [[User:Buckets]] M https://esolangs.org/w/index.php?diff=158141&oldid=158065 * Buckets * (+10)
21:21:44 <esolangs> [[Whyn]] N https://esolangs.org/w/index.php?oldid=158142 * Buckets * (+900) Created page with "Whyn is an Esoteric programming language created by [[User:Buckets]] in 2021. The Starting Direction is 45 Degrees Clockwise then Normal. {| class="wikitable" |- ! Commands !! Instructions |- | R || Turn 90 Degrees Clockwise. |- | L || Turn 90 Degrees Anti-Clockwise. |- |
21:56:02 -!- impomatic has quit (Quit: Client closed).
22:10:39 -!- slavfox has quit (Quit: ZNC 1.8.2 - https://znc.in).
22:11:00 -!- slavfox has joined.
22:39:19 <esolangs> [[User:Buckets]] M https://esolangs.org/w/index.php?diff=158143&oldid=158141 * Buckets * (+0)
23:08:00 <esolangs> [[Special:Log/newusers]] create * Idkwhatever * New user account
23:21:03 <esolangs> [[User programmed]] https://esolangs.org/w/index.php?diff=158144&oldid=158122 * I am islptng * (+219)
23:32:26 -!- Sgeo has joined.
23:33:40 <esolangs> [[Esolang:Introduce yourself]] M https://esolangs.org/w/index.php?diff=158145&oldid=158120 * Idkwhatever * (+59)
23:33:52 <esolangs> [[Unibrain]] https://esolangs.org/w/index.php?diff=158146&oldid=74115 * Kaveh Yousefi * (+168) Added a hyperlink to my implementation of the Unibrain programming language on GitHub.
23:33:57 -!- amby has quit (Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement).
23:41:54 <esolangs> [[User programmed]] https://esolangs.org/w/index.php?diff=158147&oldid=158144 * Hotcrystal0 * (+21)
23:42:20 <esolangs> [[User programmed]] https://esolangs.org/w/index.php?diff=158148&oldid=158147 * Hotcrystal0 * (+0)
23:44:34 <esolangs> [[User programmed]] https://esolangs.org/w/index.php?diff=158149&oldid=158148 * Hotcrystal0 * (-44)
23:44:45 <esolangs> [[User programmed]] https://esolangs.org/w/index.php?diff=158150&oldid=158149 * Hotcrystal0 * (-4)
23:53:37 <esolangs> [[User talk:Hotcrystal0]] https://esolangs.org/w/index.php?diff=158151&oldid=158093 * Hotcrystal0 * (+324)
23:53:47 <esolangs> [[User talk:Hotcrystal0]] https://esolangs.org/w/index.php?diff=158152&oldid=158151 * Hotcrystal0 * (-1)
23:53:59 <esolangs> [[User talk:Hotcrystal0]] https://esolangs.org/w/index.php?diff=158153&oldid=158152 * Hotcrystal0 * (+24)
23:54:44 <esolangs> [[User talk:Hotcrystal0]] https://esolangs.org/w/index.php?diff=158154&oldid=158153 * Hotcrystal0 * (+75)
23:55:12 <esolangs> [[User talk:Hotcrystal0]] https://esolangs.org/w/index.php?diff=158155&oldid=158154 * Hotcrystal0 * (+289)
23:57:06 <esolangs> [[User talk:Ais523]] https://esolangs.org/w/index.php?diff=158156&oldid=158029 * Hotcrystal0 * (+431) /* Filter 16 */ new section
23:57:23 <esolangs> [[User talk:Ais523]] https://esolangs.org/w/index.php?diff=158157&oldid=158156 * Hotcrystal0 * (-3)
23:57:41 <esolangs> [[User talk:Ais523]] M https://esolangs.org/w/index.php?diff=158158&oldid=158157 * Hotcrystal0 * (+0)
23:58:59 <esolangs> [[User talk:Ais523]] https://esolangs.org/w/index.php?diff=158159&oldid=158158 * Hotcrystal0 * (+58)