Where are you seeing the other posts?

My understanding is that people who connect specifically to the NIST ensemble in Boulder (often via a direct fiber hookup rather than using the internet) are doing so because they are running a scientific experiment that relies on that specific clock. When your use case is sensitive enough, it's not directly interchangable with other clocks.

Everyone else is already connecting to load balanced services that rotate through many servers, or have set up their own load balancing / fallbacks. The mistakenly hardcoded configurations should probably be shaken loose anyways.

Wait, does that mean Manifest v3 is so neutered that it can't load a `<script>` tag into the page if an extension needed to?

If so, I feel like something that limited is hardly even a browser extension interface in the traditional sense.

That is correct. You can not inject external scripts. You can fetch from a remote and inject through the content script though, but the content and service worker code is known at review time.

So you can still do everything you could before, but it’s not as hidden anymore

Most browser extensions don’t need to insert script tags that point to arbitrary URLs on the internet. You can inject scripts that are bundled with the extension (you don’t even need to use an actual script tag). This is one part of manifest v3 that I think was actually a good change - ad blockers don’t do this so I don’t think Google had an ulterior motive for this particular limitation.

> there are plenty things you can't express in jsdoc but can in typescript

This isn't really true anymore, they have systematically added pretty much every type system feature to the JSDoc-like syntax.

Having JSDoc-like syntax isn't the same as it being fully supported. If you have a large enough codebase, you'll likely find a few cases where things work in TypeScript but its equivalent somehow fails type check in JSDoc.

> If you have a large enough codebase, you'll likely find a few cases where things work in TypeScript but its equivalent somehow fails type check in JSDoc.

You keep repeating this throughout the thread. Can you give an example?

Not that person, but is there an easy way to write something like a basic semver?

export type SemVer = `${number}.${number}.${number}`;

Could you extend it to work with regex groups like:

export const SemVerRegex = /^(?<major>0|[1-9]\d)\.(?<minor>0|[1-9]\d)\.(?<patch>0|[1-9]\d)(?:-((?:0|[1-9]\d|\d[a-zA-Z-][0-9a-zA-Z-])(?:\.(?:0|[1-9]\d|\d[a-zA-Z-][0-9a-zA-Z-]))))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$/;

Could the groups be extracted so you the type back if you ran the regex on a string like: "1.2.3", or "1.2.3-prerelease"?

I don't understand the second part of your comment (that's a value, not a type), but the first part looks like this:

    /** @typedef {`${number}.${number}.${number}`} SemVer */

Here's a playground: https://www.typescriptlang.org/play/?filetype=js#code/PQKhAI...

Thanks for the example, I had a good play around with it.

The second part of my comment is a value yes, but it's implicitly typed by typescript automatically. I was asking about how to use that type (and it's internals) in jsdoc.

> it's implicitly typed by typescript automatically

What do you mean by this? Can you share an example?

Regular expressions do not act as type guards, and there's no way to express a type that allows one regular expression but rejects another (they're all just `RegExp`): https://www.typescriptlang.org/play/?target=5#code/MYewdgzgL...

You wouldn't use `test()` like in your example.

`test()` only returns a boolean, you want to look at `exec()` which returns the result of the regular expression (typed as: `RegExpExecArray | null` which you can narrow down to `RegExpExecArray` by checking if the result is null or not).

RegExpExecArray gives you a structure that looks different between the jsdoc version and the typescript version.

The typescript version has `.groups` inside RegExpExecArray.

You can use that as is, or you can add some extra type utilities to extract the named groups from inside the regex. (If you look inside typescript's issues on github you'll find a whole bunch of them that people have wanted typescript to include by default).

