crosspostato da: https://lemmy.world/post/1578379

Hi, I Just started working on a Emacs-inspired text editor in Rust.

Being insipred by Emacs, the most important part Is the possibiliy to implement new components.

My ideas were:

• Rust-based scripting language, like Rhai
• RustPython (slower, but more compatible and lots of people know Python)
• PyO3 (Bigger executable and not that fast)
• Wasm/Wasi (Cross-platform, but I don't know if the compatibility with Rust's hosted functions and structs is good)
• Other binded language, like V8, Lua or SpiderMonkey
• Compiled plugins, like .so or .DLL (Fast, but not compatible; there should be Rust plugin frameworks for implementing this, but I don't remember the name)

The elements to analyze are: speednees (consider it's a text editor, so...), easy-to-develop and Cross-platform (if possible, not that important), but the possibility to execute functions in the host Rust program is EXTREMELY important.

Thoughts?

Thanks in Advance.

Not my work!
U/Redditgogogo just announced his library over on reddit, and i was so impressed that I thought it should be posted here.

From Github:

"Charming is a powerful and versatile chart rendering library for Rust that leverages the power of Apache ECharts to deliver high-quality data visualizations.
Built with the Rust programming language, this library aims to provide the Rust ecosystem with an intuitive and effective way to generate and visualize charts, using a declarative and user-friendly API."

fjärrinlägg från: https://lemmyrs.org/post/154420

Ruffle, a Flash Player emulator built in Rust, is being used on archive.org to allow modern browsers access to classics like n, All Your Base, Weebl and Bob, Strong Bag Emails, Happy Tree Friends and many more.

Jason Scott writes:

Thanks to efforts by volunteers Nosamu and bai0, the Internet Archive's flash emulation just jumped generations ahead.

Mute/Unmute works. The screen resizes based on the actual animation's information. And for a certain group who will flip their lid:

We can do multi-swf flash now!

A pile of previously "broken" flashes will join the collection this week.

The Rust team is happy to announce a new version of Rust, 1.71.0. Rust is a programming language empowering everyone to build reliable and efficient software.

What's in 1.71.0 stable

• C-unwind ABI
• Debugger visualization attributes
• raw-dylib linking
• Upgrade to musl 1.2
• Const-initialized thread locals

cross-posted from: https://lemmyrs.org/post/144635

If you have a workspace with dependencies you probably noticed that sometimes cargo seemingly unnecessary recompile external dependencies as you switch between different members of your workspace.

This is caused by something called feature unification ([1]). Since features by design should be additive only cargo tries to avoid redundant work by using a superset of all required features. Problem comes when there are multiple crates in the workspace require external dependencies with different set of features. When you are working with the workspace as a whole - unified features include all the dependencies, when you target a single crate - unified features will include only features of that crate's dependencies.

What's worse - if you are using nix with crate2nix to manage dependencies - you'll get no feature unification at all and every dependency with each unique combination of features is considered a separate dependency so the same crate can be compiled (and linked in) multiple times - I've seen 20+ copies of a single crate.

Unless there are special requirements it is better to make sure that all the external dependencies have exact same set of features enabled across the workspace. One option is to do it by hand manually editing Cargo.toml files for individual dependencies or with inherited workspace dependencies. As with anything manual - it would be error prone.

That's where cargo-hackerman comes in. It can check if there are feature unification issues in the workspace so you can run it in CI if you want to do it manually or it can apply the smallest possible hack by itself (and remove it later).

This is not a new crate, we've been using it in production with a large workspace for over a year now.

In addition to feature unification it can help with some other compilation time things giving easy answers to questions like :

• are there any duplicate dependencies in my workspace?
• why is this dependency or feature on dependency is required?
• what are all the dependencies of this crate?
• where is the repository of this crate?

With updated bpaf documentation on https://crates.io/crates/cargo-hackerman should be always up to date and cli - a bit more user friendly

• https://doc.rust-lang.org/cargo/reference/features.html#feature-unification
• https://crates.io/crates/cargo-hackerman
• https://github.com/pacak/hackerman/

Quoting https://hachyderm.io/@TehPenguin/110702383979537745

If you want to check if it's enabled on your device, you can use Process Explorer to check if win32kbase_rs.sys has been loaded into the System process.

I'm wondering with my game project how best to handle types. I'm basically fetching all the rows in a particular table and creating a struct to represent that data. I then have like 5 or 6 sequential steps I'm trying to go through where I need to modify those initial values from the db.

My first thought was to have a base type called 'BaseArmy', then I needed to add new temporary properties that are not in the db and not represented in the original struct, so I decided to create a new struct 'Army'. The problem is I keep running into errors when passing converting from BaseArmy to Army. I tried writing a From impl, but it wasn't working (and I'm not even sure if it's the approach I should be taking).

So should I:

1. Have multiple different types to handle these kinds of cases
2. Have just one type somehow where I add properties to it? If so, how? I recently tried using Options for the fields that are not initially available, and that seems to be working but it feels weird.