Did a brief scan of the repo. Looks like a lot of it comes from adding new headers. This commit adds +#include <linux/wait_api.h> to 1627 files for instance.
I have the 2021 model 3, you have a physical button to fire them off once (and to do the cleaning cycle), but to manually set the speed you need to use the touchscreen. There is an auto mode, of course, but sometimes you do need to adjust it manually.
I agree… and to amplify the point, pressing the physical button, in addition to kicking off a needed wipe, also brings the adjustment right up unobtrusively on the screen in case it’s needed.
And then, not that anyone needs to touch the screen normally (because auto mode as you say) but if they aren’t all triggered by such a possibility and want to, those multiple layers of on-screen UI (that the haters are always imagining having to click through) simply are not there because it’s already been surfaced.
A driver can even learn to use it with muscle memory without looking, since it comes right up in the same closest corner of the screen with the same layout every time. Again not that anyone would ever need to because auto mode.
I don’t know why people have to have such strong opinions on things they know nothing about.
Getting everything back up again will probably be a nightmare. Imagine all the internal services trying to reach a consistent state after such a long outage.
I believe that's exactly the point. You don't set all to 5px and then override using a special rule that says 0px for the last. You exclude the last element from the 5px rule.
There might be other rules, browser, user that should not over the 5px rule
I disagree. If a 5px margin is the general rule, then I would argue it's cleaner to apply it generally, and then apply the 10px margin exceptions in separate rules.
- When special cases are added or removed, the general rule won't have to be adjusted, just code that handles the special cases.
- On the other hand, a single general rule that specifically avoids application to multiple exceptional cases will be pretty long and have multiple :not()s, thus reducing readability and maintainability.
Why burden the general rule with knowledge of its exceptions? To me, doing so is a (small) violation of the principle of separation of concerns.
plus it's called "cascading style sheets". you're going against the current if everything wants to be so specific. This is one of my gripes with styled components.. it makes it easy to forget the power of cascading rules!
For me, forgetting the cascade has nothing to do with it; in my use cases, styled-components is all about:
- eliminating the chance of colliding CSS class names when composing multiple micro-clients together
- simplifying builds, especially cascading builds (library + client). It's nice when styles are covered entirely by the JS build (no separate CSS/SCSS input or output files or separate build pipelines).
Yes, there are other complexities/problems that styled-components adds (including the likelihood that devs will forget about the cascade)... so I wouldn't recommend it for every case. But it does have its place.
As I understand it it's not about the value but that first a rule is applied to all elements and then a new rule overwrites the previous rule for some element, the last one in that example.
To quote the article referenced in the article: "I call this technique disabling selector since the li:last-child selector disables the previous selector's rule."
So the 10px margin for the last element is a disabling selector.
In the long run it would've. It was mandatory to pay if you owned a TV. They tried to collect it for people having laptops / mobile phones but it was ruled illegal in the courts.
Instead the government replaced it with a new tax which seems more fair.
The headline said that the author was specifically looking to avoid 'xhtml self-contained tags', but that doesn't mean they could assume the document they were looking in was valid XHTML - just that it might contain XHTML-style 'self-closing' tags.
I've seen plenty of plain HTML files that aren't well-formed XML yet contain <br/> tags.
Yeah the trailing slash in <br /> is legal in HTML, but it doesn't actually make the tag self-closing. For example <b /> is still an opening tag which require a </b>.
Coroutines in Kotlin can be convenient, but they are overall about 20% slower than non-suspending code. I didn't spend too much time investigating the cause, but I believe it's because of the extra object that is passed along in all method calls.
In my case, I have a programming language interpreter implemented in Kotlin, and as an experiment I made the entire interpreter using suspending calls so that I could call asynchronous functions, and my performance tests dropped by about 20%.
As I understand it, Kotlin coroutines generate what is known as irreducible control flow. This means that loops have more than one entry point, or equivalently, there are loops that have a goto jumping into the body from the outside. (Java the language and I believe also Kotlin the language don't have goto, but the Java bytecode does.)
Irreducible loops make many optimizations much more complex. Bytecode generated by javac never contains irreducible loops, and since bytecode generated by javac is the number 1 use case targeted by JVM JIT compilers, they probably just don't bother trying to be that smart about irreducibility.
https://git.kernel.org/pub/scm/linux/kernel/git/mingo/tip.gi...