Rust

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

I was hoping if I could get some help regarding Iced.rs (& maybe even advice on GUI-dev in general) since the documentation/book is a Work-In-Progress

Question is how to do these in Rust. An example might be a browser DOM: each node has a parent pointer, a list of child pointers, left and right sibling pointers, maybe a CSS node pointer, etc. Inserting or deleting nodes has to repair the pointers to and from the neighboring nodes as needed.

I know this is doable since obviously Servo (Rust's initial driving application) has to do it. I hope the answer doesn't involve the word "unsafe". But I am quite unclear about how to create such a structure under Rust's rules of pointer ownership, and also how to reliably reclaim storage when nodes and trees/subtrees are deleted. Plus there will be thread safety rules that should be statically enforced if possible.

I've heard that doubly linked lists in Rust are handled by an unsafe library, yet this seems even worse. Thanks.

Is there any way I can automatically bundle the compiled binary with the current version number as a git tag to github when I do cargo publish like stuff? Like qol thing?

In terms of its usability, not its deficits.

Hello,

This is my first post to this Rust community and I am happy to introduce myself and discuss what I love about this language, but first a little about myself.

I'm Alice, Fluffy to most, and she/her are my pronouns. I'm from the UK. I got a little boy who love like crazy. I'm Autistic, suffer from cPTSD and I also 🩷 Rust!!

Rust I feel appeals to Autistic people because of it's focus on accuracy and correctness. It's a common feeling people have about the language. But as the type of person I am I love it.

I began learning it in 2023, before this I was using C++. Rust showed me the importance of error's as values and helped improve the quality of my code.

Currently I'm writing a game-engine as a hobby. The game-engine is a work in progress (WIP) and I have only just begun it's development. Since the game-engine will natively support various platforms. To ensure consistency I'm writing all the platform specific code manually and building my own custom standard library for my engine, loosely based on the actual Rust standard library.

Right now I have the code in place to create/remove directories and to create, delete, write, read and set file pointer location. Convert UTF8 to UTF16 and output to the console in Unicode (Windows C API uses UTF16) and heap functions to get the process heap and create and delete memory dynamically.

Next will be the 'config.json' for which Serde will be used. Then the logger, and so on.

So it is a WIP but it's fun and given my conditions allows me to do what I love, writing Rust code.

Thanks for reading!!

Alice 🏳️‍⚧️

Managarr - A TUI and CLI to help you manage your Servarrs.

Thanks to everyone who contributed to this release, be that in code, issues, or enhancement suggestions! You all help fuel my passion for working on this and it doesn't go unappreciated! 😄

As always, you can try out the changes yourself via the Managarr Demo Site

Breaking Changes

• Managarr now supports multiple instances of the same Servarr with custom names and ordering. (See Features below) To accommodate this, configuration files must be updated so that all Servarrs listed beneath radarr, sonarr, etc., be updated to be lists, not individual Servarrs. For example: to migrate from the following config:

  radarr:
    host: 192.168.0.78
    port: 7878
    api_token: someApiToken1234
  sonarr:
    host: 192.168.0.89
    port: 8989
    api_token: someApiToken1234
  

  You would change the above configuration to the following:

  radarr:
    - host: 192.168.0.78
      port: 7878
      api_token: someApiToken1234
  sonarr:
    - host: 192.168.0.89
      port: 8989
      api_token: someApiToken1234
  

• The --config flag has been renamed to --config-fileto make it more clear what it does.

Features

• Users can now specify multiple instances of the same type of Servarr and give them custom names and ordering. This allows users to manage multiple instances of the same Servarr, such as an Anime and TV Show instance of Sonarr. To configure, add a list of Servarrs under the respective type (e.g. radarr, sonarr, etc.). (#17)

  • You can specify ordering of your Servarrs and how they will appear in the UI via the weight field. The lower the weight, the further to the left the Servarr will appear in the UI.
  • You can also name your Servarrs whatever you wish. This name will be displayed in the UI. For example, to name your Sonarr instances:

    sonarr:
      - name: Anime
        host: 192.168.0.89
        api_token: someApiToken
    
      - name: TV Shows
        host: 192.168.0.88
        api_token: someOtherApiToken
    

  • This change also required the introduction of a new CLI flag to specify which Servarr you wish to interact with: --servarr-name. This corresponds directly to the value of the name field in your configuration. If you did not specify a name in the configuration, then default names are provided for you corresponding to the Servarr; For example, if you defined two Radarr instances with no names, they will be named Radarr 1 and Radarr 2, respectively.
  • Omitting the --servarr-name flag with multi-instance configurations will default to using the first instance that appears in your config. For example, for the following configuration:

    sonarr:
      - host: 192.168.0.89
        api_token: someApiToken
    
      - host: 192.168.0.88
        api_token: someOtherApiToken
    

    Running managarr sonarr list series will default to interacting with the Sonarr instance at 192.168.0.89. This is the same as running managarr sonarr list series --servarr-name 'Sonarr 1'.

• API tokens can now be fetched from files instead of needing to be hardcoded (#31). The following is an example config that loads the API token from a file:

  radarr:
    - host: 192.168.0.78
      api_token_file: /home/root/.config/radarr_token
  

• Configurations now interpolate environment variables (#23). This allows you to load sensitive information from environment variables. For example, to load the API token from an environment variable, you can do the following:

  radarr:
    - host: 192.168.0.78
      api_token: ${MY_RADARR_API_TOKEN_ENV_VAR}
  

  This is available for all fields in the configuration file.

Security Updates

• Updated OpenSSL to v0.10.70 to mitigate CVE-2025-24898

Miscellaneous

• Managarr now has a Matrix space! Feel free to drop in and message me directly if you're looking to discuss features, ideas, or just want to say, "Hi!".

Source Blog Post

Hi there! Just wanted to share a project I worked on over the past 6 weeks. It is a boilerplate/template for a fairly secure API.

It now features:

• An example API,
• JWT auth (using APIkeys and username + password (+ 2 factor))
• Key rotation,
• Built-in HTTPS/HTTP2,
• Multiple keys per account,
• Usage tiers,
• Role based access,
• Healthcheck endpoint for monitoring and docker,
• OpenAPI documentation generation,
• And a lot more...

This was my first Rust project. I am always in for feedback :)

If you belong to the group of people playing World of Warcraft on linux somewhat competitively (there must be dozens of us!), you might be interested in progrs. It is an alternative to warcraftrecorder and used to create videos of your play. It monitors the combat log for interesting events (for now, deaths of players) and creates chapters in the video for easier searching. For now, only "encounters" are supported (might mean just raid bosses, but I've not done any testing in M+), but each try will end up its own video, just as in warcraft recorder.

I'd be glad for anyone trying it out and giving feedback.

cross-posted from: https://lemmy.ca/post/39555878

Invidious

Youtube

So let me be very clear: if you as a maintainer feel that you control who or what can use your code, YOU ARE WRONG.

Typst is "A new markup-based typesetting system that is powerful and easy to learn". It's written in Rust, and particularly attractive because, while providing a CLI interface, it is a proper library that you can easily incorporate into your progress to produce documents. Protip: If you do so, have a look at sys.inputs, it's awesome!

The phoronix title is a bit click bait, but the LKML thread that is linked in the article is worth reading.

I dunno if this is appropriate for this community, so mods, please delete if not.

I have been writing a screen clone in rust.

https://github.com/cameroncros/PoorMansScreen/tree/better_screen (The main branch is how I currently use it, not at all screen-like, the better_screen branch is much closer to a screen replacement.)

It all currently works fine, albeit quite simple, and I suspect not following best practices. Please talk shit about my code so I can fix that :D

For my next stage of development, I would like to use some combo of vt100 and ratatui to wrap the shell in a border, or add a menu bar at the top or bottom to make it clear when the user is inside a "screen". Does anyone have any thoughts on how to go about doing that? I am very unskilled at ratatui.

It seems like @burntsushi@programming.dev have added some optimizations to the Jiff date time library... so now it should generally be faster than 'chrono' and 'time'. Jiff is quite impressive, the 0.2.1 version number really doen't reflect its quality.

I've got 64 GB of RAM and would like to force cargo to dump build artifacts into it. So basically the target/ directory should end up there.

Unless I'm mistaken RAM is much faster than SSDs and since I do rebuild quite often, it would save some R/W cycles on my SSD and allow faster file access.

I do jot mind doing a full rebuild every morning

Solution:

These 2 comments gave me the best indication how to do it: cargo ramdisk and build.target-dir config options.

Would be great if cargo had a build.target-dir-prefix though. One could set and env var CARGO_TARGET_DIR_PREFIX and point it at /dev/shm or /tmp if it's a tmpfs and every rust project would have its artefacts end up in RAM.

Jiff is a datetime library for Rust that encourages you to jump into the pit of success. The focus of this library is providing high level datetime primitives that are difficult to misuse and have reasonable performance.

And as a user of Jiff, I must say that it is very nice to use. Well thought out API, making date time handling less of a pain. So, nice work @burntsushi@programming.dev