I'm not sure fetch is a good server-side API. The typical fetch-based code snippet `fetch(API_URL).then(r => r.json())` has no response body size limit and can potentially bring down a server due to memory exhaustion if the endpoint at API_URL malfunctions for some reason. Fine in the browser but to me it should be a no-no on the server.

> I'm not sure fetch is a good server-side API. The typical fetch-based code snippet `fetch(API_URL).then(r => r.json())` has no response body size limit and can potentially bring down a server due to memory exhaustion if the endpoint at API_URL malfunctions for some reason. Fine in the browser but to me it should be a no-no on the server.

Nor is fetch a good client-side API either; you want progress indicators, on both upload and download. Fetch is a poor API all-round.

You can pass to `fetch` an `AbortSignal` like `AbortSignal.timeout(5000)` as a simple and easy guard.

If you also want to guard on size, iterating the `response.body` stream with for/await/of and adding a counter that can `abort()` a manual `AbortSignal` is relatively straightforward, though sounds complicated. You can even do that as a custom `ReadableStream` implementation so that you can wrap it back into `Response` and still use the `response.json()` shortcut. I'm surprised I'm not seeing a standard implementation of that, but it also looks straightforward from MDN documentation [1].

[1] https://developer.mozilla.org/en-US/docs/Web/API/Streams_API...

Browser fetch can lean on the fact that the runtime environment has hard limits per tab and the user will just close the tab if things get weird. on the server you're right

Hm, I don't think axios would do much better here. `fetch` is the official replacement for axios. If both are flawed that's another topic

Axios has maxContentLength and maxBodyLength options. I would probably go with undici nowadays though (it also has maxResponseSize).

I'm not saying that axios is unmaintained, I'm saying that if you want something like axios from the standard lib, fetch is the closest thing you get to official

Sure but Axios determine what the official replacement for Axios is.

It's not deprecated, it's obsoleted.

> Current literature does not distinguish between head voice and falsetto.

Hmm, are you sure about this? I thought chest voice and head voice were understood to be a single register called the modal register. And falsetto was fundamentally different.

Yes, though again, the language around registration gets really messy. Here's a great article (with a great title!) from the Journal of Singing by Christian T. Herbst "Registers—The Snake Pit of Voice Pedagogy": https://www.nats.org/_Library/JOS_On_Point/JOS-077-02-2020-1...

One relevant excerpt before the article goes into several pages discussing M11 vs M2:

> These four laryngeal mechanisms are typically termed as: vocal fry (M0, pulse register); chest voice (M1, modal register); falsetto (M2, head voice?); and whistle register (M3).

Another article by Dr. Ingo Titze (an icon in the field of voice science and basically the father of SOVTs) about the debated "mix" register, starts this way:

> One is called chest voice, full voice, or modal voice, which is described by a vibratory mechanism that some have labeled M1. Acoustically, harmonic energy above the fundamental dominates the sound spectrum in this register. The other anchor is called falsetto or light head voice, which is described by a vibratory mechanism labeled M2.

(from https://vocology.utah.edu/_resources/documents/mixed_registr...)

Wouldn't this be because musical falsetto intentionally bypasses vibration of the vocal cords?

Seems similar to a case of tomato the fruit versus tomato the vegetable. Biologically and agriculturally, both are correct.

Thanks for the articles, great sources.

Anecdotal evidence from my own singing at 20 compared to 40 seems to point to the opposite.

It is indeed part of the standard. It says "Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared"[1] which doesn't allow implementations to reorder fields, at least according to my understanding.

[1] https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf section 6.7.3.2, paragraph 17.

i was talking abt padding/alignment, not ordering, that's indeed not allowed you're right

If history is any indication, it would only mean more passengers in the plane.

Natural languages are much more complex.

Complex for humans: I can learn a new programming language in an afternoon and be reasonably productive in it within a week or two. I wish I could say the same for natural languages.

Complex for computers: We’ve had good compilers since the 50s. Satisfactory language models are less than five years old.

My very first open source project[1] aimed to solve the same problem. Nice to see it still has quite a few weekly downloads.

[1] https://sourceforge.net/projects/bin2c/

Not the gp but I can't live without co/ci/br now.

Sure. I cannot imagine anyone living without the most common aliases anymore, but in a script you either need to alias again, or expand. Happens so often to me also.

I celebrated my 25th year on stage almost three years ago. Mostly playing covers in bars.

There was a time when we were hoping to “make it” and we did release an album but it wasn’t very successful, of course. That band broke up a few years later but I kept going with different bands.

I can’t do it every week anymore, let alone every night. It’s very physically demanding, so once a month is plenty in my age.

But it’s still fun. A lot of fun. I can’t imagine ever stopping it until I can’t physically do it. It’s part of who I am. Long live rock’n roll \m/

I've watched the SSA-related parts of these lectures and, despite the low video quality, I've found the quality of the content to be very high. Lecture notes can be found here: https://nptel.ac.in/courses/106108052