Rust

Hi Rustaceans,

I'm excited to announce the release of iceoryx2, a new inter-process zero-copy framework and middleware written entirely in Rust.

This Rust implementation succeeds the C++ project iceoryx, offering a significant speed increase and improved latency. Rest assured, iceoryx, the framework you've come to rely on, remains an active player in the field. It continues to receive consistent enhancements and is regularly updated with new features. However, the future is looking mighty Rust-y with iceoryx2.

In its initial version, iceoryx2 supports publish-subscribe messaging and efficient event transmission between processes. Notably, there's no longer a reliance on a central broker, simplifying the setup process.

For those interested, our GitHub repository contains the roadmap. I welcome your feedback, whether it's about missing features or your top two or three desired functionalities.

Our current areas of focus include Mac OS platform support, a C binding, the waitset, a reactor event-multiplexing abstraction, and the expansion of messaging patterns with features like request-response and pipelines.

Additionally, for those acquainted with our demonstrator robot Larry, anticipate a Rusty transformation as he eagerly ventures into the realm of Rust.

The iceoryx developers invite you to explore the GitHub repository, engage in discussions, and contribute to the development of iceoryx2.

Elfenpiff

Links:

• repo: https://github.com/eclipse-iceoryx/iceoryx2
• roadmap: https://github.com/eclipse-iceoryx/iceoryx2/blob/main/ROADMAP.md
• crates.io: https://crates.io/crates/iceoryx2
• docs.rs: https://docs.rs/iceoryx2/0.1.0/iceoryx2/

There seems to be a new Rust related podcast out. I will probably not have time to listen to it right away, so if someone listens to it, post and let me know if it is worth listening to.

The Rust for Linux (RFL) project may not have (yet) resulted in user-visible changes to the Linux kernel, but it seems the wider world has taken notice. Hongyu Li has announced that the Rust for Linux code is now part of a satellite just launched out of China. The satellite is running a system called RROS, which follows the old RTLinux pattern of running a realtime kernel alongside Linux. The realtime core is written in Rust, using the RFL groundwork.

Despite its imperfections, we still want to share RROS with the community, showcasing our serious commitment to using RFL for substantial projects and contributing to the community's growth. Our development journey with RROS has been greatly enriched by the support and knowledge from the RFL community. We also have received invaluable assistance from enthusiastic forks here, especially when addressing issues related to safety abstraction

(Thanks to Dirk Behme).

An interesting blog post by @bagder@mastodon.social about security in curl

Cargo has recently gained an unstable feature on the nightly channel (starting with nightly-2023-11-17) to perform automatic cleaning of cache content within Cargo's home directory.

From the conclusion:

The authoring agencies urge executives of software manufacturers to prioritize using MSLs [memory-safe languages] in their products and to demonstrate that commitment by writing and publishing memory safe roadmaps. The authoring agencies encourage software manufacturers to lead from the top by publicly naming a business executive who will personally drive the elimination of memory safety vulnerabilities from the product line.

cross-posted from: https://lemmy.world/post/9117180

If you're writing Advent of Code solutions in Rust, then I've written a crate that can fetch the user input data directly from the main website.

Long story short, you provide it a login token copied from your browser cookies, and it can fetch the input data by year and day. Inputs are cached locally, so it'll only download it once for a given problem. This was heavily inspired by the PyPi advent-of-code-data package.

Unlike other AoC-centric Rust crates, that's all it does. The other crates I've seen all want the code structured in a specific way to add timing benchmarks, unit testing, and other features. I wanted something lightweight where you just call a function to get the input; no more and no less.

To use the crate:

• Follow the AoCD instructions to set the AOC_SESSION environment variable.
  This key is used for authentication and should not be shared with anyone.
• Add the aocfetch crate to your Cargo.toml [dependencies] section:
  aocfetch = { git = "https://github.com/ooterness/AdventOfCode.git" }
• Import the crate and call aocfetch::get_data(year, day) to fetch your input data.

An example:

use aocfetch;

fn main() {
    let input = aocfetch::get_data(2023, 1).unwrap();
    println!("My input data: {}", input);
    println!("Part 1 solution: 42");    // TODO
    println!("Part 2 solution: 42");    // TODO
}

If this goes well I will submit it to crates.io, but I wanted to open this up for beta-testing first.

Sorry if this is a stupid question, but I'm struggling with what I think is ownership in rust.

I'm completely new to rust, but have done low level languages before so I know the concept of pointers pretty well. However, this rust ownership I can't quite wrap my head around.

I'm trying to refactor my solution to AoC Day 4 Part 2 using a struct reference instead of a stand-alone vector.

The error I'm getting, and can't figure out is in the process function at line

cards.iter_mut().for_each(|card | {

The error is

cannot borrow cards as mutable more than once at a time second mutable borrow occurs here

There is a lot of parsing in my code, so I stuck that in a spoiler below.

The relevant code is:

#[derive(Debug)]
struct Card {
    id: u32,
    score: u32,
    copies: u32,
}

fn process(input: &str) -> u32 {
    let mut cards: Vec = parse_cards(input);

    cards.iter_mut().for_each(|card| {
        let copy_from = card.id as usize + 1;
        let copy_to: usize = copy_from + card.score as usize - 1;

        if card.score == 0 || copy_from > cards.len() {
            return;
        }

        for card_copy in cards[copy_from - 1..copy_to].iter() {
            let id = card_copy.id as usize - 1;
            let add = cards[card.id as usize - 1].copies;
            cards[id].copies += add;
        }
    });

    return cards.iter().map(|c| c.copies).sum();
}

Other code:

fn main() {
    let input = include_str!("./input1.txt");
    let output = process(input);
    dbg!(output);
}

fn parse_cards(input: &str) -> Vec {
    return input.lines().map(|line| parse_line(line)).collect();
}

fn parse_line(line: &str) -> Card {
    let mut card_split = line.split(':');
    let id = card_split
        .next()
        .unwrap()
        .replace("Card", "")
        .trim()
        .parse::()
        .unwrap();

    let mut number_split = card_split.next().unwrap().trim().split('|');

    let winning: Vec = number_split
        .next()
        .unwrap()
        .trim()
        .split_whitespace()
        .map(|nbr| nbr.trim().parse::().unwrap())
        .collect();
    let drawn: Vec = number_split
        .next()
        .unwrap()
        .trim()
        .split_whitespace()
        .map(|nbr| nbr.trim().parse::().unwrap())
        .collect();

    let mut score = 0;

    for nbr in &drawn {
        if winning.contains(&nbr) {
            score = score + 1;
        }
    }

    return Card {
        id,
        score,
        copies: 1,
    };
}

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

    #[test]
    fn full_test() {
        let result = process(
            "Card 1: 41 48 83 86 17 | 83 86  6 31 17  9 48 53
        Card 2: 13 32 20 16 61 | 61 30 68 82 17 32 24 19
        Card 3:  1 21 53 59 44 | 69 82 63 72 16 21 14  1
        Card 4: 41 92 73 84 69 | 59 84 76 51 58  5 54 83
        Card 5: 87 83 26 28 32 | 88 30 70 12 93 22 82 36
        Card 6: 31 18 13 56 72 | 74 77 10 23 35 67 36 11",
        );
        assert!(result != 0);
        assert_eq!(result, 30);
    }
}

I'm the author of Kellnr, the Rust crate registry to self-host. I released version 5.0.0 a few days ago and need to prioritise the next features.

I've added a few possible features/improvements to Github as issues, but I need more input from (future) Kellnr users.

What features/improvements would you like to see in Kellnr?