ono

Please let Geralt have responsive movement and sensible object targeting this time.

How about backing up that letter with some lobbyists?

Is this a proposal to make Nim compile to Assembly instead of C?

No, it's for stuff that happens internally to the compiler.

https://en.wikipedia.org/wiki/Intermediate_representation

I've given up on Nim, though, because the creator / project lead is more than a little problematic, and I don't think that can be fixed.

Perhaps Nimskull will develop into something useful eventually. For now, there are plenty of other languages to try.

I hope nobody today is depending on websites that use Flash, but I'm still glad to see projects like this, for the sake of cultural preservation.

I don't know whether I would be comfortable murdering pokemon, but if the gameplay turns out to be great, I would give it a try. I think I'll wait on this one until it develops a bit and there are enough reviews to balance out early adopter (dev friends & family) bias.

Direct link: https://store.steampowered.com/app/1623730/Palworld/

*r34 ;)

That's as I expected; Thanks for confirming.

Unfortunately, that leaves out the kind of integration I was asking about (and the kind implied in this post), through existing Qt & KDE shared libraries and such.

CopperSpice might still be interesting for stand-alone projects written in C++, though, and I appreciate that you're here engaging with the community.

I think you're talking about migration from Qt to CopperSpipce, though, yes? I'm talking about integration with existing desktop environments. Making use of the themes that are already installed. Communicating with existing libraries via the existing interfaces. Are there any hitches to be aware of on that front?

And language bindings, for those of us who are trying to get away from writing in C++?

It's an interesting project, but as a fork, I would be concerned about its compatibility with standard Qt & KDE libraries, widgets, and styles. Can you comment on that?

Also, what language bindings does it offer?

Linux has quite a few schedulers. The performance of this new one is almost certainly a result of different algorithms used, not an effect of refactoring the existing ones, nor the language it's written in.

I don't think I'll dig in to the code just now, but if it turns out to have much practical value, perhaps we'll eventually see an article about the design.

Seems like a weird headline. AFAIK, the language it's written in has nothing to do with the performance.

Yes, exactly. So a standard compiler can be used, making language bindings much cleaner, while the runtime functionality and library compatibility are preserved.

And then there's DQt, which uses DLang's compile-time function execution instead of the meta-object compiler.