matvore

I think you would need to have a compiler intrinsic type which is 16 bits. That is what the stdint.h file would define (u)int_16 to.

It would be odd for there to be a compiler intrinsic type to be unavailable until a header was included.

The compiler intrinsic type could be a mess like __int16_exactly_t but without it stdint.h would have some magic line which makes a compiler intrinsic available which wasn't before, or generates a new 16-bit type ex nihilo.

So you could have a "#pragma expose_extra_types" in stdint.h but that would not be the conventional approach.

I mostly wanted to make the point that a mere "at least 16 bits" type is not sufficient for some use cases, which is not in response to you but the comment you responded to.

You would still want a native 16 bit type in order to have a pointer to a 16-bit memory location, including an array of 16-bit values.

> Moving to the "four stroke" category, we can see 切 ["cut", today qiē]. This is as clear > as they come: it has a phonetic component 七 [today qī], and a semantic component 刀 > ["knife"]. There is absolutely no possibility that it could be interpreted as 会意, because > the meaning of the phonetic component is "seven".

Originally, 七 meant to cut vertically and horizontally (confirmed on a few sources).

Regarding 與 and 与, the site shows the breakdown for the former and shows how it was the older form for the latter. I guess you didn't actually click on the characters and look for the explanation. The analysis shows it comes from 牙+口+舁. The last is the meaning as well as pronunciation, the meaning being "hold up, carry together"

> > I confirmed a few, and they seem correct.

> Really?

Yes I did click through and read a couple of explanations.

As for 圓, according to the site the inner portion actually represents a picture of a 鼎 (ding). It is surprising to me, and a lot of this is theoretical and there will be more than one opinion. That same site doesn't say 員 itself is related to ding.

> if you search baidu for it you'll find a total of zero uses

There is a page on it right here. I cannot read Chinese but putting the first section into Google translate there is nothing surprising here. It also has examples. https://baike.baidu.com/item/%E4%BC%9A%E6%84%8F%E5%85%BC%E5%...

I learned about 沌 quite a while ago when I studied the first few chapters of Genesis in Japanese (混沌 was used to describe the earth in Gen 1:2) and something jogged my memory when I was looking for examples.

The dictionary link I posted had あつまる、水があつまる in the first definition. I don't know if that's a reliable dictionary. Maybe you think it's not?

> - This is a meaning assigned long after the character came into existence, which means it > cannot have informed the construction of the character.

I don't know anything about which meanings were used first and which were added later, but what you say sounds believable.

> - There's still no "gathering" or "accumulating" sense. (Nor is there an "obstruct" sense of 屯.)

Let me clarify. Even without the first sense for 沌 in the above dictionary (あつまる、水があつまる) some of the other definitions for 沌 had "gather" included in it conceptually, namely clog and joined together without distinction.

This phenomenon we are talking about is called 会意兼形声文字 and this site seems to have a lot of accurate examples: https://okjiten.jp/20-kaiikenkeiseimoji.html#google_vignette

I confirmed a few, and they seem correct. I thought 界 was the most easily understood example. 介 means being between two things and contributes the pronunciation. 界 means region, span, separate, division.

According to https://kotobank.jp/word/%E6%B2%8C-2789579#goog_rewarded 沌 has a meaning "gather, water gathers"

There are other meanings to it.

I admit I had a hard time finding an example.

A component can contribute meaning as well as pronunciation. 沌 is pronounced like 屯 and they both have a kind of "gather" "clog" meaning

  > Obviously the proper solution is to adjust your system thermal management / power targets,

My point is that I understand the users' complaint and request for a revert, not that I can't address this for my own machines. The proper solution for non-technical people is to ask the expert to fix it, which may include undoing the change if they were never interested in the process finishing faster anyway.

I did solve this problem once upon a time by running the process in a cgroup with limited CPU, though I later rewrote my dwm config and lost the command, without caring enough to maintain the fix.

If the fan was turning on where it wasn't before, it seems like cooling was once happening through natural dissipation, but after your fix it needed fans to cool faster. So the fix saved time but burnt extra electricity (and the peacefulness of a quiet room.)

