Search

\#rust analyzer question for #emacs folks In client more I see run and debug But gui emacs I don't .. why pfa

@rust

Hi all.

I want to develop a plugin system within my program, and I have a trait that functions defined by plugins should implement.

Currently, my code gets all the functions in a HashMap and then calls them by their name. Problem is, I have to create that hashmap myself by inserting every function myself.

I would really appreciate it if there was a way to say, suppose, all pub members of mod functions:: that implement this trait PluginFunction call register(hashmap) function. So as I add more functions as mod in functions it'll be automatically added on compile.

Pseudocode:

Files: src/ ├── attrs.rs ├── functions │   ├── attrs.rs │   ├── export.rs │   └── render.rs ├── functions.rs ├── lib.rs

Basically, in mod functions I want: impl AllFunctions{ pub fn new() -> Self { let mut functions_map = HashMap::new();[[ register_all!(crate::functions::* implementing PluginFunction, &mut functions_map); Self { function_map } } } Right now I'm doing: impl AllFunctions{ pub fn new() -> Self { let mut functions_map = HashMap::new();[[ crate::functions::attrs::PrintAttr{}.register(&mut functions_map); crate::functions::export::ExportCSV{}.register(&mut functions_map); crate::functions::render::RenderText{}.register(&mut functions_map); // More as I add more functions Self { function_map } } }

Hey all, just sharing a small, single-page site I built using Leptos + TailwindCSS, mainly intended as a demo for an API I built using Axum. Hope someone also finds it interesting!

I'm sharing this site and not the API itself cause I figure it's easier to look at and understand, but if you want to roast some code I would appreciate any feedback you have on the API itself (repo here). Trying to leave the front end developer scene so this is the first API I've tried building, fairly basic but it was fun (I am a big Civ V fan - I hear it's inspired by some niche thing called human history?).

Edit: whoops, looks like the link didn't get set cause I put an image - the site is available here, and the repo for it is here. The live API is available here

After reading Drew's pitch to the rust community to write our own kernel, I've searched for "linux abi compatible rust kernel" and found "Asterinas". Surprised that it is not mentioned here

cross-posted from: https://programming.dev/post/18265389 >Hello again everyone, Dihar here. It's been a while since the last release of treedome, but here you go! This release is all about UI update, emojis, and bug fixes. Please consult this git diff for a more detailed changelog https://codeberg.org/solver-orgz/treedome/compare/0.4.5...0.5.0. These are the highlight of the release. > > ! > > * Add emoji picker for title, will show up in tree! > * Text Editor toolbar is back, now with option to toggle both toolbar and floating menu independently! > * Checkbox is here! Thanks Mantine UI! > * You can check the size of each notes by navigating to Escape Menu -> Configure -> Show Note Sizes! > * Add created/last modified date in notes. Note created before this will not have this field and will set as today's date! > * Create child note can now be done through dropdown instead of only from shortcuts! > * Fix bugs of saving empty tree > * General UI update and more stability for auto scrolling in tree view > * Documentation update

Another crazy idea I share with this website.

I was developing a game and an engine in Rust, so I was reading many articles, most of which criticize the 'borrow checker'.

I know that Rust is a big agenda language, and the extreme 'borrow checker' shows that, but if it weren't for the checker, Rust would be a straight-up better C++ for Game development, so I thought: "Why not just use unsafe?", but the truth is: unsafe is not ergonomic, and so is Refcell<T> so after thinking for a bit, I came up with this pattern:

let mut enemies = if cfg!(debug_assertions) { // We use `expect()` in debug mode as a layer of safety in order // to detect any possibility of undefined bahavior. enemies.expect("*message*"); } else { // SAFETY: The `if` statement (if self.body.overlaps...) must // run only once, and it is the only thing that can make // `self.enemies == None`. unsafe { enemies.unwrap_unchecked() } };

You can also use the same pattern to create a RefCell<T> clone that only does its checks in 'debug' mode, but I didn't test that; it's too much of an investment until I get feedback for the idea.

This has several benefits:

1 - No performance drawbacks, the compiler optimizes away the if statement if opt-level is 1 or more. (source: Compiler Explorer)

2 - It's as safe as expect() for all practical use cases, since you'll run the game in debug mode 1000s of times, and you'll know it doesn't produce Undefined Behavior If it doesn't crash.

You can also wrap it in a "safe" API for convenience:

``` // The 'U' stands for 'unsafe'. pub trait UnwrapUExt { type Target;

fn unwrap_u(self) -> Self::Target; }

impl<T> UnwrapUExt for Option<T> { type Target = T;

fn unwrap_u(self) -> Self::Target { if cfg!(debug_assertions) { self.unwrap() } else { unsafe { self.unwrap_unchecked() } } } } ```

I imagine you can do many cool things with these probably-safe APIs, an example of which is macroquad's possibly unsound usage of get_context() to acquire a static mut variable.

Game development is a risky business, and while borrow-checking by default is nice, just like immutability-by-default, we shouldn't feel bad about disabling it, as forcing it upon ourselves is like forcing immutability, just like Haskell does, and while it has 100% side-effect safety, you don't use much software that's written in Haskell, do you?

Conclusion: we shouldn't fear unsafe even when it's probably unsafe, and we must remember that we're programming a computer, a machine built upon chaotic mutable state, and that our languages are but an abstraction around assembly.

Excerpt:

> This is a reconstruction -- extracted and very lightly edited -- of the "prehistory" of Rust development, when it was a personal project between 2006-2009 and, after late 2009, a Mozilla project conducted in private. > > The purposes of publishing this now are: > > - It might encourage someone with a hobby project to persevere > - It might be of interest to language or CS researchers someday > - It might settle some arguments / disputed historical claims

Rust started being developed 18 years ago. This is how it looked until 14 years ago, where I believe the rest of development is on rust-lang/rust. The first Rust program looks completely different than the Rust we know today.

Table of Arena Crates

For a technical discussion of using arenas for memory allocation with an example implementation, see gingerBill's Memory Allocation Strategies - Part 2: Linear/Arena Allocators

archived link

So, I'm basically trying to parse a string literal with nom. This is the code I've come up with:

```rust use nom::{ bytes::complete::{tag, take_until}, sequence::delimited, IResult, };

/// Parses string literals. fn parse_literal<'a>(input: &'a str) -> IResult<&'a str, &'a str> { // escape tag identifier is the same as delimiter, obviously let escape_tag_identifier = input .chars() .nth(0) .ok_or(nom::Err::Error(nom::error::Error::new( input, nom::error::ErrorKind::Verify, )))?;

let (remaining, value) = delimited( tag(escape_tag_identifier.to_string().as_str()), take_until(match escape_tag_identifier { '\'' => "'", '"' => "\"", _ => unreachable!("parse_literal>>take_until branched into unreachable."), }), tag(escape_tag_identifier.to_string().as_str()), )(input)?;

Ok((remaining, value)) }

#[cfg(test)] mod literal_tests { use super::*;

#[rstest] #[case(r#""foo""#, "foo")] #[case(r#""foo bar""#, "foo bar")] #[case(r#""foo \" bar""#, r#"foo " bar"#)] fn test_dquotes(#[case] input: &str, #[case] expected_output: &str) { let result = parse_literal(input); assert_eq!(result, Ok(("", expected_output))); }

#[rstest] #[case("'foo'", "foo")] #[case("'foo bar'", "foo bar")] #[case(r#"'foo \' bar'"#, "foo ' bar")] fn test_squotes(#[case] input: &str, #[case] expected_output: &str) { let result = parse_literal(input); assert_eq!(result, Ok(("", expected_output))); }

#[rstest] #[case(r#""foo'"#, "foo'")] #[case(r#"'foo""#, r#"foo""#)] fn test_errs(#[case] input: &str, #[case] expected_err_input: &str) { let result = parse_literal(input); assert_eq!( result, Err(nom::Err::Error(nom::error::Error::new( expected_err_input, nom::error::ErrorKind::TakeUntil ))), ); } } ```

> Note: The example uses rstest for tests.

Although it looks a little bit complex, actually, it is not. Basically, the parse function is parse_literal. The tests are separated for double quotes and single quotes and errors.,

When you run the tests, you will realize first and second cases for single and double quotes run successfully. The problem is with the third case of each: #[case(r#""foo \" bar""#, r#"foo " bar"#)] for test_dquotes and #[case(r#"'foo \' bar'"#, "foo ' bar")] for test_squotes.

Ideally, if a string literal is defined with single quotes and has single quotes in its content, the single quotes can be escaped with single quotes again. Same goes for double quotes as well. To demonstrate in a pseudocode:

plain "foo ' bar" // is ok "foo \" bar" // is ok "foo " bar" // is err 'foo " bar' // is ok 'foo \' bar' // is ok 'foo ' bar' // is err

Currently, in the code, I take characters until the delimiter with take_until, which reaches to the end of the input, which, let's say, in this case, is guaranteed to contain only and only the string literal as input. So it's kind of okay for first and second cases in the tests.

But, of course, this fails in the third cases of each test since the input has the delimiter character early on, finishes early and returns the remaining.

This is only for research purposes, so you do not need to give a fully-featured answer. A pathway is, as well, appreciated.

Thanks in advance.

> Many devs dream of one day writing their own operating system. Ideally in their favorite language: Rust. For many of us, this dream remains just that: a dream. > > Jeremy Soller from System76, however, didn't just contribute kernel code for Pop!_OS, but also started his own operating system, RedoxOS, which is completely written in Rust. One might get the impression that he likes to tinker with low-level code! > > In this episode of Rust in Production, Jeremy talks about his journey. From getting hired as a kernel developer at Denver-based company System76 after looking at the job ad for 1 month and finally applying, to being the maintainer of not one but two operating systems, additional system tools, and the Rust-based Cosmic desktop. We'll talk about why it's hard to write correct C code even for exceptional developers like Jeremy and why Rust is so great for refactoring and sharing code across different levels of abstraction.

Listen to Rust in Production Podcast S02 E07

• Comparison with other Rust datetime crates
• Why build another datetime library?
• Why not contribute to an existing library instead of building a new one?

cross-posted from: https://lemmy.ml/post/18162485

> This would entail: > > - Pulling in the ClearUrls rules as a git submodule. > - Reading / transforming the json there into Rust structs. > - Creating a Rust crate that runs a .clean(input_url) -> String > > Lemmy issue: https://github.com/LemmyNet/lemmy/issues/4905

> - Added type diesel_async::pooled_connection::mobc::PooledConnection > - MySQL/MariaDB now use CLIENT_FOUND_ROWS capability to allow consistent behaviour with PostgreSQL regarding return value of UPDATe commands. > - The minimal supported rust version is now 1.78.0 > - Add a SyncConnectionWrapper type that turns a sync connection into an async one. This enables SQLite support for diesel-async > - Add support for diesel::connection::Instrumentation to support logging and other instrumentation for any of the provided connection impls. > - Bump minimal supported mysql_async version to 0.34 > > A special thanks goes to @momobel and Wattsense for contributing the SyncConnectionWrapper implementation. > > To support future development efforts, please consider sponsoring me on GitHub. > > Full Changelog: v0.4.0...v0.5.0

I hope this slightly off-topic post is ok here. Today the Fediverse Canvas 2024 event begun and I thought it would be nice to add Ferris to the canvas. I started with a couple of pixels, but after a while I got distracted with other things. When I came back, I found that some of you have already finished it 🦀

Btw. Ferris sits on top of the Godot logo (bottom and slightly right).

Hi all,

ref: https://programming.dev/post/16349359

I agree with all the criticism about the author, the intentions, and the points in the article, expressed in the ref. thread. I also think the author highlights a serious issue (if we leave "selling the book", cheap criticism, and sensationalism aside). While nothing new for most developers, the article has spawned a personal rabbit hole of discovery, starting from supply chain attacks.

I am still very early in my process of learning Rust (still reading The Book) and self-taught software engineering in general, and the journey the article has spawned was very educational to me. I've learned about securing software and being mindful across the whole SDLC[1], AppSec, DevSec, OWASP, SLSA[2] Socket[3], GitHub Advanced Security, and many more tools and guidelines. Last of which is RustSec[4]. Which quenched my thirst and closed that personal rabbit hole. It has opened a different can of worms though.

While endemic to any non-monolithic ecosystem and only part of the "big security picture", supply chain is possibly the major player across the spectrum. Comparable to "the legacy issue" of stagnating systems and infrastructures, open to exploits as old as the Sun.

Now, while I am aware that security is a process, not a product and that this is easier said than done: I wonder if tools like RustSec should be embraced at the foundational level and made a "mandatory best practice". RustSec tools integrate with an up to date security advisory database and Cargo. They can also be deployed as GitHub Actions.

Because I am sure this is not all roses: I agree that (for example) dependabot is seen as a major annoyance more than a useful tools for a number of reasons, and that RustSec could spark the same kind of thoughts. However, it could be a great stepping stone of the security process.

I am aware I may be being too idealistic here, but the process has to start from somewhere and stagnating on "dogmas" ain't helping either.

Please be kind in your replies.

Cheers

[1] https://www.youtube.com/watch?v=hDvz8KivY_U [2] https://slsa.dev [3] https://socket.dev [4] https://rustsec.org

July 2, 2024

Sylvain Kerkour writes:

> Rust adoption is stagnating not because it's missing some feature pushed by programming language theory enthusiasts, but because of a lack of focus on solving the practical problems that developers are facing every day. > > ... no company outside of AWS is making SDKs for Rust ... it has no official HTTP library. > > As a result of Rust's lack of official packages, even its core infrastructure components need to import hundreds of third-party crates. > > - cargo imports over 400 crates. > > - crates.io has over 500 transitive dependencies. > > ...the offical libsignal (from the Signal messaging app) uses 500 third-party packages. > > ... what is really inside these packages. It has been found last month that among the 999 most popular packages on crates.io, the content of around 20% of these doesn't even match the content of their Git repository. > > ...how I would do it (there may be better ways): > > A stdx (for std eXtended) under the rust-lang organization containing the most-needed packages. ... to make it secure: all packages in stdx can only import packages from std or stdx. No third-party imports. No supply-chain risks.

[stdx packages to include, among others]:

> gzip, hex, http, json, net, rand

Read Rust has a HUGE supply chain security problem

---

Submitter's note:

I find the author's writing style immature, sensationalist, and tiresome, but they raise a number of what appear to be solid points, some of which are highlighted above.