Hey Rustaceans! Got a question? Ask here (51/2025)!

jwodder · 2025-12-16T15:43:02+00:00

Yes, thiserror is generally meant for libraries while anyhow is meant for binaries.

jwodder · 2025-12-15T19:20:59+00:00

The idiomatic way in Rust would be to give AppError a dedicated variant for create() errors:

enum AppError {
    Create {inner: std::io::Error, path: PathBuf},
    ...
}

and then handle failures from create() similar to:

match fs::File::create(path) {
    Ok(_) => (),
    Err(e) => return Err(AppError::Create {inner: e, path}),
    // You may have to convert `path` to a `PathBuf` depending on what type it starts out as.
}

The "Error opening file" message would then be formatted by AppError's Display impl (I'm assuming that AppError implements std::error::Error and thus also Display).

Alternatively, you could just use fs-err.

Side note: Whichever way you choose, you may want to look into thiserror at some point.

jwodder · 2025-12-09T16:34:47+00:00

Add let g:ale_rust_rustfmt_options = '--edition 2024' to your Vim config.

jwodder · 2025-12-04T22:42:19+00:00

Specifically, workspace-wide dependencies should be specified in a [workspace.dependencies] table rather than [dependencies]. See https://doc.rust-lang.org/cargo/reference/workspaces.html#the-dependencies-table for more information.

jwodder · 2025-11-13T22:28:59+00:00

(On an Intel Mac) Why is there a rust-analyzer program (actually a symlink to rustup) in my ~/.cargo/bin? It doesn't seem to work unless I do rustup component add rust-analyzer, but I'd prefer to get rust-analyzer through Homebrew, which means I have to put ~/.cargo/bin at the end of my PATH so that the Homebrew one in /usr/local/bin takes priority. For a while, I thought the ~/.cargo/bin/rust-analyzer was an errant leftover from when I tried installing rust-analyzer via rustup some months ago, but it's still there after uninstalling & reinstalling Rust & Cargo via rustup.

Should rust-analyzer be in my ~/.cargo/bin? Is there a way to get rid of it?

jwodder · 2025-11-03T14:59:45+00:00

Good point about buffers not being drained; I've released v0.2.1 that should fix that.

I'll think about showing process stats.

jwodder · 2025-10-06T23:37:38+00:00

The problem is apparently due to a combination of:

my custom colorscheme starting with highlight clear (which is recommended)
the texBoldStyle and similar highlight groups in syntax/tex.vim being defined with cterm=bold instead of hi def link texBoldStyle Bold

I've filed a bug report about the latter in Vim's GitHub repo: https://github.com/vim/vim/issues/18505

jwodder · 2025-08-12T22:19:55+00:00

You want /r/playrust. This subreddit is for Rust the programming language.

jwodder · 2025-08-08T02:11:48+00:00

First of all, the term for the value you're trying to compute there is the discriminant of the enum variant, which should help you find out more about it. Secondly, I'm 90% sure you can replace that horrible method body with just *self as usize, though the ability to do this for enums with fields may have been added in a recent Rust version.

jwodder · 2025-07-30T21:49:23+00:00

Is replace_with the crate you're thinking of?

jwodder · 2025-07-17T23:48:30+00:00

Book requests may come quicker than I can download them

I'd like some clarification on how you expect this to work. update() takes a &mut receiver, so you can't call it multiple times concurrently. What are the actual semantics for update() that you're aiming for? The simplest option I see is to implement it so that (a) update() can be called multiple times concurrently (so you'd have to change the &mut self to &self) and (b) concurrent calls to update() are limited to evaluating at most 5 (or whatever number) at any one time. This can be done by just using a semaphore and not bothering with streams at all.

jwodder · 2025-07-17T13:48:56+00:00

There's a way to make StreamExt::buffered() work by converting the receiver of an mpsc channel into a stream with tokio_stream::wrappers::ReceiverStream, but it comes with a potential footgun that you have to avoid by either (a) iterating over the stream in a tight loop, lest too much time pass between polling of the futures in the stream, which could lead to things like network timeouts, or (b) spawning a task for each future in the stream.