This is pretty easy to understand IMO. About 70% of the time I hear machine's fans speed up I silently wish the processing would have just been slower. This is especially true for very short bursts of activity.

  > all of the languages mentioned so far appear before the "Latin alphabet" 
  > style languages, but 閩南語 and 閩東語 appear after them.

Could it have something to do with Minnan and Mindong Chinese articles being written in a Latin script, (despite the language name showing in both Chinese characters and Latin letters) ?

The Wikipedia sort for the languages is as I stated above, with Literary Chinese and Japanese between Wu Chinese and Yue Chinese. I explained why it was sorted that way, because radical is considered first. You could not explain why Japanese appeared between Wu and Yue because you insisted and continue to insist that radicals are not used.

I didn't say sorting is never done by stroke count alone. But I have seen radical+residual stroke count much more often than stroke count alone. Probably a result of the content I'm accessing. It's mostly Japanese and not intended for children.

The dictionary and non-dictionary sorting distinction that you make doesn't sound like a real thing. The audience, the country, and the number of items sorted are bigger factors. But you're not wrong in that stroke count is sometimes used alone.

It is sorted FIRST by radical and SECOND by stroke order. This is roughly equivalent to the Unicode codepoint sort if you stay in the basic multilingual plane. The order also puts literary chinese afer wu Chinese, which breaks with a pure stroke-count sort:

中文 - 中 = 丨 + 3 strokes

吴语 - 吴 = 口 + 4 strokes

文言 - 文 = 文 + 0 strokes

日本語 - 日 = 日 + 0 strokes

粵語 - 粵 = 米 + 7 strokes

Note I work for Google and I've contributed to Chromium, though I'm not necessarily an expert on Chromium forks.

1. Google Chrome

This is offical Chrome you download from google.com and also comes on ChromeOS devices.

2. Chromium

This is what you get when someone builds Chromium from the official repo without access to confidential source.

Source is confidential for various reasons, and some code that seems should be confidential actually isn't, like Android-for-ChromeOS integration, some of which is here: https://crsrc.org/c/chrome/browser/ash/arc/

3. Ungoogled Chrome?

This seems a contradiction of terms. Only Google can build Chrome, so they are not likely to e.g. set Bing as default or remove Google password manager support.

4. Ungoogled Chromium?

A particular project run by a particular team which forks Chromium and removes pro-Google behavior and settings.

5. Googled Chromium?

I don't know the original context of the use of this term, but possibly this just refers to official Chrome.

Chromium is merely Chrome with only the open source parts. Chromium components are still implemented in a Google-controlled repo. So it has Google-oriented features and defaults.

This is the default font of my browser-based terminal emulator, http://github.com/google/werm, along with a handful of other retro fonts (uses the int10h.org ttf's--converted to bitmaps--which I suspect has all the same characters as Neue)

IMO it still looks rather nostalgic. I do remember using cmd.exe or command.exe in Windows 95 and later and this being the default (but it would different if you had a different legacy code page set, IIRC). Of course cmd.exe just rendered the pixels as-is, no emulation or retro effects.

Yes, let's take dozens of terminal emulator projects out of maintenance mode so app devs can individually and capriciously overload my shift and escape keys, because modern.

  > Context: Bitcoin miners have just adopted a 50% pay cut for themselves.

Miners don't decide the consensus rules. The nodes validate blocks, and the miners generate them.

The halvening timing was coded a long time ago, and in order to change it, the nodes would need to adopt the new code by installing updated clients, and at that point, you have a hard fork, because there will be nodes on the old rules, either accidentally through not updating or intentionally through using a modified core distro, and you have the new rules' valid blocks is a disjoint set from the old rules'.

The new rules' block set being a subset of the old rules' is a strictening of the consensus rules. A strictening consensus scheme is a soft fork and can keep the network in one piece.

So, there is no real way for the miners to avoid the halvening without a hardfork and a great risk to the network.