There's a few regex PRs to add extraction and syntax checking to typescript by default, but they're delayed until after the compiler switch from ts to go. (but there's porting to go in the PRs anyway).

Thanks for the reply.

> RegExpExecArray gives you a structure that looks different between the jsdoc version and the typescript version.

> The typescript version has `.groups` inside RegExpExecArray.

The JSDoc version has `.groups` too, and it appears to be typed identically to the TypeScript version given similar configuration.

Here's the TypeScript version: https://www.typescriptlang.org/play/?target=5&strictNullChec...

And here's the JSDoc version: https://www.typescriptlang.org/play/?target=5&strictNullChec...

Could you show me what you mean in the playground? You can change it to JSDoc mode by selecting "JavaScript" in the "Lang" dropdown in the "TS Config" tab.

Your examples has groups only typed as { [key: string]: string }.

It isn't narrowed down to the actual named capture groups inside the regex.

For the whole semver example, we'd want something typed as: { major: string, minor: string, patch: string }.

(sidenote for this semver example and not regex in general: they will be strings because a major of "01" and a patch of "3-prerelease" are both valid. You can parse them into ints later depending on what you're actually doing with the semver)

---

For an example of a type narrowed regex in the ts playground, I'll take the lazy route and point you to an example someone else has made:

https://www.typescriptlang.org/play/?ssl=1&ssc=39&pln=1&pc=3...

You can use a utility library (e.g. ts-regexp, arkregex, etc...), you can use one of the utilities that are shared around the typescript spaces online for the one part you need, or you can make your own utility type.

---

For my use-case, I just want to know that I can change either my code or regex and I'll be alerted before runtime or buildtime if I've forgotten to account for something.

To carry on with the semver example, if a fourth piece of data was added to the incoming string (e.g. product name, build timestamp, build variant, etc...) and I forgot to update both the code and the regex together and instead only updated one, I'd want an alert in my IDE to tell me that I forgot to update the other one.

The ts-regexp package `infer`s out of template literal types to do its magic. That's possible from JSDoc too: https://www.typescriptlang.org/play/?filetype=js#code/PQKhCg...

The behavior of ts-regexp is not especially related to the `RegExpExecArray` type. That package uses unsafe assertions to implement its API.

The only thing that requires TypeScript syntax in the playground you linked is the non-null assertions. Here's that same code in JSDoc mode with the non-null assertions removed (`strictNullChecks` is disabled instead): https://www.typescriptlang.org/play/?filetype=js#code/JYWwDg...

---

> For my use-case, I just want to know that I can change either my code or regex and I'll be alerted before runtime or buildtime if I've forgotten to account for something.

If you can show a concrete example what you want using TypeScript syntax then I'm pretty sure I could port it to JSDoc syntax. (To be clear I'd personally much rather write the TypeScript syntax as I find JSDoc comments annoying & verbose, but they're plenty powerful, being nearly isomorphic to TypeScript annotations.)

it is possible to do many of these with @typedef, but it gets difficult with JSDoc very quickly. In TypeScript you can easily create multi-line type aliases. Not quite so in JSDoc.

When it comes to VMs, most things are solved and have near native performance, but desktop graphics are not. Due to limitations in GPU architecture, you usually have to dedicate an entire GPU to the VM to have reasonable graphical acceleration. Qubes doesn't solve this either, IIRC the apps running in VMs are glued to the host with X11 forwarding without any acceleration support.

It's planned to allow GPU for chosen, trusted VMs on Qubes: https://github.com/QubesOS/qubes-issues/issues/8552

For what it's worth the Intel B50 supports GPU virtualization and software support seems to be improving quickly. Really hoping this blows the lid off over the next couple years.

There is another visualization from the same author, that starts at an astronaut and ends with the observable universe https://neal.fun/size-of-space/

This is an idiotic media talking point not actually reflected in the clinical evidence. Unifying autism diagnosis under the ASD label was not a mistake, for a lot of reasons.

A disk that is powered off is not holding your data, regardless of whether it is an HDD, SDD, or if it is in redundant RAID or not. Disks are fundamentally a disposable medium. If you don't have them powered on, you have no way to monitor for failures and replace a drive if something goes wrong - it will just disappear someday without you noticing.

Tape, M-DISC, microfilm, and etched quartz are the only modern mediums that are meant to be left in storage without needing to be babysit, in climate controlled warehousing at least.

Where are the images sourced from? I'm not necessarily against AI illustrations... but making recreations of extinct species right is a tricky multidisciplinary thing, not something AI can do well without a great deal of tweaking and domain-specific knowledge. If it's AI, it would be good to know the prompts and what specific features they mention, because then we'd know the actual methodology.

Edit: Don't waste your time scrolling. The images are a complete joke. There are some bad recreations out there - these are worse than you can imagine.

They are Gemini generated images. The original idea was to get my kids to draw pictures for each change, but their enthusiasm was not quite what I envisaged! Wanted to get it out there so AI to the rescue on that one. I agree it does cheapen the experience a bit :)