oshepherd
like, the use of christian symbology is arbitrary and it poses basically no meaning to the plot, merely being used for texture; but someone with sufficient knowledge of it can use it to predict some short term plot points.
'00' -> '000'
'01' -> '001', '010', '100'
'10' -> '011', '101', '110'
'11' -> '111'
Uh, mobile GPUs tend to be way, way ahead of desktop GPUs in Z-Buffer bandwidth (especially in relative terms)
and you can't increase your tile count; there's a fixed number of tiles in the frame buffer (unless you're referring to not drawing some tiles at all - in which case set your scissor rect appropriately. oh, and if you can find out the GPU's tile size round your rectangle up to cover whole tiles)
Given that <1% of the dark matter search space has been covered, this is an entirely unsurprising result.
The ΛCDM model doesn't come out of theory, it comes out of observation - the only thing we can make fit our observations of the universe is cold dark matter (and a cosmological constant, aka dark energy)
The thing a lot of people don't seem to get is that astronomers hate¹ dark energy and dark matter - they're really quite inelegant - but nothing else fits. Every other attempt (and lots and lots of time and energy have been spent on this) to explain our observations without hypothesising the existence of a lot of weakly interacting matter out there (e.g. MOND) has failed to match them
¹ In much the same way physicists dislike the standard model in all of its' ugliness - even though it works
They do tend to be 10x as annoying to debug though. Not more difficult - just tedious - especially because you often end up triaging what turns out to be somebody else's bug (i.e. a checker on your block fails, so you need to trace it back to somebody else, and often they also trace it outwards to somebody else).
And this is where using it as a class example gets really difficult - even people on the design team are specialists in their own blocks. Giving students all the knowledge they'd need to debug a problem would be incredibly difficult.
In this system, that would be 64 bytes.
Any halfword where bit[15:13]=='111' && bit[12:11]!='00' is the leading half of a 32-bit Thumb instruction
There is very little reason to use ARM code in ARMv7 and up.
Incidentally, ARMv8's 64-bit mode (AArch64) adds a whole new instruction set, called A64. It's fixed width 32-bit per instruction, and the only option for 64-bit code.
* Excluding some really obscure, mostly long deprecated ones
As for UB: Maybe it has less, but that which exists (e.g. noalias on mut refs) is very dangerous.
However.
This is a microkernel. There is very, very little code inside a microkernel which, if written in Rust, would not end up inside an unsafe block. You are building the safe abstractions here; that code is inherently unsafe.
You could use Rust as a C replacement, but it is a worse C than C, and unsafe rust contains more perils (i.e. UB) than C.
Type punning by union is implementation defined behavior. Everyone fortunately defines it to Do The Right Thing (TM).
The truly standard supported way to type pun is by memcpy
float f = ...; int x; memcpy(&x, &f, sizeof x);
The request for location data implies the usage of the location feature, so the Android package manager won't let you install it on devices without a coarse location provider.
Therefore, like most Android apps which lookup location information, it just assumed that it could do location lookups. No point testing for a feature which will always be present, right?
Now guess what would happen if you used AppOps to turn location off? That's right, it would crash.
Not exactly acceptable user experience.
Now, what Google should do is probably: * For apps targetting Android 4.5+, certain features with privacy implications will default to OPTIONAL rather than REQUIRED when implied by a permission request. * AppOps is then able to toggle access to features which are declared optional, which apps must handle the absence of anyway.