"Developers, Apple’s new WeatherKit API lets you incorporate Apple Weather forecast data into your app and is available for iOS, iPadOS, macOS, tvOS, and web."
Sorry for your loss :-/
1,876 karma · joined November 2, 2010
"Developers, Apple’s new WeatherKit API lets you incorporate Apple Weather forecast data into your app and is available for iOS, iPadOS, macOS, tvOS, and web."
Sorry for your loss :-/
Not necessarily more hours or $$ spent on it, but more care.
Presumably by hiking residential tax rates and converting office space to residential, but the latter could take a long time…
Gives you a kb-vs-quality tradeoff graph.
A little over the top perhaps, but when you just need to do a couple of quick images… ;)
There are quite a few books written, so maybe transfer learning from that?
My reading of the concerns is that USDC has effective fork veto, and that with PoS the chain would be subject to OFAC, which would effectively destroy it.
(my reading may well be incorrect / the concerns irrelevant)
The mouse is participating in the positive sum game of joint savings, and the cat is robbing it blind (very negative sum as it's also robbing its future self).
There's a lot of that happening across society (healthcare, education, addiction-fueled tech companies, ...), and the people who do it oftentimes do end up (at least short term) better off (= rich), but we as a nation end up poorer (the whole negative sum thing).
There are however plenty of ways to become rich doing positive sum things (though lord knows it's harder than it looks), so there will be rich people who don't deserve the blame so to speak.
But the clearly visible, media-amplified cases will of course be cartoonish villains, all too eager to sell you the rope to hang them with so to speak.
(Whatever that means. Or don’t. Apply any and all advice to your situation, don’t just take the advice as stated ;)
Functions that need to return dynamically sized things take a *PointerScope parameter, which is a struct with two function pointers: malloc() and close().
The api function uses the provided malloc, the caller calls close when they’re done with the returned data.
This can then be used with a bunch of calls (and by the caller itself), and then at the end all the allocations get freed with one simple call.
Obviously the PointerScope would internally need to keep track of what was allocated, so it’s a far from simple struct&code combo, but should provide decent user ergonomics?
Add a create() function too, to create a new PointerScope and you have an entire malloc/free replacing resource management paradigm! ;)
What I believe OP is talking about is how the blockchain made it possible to incentivize people to mine, thereby delivering the service of the public good of the blockchain.
Sure, all of those individual points are of perhaps debatable value, but he acknowledges that while maybe mining or staking aren't quite it yet, the fundamental blockchain tech still enables decentralized coordination and the creation of a public good through private incentive.
Which is no small feat.
Note that for ch<O(512) (varies by GPU & hw) you tend to be memory-transfer-speed limited, not compute limited.
So unfortunately depthwise convolutions end up having terrible performance.
(There’s probably a lot more to it, and this may not be a factor at all)
So it would take the long text, bulletize the main points, and then you can tap to expand any of them to see the details, recursively.
Just a thought…
That’s a pretty high exposure?
Why not stack a few layers of corrugated steel/ceramic plates to try to split the jet apart?
Basic theory would be to present the projectile with a surface that has drastically different amounts of resistance across the front of the projectile, in the hope of destabilizing it & the jet it creates.
I guess it would make the armor quite thick, but with varying density/composition it may not end up that much heavier?
(And maybe it just wouldn't work ;)
Static vs dynamic makes for such difference in the detailed workflow, both in terms of changing existing code & in terms of writing new/(more) from scratch code, yet they can both be quite fruitful, and can both be abused in absurdum.
It seems like people naturally fall into one of the two camps (either by personality or by training), and the other side just seems kind of insane: "how can you even work that way!?". Then culture and idioms emerge over time and strengthen the tribalism.
I've gone back and forth between the two over the course of my career, and it's quite a mind-shift when switching, with a fair bit of pain involved ("but it would be so easy to do this in [old language]", or "what the hell is this garbage anyway!?") and then eventually it settles in and it's not all painful, all the time ;)
(Going back and forth between Scala and Python right now, so this hit a bit of a nerve)
My concern with UBI is more that we're unlikely to be able to fix it if it's actually terrible - once in place, handouts tend to become sacrosanct regardless of efficacy (I'm sure that are exceptions that prove the rule ;) - and it is stupendously expensive.
How about Universal Basic Assistance instead?
We tend to make government assistance be "hard shell, soft center", i.e. hard to qualify for, but once you're in, it's all gravy, unless you do something silly like get back on your feet (see unemployment & disability).
What if we instead switched to a "soft shell, firm center" approach and made it really easy to access assistance funds, but they e.g. got gradually reduced over time as you tap into them? And perhaps you have some skin in the game with a required personal emergency fund? And perhaps you owe some of the assistance $$ back, so that the average person "pays for themselves" over the course of their life?
Just spit-balling. I'm sure there are tons of problems with such an approach as well. But maybe it would still be quite useful for the recipients, and a lot more palatable for the tax payers = more reasonable to actually implement?