I'm sindresorhus. I collaborate well with people on GitHub every day. My GitHub activity is open and anyone can take a look if they doubt it. If you are going to make personal attacks, at least include some proof.
Why not just use the Paste and Match Style menu item or ⌥⇧⌘V?
- This app can make it the default behavior.
- That menu item is not available in all apps.
- The keyboard shortcut is hard to remember and type.
- In some apps, like Chrome, the keyboard shortcut is different.
- This app can exclude certain apps, preserve links, and also remove tracking parameters from URLs.
It could indeed be faster. The app does not currently use the neural engine (ANE) because it has a tendency to crash the app, so it uses only CPU and GPU. The app also does upscaling, which adds ~10 seconds.
I am going to put model related code we use in a public repo soon (it is very similar to https://github.com/liuliu/swift-diffusion but in NHWC format). ANE will be around 25s if it runs. DT's default only uses GPUs and 35s is on GPU (yes, like you said, upscaling would take extra 10s).
There was a tool called "OneTask" about a decade ago that I really liked and which served as a lot of the inspiration for NowDo.
Unfortunately its creators fell into the trap of adding a bunch of features which ruined it IMHO. It's not clear whether this is related to that, it doesn't look like it is.
There are, what makes NowDo unique is that I've whittled the feature set down to an absolute minimum - based on over 2 years of prototyping and usage. With NowDo the lack of features is its most important feature.
That’s great yeah, looks awesome. Sorry if it seemed like I was poo-pooing on it. Mostly meant that if everyone were to list their personal favorite todo app the thread would never end ha.
TypeScript had years to prepare for ESM, but they did not. Same with Jest. ESM was developed in the open and anyone could participate, including the TypeScript team. You are talking like ESM just happened overnight. It had been in development for 10 years.
Node.js released initial ESM support [1] in Node.js 12.17 in May 2020, 2 years later (!), TypeScript finally added support for ESM [2].
> ESM was developed in the open and anyone could participate, including the TypeScript team.
This point stings for me, personally, since _I_ was the TypeScript language dev _in_ this wg trying to make our concerns noted, because we certainly did participate. However the group largely deadlocked on shipping with ecosystem compatibility measures, and what you see in node today is the "minimal core" the group could "agree" on (or be bullied into by group politic - this was getting shipped weather we liked it or not, as the last holdouts). The group was dissolved shortly after shipping it, making said "minimal core" the whole thing (which was the stated goal of some engineers who have since ascended to node maintainer status and are now the primary module system maintainers), with the concerns about existing ecosystem interoperability brought up left almost completely unaddressed. It's been a massive "I told yo so" moment (since a concern with shipping the "minimal core" was that they would never be addressed), but it's not like that helps anyone.
Like this shipped, because _in theory_, it'd be a non-breaking from a library author perspective to get node's CJS to behave reasonably with ESM (...like it does in `bun`, or any one of the bundler-like environments available like `tsx` or `webpack` or `esbuild`), and _in theory_ they're open to a PR for a fix... I wish anyone who tries good luck in getting such a change merged.
Fwiw I appreciate your effort! That sounds really frustrating.
I agree the recent bun/tsx/esbuild (but bun especially) has shown the node CJS/ESM fiasco was a bit of an emperor-wearing-no-clothes moment, where I think us every-day JS programmers just trusted the node devs at their word, that CJS/ESM had to be this painful...
But now, seeing that it doesn't have to be that way, it's like wait a sec...the last ~5 years of pain could have been avoided with some more pragmatic choices? Oof.
Completely different behavior is not an implementation detail.
Changing method behavior in subclasses is part of inheritance, but it shouldn't confuse or mislead. In the case of Buffer and Uint8Array, the altered `.slice()` functionality isn't a mere implementation detail; it's a significant deviation. This inconsistency can lead to unexpected bugs, especially for those who assume similar behavior based on the inheritance hierarchy. It's crucial for reliability that such fundamental behaviors remain predictable across subclasses.
Any behavior that is not defined in the spec[0] is, by definition, an implementation detail. Relying on undefined behavior is a recipe for bugs. If you need an immutable array, and the spec doesn't require the returned array to be immutable, you should create one yourself.
Steps 14.g.i to 14.g.ix detail the transfer of data from the original TypedArray (O) to the new TypedArray (A). It involves reading values from the original and writing them to the new array's buffer, effectively duplicating the data segment. The process ensures both arrays are distinct with separate memory spaces.
