rovingeye

it's literally the exact same thing. We use trailing return types to be consistent across the language.

This has been valid C++ since C++ 11

It looks like you missed the part where you "move the context into the lambda body via capture specifier."

Consistency (lambdas, etc.)

All my window classes uses cbWndExtra, and I leave GWLP_USERDATA for the user who is creating windows.

That doesn't sound like a valid wndproc

I assume by "move the context into the body" you mean using GetWindowLongPtr? Why not just use a static wndproc at that point?

I wasn't aware of the thread local trick, I solve this problem by not setting WS_VISIBLE and calling SetWindowPos & ShowWindow after CreateWindow returns (this solves some other problems as well..)

I have that turned on in Windows Terminal but still use ctrl+c because it's how all other software works

The windowing is pretty broken if you use system scaling https://github.com/zed-industries/zed/issues/40272

Thanks for the info. Looks like they're using /silent right there in the example

"Steam customers love a quick and silent install. Add silent or quiet parameters to all run process commands and only add what you absolutely need for the game."

MicrosoftEdgeWebview2Setup.exe /silent /install

I can understand the argument, since npm has no solution for TypeScript packages, unlike JSR:

"You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility."

Still would have been nice to have this for private packages.

This makes Deno/Bun much more attractive alternatives

I can sort of understand the publishing argument, since npm doesn't solve for this at all, unlike JSR:

"You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility."

Not allowing it for private modules doesn't make much sense to me, though. It either forces me to use a loader, or now figure out a JS build step which I have been more than happy to avoid up until now.

I mean, you can just use a loader, as we've all been doing. It's already built, they just didn't implement it properly.

What? All this does is strip types

Why would I want to ship a JS build for my private package? That's just extra machinery I don't need. Switching to a superior runtime would be easier.

I made the same comment here https://news.ycombinator.com/item?id=44931575

"To discourage package authors from publishing packages written in TypeScript"

I tried to use it with private packages but that doesn't work either, apparently node doesn't even read the "private" field.

It was the first thing I tried and of course it didn't work.

It might finally be time to switch to Deno or Bun =(

https://github.com/nodejs/node/issues/57215

Not supporting type stripping in node_modules is unfortunate

Win32 + WebView2

That's about when they added the capability, yeah. They've dropped support for win 7/8, not sure if CHOC goes back that far.

I suppose this would break the "Nothing needs adding to your build system to use any of this stuff.", but that doesn't seem true now that Boost is a dependency for the server stuff.

I still don't see a reason to re-implement this functionality when you can just.. statically link the loader. CHOC is great though!

Yeah, it's kind of silly when the WebView2 loader can be statically linked. It's just build system avoidance. CHOC is great though!

Users want an installer. You can see what the installers are doing by looking at the scripts in the repo (this is an open source project). Admin permission is necessary to write to the Global VST folder. You can direct your "Wow" at Steinberg if you want. The spec was recently updated to allow for a User install location which has been considered: https://steinbergmedia.github.io/vst3_dev_portal/pages/Techn...

If you don't want an installer, you can download the pluginsonly bundle on the release page and do it yourself: https://github.com/surge-synthesizer/releases-xt/releases