trogdc

I don't understand the premise, maybe I'm missing something.

> LLM-generated code is fuzzy at runtime: non-reproducible, expensive per call, hard to debug.

Wouldn't you have the LLM generate code once, then check in that code. What's not reproducible about that? How is checking in an "E--" script any different from checking in a python script?

The example on the site does have tween frames: `transition-duration: .15s`

These are just wrappers around intrinsics that exist in LLVM already.

> If you fail to adhere to the Simulcast Guidelines, Twitch will send you a warning prior to taking any enforcement action

https://help.twitch.tv/s/article/simulcasting-guidelines?lan...

Does this have native-comp enabled? Or do you still have to build from source for that?

Not sure how MLIR would solve anything, there's no bridge from C++ to MLIR, or from MLIR to assembly, other than going through LLVM.

No they still use GitHub, and there are plans to switch code reviews to use GitHub PRs as well.

Some companies might be in the position to make that choice, but I'd guess most aren't really equipped for it. First of all there's the issue of getting your changes upstream, you have to convince the community it's worth their time to help maintain your code, plus a quality bar you have to meet. And then once it's upstream you're committed to drinking from the firehose, instead of updating at your own pace, and there's extra scrutiny on every change you make.

I really think most of these proprietary users are just figuring things out as they go, and doing that upstream 1. wouldn't be accepted, and 2. wouldn't make sense for them in the first place. But I'll admit that's speculation, I don't have intimate knowledge of what everyone's doing :)

Sure, but I think this mostly results in a difference in quality/velocity, not proprietary vs open.

They probably would have their own proprietary "something" anyways, if not MLIR.

Those are intentional deviations from the standard, and I think there's a reasonable assumption that those stay the same/compatible from version to version. I think the other kind are a bit more problematic, and without a standard it can be difficult to tell whether your assumptions are reasonable.

Well I don't think most people these days are interacting with assembly by hand-writing programs. The real users of ISAs now are compiler authors, and the simpler and regular languages seem better for them. So is there some other reason (other than inertia) that RISC isn't practical?

this program is in canada

Sounds about the same as pipenv's functionality.

You'd have to use "volatile int n"