Stacked PRs track changes through updates and can be integrated progressively as they get validated.
They also allow reviewing commits individually, which is very frustrating to do without dedicated support (unless you devolve back to mailing list patch stacks).
Yes, except with a proper UI. Also while you could do this on GitHub before in the same way that that Gitlab feature works, it didn't work cross-repo so in practice it wasn't an option for most open source code.
I can't remember if Gitlab has the same limitations but I do remember trying to use Gitlab's stacked diffs and finding them to not work very well. Can't remember why tbh.
The big recess above the pins is what encases the button of the charger and provides grounding if it includes metal strips. Assuming the charger itself has a metal button.
In the EU a grounded cable has been the default forever (I have a grounded cable from my 2010 MBP which I use as travel cable for my 2021 MBP)
In my understanding of the Manley video, the materials change will only occur for Artemis 3, for which it will be irrelevant as that will not be leaving LEO.
Not sure why I'm being downvoted. Here's the segment where Manley explains this: https://youtu.be/shcj7MUK5BU?t=828 and this is also the section where Manley explains Artemis III is not going to the moon so it won't actually be testing this change.
> Engineers already are assembling and integrating the Orion spacecraft for Artemis III based on lessons learned from Artemis I and implementing enhancements to how heat shields for crewed returns from lunar landing missions are manufactured to achieve uniformity and consistent permeability.
Unions can be used as a somewhat safer (not safe by any means but safer), more flexible, and less error-prone form of transmute. Notably you can use unions to transmute between a large type and a smaller type.
That is essentially the motivation, primarily in the context of FFI where matching C's union behaviour using transmute is tricky and error-prone.
There are rare cases where all attributes of the C union are valid at the same time. Say you have a 32-bit RGBA color value and you want to access the individual 8 bit values. You can make a union of an 32 bit int and a struct that contains 4x 8 bit integers.
Also you can manually tag them and get s.th. more like other high level languages. It will just look ugly.
Yes. I once wanted C unions limited to fully mapped type conversions, where any bit pattern in either type is a valid bit pattern in the other. Then you can map two "char" to "int". Even "float". But pointer types must match exactly.
If you want disjoint types, something like Pascal's discriminated variants or Rust's enums is the way to go. It's embarrassing that C never had this.
Many bad design decision in C come from the fact that originally, separate compilation was really dumb, so the compiler would fit in small machines.
I assume it's anthropic rejecting the US Government's use of their software for domestic mass surveillance or fully autonomous weapons, and openai happily agreeing to it.
That has led to a significant number of people switching over from openai, or at least stating they were going to do so.
> Yes, it's also a systems language without a runtime. But that's not the novel part.
Low level strong correctness was absolutely a novel part. In fact it’s exactly why many people glommed onto early rust, and why it was lowered on the stack.
Although learnability and weirdness budgets were also extremely novel in low level contexts which had been subsumed by C and C++.
> horrors in C++
Yes, horrors in C++. Half baked jerry-rigged and barely usable nonsense. Not an industrial strength langage with a reliable type system and a strong focus on safety through types.
50 years of computing have proved pretty conclusively that less than that is wishful thinking at best. Large C++ programs, even with massive amounts of resources and tooling, can’t even get memory management correct.
reply