HN user
Herdr supports mobile-friendly layouts seamlessly, just like responsive web pages. On a narrow terminal, the sidebar is automatically hidden, and the tab bar is replaced with a status line (current workspace name, current tab name, and agent statuses). Everything else is tucked into the hamburger menu.
You can, but forks or branches need constant merging or rebasing (and sometimes conflict resolution) for each one. Clean/smudge filters are fiddly to set up correctly and almost certainly require shelling out to another program, which could break. The second-to-last thing you need is your hand-rolled solution breaking on a new environment. If and when you need several advanced features that a stable dotfiles manager already covers, why roll your own?
Git works until you need conditional logic such as platform-specific files or templating.
pnpm is written in Rust
Not just yet. The Rust rewrite of the installation engine is still experimental and available as an opt-in preview[0].
Got an incorrect result on my first try. Input was 振り仮名変換器の性能が如何程か試してみよう. It returned 如何(どう)程(ほど) instead of 如何(いか)程(ほど).
Regardless, I'm impressed with the tool!
Even with that workflow jj can help a lot. Haven't you ever been annoyed by situations like, while working on a few features at once, having unrelated changes from different feature branches piling up in the stash? Or wanting to switch to another branch mid-rebase without losing your place? jj's working-copy-as-commit model and its first-class treatment of conflicts address those pain points.
Those resources were a huge help when I was digging into the DEFLATE algorithm, thank you!
That number is unfairly exaggerated. The list includes ~40 internal keywords used only by language developers, plus dozens of tokens that would be called preprocessor directives, attributes, or annotations in other languages (e.g. `canImport` as in `#if canImport(...) #endif`; `available` and `deprecated` as in `@available(*, deprecated) func`).
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...
1.6 *dollars
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?
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
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 "ほお(頬)".
塔 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.
方 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).
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.
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.
JVM predates BEAM.
create a new global object named "Resource" which has the needed method prototypes that can be overwritten.
those methods could conflict with existing methods already used in other ways if you’d want to make an existing class a subclass of Resource.
Patchwork robes and non-orange clothes are common in Japanese Buddhism. The styles and colors vary significantly depending on the sect and one’s rank.[1]
[1] https://www2.ntj.jac.go.jp/dglib/contents/learn/edc28/shiru/...
The author uses something like `list.push(...objects)` in his demo code, and I believe this is the culprit. Passing many (~100,000) arguments to a method at once using the spread operator is known to cause a stack overflow, because, in JavaScript, each argument is placed on the call stack.
What do you mean?
`events.push(...arr)` puts all arguments on the call stack before calling the method, which causes the error. Don't push tens of thousands of items at once.
require(esm) is no longer behind a flag in v22.12.0+ and v20.19.0+.
As a Japanese person, I can confidently say that うな重が食い逃げした sounds nonsensical to Japanese ears. The verb 食い逃げ means the subject (うな重 in this case) ate something, not the other way around. Regarding euphemism, you could instead use expressions like うな重が消えた ("うな重 vanished") or うな重が旅立った ("うな重 set off on a journey") to metaphorically describe someone eating their meal.
But... come to think of it, even a native speaker may not be in a position to deny someone's finding about interesting similarities between Japanese and English sentences and possibilities of interpretation.
うな重が食い逃げした doesn't make sense at all. It literally only means that eel over rice itself ate something and fled away.
I think GP meant うな重は食い逃げした. This sentence can be interpreted as the same as above or "[the person] ate eel over rice [but not other dishes] and fled away".
Yeah, translators would probably lose their minds when they have to translate horribly ambiguous sentences like 今日はウナギ？行くなら行く。 (lit. "Is today an eel? If go, then go."), which means "Are they going to have eel today? If you go with them, I'll go too." or "Today's daily special is eel, isn't it? If you go, I'll go too."
Because Japanese is a notoriously context-dependent language, AI cannot accurately translate even simple sentences like "Daijoubu desu". Its meaning varies wildly depending on the context, such as "I'm fine", "He was okay", "We'll make it", "You can count on this", "No thank you", etc.
And context isn't always clear. It depends on where the conversation is taking place, where the speaker is looking, where speech bubbles are positioned, and if the author intends to mislead readers, the information necessary to understand the context might even be revealed in future episodes.
uv offers another useful feature for inline dependencies, which is the exclude-newer field[1]. It improves reproducibility by excluding packages released after a specified date during dependency resolution.
I once investigated whether this feature could be integrated into Mix as well, but it wasn't possible since hex.pm doesn't provide release timestamps for packages.
Does uv work with Jupyter notebooks too?
Yes![2]
[1] https://docs.astral.sh/uv/guides/scripts/#improving-reproduc... [2] https://docs.astral.sh/uv/guides/integration/jupyter/
Adding `foo = "*"` to Cargo.toml is as easy as adding `-l foo` to Makefile.