Some say hunky dory comes from "honcho doori" or 本町通り (personally I don't see how ki can come from cho)

I wish I knew awk as well as I know perl, since then I wouldn't need to hear recommendations for CPAN modules and spurious style prescriptions.

Perl has the advantage of only having one implementation, unlike sed and grep (e.g. BSD or GNU) and /bin/sh (can be one of many POSIX shells), so upgrading this pipeline to 100% perl is safer in some respects. The example in the article is light on details so it's hard to comment very deeply.

I have heard snarky Perl putdowns ad nauseam at work and on HN and may have regretted using it a handful of times but I can say worse or similar for other popular tools, languages...

If we're going to talk about unnecessary extra processes like useless cat, we should merge the head and grep commands into a sed, and possibly just merge everything into perl:

    <access.log sed -n '/mail/p; 500q' | perl -e ...

If perl is processing the file line-by-line then filtering lines by regex and stopping at line X is trivial, and you don't even need sed.

  > To prove a point, I spent an hour reading his opensource project
  > and found several resource leaks

This is asking a lot, but if you enjoy that, I would be thrilled if you could do the same for some of my C projects - nusort and werm under github.com/matvore.

  > To prove a point, I spent an hour reading his opensource project
  > and found several resource leaks

Sounds like some interesting case studies. Could you share some?

  > > if I find [… typo words(?) omitted … ] a leak in the code I
  > > usually refactor to make the correctness more obvious.

I should rewrite this as - if I find a leak that I accidentally introduced, I will refactor in the process of correcting it, to make the mistake harder to repeat and the correctness easier to confirm.

There are non-language mechanisms that help code run safely, like Wasm, which is a sandbox. Also msan and asan should be used more.

Thinking that changing the language is the right way to fix all the problems you mentioned still seems like a premature assumption. The fact that 100% perfection is worth pursuing at all costs is theoretical and you could be losing things more valuable in the process - e.g. FFI bindings suck, and the added fragmentation in having so many languages in the craft is a pernicious cost with a multitude of aspects to it.

Don't worry, we enjoy that kind of stuff.

I usually put all the resource freeing at the end of a function under a goto label, or only a few lines within the allocation, so it's easy to visually confirm everything is cleaned up. The way this commit frees the resources inside of if blocks is not how I would have done it. And if I find I let a leak in the code I usually refactor to make the correctness more obvious.

In this example, the fact that m3_ParseModule takes ownership of the wasm pointer is very tricky. It looks like there is still a leak but there is not.

If you store the number of zeros as value z, computing z+1 is O(log n) in the long run for unbounded values of z.

If you define predictable as computable with finite memory, it is correct.

If you have finite memory, you have a finite number of states and will eventually return to a previous state. In your example, you eventually will run out of memory to track the number of consecutive zeros.

  > No, they're crazy. I already have a window manager I like; I don't need my 
  > terminal to implement their own half-assed one,

Basically agree, though note that ssh and dtach and similar tools need to create pty's on the server and client ends because they implement essentially an adapter between a tty and a byte stream.

  > I notice no 1 second delay when switching modes with the Esc key, so perhaps 
  > this is something you can configure in your terminal.

This is configurable in Vim. ttimeoutlen, timeoutlen, and noesckeys are pertinent. tmux et al may also need tweaking.

What does `Ctrl + [` send to the terminal for you if not esc? In my experience these are always the same, so Vim shouldn't be able to tell the difference unless it's a GUI-integrated version like gVim.

Try to run `xxd` and then press Ctrl-V and either Ctrl+[ or Esc, then Enter and Ctrl+D. Typical terminal setups will show the same codes both times (1b0a for esc and \n).

Alt+Space (or Alt+J Alt+K Alt+B to go up, down, left one word from current position after returning to normal mode) is what I often do which should work universally.

  > I stick with emacs because of the modal and recursive minibuffer(s) (ie. command-line(s)). What vim setting do I change to be able to use normal mode down there?

Not a setting. Just press Ctrl+F when your cursor is in the command line. After that, and until you finish entering the command, you will be able to use Esc to go into normal mode again.