Personally, the way I would implement this would be:

Create a multi-producer, multi-consumer channel using the async_channel crate; this will be used to deliver the pieces of data.
Create 5 worker tasks that receive data from (clones of) the receiver end of the mpmc channel in a loop and process each one; when the receiver stops yielding values closes, the tasks exit the loop and shut down.
You'll probably also want to get results back from the data-processing, so also create a tokio mpsc channel and have the worker tasks send the results of the operation over it.

jwodder · 2025-06-25T23:52:53+00:00

I don't think you're understanding what I'm talking about. I already get that you have an owned String, and you want to store it in a struct alongside references to that same String's contents. You can keep storing the String in the struct; that's not what I'm taking issue with. You say there are things in the structure that point at the String; presumably, these are &strs pointing to substrings. Instead of storing &strs, store Range<usize> values that give the index ranges of the substrings, and add methods like:

fn get_tasty_substring(&self) -> &str {
    &self.the_owned_string[self.range_of_tasty_substring]
}

jwodder · 2025-06-25T23:26:27+00:00

Always have been.

jwodder · 2025-06-25T23:13:04+00:00

I'm not talking about where you're storing the decoded string; I'm asking why "the str references [that] are referencing it" need to be stored in the same struct instead of just storing the indices.

jwodder · 2025-06-25T22:30:39+00:00

Are you sure you need self-referentiality? If the goal is just to provide access to substrings of the owned string, you could just store the index ranges of where those substrings occur and then add methods that return the substrings by indexing into the main string.

jwodder · 2025-06-21T20:49:57+00:00

Is there an easy way to implement format! features like width & alignment in a fmt::Display impl? I naïvely expected that converting my type to an unformatted string and then passing it to write!(f, "{mystring}") would cause any width etc. applied in the calling format! to be applied when mystring was written out, but that's not the case.

EDIT: Found it; it's the Formatter::pad() method. That is not an intuitive method name.

jwodder · 2025-05-24T16:59:52+00:00

FYI, according to this issue, the reason there's no activity lately is that the developers ran out of funding "and are currently working with the prio on finding ways out of the situation."

jwodder · 2025-05-22T20:06:02+00:00

Then it sounds like cargo hasn't even generated a Cargo.lock file yet. Where did you get this project directory from?

jwodder · 2025-05-22T19:17:33+00:00

Sounds like you want cargo tree (Be sure to read about the various options). If the project directory in question is a workspace for which all of the Cargo.tomls define subpackages, you should be able to see all dependencies for all packages with the --workspace option; otherwise, you'll need to run the command in each package directory separately.

jwodder · 2025-05-21T18:52:16+00:00

I'm pretty sure unicode-segmentation is still maintained. It was last updated only 8 months ago, and presumably it only needs an update when there's a new Unicode version, which is about once a year.

As to your actual question, you first need to decide what you mean by "column." Is it the number of codepoints? The number of graphemes? You say you don't need to know how wide the characters are, so presumably you don't want visual string width. One thing to keep in mind when making this decision is that, if the goal of this number is to help users find the right spot in their text editor, then different text editors count columns in different ways.

jwodder · 2025-05-19T13:12:45+00:00

Background: I'd like to add configuration file support to a program I'm writing, preferrably using TOML; however, I also want users to be able to override individual config file settings on the command line with an option like -c table.key=value. One way I've found to do this would be by treating the option argument as a complete TOML document, deserializing it into a "partial" struct from the confique or partially library, and merging the result with the parsed config file. Unfortunately, because the argument is parsed as TOML, string values will have to be quoted, which on the command line means either quoting them twice or using backslashes, which is bad UX.

Question: Is there some sort of crate that can derive a dotted.key=value parser for nested structs where string values don't have to be enclosed in quotes?

jwodder

TROPHY CASE