Aode (He/They)

doing some rust dev

  • 3 Posts
  • 19 Comments
Joined 2Y ago
cake
Cake day: Jun 29, 2020

help-circle
rss
I've just published the stable version of pict-rs 0.3, and included a short write-up in the release description. Not much has changed since I posted about the betas, but check out the release anyway! - v0.3.0 changes: https://git.asonix.dog/asonix/pict-rs/releases/tag/v0.3.0 - v0.3.1 changes: https://git.asonix.dog/asonix/pict-rs/releases/tag/v0.3.1
fedilink

what I noticed personally is that my pict-rs server had eaten 1,200MB of RAM, which is the limit I allowed that container. it was still working and it automatically restarted on crash so I didn’t notice it oops

after I fixed the problem, my pict-rs server has been running at about 29MB for the last 12 hours. Significant improvement I’d say



Problem:

I gave tokio-console a buffer way too big

Fix:

Update pict-rs to at least v0.3.0-rc.7, which doesn’t enable console by default


how long does it take for pict-rs to use up this memory?


Hey all! Just wanted to share a little fun side project I've been working on recently. It's an ecosystem similar to smol for writing async rust code, but the internals make no use of `unsafe` at all ### repos: - `async-join`: a safe `join_all` function for `Vec<Future>` - `polldance`: a safe polling library built on unix `poll` with `rustix` for memory & io safety - `foxtrot`: a safe async reactor bulit on `polldance` and `rustix` - `jitterbug`: a safe async executor with multi-threaded work-stealing support I'm not here to say "you should definitely use this" because I've wirtten zero tests, and I've made no effort to implement standard apis like AsyncRead, AsyncWrite, etc, but I wanted to show it is possible to build these things yourself Shoutout to [rustix](https://github.com/bytecodealliance/rustix) for making socket programming safe and easy
fedilink

If you don’t know what OpenTelemetry is but you’re having OpenTelemetry errors in your logs, it likely means that you have an opentelemetry_url set in your config when you shouldn’t. You can get rid of the error by deleting that line, which will disable opentelemetry exports



i might try

let res = collection.into_iter().map(|item| item.fallible_operation()).fold(Ok(Vec::new()), |acc, res| {
    match (acc, res) {
        (Ok(mut vec), Ok(item)) => {
            vec.push(item);
            Ok(vec)
        }
        (Err(mut vec), Err(error)) => {
            vec.push(error);
            Err(vec)
        }
        (Ok(_), Err(error)) => Err(vec![error]),
        (acc, _) => acc,
    }
});

Maybe expand it with

pub trait Evert<T, E> {
    fn evert(self) -> Result<Vec<T>, Vec<E>>;
}

impl<I, T, E> Evert<T, E> for I
where
    I: IntoIterator<Item = Result<T, E>>,
{
    fn evert(self) -> Result<Vec<T>, Vec<E>> {
        self.into_iter().fold(/* implementation from above */)
    }
}

fn main() {
    let result = vec![Ok(1), Err(3), Ok(4), Err(8)].evert();
    assert_eq!(result, Err(vec![3, 8]));
}


I’m a sponsor on github for spacejam (github user) and elementary OS, and I’m a patron of Hector Martin on patreon.


First, it doesn’t take an array as input, it takes a slice as input. You can turn a Vec<&str> into a slice &[&str] by borrowing it.

Second, the human-sort crate’s api is bad, because rarely to people have Vec<&str> or &[str] and there’s no way to produce a Vec<&str> from a Vec<String> without creating a new vector that borrows from the first.

let mut strs = Vec::new();

for s in strings.iter() {
    strs.push(s);
}

human_sort::sort(&mut strs);

What human-sort should have done was accept &[T] where T: Deref<Target = str> which would allow passing a Vec of String or a Vec of &str.

Feel free to open a PR against human-sort, but it looks like it hasn’t been updated in a couple years so it might not be maintained anymore


Pawoo is a mastodon server run by the same company that owns pixiv. They’re using the default mastodon description but have also deliberately added tracking because they’re a company that doesn’t care about privacy.

I dont really know what point this post is trying to make. There are other mastodon servers you can join that wont track your activity.


It also has .flush() and .flush_async() to flush inline with your application if you need that


Sled is my go-to key value store in Rust. It flushes to disk every 500ms by default iirc


I love writing rust and I’ve done all my personal projects for the last 4 or 5 years in it, but I dont think it’s a good idea for other existing languages to adopt more of Rust’s features.

Languages like Elixir or Lisp are so different it doesn’t make any sense to adopt Rust semantics or syntax, and anything with a garbage collector, Go included, doesn’t need to care about ownership, borrowing, or lifetimes (besides the usual passing references being cheaper than passing whole objects).

Languages like C or C++ can definitely be replaced in many cases with Rust, but I dont think making them more like rust is a wise decision. Adopting something like a borrow checker in c or c++ completely changes the language in a way thats not only backwards incompatible, but also probably not welcome by developers already working in those languages.

All this to say: I’d prefer more people to work in rust than to alter other languages to be more like rust, but I also think there are a number of other languages worth learning and working in. To a large extent, choosing a language is about taste.


