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.
I understand what you're saying, but that's actually in support of my point. This is still extremely trivial code to implement and, from what I can tell, doesn't warrant downloading an NPM package. Have we already forgotten the left-pad fiasco?
This isn't meant as a personal attack on anyone, but we really need to frown upon needless dependencies, especially given the growing number of malicious NPM packages.
No one is forcing you to use it. You can choose to reimplement the code yourself or you can choose to copy-paste the code. I made the package for my own convenience as I need to transition a lot of packages from `Buffer` and I don't want to maintain duplicates of the code in every package. Others are free to use the package or not.
Hey, that's totally fine if that's what you want to do, especially if it's for your own convenience. What I'm trying to communicate really has nothing to do with whether anyone is being forced to install anything. My point is that there easily avoidable problems that are inherent to pulling in packages hosted elsewhere, and that programmers should consider whether they should avoid suggesting that using a third-party package for something that can be written by hand in a few minutes. That's all I'm saying. For your own use, this makes a lot of sense. If it were me, I would avoid sharing it, and I hope more programmers move away from relying heavily on other people's packages for tiny units of functionality. But I probably wouldn't have been vocal about that here if I knew your intent with that package (or that you even wrote it, which perhaps I missed somewhere).
Ah thanks, I thought "realms" sounded familiar and that helps clear things up a bit. Also Lavamoat and SES look really interesting thanks for the link.
That’s a reasonable intuition, but it’s not a bug. Global scopes are isolated between realms by design, and that applies to built-ins as well as their prototype chains.
Uint8Array has this too, but it's called `.subarray()`. The problem is that Buffer is a subclass of Uint8Array, but changes the behavior of the `.slice()` method.
- 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.