00:08:17 -!- Lord_of_Life has quit (Remote host closed the connection).
00:10:00 <ais523> !zjoust medium http://nethack4.org/pastebin/medium.bfjoust
00:10:00 <zemhill> ais523.medium: points 10.38, score 33.76, rank 5/47 (--)
00:13:06 -!- Lord_of_Life has joined.
00:17:55 <esolangs> [[User:DumbEsolangsOrgUser]] https://esolangs.org/w/index.php?diff=163637&oldid=163613 * DumbEsolangsOrgUser * (+33)
00:19:37 <ais523> !zjoust medium http://nethack4.org/pastebin/medium.bfjoust
00:19:37 <zemhill> ais523.medium: points 10.67, score 34.09, rank 5/47 (--)
00:27:12 -!- Lord_of_Life has quit (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine).
00:30:24 <esolangs> [[Dumbascii-2]] https://esolangs.org/w/index.php?diff=163638&oldid=163617 * DumbEsolangsOrgUser * (+787) /* Language Overview */
00:30:36 -!- Lord_of_Life has joined.
00:30:51 <esolangs> [[Dumbascii-2]] https://esolangs.org/w/index.php?diff=163639&oldid=163638 * DumbEsolangsOrgUser * (+2) /* Python IDE */
00:42:35 <ais523> !zjoust medium http://nethack4.org/pastebin/medium.bfjoust
00:42:35 <zemhill> ais523.medium: points 10.76, score 34.29, rank 5/47 (--)
01:04:33 -!- ski has quit (Ping timeout: 245 seconds).
01:09:55 <esolangs> [[BadEsolangIMadeForABet]] N https://esolangs.org/w/index.php?oldid=163640 * Mouldyair * (+3023) created page for BEIMFAB
01:18:54 <ais523> !zjoust medium http://nethack4.org/pastebin/medium.bfjoust
01:18:55 <zemhill> ais523.medium: points 11.26, score 34.79, rank 5/47 (--)
01:19:08 -!- ski has joined.
01:19:26 -!- 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).
01:24:36 <ais523> !zjoust medium http://nethack4.org/pastebin/medium.bfjoust
01:24:36 <zemhill> ais523.medium: points 11.29, score 34.82, rank 5/47 (--)
01:34:01 <ais523> !zjoust medium http://nethack4.org/pastebin/medium.bfjoust
01:34:01 <zemhill> ais523.medium: points 11.57, score 35.26, rank 5/47 (--)
01:36:36 -!- zzo38 has quit (Ping timeout: 272 seconds).
01:45:46 -!- ais523 has quit (Quit: quit).
01:54:01 -!- zzo38 has joined.
03:03:09 -!- chloetax has quit (Quit: Leaving).
03:03:31 -!- chloetax has joined.
03:06:44 -!- Lymia has quit (Server closed connection).
03:06:57 -!- Lymia has joined.
03:32:24 <esolangs> [[Gur yvsr]] M https://esolangs.org/w/index.php?diff=163641&oldid=163610 * Placeholding * (+5)
04:20:58 -!- ais523 has joined.
04:21:13 <ais523> !zjoust medium http://nethack4.org/pastebin/medium.bfjoust
04:21:13 <zemhill> ais523.medium: points 12.55, score 37.03, rank 5/47 (--)
04:35:46 -!- ais523 has quit (Quit: quit).
05:18:23 -!- Sgeo has quit (Read error: Connection reset by peer).
05:49:33 <zzo38> I read about the Legasm and I think of some things that could be done differently if I would be designing it better. The flag register seems only used for carry, so now it will be the carry register instead, set to 1 or 0 by addition and to -1 or 0 by subtraction, and the ones the adc and sbb will add the previous value of the carry register to the result.
05:51:44 <zzo38> For the insrtuctions that sign-extend immediate values, I would just have it automatically set all of the high bits regardless of the value, since otherwise you could use the unsigned variants if the value to set is a constant anyways.
05:55:35 <zzo38> I would also think to add instructions for multiplication and division, and for rotate through carry, and to have two stacks. (The push and pop instructions currently have many unused bits, so possibly some of them can be used to select any arbitrary register to use for the stack pointer.)
05:57:55 <zzo38> (The existing stack pointer can be used for subroutine calls.)
06:01:03 <esolangs> [[Pigs]] https://esolangs.org/w/index.php?diff=163642&oldid=163340 * Corbin * (+14) Remove undiscussed category. See also Deadfish, a likely influence.
06:17:31 -!- user3456 has quit (Ping timeout: 252 seconds).
06:18:13 <esolangs> [[(piggus)]] https://esolangs.org/w/index.php?diff=163643&oldid=162824 * Corbin * (+301) Fix categories. Refactor to emphasize that this is a TBS.
07:17:59 <b_jonas> strerror: thank you, I tried xinput --test-xi2 , and it does seem like I get subpixel precision mouse coordinates when I move the mouse slowly to not trigger mouse acceleration. I don't get much more precision than a pixel, but that of course can depend on the mouse and the speed setting, so I'm fine with that.
07:34:11 <strerror> b_jonas: Did it have temporal precision as well? (I'm not sure if xinput can determine this, you might need to do the mouse query in a tight loop)
07:39:08 <esolangs> [[OBrainfuck]] N https://esolangs.org/w/index.php?oldid=163644 * L4.m2 * (+481) Created page with "oBrainfuck is like brainfuck but the k-th <code>[</code> matches the k-th <code>]</code>. aka, the k-th <code>[</code> matches in C <code>goto Rk;Lk:</code> and the k-th <code>]</code> matches in C <code>Rk:if(*cur)goto Lk;</code>.<code>+-<>,.</code> work same. Thus,
08:06:16 <b_jonas> strerror: I don't know, with those arguments it's not printing any timestamps so it's slightly more tricky to test for that and I haven't tried yet, and I'm not familiar with xinput in general
08:06:36 <esolangs> [[Algebraic Brainfuck]] https://esolangs.org/w/index.php?diff=163645&oldid=145100 * Corbin * (+615) Fix capitalization. Update bluelinks. Stub a section on computability.
09:06:33 <esolangs> [[Computable]] https://esolangs.org/w/index.php?diff=163646&oldid=163203 * Corbin * (+3689) Sketch the Diophantine path. This wasn't part of my education and I'm going to have to do a lot of reading in order to shore it up; nonetheless this captures the important bits.
09:07:39 <korvo> I'm gonna have to sleep on this new section. Rice's theorem (and Gödel's first incompleteness) are very weird-tasting for Diophantine equations.
09:09:03 <korvo> Pick a sufficiently-strong language of arithmetic. Its set of proofs is Diophantine. Its set of WFFs is Diophantine. Its set of provable WFFs is *not* Diophantine; that's Rice's theorem! So there's a way to pen-and-paper all of the proofs that are valid, but not all of the provable statements.
09:27:20 <esolangs> [[Algebraic Brainfuck]] https://esolangs.org/w/index.php?diff=163647&oldid=163645 * Corbin * (+841) /* Computability */ A new approach to Halting for BF: BF can encode Diophantine searches! No input or output commands needed, just a pre-allocated output register.
09:29:16 <esolangs> [[Brainfuck]] M https://esolangs.org/w/index.php?diff=163648&oldid=156122 * RixTheTyrunt * (+262) /* Truth-machine */
10:34:31 <strerror> Perhaps the wiki could link to oddball, counter-intuitive (and in that sense *esoteric*) characterizations of RE
10:34:59 <strerror> Like Demaine & Hearn's game (a finite multiplayer game with finite hidden information at each turn), or the claimed proof of MIP*=RE (https://scottaaronson.blog/?p=4512)
10:36:16 <strerror> There have also been attempts to disprove the Navier-Stokes smoothness conjecture by constructing zeno machines in the model, though none have worked yet
10:47:47 -!- tromp has joined.
11:15:08 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
11:18:04 -!- tromp has joined.
11:18:54 <esolangs> [[GolfScratch]] M https://esolangs.org/w/index.php?diff=163649&oldid=141449 * Ractangle * (+488) /* External links */
11:19:08 <esolangs> [[GolfScratch]] M https://esolangs.org/w/index.php?diff=163650&oldid=163649 * Ractangle * (+1) /* External links */
11:25:00 -!- Lord_of_Life_ has joined.
11:25:36 -!- Lord_of_Life has quit (Ping timeout: 272 seconds).
11:26:20 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
11:29:45 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
12:53:32 -!- tromp has joined.
12:57:54 -!- amby has joined.
13:20:03 <esolangs> [[Espaol]] https://esolangs.org/w/index.php?diff=163651&oldid=81407 * MijiGamin1 * (-18) fixed beginning sentence
14:32:32 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
14:33:55 -!- Lord_of_Life has quit (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine).
14:42:24 -!- Lord_of_Life has joined.
16:06:27 -!- tromp has joined.
16:13:08 -!- ais523 has joined.
16:41:50 <esolangs> [[Dumbascii-2]] https://esolangs.org/w/index.php?diff=163652&oldid=163639 * DumbEsolangsOrgUser * (+85)
16:43:34 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
16:46:49 <esolangs> [[User:ChuckEsoteric08]] https://esolangs.org/w/index.php?diff=163653&oldid=163624 * ChuckEsoteric08 * (+12) /* 2024 */
16:49:15 -!- Lord_of_Life has quit (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine).
16:53:21 -!- Lord_of_Life has joined.
16:57:18 -!- Lord_of_Life has quit (Client Quit).
17:00:38 -!- Lord_of_Life has joined.
17:03:22 -!- gAy_Dragon has changed nick to Awoobis.
17:04:16 -!- Awoobis has changed nick to gAy_Dragon.
17:30:03 -!- tromp has joined.
18:35:35 <ais523> is there a general name for the type of garbage collector that looks through memory to determine what's unreferenced (e.g. mark/sweep, generational, compacting), as opposed to things like reference counting which can also be considered a form of garbage collection?
18:41:01 <korvo> "tracing", from "A unified theory of GC" https://courses.cs.washington.edu/courses/cse590p/05au/p50-bacon.pdf
18:44:10 <ais523> korvo: ah, that makes sense – I have heard the terminology before but forgot
18:45:03 <korvo> ais523: No worries. The unified theory is not even a decade old and we live in an industry that actively spreads misinformation about GC; it takes a lot of active effort to just kind of remember that this exists, and I had to dig for a few minutes to find it.
18:46:56 -!- FreeFull has quit (Quit: Lost terminal).
18:47:40 <ais523> korvo: although I'm not surprised about the misinformation, I don't think I've been on the receiving end of it much
18:47:45 <ais523> what sort of things does the industry say?
18:48:13 <korvo> GC is slow, interrupting, unmanageable, requires tuning, etc.
18:49:06 <ais523> fwiw I suspect that the "correct" way to do things is some sort of mixture where some things are GCed and other things have their allocation and deallocation times statically calculated and proven at compile time
18:49:58 <korvo> Sure. RPython has an explicit malloc-removal phase at compile time along with a choice of hybrid GCs at runtime, and all evidence suggests that this is the right direction.
18:50:13 <ais523> generational GCs existing is kind-of ridiculous from my point of view, because it's an optimisation to easily clean up the short-lived objects – but usually you can statically determine from the program when the short-lived objects need deallocating, and it is the long-lived objects which are more interesting to GC
18:50:26 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
18:51:06 <ais523> there usually seems to be about a 10× speedup when people port from GCed languages to Rust, but I suspect the speedup may be based more on the static typing than the lack of GC
18:51:33 <korvo> "Using [the BCR] framework, [BCR] show that all high-performance collectors are in fact hybrids of tracing and RC'ing. ...[The BCR cost model] allows the correct scheme to be selected based on ... performance requirements and the ... properties of the ... application."
18:52:01 <ais523> although they probably exist, I can't think offhand of any widely used languages which a) are GCed and b) have non-primitive types that are sufficiently static to optimise the generated code based on knowledge of the type
18:52:33 <korvo> OCaml? OCaml, Haskell, and RPython are all environments where GC is part of how I expect to reliably beat Rust on speed.
18:53:27 <ais523> hmm, I actually don't know that much about ocaml's internals, except for the "everything is either a pointer or an integer with one reserved bit" thing
18:53:30 -!- JAA has quit (Server closed connection).
18:53:40 -!- JAA has joined.
18:53:48 <ais523> (with the reserved bit being used to distinguish integers from pointers in memory so that a GC can trace them without having to know the types)
18:54:49 <korvo> My perspective is likely skewed. I see the C++ memory model that Rust inherited as a big speed barrier. Fortran's memory model is better, but both Haskell's lazy model and OCaml's strict model (or Cammy or other CAM-likes) have their own further advantages.
18:55:20 <ais523> Rust only shares C++'s memory model with respect to atomics/multithreading, I think – they're different in other respects
18:55:45 <korvo> Yeah, at the value level, OCaml values are just tagged. I don't know of a good writeup, but CHICKEN Scheme uses almost the same setup and there's a great post on that: https://www.more-magic.net/posts/internals-data-representation.html
18:57:09 <ais523> my thoughts on all this are along the lines of "it is definitely possible to do better than Rust, but I think I have to really understand Rust first in order to beat it"
18:57:38 <ais523> I think C may also be beatable (for code written idiomatically), primarily through compiler optimisations that wouldn't be valid in C
18:58:31 <ais523> err, I meant "via" rather than "through" I think, English is hard sometimes
18:59:00 -!- tromp has joined.
19:03:11 <ais523> English doesn't have an instructive case so we have to try to fake it using prepositions
19:07:52 <korvo> My experience is from Python-driven HPC, so maybe this is not something you've seen before, but IMO the atomics and multithreading *are* the issue. Suppose we have an embarrassingly-parallel for-loop and we're using something like OpenMP. When the compiler is optimizing blocks, it has to determine whether any pointers in the block are used elsewhere, because it needs to know whether it can safely remove loads/stores.
19:08:20 <korvo> *Fortran's memory model is better than C's model. It straight-up doesn't permit as much aliasing.
19:16:29 <ais523> korvo: nor does Rust's
19:18:14 <ais523> e.g. unless you use a type that is explicitly defined as a special case, function arguments that are references cannot alias with each other unless they are read-only, but the assumption that something is not aliased is less powerful than an assumption that it is read-only
19:19:09 <ais523> rustc puts an LLVM "noalias" attribute on every function argument (that isn't a defined special case or raw pointer) because of that, which is the same thing that Fortran's memory model lets you do
19:20:12 <ais523> (the guarantees for things that aren't function arguments are complex and not fully decided yet – I have been writing a blog post about it, it's the same blog post where I discuss how linear logic's ? seems to be present in Rust)
19:20:44 <ais523> but, LLVM only knows how to optimise based on non-aliasing assumptions for function arguments, because C and Fortran only have them in that location
19:21:10 <ais523> (to be precise: they don't alias each other nor alias global variables, that's true for Rust and for C restrict, I am not sure about Fortran but it probably has the same rule)
19:21:37 <ais523> and don't alias memory reached via each other either
19:22:10 <korvo> Yeah. Rust or e.g. Pony extend Fortran's approach by making it possible to have immutable objects, so that we *don't care* if they're aliased. If all the threads want to access some constant input data, then those accesses can be optimized away sometimes.
19:23:30 <ais523> anyway, atomics are one of those special-cased that are allowed to be aliased – they wouldn't be very useful otherwise
19:26:53 <esolangs> [[Onlydot]] N https://esolangs.org/w/index.php?oldid=163654 * DumbEsolangsOrgUser * (+374) Created page with "{{lowercase}} {{wip}} :'''Onlydot' writing in full in lower case, excepting start of proposal.'' '''[[onlydot]]''' is [[:Category:Joke languages| joke]] [[esoteric programming language]] where valid command is only <code>.</code>. =Language overview= onlydo
19:27:21 <esolangs> [[User:DumbEsolangsOrgUser]] https://esolangs.org/w/index.php?diff=163655&oldid=163637 * DumbEsolangsOrgUser * (+4) /* Newest Esolang */
19:28:00 <esolangs> [[User:DumbEsolangsOrgUser]] https://esolangs.org/w/index.php?diff=163656&oldid=163655 * DumbEsolangsOrgUser * (+15) /* O */
19:30:19 <korvo> Yes, definitely. But maybe atomics aren't necessary.
19:31:39 <korvo> In Monte, there aren't any atomic variables. Instead, everything is serialized into "turns", which are single deliveries of single events to a single thread. Any cross-thread communication is done via the same generic IPC mechanism as cross-machine communication: promises!
19:32:30 <ais523> I think atomics are mostly only necessary in cases where you need blocking-free algorithms, i.e. a guarantee that any given thread can make progress even if all others are paused
19:32:46 <korvo> To let threads share starting data, each thread can be given a transitively-immutable object. Incidentally, Monte modules are transitively immutable at import time. After that, they have to send messages asynchronously to communicate.
19:33:17 <ais523> signal handlers are a notable example of that, because they block the thread to which the signal was sent
19:33:53 <ais523> "how do you allocate memory from a signal handler" has been a longstanding area of interest for me, existing programming frameworks make it unreasonably difficult and yet it is a potentially useful thing to do
19:34:20 <ais523> (at least, it's unreasonably difficult if you want to be able to deallocate the memory again, from outside the handler)
19:35:54 <korvo> signalfd makes it straightforward on Linux. Taming signals is historically a nasty thing, and if it weren't for signalfd then I wouldn't have bothered at all.
19:40:55 <korvo> ais523: So, one other nice thing about any sort of referentially-transparent machine, whether it's lazy or strict, is that *any* algebraic optimizations are valid when inlining. SML/NJ, OCaml, GHC, and other popular compilers all have some sort of straight-line monomorphic detection phase that "strictifies" or "destackifies" with respect to that algebra.
19:42:18 <korvo> I don't know exactly how referentially transparent Rust is. I hear that LLVM Rust is already starting to be sensitive to phase ordering in LLVM, which is not a good sign.
19:44:01 <shachaf> ais523: You can just call mmap, right?
19:50:25 <ais523> shachaf: I was allocating small things, but I guess that *would* work
19:51:41 <ais523> korvo: Rust feels like it's kind-of sort-of meant to be referentially transparent but a lot of things break that in practice
19:52:27 <ais523> unsafe code allows you to do a lot of things that seem like the memory model shouldn't allow them, and yet it continues to be supported because it would break too much code if it wasn't
19:52:53 <korvo> ais523: Okay, good to hear. Or bad to hear, but good for my expectations. Or bad for my expectations because I shouldn't be so cynical...
19:53:36 <korvo> I suppose that the flip side of this is that there's thousands of lines of Monte code that merely reimplement standard floating-point routines because there wasn't a safe way to get those routines from existing C/C++ code.
19:53:38 <ais523> one thing I realised while working on the ? blog post is that the standard traits Clone and Debug can both be meaningful for both a) smart pointers and b) the objects they point to
19:53:54 <ais523> but, for Clone you usually want to clone the pointer itself and for Debug you usually want to debug the value inside
19:55:15 <ais523> and I think this is a design flaw – it feels like Rust wants a rule "implementing a trait on a value also implements it on smart pointers to that value", which means that Clone and Debug should probably really be CloneAs<T> and DebugAs<T> that let you specify which level of indirection you want to clone at or debug at
19:56:05 <ais523> ("feels like" is partly just feelings, but also partly soundness bugs that have come about as a consequence of people not realising that a custom reference (smart pointer) type and the object it points to could implement the same standard trait in entirely unrelated ways)
19:56:26 <korvo> Right. Move semantics suddenly imply subtyping rules, somehow.
19:56:58 <ais523> I don't think this is actually based on the move semantics, it's a different aspect of the language design and one that I don't think is as fundamental
19:58:12 <ais523> although, I'm also not sure the Deref/DerefMut traits know what they actually are – they have a defined API but it is less clear what they actually *mean*, in terms of what assumptions you can make when using that API
19:58:21 <korvo> In Monte, m`def x :T := z` desugars to roughly m`def &&x := makeBinding(T.coerce(z, null), makeFinalSlot(T))`. There are exactly two levels of underlying indirection (slot and binding) and they may only be captured or introspected in order to facilitate that .coerce/2 method.
19:58:34 <ais523> (other than "you can't make any assumptions because they are safe to implement with arbitrary code, thus anything that isn't guaranteed by the API isn't guaranteed by the compiler")
19:59:46 <korvo> This is another surprising limitation of C-style memory management: being able to take a pointer of a pointer *of a pointer* is too much; at some point, you're going to take a pointer into Somebody Else's Memory that you are borrowing for stack/locals.
20:00:36 <ais523> this is the whole Three Star Programmer thing that I named the language after, isn't it?
20:00:57 <korvo> In E or Monte, if x is a local name then `x` dereferences, `&x` gets the slot, and `&&x` gets the binding. There isn't a generic operator & which takes any value; it must be a name in scope, so `&42` doesn't do anything.
20:01:40 <ais523> in Rust you can use the borrow operator & on anything, if necessary it creates a temporary and gives you a reference to that
20:01:59 <ais523> you can write &&&42 and get a reference to a reference to a reference to 42
20:02:09 <ais523> I am not sure I agree with this
20:02:48 <korvo> We have the same ergonomics. m`var x := whatever; f(&x)` will pass a mutable slot, and m`def f(&x) { x += 5; ... }` accepts the mutable slot and sets it up in the local scope as something that can be mutated with augmented assignments.
20:02:49 <ais523> (the program will be rejected if the compiler can't make the reference live long enough, but there are at least two ways in which the lifetime of the reference can be extended, so it works in more cases than it looks like it sohuld be able to)
20:03:51 <ais523> one of the things I dislike most about Rust is how much it does that's implicit in the syntax, in order to try to make the program meaningful
20:03:54 <ais523> you can write it explicitly but usually don't
20:04:51 <ais523> in particular, pattern matches have a whole lot of dereferencing and referencing added implicitly – you can be explicit but usually aren't – and I basically end up relying on compiler error messages to work out what is or isn't a reference when working with htem
20:12:33 -!- user3456 has joined.
20:15:55 <ais523> korvo: thanks for your earlier link to the paper about how to hybridise tracing and reference counting – the content feels like information that is beneficial for me to know
20:16:29 <korvo> ais523: No biggie. It made a big splash in the JIT world a few years ago but doesn't seem to have become more popular.
21:11:43 <b_jonas> "Rust only shares C++'s memory model with respect to atomics/multithreading, I think" => also in that both allow memory to be in an uninitialized state where it's UB to read even as a type like uint8_t where any combination of bits is valid, even when writing the same memory would be fine
21:15:07 <b_jonas> in both C++ and rust if a vector allocates memory with more capacity than size, the memory will be in that uninitialized state, and the program has to make sure to initialize it before use
21:16:45 <esolangs> [[Maybegolf]] N https://esolangs.org/w/index.php?oldid=163657 * DumbEsolangsOrgUser * (+144) Created page with "{{Wip}} [[Maybegolf]] is [[esoteric programming language]] for golf, emphasis on the multitude of commands and the unification of some into one."
21:20:43 <korvo> I think that you can get uninitialized memory in GHC Haskell if you ask for it, with some sort of primitive Array type. It's not possible in Monte or Pony though.
21:21:23 <korvo> E and Monte actually have some determinism requirements. E never quite figured out randomness and Monte requires it to be passed around like an RNG monad.
21:24:00 <esolangs> [[Computable]] https://esolangs.org/w/index.php?diff=163658&oldid=163646 * Corbin * (+948) /* Via Diophantine equations */ Define Diophantine equations and sets. I need to figure out whether listability (effective enumerability) and Davis normal form need to be mentioned here.
21:42:01 <ais523> <b_jonas> also in that both allow memory to be in an uninitialized state where it's UB to read even as a type like uint8_t where any combination of bits is valid, even when writing the same memory would be fine ← so although Rust and C++ both do that, the rules are actually different!
21:42:29 <ais523> in C++, memory that is initialised using an object of one type can't be read through a pointer of a different type
21:42:43 <ais523> so memory isn't just initialised, it's initialised with a particular type
21:43:03 <ais523> Rust's rule is different, memory that has been initialised using any type can be read using any other type that can hold the same range of values, except for padding bytes
21:43:14 <ais523> so, e.g., Rust lets you read the second byte of a float as u8 and C++ doesn't
21:43:39 <ais523> this means that C++ needs a special case for "the type that memcpy uses to copy bytes around"
21:43:46 <ais523> whereas Rust can just use u8
21:44:31 <b_jonas> "<ais523> I think atomics are mostly only necessary in cases where you need blocking-free algorithms" => I think there's at least one more use case. Suppose you have a lot of small objects that are rarely shared and rarely written, but you can't prove that they aren't shared so you have to use some thread-safety for them. An inter-thread mutex in every object would be logical, but as the objects are
21:44:37 <b_jonas> small it would consume more memory and might even use more bandwidth to the memory shared between cpu threads, so accessing the objects atomically is probably better.
21:44:37 <ais523> the difference leads to some interesting consequences sometimes, e.g. in Rust's model it matters whether bytes are part of a pointer or not, so if you, e.g., reverse the bytes in a pointer by reading them as u8, then reverse them again, there's some issue with whether you're allowed to read from the resulting pointer or not
21:44:40 <b_jonas> But I'm not really sure about this.
21:44:45 <ais523> I think the answer changed to "you aren't" to "you are" recently
21:44:54 <ais523> * changed from "you aren't" to "you are"
21:46:12 <b_jonas> ais523: ah, so C++ has more complicated rules about what memory counts as uninitialized. true. I don't understand those rules much because they don't come up often in practice.
21:46:19 <b_jonas> at least not in the code that I write.
21:46:42 <ais523> b_jonas: occasionally I need to type-pun and have to remember the legal way to do that
21:47:04 <ais523> in C, I believe that memcpy is sufficient, as long as you memcpy the actual bytes you are reinterpreting and not a pointer to them
21:47:31 <ais523> in Rust, transmuting a pointer is sufficient (and transmuting a reference is OK as long as you match size and alignment and lifetime)
21:51:44 -!- callforjudgement has joined.
21:51:58 -!- ais523 has quit (Ping timeout: 256 seconds).
21:53:03 <b_jonas> ais523: re Deref/DerefMut, yes, I don't think there's much semantics they're supposed to represent, so you'd rarely write code that's generic over the trait. those traits are there to allow user code to define new types that can use a syntactic sugar of omitting the splat when you're calling a method. it's sort of like the Mul trait, which is there so you can define new types that can use the infix *
21:53:09 <b_jonas> operator for syntactic convenience, not because there's some general semantics that all Mul types satisfy.
21:54:02 -!- callforjudgement has changed nick to ais523.
21:54:27 <ais523> b_jonas: is that a generic "you"? I personally would write such code but I may be the only person who does
21:55:49 <b_jonas> "<korvo> In E or Monte, if x is a local name then `x` dereferences, `&x` gets the slot, and `&&x` gets the binding. There isn't a generic operator & which takes any value" => is that like perl package variables where you can use $x by value, use $x by reference (including assigning to it), or use *x by reference, but you can't go deeper.
21:55:52 <ais523> https://github.com/rust-lang/rust/issues/129147#issuecomment-3026624324
21:57:16 <ais523> (the link is me arguing that method receivers that are generic over Deref should be allowed, with caveats, and explaining why I want it)
21:57:40 <ais523> unfortunately I have to post it on Github because that's where Rust's issue tracker is
22:03:12 <b_jonas> "Rust lets you read the second byte of a float as u8" => not really related to the memory models, but fortunately Rust added a safe high-level wrapper for that now. and you might need to use it because the standard library still doesn't have a frickin' ldexp/scalbn or frexp/ilogb builtin. nor good ways to strigify floats for that matter.
22:07:13 <b_jonas> though float/int transmutes are an important enough special case that the library functions are worth it for other reasons even if you have a working ldexp/frexp like in C++
22:07:52 <korvo> b_jonas: Same sort of idea, I think, yes. I don't fully understand the whole Perl/PHP way of looking up names; there's probably a piece of history that I don't know.
22:08:03 <ais523> yes, float/int transmutes are in the standard library (and safe), I was quite impressed when I saw them
22:08:13 <b_jonas> I want to use them for serializing floats, manipulating nans, and more
22:08:15 <korvo> But E does heavily borrow from Perl. Some of E's pattern matching comes from the =~ operator, for example.
22:08:40 <b_jonas> korvo: piece of history => yes
22:09:07 <ais523> I even used them recently, except that I was writing a C program so I had to do the transmute with memcpy instead
22:09:50 <ais523> (the context was a "how many digits are there in this integer" function, which was being used in memory allocation code that calculated how long a string would eventually be when formatted)
22:10:05 <b_jonas> korvo: anyway, even for perl lexically local variables where that history isn't relevant, you can take a reference to such a local variable, but taking a reference to a reference isn't very useful, you'd just get a reference to a temporary and that temporary would be different each time
22:10:31 <ais523> in Rust, you can't normally ==-compare things unless they have the same level of indirection
22:10:56 <ais523> so when you end up with a double indirection (e.g. when iterating over a list of references without consuming it), you often end up with code like |x| x = &&6
22:11:30 <ais523> there are various ways to avoid this situation happening but sometimes the double reference is the most obvious way to express it
22:11:39 <ais523> (this is, of course, another way in which Rust fails at referential transparency)
22:12:00 <ais523> of course, in C++, prefix && has a different meaning to two prefix &s
22:26:15 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
23:10:16 -!- Sgeo has joined.
23:57:03 <esolangs> [[Crazy?]] N https://esolangs.org/w/index.php?oldid=163659 * Mouldyair * (+38979) Created page with "{{Wrongtitle|title=Crazy? I was crazy once. They locked me in a room. A rubber room. A rubber room with rats. And rats make me crazy.Crazy? I was crazy once. They locked me in a room. A rubber room. A rubber room with rats. And rats make me crazy.Crazy? I was crazy on