oh I forgot to mention pict-rs is now nicely instrumented with the tracing framework and can export spans to OTLP collectors if the opentelemetry_url configuration option is set. It supports reading OpenTelemetry span information out of HTTP requests to enable tracing requests through the calling application to pict-rs and back. This is incredibly helpful for debugging.

Since lemmy is not instrumented (yet) with tracing, the benefit to lemmy admins and developers is not much, but this prepares for a future when lemmy is instrumented.

This also changes how pict-rs logs look. Hopefully admins and developers can glean more information from pict-rs logging now, especially in the event of an error.


pict-rs 0.3 betas rolling out
Hey all! I'm the developer of pict-rs, the image host API used by lemmy. I'm here to officially announce the availability of the pict-rs 0.3 beta releases. As I type this, v0.3.0-beta.3 is currently building and should be published to dockerhub shortly. Here's what's new # Api There are now APIs to fetch metadata about images. These endpoints are mentioned in pict-rs's README.md, but at a high level they can return mime-type, dimensions, and creation date for original or processed images The rest of the pict-rs APIs have not changed, so if you experience different behavior, please let me know in the [#pict-rs:matrix.asonix.dog](https://matrix.to/#/#pictrs:matrix.asonix.dog) channel on matrix. # Dependencies pict-rs no longer links against imagemagick, ffmpeg, and gexiv2. This change makes developing on pict-rs significantly easier, since it now compiles like a normal rust application with very few system dependencies. This also means it can be easily linked against the musl standard library to create a static executable. Instead of linking against the programs mentioned above, pict-rs will now spawn imagemagick, ffmpeg, and perl-image-exiftool processes in order to manipulate images. The required versions are - Imagemagick: At least 7.0 - ffmpeg: At least 4.0 - perl-image-exiftool: whatever Arch or Alpine are packaging right now # Files images are now organized into directories by default, and will no longer have original files dumped into the root of `files/`. If upgrading from 0.2, a migration script will attempt to move existing files from their current locations to this new structure. Please please please take a backup of your pict-rs storage directories before upgrading. # Configuration pict-rs now supports configuring the service with a file, rather than relying on commandline arguments or environment variables. The majority of settings can still be manipulated through the environment or through the commandline, but there is a specific feature (mentioned below) that can only be accessed through a configuration file. For information on configuring pict-rs, take a look at the [pict-rs.toml file](https://git.asonix.dog/asonix/pict-rs/src/branch/main/pict-rs.toml) # Object Storage There is now object storage support built-in to pict-rs. If you already have a pict-rs deployment as part of your lemmy server, there is an included migration feature to help move from your existing block storage to object storage for the image files. This does not completely remove pict-rs dependency on a local filesystem, but all original images and transformed images will be stored in object storage rather than on the local filesystem. In particular, pict-rs database still resides on the local filesystem, and temporary files created when manipulating images will still use the /tmp directory. Object Storage has not been tested with any cloud provider, but I have set up a local [minio](https://min.io/) container for local testing. If you try to use pict-rs with your favorite cloud provider and it doesn't work, please let me know in the [#pict-rs:matrix.asonix.dog](https://matrix.to/#/#pictrs:matrix.asonix.dog) channel on matrix. If you are migrating from local storage to object storage, the specific way to accomplish that is with pict-rs's `--migrate-file <file>` flag, and the associated migration file. An example can be found [here](https://git.asonix.dog/asonix/pict-rs/src/branch/main/migrate.toml) Finally, object-storage is behind a feature flag, and can be disabled in custom builds of pict-rs by providing the `--no-default-features` flag to cargo when building # io-uring Since actix-rt gained support for io-uring with 2.3.0, I have implemented an io-uring file backend for pict-rs. It is disabled by default, as io-uring requires a recent linux kernel release and I don't want to publish an application that doesn't work on most people's computers, but if you are interested in building and running an io-uring version of the application, you can pass `--features io-uring` to cargo to produce an io-uring backed binary rather than traditional blocking file IO. In my personal testing, io-uring performed significantly better for serving files on my laptop running linux kernel 5.13. Keep in mind that io-uring in the actix-web ecosystem is currently considered unstable and is therefore exempt from semver, so the io-uring feature in pict-rs should also be considered unstable. # Links That about wraps up this announcement! Here's some useful links for pict-rs: - git: https://git.asonix.dog/asonix/pict-rs - matrix: https://matrix.to/#/#pictrs:matrix.asonix.dog - dockerhub: https://hub.docker.com/r/asonix/pictrs - asonix on mastodon https://masto.asonix.dog/@asonix
fedilink

As an update, I’m back online on cable internet instead of fiber. I still need to get our fiber fixed but paying a different provider to get us online in the meantime made some amount of sense.

git.asonix.dog should work now



If you want all the code required to build pict-rs I can try getting it all working on yerbamate.dev this evening


Yup, my internet is down. A fiber line in our neighbor’s attic was broken (assuming an animal chewed through it). We’re trying to get back online but it’s taking some time. So far we’ve been offline for around 87 hours :/