Seems that retries are good when the error is rare, and bad when the error is common. Typically outages have you transitioning from "everything is fine" to "nothing works", so being able detect that transition early is helpful
Did you disable cookies or something? Table of Contents sidebar hides and stays hidden across page loads, browser restarts, etc. Appearance sidebar is the same. Appearance sidebar lets you set the article width as well, with the default being slightly slim, but the wide option being the full browser width.
The only way I can get it to reset is to clear my cookies, so its likely that.
But many artists are hallucinating when they envisioned some of their pieces. Who's to say Mozart wasn't on a trip when he created The Marriage of Figaro.
If you need to grab a particular struct's version of the data, you can via `opts.BarService.URL` or `opts.FooService.URL`: https://go.dev/play/p/MUSYJhmoC2D
Still worth being careful, but it can be useful when you have a set of common fields that everything of a certain group will have (such as a response object with basic status, debug info, etc. and then additional data based on the particular struct). I don't know why they let you embed multiple layers and multiple objects though. I've never gotten value out of anything but a "here's a single set of common fields struct embedding".
There aren’t grid-scale batteries that can handle hundreds of thousands of cycles at an affordable price. If we crack that problem, solar and wind for everything will immediately be the only technology worth deploying for energy in 99% of areas.
The appeal back then was being able to get all the shows you wanted on a single platform. Netflix had all of Disney, WB, ABC, CBS, NBC, etc. at one point, including strong original content. Going all in on $10/month for all the TV I wanted to watch was a good deal. Paying $15/month times 5 for a worse experience... not so much.
I don't remember any cable tv packages that were $10/month except for maybe getting the local tv channels because you couldn't get good reception with an antennae.
Cable TV packages were $20-$30/month (base packages) for 200 channels, of which 10 of them you really cared about, then you had to add on another $10-$40 depending on what it was to get what you wanted. So, to finally get the 10-15 channels you actually care about you had to pay $50-$75/month for 900 channels.
Like, if all you wanted was Disney, you couldn't just get Disney channel(s), you had to pay for 250+ other channels too. Now you can just sign up for Disney+ streaming.
US students are expected to be able to read 104 characters by the end of 6th grade. While Chinese students are expected to be able to read 20k words by that time.
Characters in Chinese can be combined to make more words, and you need around 9k words in English to read a novel and 2k characters in Chinese to read a novel.
It is wrong to compare number of characters in English to number of words in Chinese. The proper comparison would be words in English to words in Chinese. By 4th grade I knew enough English to proofread ycombinator posts. Of course, that is a low bar...
And I think you're off by an order of magnitude about vocabulary size. Chinese vocabulary size around 6th grade is more like 2K - 4k words tops, not 20K. See
I get that there are tradeoffs and that logographic languages have advantages and disadvantages.
In this case specifically though there seems to be a pretty strong consensus that one of the advantages of a phonetic alphabet is ease and time to learn.
In a completely phonetic language (which English is obviously not) once a kid learns the alphabet and around 50 phonemes you can represent with it, their auditory and reading vocabulary is roughly the same. So you can have 6 year olds with a reading vocabulary of 20k words.
It’s not that simple, but clearly the more phonetic a language is the easier it is to learn for someone who can already understand the spoken words.
Current models are lossy databases at this point. Carmack looks like he might be trying to get logical reasoning to work (learning something abstract in one context and applying it to a similar context). That is something that would advance the field significantly and may be possible with a small team of researchers.
Well, fnmatch really does two things, it parses the pattern and then applies that to a string, so really, there should be a "ptnparse" library that handles the pattern matching that fnmatch has a dependency.
Though, thinking it through, the "ptnparse" library is responsible for patterns matching single characters and multiple characters. We should split that up into "singleptn" and "multiptn" libraries that ptnparse can take as dependencies.
Oh, and those flags that fnmatch takes makes fnmatch work in several different ways, let's decompose those into three libraries so that we only have to pull in the matcher we care about: pthmatch, nscmatch, and prdmatch. Then we can compose those libraries based on what we want in fnmatch.
This is perfect, now if we don't care about part of the fnmatch functionality, we don't have to include it!
/s
This decomposition is how we wind up with the notorious leftpad situation. Knowing when to stop decomposing is important. fnmatch is a single function that does less than most syscalls. We can probably bundle that with a few more string functions without actually costing us a ton. Glob matching at a string level probably belongs with all the other string manipulation functions in the average "strings" library.
Importantly, my suggestion that fnmatch belongs in a "strings" library does align with your suggestion that fnmatch shouldn't be locked into a "glob" library that also includes the filesystem traversal components.
Seems that retries are good when the error is rare, and bad when the error is common. Typically outages have you transitioning from "everything is fine" to "nothing works", so being able detect that transition early is helpful
reply