This works for both shiitake and button (portobello) mushrooms.
This trick came from Paul Stamets, one of the world’s foremost mycologist. He is based out in Casscadia. You may have to track down exactly what “2 days” means... I wouldn’t be surprised if he went looking for a way to maintain his Vitamin D health.
You only need 10g of this four times a week, according to this article. While it is summer time in Seattle, you can prepare a bunch and then dry them, so they last until next spring.
I recommend a bottle of chewables, placed somewhere you're likely to see it every day. It's makes it easier to get others to take their dose as well, if you take the water glass out of the equation.
Some teams turn on the switch in their compiler or linter that turns warnings into errors. Not many people invoke their compilers directly anymore, so disabling this requires digging into the build system configuration, which is not always simple (and as the OP mentioned, can require a full rebuild).
Sometimes this is even baked into the language itself. For example Go can be strict about unused imports and variables. Python is strict about having correct indentation.
Right - I understand all that, I just think it's not a good idea. The compiler makers made some things warnings and others errors for a reason, to disregard their input because you have some idea that "warnings are just as bad as errors and should never be permitted in even dev builds of my very highly precious code" is to me a sign of an over-controlling "principle engineer" somewhere behind the scenes that doesn't trust their team, which is not a work environment I'd want to be in. (In the go case, the over-controlling principle engineers creating a work environment I'm not interested in participating in are the language designers themselves!)
I introduce unused variables all the time when I'm debugging/exploring, which always get cleaned up before commit (this is programmatically enforced, which I think is reasonable), to need to go and comment out the declarations for each variable that goes unused if I comment out a section, just because some "principle engineer" somewhere on my team (or the language design team) thinks unused variables are the devil reincarnate and can't be allowed in any build whatsoever is frankly insane. (Don't even get me started on cases where commenting out the declarations changes behavior...)
> Some teams turn on the switch in their compiler or linter that turns warnings into errors.
That's completely self-inflicted. I really don't get why people do that instead of just fixing the warnings... except if one is in some position of power over environment configuration, but not over work results. Even then, why does that person care about work results?
One problem is the updates in toolchains that come up with new warnings, a lot of which are nuisances. Developers get tired of the make-work which that generates, either to fix the warnings or else identify where they are coming from and put in options to stop them.
The real problem are warnings that are super-useful (find a bug) about one out of twenty times (or less). The other nineteen times, they are false positives, such that refactoring the program to eliminate them is a fool's errand.
You don't want to turn off these warnings, and you don't want to fix all instances. So then you need per-file warning disabling, or start using compiler-specific #pragma-s:
The issue is incremental compilation. It is common (although not universal) that the way the build system (interpreted broadly) remembers that there are errors in unit X is that it has failed to produce a (new enough) unit X. In that setting, -Werror turns warnings from something that might not be surfaced in a (re)build into something that will be.
I think a good compromise is warnings aren't allowed in the final committed code (this can be enforced either by convention or with git hooks), but whatever you do locally is between you and your compiler. "What happens in the devbox stays in the devbox"
Generally I would hope that your CI build allows you to set this kind of configuration. (At the very least, you must have this as an option, because someone will run into it at some point and will have to turn your -Werror off.)
Code size can have something to do with it, but less than you think.
Basically, you don't notice warnings because you choose not to look.
Firstly, no matter how large the program is, if it builds without warnings and then a change is introduced which triggers a warning, it will be noticed. You only don't notice a new, potentially important warning when it is drowned out by "nuisance" warnings that you stopped caring about months or years ago. This tends to be a problem in larger programs worked on by many people, but it could easily affect a small, solo-effort program as well.
You perhaps don't notice warnings because the build log is too long to read, and you haven't put in CI process which scans logs for warnings and produces feedback.
When you build locally, you don't bother using an IDE which picks up all the errors and warnings out of the build output an lets you navigate through them. This can be a problem when people don't build locally; they just throw the code into some remote build system and if it goes "green", they "ship it".
This is generally why such a policy is often accompanied with "we don't want you introducing warnings; the policy is just relaxed while you're developing the code".
While perhaps satisfying, the issue is that this usually does little good in that the person you are directing this at will rarely change their ways in response.
So you change your ways I bet, to accommodate the stubborn cargo cultists who cause toil for you. Here's an alternative for you to consider. Say yes, I can absolutely support you, but if you believe that cc is an ada linter, then you can't use the project in 'preferred form' you have to link against the finished .so / .a binaries, and include the ANSI C89 preprocessed header file amalgamation, which will enable you to use whatever compiler flags you want, but you won't get the benefit of all the fancy macro optimizations and such.
Most of "feeling sick" isn't the actual bacteria/virus causing problems, it's your immune system doing things like raising your internal temperature to fight off the virus or generating boatloads of phlegm to do whatever that does.
Good reason to pull all crypto into fiat ASAP, store it in a real bank (or really, diversify it - user said that was the "vast vast majority" of their savings, that should never be all in one asset), and report it as other income on your taxes.
In general I'd say that most "higher functioning" Bitcoin users are fairly decent with C++, using CLI/TTY only wallets, and familiar with the cypherpunk movement, culture, and history. If you are not familiar with IRC it makes it sound like you just started using a computer the last couple years.
I agree it's probably a joke, but I'm not so sure that the core idea is actually impossible... I could reasonably see a SaaS that simply provides a quick and dirty key-val store. The code is just a translation from REST to REDIS which could easily be done in 2 lines, the value-add is the hosting.
That'd actually be pretty helpful for initial prototyping, where you want to have state shared across devices but don't want to bother with hosting a backend at first, and localhost wont work because the client wants to play with it too.
My guess from the list of premium airports is that Microsoft has made a judgement based on wealthy geek density. People love to fly their local or familiar airports, and the kind of people in San Francisco who play flight simulator are wealthier than most. All the premium airports are either tech or financial hubs.
If you take to time to set up incremental compilation, it's really quite fast. For reference, updates to the vscode repo (~5k files) take generally <300ms to recompile, and even incrementally updating after pulling in a batch of hundreds of commits takes only ~10 seconds.
It's concerning to me that the deno folks chose giving up on type safety over figuring out how to set up their development environment to better meet their needs.
Really hoping this is better by the next few months or my Seattle winter will be even more pill popping to maintain basic human functionality....