![](https://aggregatet.org/pictrs/image/1342e9a3-c172-4918-8a34-accd26338de2.jpeg)
![](https://programming.dev/pictrs/image/028151d2-3692-416d-a8eb-9d3d4cc18b41.png)
It’s also a lot better than doing it in 100% C++ templates!
It’s also a lot better than doing it in 100% C++ templates!
The only part of a JIT compiler I don’t understand how it works is the part that swaps in compiled routines during interpretation. That’s the point I’m unsure of how to write in Rust because it seems like it would require very custom control flow. It might be that you can handle this by storing your compiled instructions somewhere using the C calling convention and then having Rust call your compiled function like a C function.
In essence, what you have is a Rust program that has to produce machine code (easy!), store it somewhere in RAM (also easy, I think), and then somehow call it (how???). The final part seems like the difficult one since passing execution into arbitrary memory they just wrote is just the sort of thing programs aren’t normally supposed to do.
Cool! Thanks!
According to the readme, that’s Lua bindings and not the language itself, that’s probably why it’s not on the list since it wasn’t written in Rust.
Thanks, I think Rhai is what I’d try at this point. Pretty much ticks all my boxes!
Sure you could JIT Rust, the question is if you can write a JIT compiler in rust since it needs to do some quite scary stuff to swap in compiled routines when evaluating code. I’m not even sure if unsafe is enough for that, you may need goto or arbitrary function pointers (which is kind of the same thing)
I’m kind of souring on Fedora Kinoite. I generally sometimes pop in to try how Linux is doing, and I had great hopes for KDE Plasma 6 and immutable distributions for stability. However, I’ve found that many things in the UI are still wonky and broken, fonts don’t render well, and I keep running into limitations in the flatopak/containers ecosystem.
Here are a few paper cuts:
I meant, obviously in the sense that Windows and macOS both apparently already do this and that it’s a desirable property to have, not that it’s technically easy.
Lots of bad answers here. Obviously the kernel should schedule the UI to be responsive even under high load. That’s doable; just prioritise running those over batch jobs. That’s a perfectly valid demand to have on your system.
This is one of the cases where Linux shows its history as a large shared unix system and its focus as a server OS; if the desktop is just a program like any other, who’s to say it should have more priority than Rust?
I’ve also run into this problem. I never found a solution for this, but I think one of those fancy new schedulers might work, or at least is worth a shot. I’d appreciate hearing about it if it does work for you!
Hopefully in a while there are separate desktop-oriented schedulers for the desktop distros (and ideally also better OOM handlers), but that seems to be a few years away maybe.
In the short term you may have some success in adjusting the priority of Rust with nice, an incomprehensibly named tool to adjust the priority of your processes. High numbers = low priority (the task is “nicer” to the system). You run it like this: nice -n5 cargo build
.
I have no idea what you’re talking about but you seem to be quite upset about something I guess
Out of curiosity, what did you use for the UI for the todoist clone?
Wow that’s one heck of a how it started // how it’s going
I’ve also set up both and in my experience Nextcloud is much much more complicated to set up but simpler to use and syncthing is pretty much the exact opposite.
In my case, a rather long time ago, it failed to reliably sync my files, had a super annoying web based UI, was a pain to get all my devices to talk to each other because because they had to join some sort of peer to peer network and authenticate with the earth other all three. It also didn’t have any working solution for mobile devices. Hopefully all of that’s fixed now because there’s no inherent reason it couldn’t work.
Can you (or a human) expand NPM, presumably not the Node Package Manager?