AprilArcus

The chromaticity diagram is basically a straight line between 640nm (red) and 545nm (green), so anything in between (including pure yellow around 570nm) can be reproduced with a linear combination of red and green.

RGBY televisions do exist, but their goal is to boost brightness in the yellow region, not color gamut.

It uses nonphysical "imaginary" primaries that have meaning within the coordinate system but not within the human perceptual system.

How did I know it was going to be `nvm` before I clicked?

The Australian-Vietnamese continuum is well-explained by Australia being the geographically nearest region which can supply native English language teachers to English language learners in Vietnam, rather than by any intrinsic phonetic resemblance between Vietnamese and Australian English.

Those seem like standard needs for any kind of CRUD app, so I would call this approach pretty useful. Currently I do something similar by keeping a private primary uuidv7 key with a btree index (a sortable index), and a separate public uuidv4 with a hash index (a lookup index), which is a workable but annoying arrangement. This solution achieves the same effect and is simpler.

Could this be used in reverse to correct for color vision disorders, e.g. by punching down greens and blues and punching up reds into the outer range of the P3 gamut?

I don't think R&T will ever ship at this point, since the browser vendors are apparently unwilling to absorb the complexity that would be required to add new primitive types with value semantics.

No, they run a headless neovim process in the background and sync its state with vscode

They'd need some very big RTGs to last that long, and I don't think we manufacture plutonium at the necessary volumes for that anymore.

of course this created an interoperability nightmare with third party libraries, which irrevocably forked Google's whole JS ecosystem from the community's 20 years ago and turned their codebases into a miserable backwater.

No, once the epiphyseal plates close further growth of long bones is impossible. Only intervention during puberty can influence final adult height.

The Japanese equivalent to emoticons are 顔文字 kaomoji, "face characters", and will be familiar as the horizontal ^_^ and (╯°□°)╯︵ ┻━┻ type of emotes.

It's from Japanese, a wasei kango (和製漢語) formation using on-readings of Chinese characters: 絵 (e, "picture") + 文字 (moji, "script"). The 字 (read ji) is the same as in 漢字 (kanji, "Han characters") and ローマ字 (rōmaji, "Roman characters". Exactly parallel to a neo-Latin / neo-Greek formation like "pictograph" (Latin pictūra, "picture" + Greek γράφω / graphō, "write, draw").

漢字 itself originates from Chinese, where it is pronounced hànzì in Mandarin and hon3 zi6 in Cantonese. It is also used in Korean, where it is pronounced hanja.

In Chinese, 絵文字 is orthographically borrowed as 繪文字 (traditional) / 绘文字 (simplified) — 繪, 絵 and 绘 all being alternate renderings of the same character. It is pronounced huìwénzì in Mandarin and kui2 man4 zi6 in Cantonese, according to the etymology of its constituent characters. In Korean it is borrowed phonetically as 이모지, imoji.

Unfortunately, Ruhlen, Greenberg, and Starostin's work relies on mass comparison and is neither rigorous nor noteworthy. Prefixing languages are rare and most have been suggested to be related to one another at some point on that basis alone, starting with Trombetti's unscientific speculation in the 1920s.

Ed Vajda brought rigor to the hypothesis in series of publications which established Dene-Yenesian through the comparative method starting in 2008 and continuing to the present. Nichols briefly and favorably reviews this bibliography in her paper. As a senior researcher in the field, she was one of Vajda's original advocates when his proposal made its splashy debut.

Well that's just what the Higgs field is, a scalar field with a nonzero vacuum expectation value. So the existence of a field of this kind isn't just possible in principle, it's been experimentally verified.

Apple could revoke Zoom's signing certificate, if they were discovered to be doing this.

This is a common idiom when working with generators, since iteration is controlled on the consuming side. Consider e.g. a trivial generator that counts up from one:

  function * makeSequence() {
    let i = 1;
    while (true) yield i++;
  }

  const ints = makeSequence();

  function sumTo(cutoff) {
    const ints = makeSequence();
    let sum = 0;
    for (let i = 0; i < cutoff; i++) {
      sum += ints.next().value;
    }
    return sum;
  }

custom menu commands that will appear in the File menu and the Dock context menu

This is pretty neat, but the "File" menu is sort of a vestige of a file-based approach to content management that isn't especially popular in the present era.

Web apps aren't usually file-based (e.g. Twitter, Facebook) or aren't file-based in a way that is exposed to the PWA's API (e.g. Figma). It would be better to put these in the application menu (the bold faced one with the application name to the left of "file").

<input type="checkbox" switch>

This grieves me a bit. Because the semantics of a checkbox and switch are identical, I wish it were handled at the CSS layer and not by means of an attribute. Then you could e.g. switch from checkboxes for desktop user agents to switches for mobile UAs using a breakpoint.

Hijacked? Can we not still use react-router in a standalone capacity as we have always done?

UUIDv4s are fully random, and btree indices expect "right-leaning" values with a sensible ordering. This makes indexing operations on UUIDv4 columns slow, and was the motivation for the development of UUIDv6 and UUIDv7.

the middle passage being a close third, by your reckoning?

The MCAS problem also involved:

• developing MCAS in the first place as a scheme to deny pilots simulator time on the novel flight characteristics introduced by the changed engine size and position (as a matter of marketing policy)

• deliberately failing to document the MCAS system to avoid attracting regulatory attention

• designing the system such that it only received data from the current pilot seat's ipsilateral air speed sensor, instead of reading redundantly from both air speed sensors, creating a single point of failure

it was a case of engineering incompetence upon moral incompetence.

I have one. The build quality is great. The tactility is second to none. And, it's so insanely loud that it's only really usable alone in one's own home.

I worked with her at Leap Motion, and found her to be incredibly intelligent, charismatic, energetic, compassionate, and candid. I think she will dazzle.

Cable has a nice little "3.0" logo embossed, but don't those fools at Elgato know that it's called USB "3.2 Gen 1x1" now?

FWIW, Babel has supported const enums for a few years now (since 7.15)

https://babeljs.io/blog/2021/07/26/7.15.0

OLED image retention makes them a bad match for desktop operating systems that have a lot of static elements like menu bars, docs, task bars, etc.

There will be an exact point at which a certain molecule has interacted with another molecule marking the exact point of perfect sleep.

I have some terrible news for you about statistical mechanics.

From about 3000 BC (the fall of the Cucuteni–Trypillia farming culture to the Yamnaya nomads) to about AD 895 (the conquest of the Carpathian basin by the Hungarians), each nomad community that settled down could count on eventually being conquered by one or another of their distant cousins who stayed on horseback.

I question whether the agricultural lifestyle is a better lifestyle for humanity than pastoralism in some kind of utilitarian or consequentialist sense, provided the conquest of and parasitism upon agricultural peoples could be factored out. Pastoralists had generally taller stature and better dentition than agriculturalists until the industrial revolution. Pastoralists maintained smaller populations, and avoided the negative externalities of settled agriculture, e.g. soil exhaustion under intensive irrigation, pests and disease from close-quarters living.

I also maintain a JVM which we run some backend JS libraries on via custom Nashorn builds. It's slow and drinks memory. Setting up a façade in front of a pool of ScriptEngine objects mitigates some of the startup cost, but I super don't like the idea of running React for server rendering. I would suggest standing up a NodeJS rendering microservice instead; we'd do it if arcane deployment reasons didn't preclude the possibility.