Some open source projects use Slack to communicate, which is a real ram hog. Github, especially for viewing large PR discussions, takes a huge amount of memory.
If someone with a low-memory laptop wants to get into coding, modern software-development-related services are incredible memory hogs.
It has also made it easier than ever to build native applications that use the os provided toolkits and avoid adding a complete web-tech stack to everything.
Wildly incorrect title, and I am not happy I had to watch through a typical youtube-minecrafter to verify that.
Java's memory safe, a real memory overflow would be interesting. This is just about triggering out-of-memory on saving a chunk by making that chunk very large. The title is wrong imo.
I'm not sure if it even makes sense for a TOML file to be "read incrementally", because of the weird feature of TOML (inherited from INI conventions) that allow tables to be defined in a piecemeal, out-of-order fashion. Here's an example that the TOML spec calls "valid, but discouraged":
[fruit.apple]
[animal]
[fruit.orange]
So the only way to know that you have all the keys in a given table is to literally read the entire file. This is one of those unfortunate things in TOML that I would honestly ignore if I were writing my own TOML parser, even if it meant I wasn't "compliant".
I don't think that's worse than having to search an arbitrary distance for a matching closing bracket. There are tasks where you can start working knowing that a given array in the data might be appended to later (similarly for objects).
It's worse than having to parse a matching bracket, because any context where you have an item defined via nested brackets is going to be a subset of this use case. But yes, that doesn't mean you couldn't do some theoretical eager processing, but it's going to be context dependent. For example, consider a Cargo.toml file, where we've processed the `features` key for a given dependency. Is it safe to begin compiling that dependency with the given set of features before we finish parsing the file? No, because there might be a `default-features=false` key that applies to this dependency later in the file. In a format where tables weren't allowed to be split, the mere act of parsing a single, self-contained dependency entry would be enough to know for certain that no such `default-features` key exists. Not all potential keys are going to require this sort of consideration, but it could be a footgun depending on the semantics of your schema.
The same technical detail that makes it so the "Default Navigation App" toggle to change the default from 'Apple Maps' to 'Google Maps' only shows up if you live in the EU but not in the US.
No one has presented a remotely correct fix anywhere on that issue, or elsewhere to my knowledge.
You're welcome to write an actually correct patch for android if you want, one that isn't just commenting out code and probably breaking some spec-compliant bluetooth devices.
Make sure to test your patch against all the bluetooth devices in existence to make sure it doesn't regress.
Do that, make a PR, wait the average third-party-android-PR review time (approximately 5 years), and then if your PR isn't accepted at that point we can maybe say Google is intentionally ignoring this issue.
Nobody actually productively commenting in the thread thinks it's a conspiracy theory and everyone acknowledges that the Apple hardware is off-spec. It would be nice to see Android add this workaround.
You have linked me to what sounds like an AI generated comment. AI comments cannot be trusted. AI will make up believable sounding gunk and cannot be trusted.
Being able to say "Our server never sees user-input license plate numbers", even though from a technical perspective the hash is just as identifiable, does have value. Even though it offers no additional privacy, it does let non-technically-minded users and so on feel safer, and that's valuable.
I think it can be read more charitably, the last bit includes "with positive intentions", which does act to indicate the outcome is bad, even though no one involved necessarily intends to make a scam-machine.
The direction I pick up from the piece is "Here's why this system is weird, that has some unfortunate outcomes, but that's the way it is" without any explicit call for action. If anything, it seems to accept the status quo as too difficult to change, while pointing out negative side-effects there.
You missed step 3 - click the first result, which is an Ad for a some shovelware app with an almost identical name and icon to the real thing and which displays ads.
For example, my friends told me about wordle and said they play it on an app on their phone. I search "wordle" in the app store, and the correct app is the 4th result, after an ad and some other gunk.
My friend told me I should use "Google Authenticator", the first result is an ad for another paid authenticator app that uses the Google logo in its first screenshot to try and confuse people into downloading it instead.
The Apple App Store is actively hostile to users. I thought the point of iPhones was you could give them to your technologically illiterate parents without them getting phished, but I guess those times are gone.
It's gone from "search something in the app store and install the first result" to "google '<term> iOS app store' and click the first result", that gives you better safer results.
If someone with a low-memory laptop wants to get into coding, modern software-development-related services are incredible memory hogs.
reply