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]
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.
I see a number of issues, but don't have time to look into them.
1. Spreading when you probably don't need a copy: sortEntries. Sorting is probably where the overflow happens. Just sort in place or use Array.from or slice.
2. Excessive use of array functions. In my experience, a C style for loop performs better when you need performance. Create an empty array before, perform your business logic inside the block, and push to the array.
3. I don't know how filter is called, but it potentially loops through all of the events three times in the worst case.
4. paginate manually creates a JSON string from the returned entries. I don't know why, it seems inefficient.
`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.
It has nothing to do with architecture, but rather understanding how the DOM works. The DOM is notoriously slow, so you should never render a huge number of rows at once. You can render millions of rows in plain JavaScript without impacting performance.
Here, I have recreated your JS example with searching and filtering and it does not crash. It's trivial to reuse a similar approach with the real backend and real events from the event source.
The point should not be using the spread operator at all costs. There are other ways in javascript to push multiple elements in an array that are more efficient than the spread operator.
The fact you didn't even stop to wonder why the error was a stack overflow when you weren't using recursive functions is also telling.
うな重が食い逃げした 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".
It says that the grilled eel over rice dined and dashed. It sounds like a euphemism to me. It is not very different from saying the grilled eel over rice developed legs and ran away. In either case, you are suggesting someone stole it.
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.
I just realized the example might have had a typo like you said. It is an interesting typo since it reminded me of a similarly absurd expression in English. When the expression is used in English, the entire point is to be nonsensical such that the only resolution is that someone moved/stole something.
As I am still learning, I have been trying to be open minded about possibilities. That helps when encountering things like 風邪です and 空気がおいしい. The former as you know literally means wind, but also can mean having a cold (and it would be very socially awkward if someone’s name was 風邪). The latter literally calls the air tasty, but means the air is fresh. The downside of being open minded is that someone can tell me something wrong and I will try to interpret it under the assumption that it is correct.
That's interesting, because I took the sentence verbatim from a linguistics book (辞書には書かれていないことばの話、仁田義雄). It says うな重 is short for 「うな重を食べた人」. It was compared with 漱石を読んだ (-> 漱石の作品) and 及第点に荷物を持たせよう (-> 及第点を取った人)
So you're saying that this sentence makes no sense unless は is used?
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.
That interaction looks fine to me. It's just their automated bot response for newcomers, which they use with similar wording across all issues. While the thread was initially locked, it was probably a false positive and quickly reopened by a human.
[1] https://www2.ntj.jac.go.jp/dglib/contents/learn/edc28/shiru/...