Readit News logoReadit News
uasi commented on Lix – universal version control system for binary files   lix.dev/blog/introducing-... · Posted by u/onecommit
uasi · 2 months ago
Git can display diff between binary files using custom diff drivers:

> Put the following line in your .gitattributes file: *.docx diff=word

> This tells Git that any file that matches this pattern (.docx) should use the “word” filter when you try to view a diff that contains changes. What is the “word” filter? You have to set it up [in .gitconfig].

https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...

uasi commented on Code and Let Live   fly.io/blog/code-and-let-... · Posted by u/usrme
karmajunkie · 2 months ago
yeah reading further into the docs it looks like that’s the model. storage is pretty cheap, $.00068/gb-hr, so a 100GB disk runs you about 1.6 cents per day.
uasi · 2 months ago
1.6 *dollars
uasi commented on Go.sum is not a lockfile   words.filippo.io/gosum/... · Posted by u/pabs3
djha-skin · 2 months ago
> Instead, just look at go.mod. It lists the precise version at which all dependencies are built.

No, it does not. Minimum version selection means that the libraries will at least be that version, but it could be substituted for a later version if a transient dependency asks for such.

That I'm reading this blog post at all suggests there is a "market" for a single checksum/version manifest, which data is currently housed in go.sum . This is sad, but, Hyrum's Law and all that.

uasi · 2 months ago
I'm not deeply familiar with this, but from reading the `go mod tidy` manual[1], it seems that running `go mod tidy` loads all packages imported from the main module (including transitive dependencies) and records them with their precise versions back to `go.mod`, which should prevent them from being substituted with later versions. Am I understanding this correctly?

[1]: https://go.dev/ref/mod#go-mod-tidy

uasi commented on Japan to revise romanization rules for first time in 70 years   japantimes.co.jp/news/202... · Posted by u/rgovostes
kazinator · 3 months ago
> 塔 can be pronounced as tou

No it can't, unless someone is spelling it out, or singing it in a song where it is given two notes, or just hyper-correcting their speech based on their knowledge of writing.

Annoyed speech and such can break words into their morae for empahsis, which breaks up dipthongs.

E.g. angry Japanese five-year-old:

ga kkō ni i ki ta ku nā i!!! (I don't wanna go to school!!!)

"nā i" is not the regular way of saying "nai". The idea that "nai" has that as an alternative pronunciation is a strawman.

uasi · 3 months ago
You're right. I looked up 現代仮名遣いの告示 [0] for the first time, and it says 塔(とう) is officially pronounced as "too". I had it backwards - I thought that 塔 is "tou", but due to the varying sounds of う, people could (and often preferred to) pronounce it as "too" in everyday speech.

This kind of misconception seems not uncommon. There's an FAQ on NHK's website [1] that addresses the question of whether 言う(いう) is pronounced "iu" or "yuu". The answer is "yuu", and the article make it clear that: "It's not that [iu] is used for polite/careful speech and [yuu] for casual speech - there is no such distinction."

I think native speakers learn words by hearing them and seeing them written in hiragana, before learning the underlying rules, so they know "too" is written as とう, but might not realize that とう shouldn't be pronounced as "tou" or いう as "iu". These are at least less obvious than cases like は in こんにちは never being "ha".

Personally, if I heard someone say 塔 as "tou" or 言う as "iu", I probably wouldn't count it as incorrect, nor would I even notice the phonetic difference.

[0] https://www.bunka.go.jp/kokugo_nihongo/sisaku/joho/joho/kiju...

[1] https://www.nhk.or.jp/bunken/research/kotoba/20160801_2.html

uasi commented on Japan to revise romanization rules for first time in 70 years   japantimes.co.jp/news/202... · Posted by u/rgovostes
kazinator · 3 months ago
Your comment is astonishing.

If you know the word 方, that it is /ho:/, and you know that it has a う in it when written out, how can you not know that う stands for making the o long? The only vowel is the long o.

Japanese kindergarten kids can recognize hiragana words with "おう", correctly identifying it as /o:/. By the time they learn the 方 kanji they would have seen it written in hiragana upmpteen times, like AよりBのほうがいい and whatnot.

uasi · 3 months ago
Well, speaking for myself, I internalized how う is pronounced differently in different contexts when I was young, and by now I've almost forgotten there's a difference I need to be conscious of.

When I hear /ho:/ in a certain context, "ほう(方)" immediately comes to mind, without noticing that what I heard was a long o. To me it's just the う sound. And if someone pointed to their face while saying /ho:/, I'd think it's the お sound as in "ほお(頬)".

uasi commented on Japan to revise romanization rules for first time in 70 years   japantimes.co.jp/news/202... · Posted by u/rgovostes
BalinKing · 3 months ago
Could you elaborate on the last sentence? Wiktionary claims they're pronounced the same modulo pitch accent, but Wiktionary's phonetic transcriptions are (mostly?) auto-generated AFAIK.
uasi · 3 months ago
塔 can be pronounced as tou, too, or somewhere between the two. It depends on the speaker, speaking style, and possibly dialect. Either way, Japanese speakers rely more on context and pitch accent than actual pronunciation, so it communicates fine.
uasi commented on Japan to revise romanization rules for first time in 70 years   japantimes.co.jp/news/202... · Posted by u/rgovostes
Anon1096 · 3 months ago
負う and 王 are both hepburn-romanized as ou though. 方 and 頬 (hou vs hoo) is a better example. I don't really think native speakers still distinguish these.

Feel free to try listening yourself though:

頬, note that it has multiple pronunciations but we only care about hoo: https://forvo.com/word/%E9%A0%AC/#ja

https://forvo.com/word/%E6%96%B9%E3%80%80%EF%BC%88%E3%81%BB%...

In some cases though there is still a clear difference in pronunciation for most speakers, ex 塔 vs 遠

uasi · 3 months ago
> 方 and 頬 (hou vs hoo) is a better example.

As a native Japanese speaker, this example is eye-opening. I hadn't even realized that the u in 方 is pronounced as /o:/ — I believe most Japanese people haven't either, despite unknowingly pronounce it that way.

Also, I have no idea how to Hepburn-romanize 方 vs 頬, 負う vs 王, and 塔 vs 遠. If I had to romanize, I would just write it as whatever the romaji input method understands correctly (hou/hoo, ou/ou, and tou/too, in this case).

uasi commented on Japanese game devs face font dilemma as license increases from $380 to $20k   gamesindustry.biz/japanes... · Posted by u/zdw
kouteiheika · 3 months ago
> I guess designing a font for a language with 2100 different characters is probably a hassle.

The ~2000 is the official count taught in schools, but the actually "commonly" used number in literature is around ~3000. And you actually want more than that, because people's names can use weird kanji which are used nowhere else.

On the other hand, the vast majority of kanji are actually composed of a limited set of "subcharacters". For example, picking a completely random one:

    徧  ⿰彳扁
The '徧' is composed of '彳' and '扁' arranged in a horizontal pattern. Unicode even has special characters (⿰,⿱,⿶, etc.) to describe these relationships.

So this actually makes creating a CJK font somewhat easier, because you can do it semi-algorithmically. You don't have to manually draw however many thousand characters there are, but you draw those "subcharacters" and then compose them together.

uasi · 3 months ago
Although many kanjis can be algorithmically composed, manual adjustment of each character's shape is still necessary for production-grade fonts. For example, if you closely compare the 彳 radical between 徧, 行, and 桁, you'll notice subtle differences in width, stroke length, angle, and margin.
uasi commented on Fastmail desktop app   fastmail.com/blog/desktop... · Posted by u/soheilpro
ho_schi · 5 months ago
Electron is Flash for the Desktop.

https://josephg.com/blog/electron-is-flash-for-the-desktop/

   * Non-native UI toolkit
   * Massive waste of resources (CPU, RAM, Battery, Disk). Consumption of 500 MB RAM for idle is the norm.
   * Slow.
   * Often issues with autonomous, local operation.
   * Security -> Browser Engine
It is always better to use a well-working application with your native UI-Toolkit:

    * Linux: Evolution, Geary, K-Mail, Claws, whatever TUI application you prefer. And Thunderbird.
    * macOS: Apple Mail or Thunderbird.
    * Windows: Please. Stop using Windows. You harm other people. Start with using Thunderbird :)

The “Electron” from Signal is one of the best applications using Electron. It is fat. Even in this case people resist. Signal isn’t supporting a stable API but: https://github.com/boxdot/gurk-rs

TUI :)

Electron is used, when a company wants to save on developer. All users pay with suffering from bad UI and their hardware resources. In this case it is something nobody asked for?

uasi · 5 months ago
Thunderbird is no different than Electron apps, though. It's built on a browser engine, renders UI written in HTML + CSS (+ XUL partially), consumes ~500MB of RAM on idle, etc.
uasi commented on AtomVM, the Erlang virtual machine for IoT devices   atomvm.org... · Posted by u/ahamez
revskill · 9 months ago
Why did people reinvent the wheel with JVM while there's already Erlang VM ? Java did poisionate so much generations of people.
uasi · 9 months ago
JVM predates BEAM.

u/uasi

KarmaCake day99July 26, 2015View Original