Crate of the Week

As a response to BreadX, here is something even more powerful: x11rb

  • x11rb supports all the X11 extensions for which the libxcb project provides XML project (BreadX so far only supports the core X11 protocol that is older than I am)
    • Basically: All X11 extensions that are still relevant are supported
  • x11rb can be used as 100% safe Rust (with #[forbid(unsafe_code)])
  • When the allow-unsafe-code feature is enabled (which it is by default), you additionally gain access to an FFI-based libxcb interop. All the serializing / unserializing still happens in safe Rust and only the "on-the-wire bytes" are exchanged with libxcb
  • On Unix, x11rb also supports FD-passing. This allows to exchange file descriptors with the X11 server. For example, this is used by the shared memory extension to exchange shared memory in a safe way.
  • Also supports Windows (and this is even tested in CI) (but I guess BreadX also works on Windows)
  • Besides the pure protocol, there are also a couple of helpers to load cursor files, simplify image handling, and to access the X11 resource database (Xrm)

To be fair, the first commit to BreadX happened in June (half a year ago), while x11rb was started in September 2019 (15 months ago).

The only downside to x11rb is that you cannot opt-out Sync. However, I am also curious to see numbers for BreadX's claim "generally faster". Is Mutex really that bad for a network protocol? If so, one could easily add a variant to x11rb that uses RefCell instead of Mutex.

Since BreadX's README also says that its "dependencies are either safe or verified":

  • On Unix, x11rb depends on gethostname and nix
  • On Windows, x11rb depends on winapi and winapi-wsapoll (smaller wrapper crate that exposes a safe API to winapi's WSAPoll())
  • With the allow-unsafe-code feature, the libxcb FFI needs libc::free() and some type definitions from libc

I do not know what "verified" refers to, but I would say these dependencies are reasonable. The gethostname dependency is needed to properly deal with ~/.Xauthority files, which is something that BreadX does not support yet.


Since my previous post apparently disappeared: x11rb, a crate similar to this week's BreadX, but supporting all the X11 extensions and file descriptor passing. Also, if you not disable the allow-unsafe-code cargo feature, there is FFI-based interoperability with libxcb (where all the "messing with bytes" still happens in safe Rust and only the "on-the-wire bytes" are exchanged with libxcb).

1 Like

Sorry about that. Posts by new users sometimes get caught by our spam filter and require manual approval.


From the ReadMe:

This crate is primarily used to load new function definitions from shared object files in an exceedingly easy way.


The new experimental 5.0 release seems to be faster than FFTW:


Autograd: Tensors and differentiable operations (like TensorFlow) in Rust


nom-supreme is a crate of utilities for nom parsers, especially for great parse error handling.


Just stumbled across this project and I'm pretty stoked about it. It helps you automatically "absorb" changes into your git history without having to manually find the relevant commits. I have often wanted to have this functionality and haven't been able to find this until now.

If this isn't making sense, learn more about git fixup and autosquash.


It seems to be faster than the lexical crate.



A nice crate implementing some numeric algorithms.

1 Like

StructOpt if you ever want easy commandline parser


Yes, StructOpt is cool as is CLAP. Looks like both will merge in a future version of CLAP.
StructOpt was already crate of the week in issue 186.

broccoli: A 2D collision detection crate.

This looks nice, I wonder how it compares to ncollide.

Allows you to have some nice diagrams in your docs.


A Rust macro for writing regex pattern matching.


fn main() {
    let text1 = "2020-01-01";
    regexm::regexm!(match text1 {
        r"^\d{4}$" => println!("y"),
        r"^\d{4}-\d{2}$" => println!("y-m"),
        r"^\d{4}-\d{2}-\d{2}$" => {
            let y_m_d = "y-m-d";
            println!("{}", y_m_d);
        _ => println!("default"),

Pals, Processes' Arguments LiSt

The pals command dumps all running processes' pid,ppid,command name,arguments and prints JSON to reflect the process trees.

Example of output

[{cmd: "alpha", pid:105, args:[ "alpha" ], subs:[
  {cmd: "beta", pid:107, args:[ "beta", "--help" ]},
  {cmd: "gamma", pid:106 }]},
 {cmd: "lorum", pid:102, subs:[
  {cmd: "ipsumipsum", pid:104, args:[ "ipsumipsumipsum", "--name-too-long" ]}]}]

The pals library provides pals() which returns a list of process trees.

Example of API usage

use pals::{Proc, pals};

pals().map( |proc_list| {
    fn assert_ppid_is_parent_pid( proc: Proc ) {
            .map( |parent| assert_eq!(, proc.ppid ));
            .for_each( |subproc| assert_ppid_is_parent_pid( subproc ));

        .for_each( |proc| assert_ppid_is_parent_pid( proc ))
1 Like

fancy-regex is really cool. It implements backtracking and look-around for regular expressions while delegating as much as possible to the regex crate.

In essence, it is a backtracking VM (as well explained in Regular Expression Matching: the Virtual Machine Approach) in which one of the "instructions" in the VM delegates to an inner NFA implementation (in Rust, the regex crate, though a similar approach would certainly be possible using RE2 or the Go regexp package). Then there's an analysis which decides for each subexpression whether it is "hard", or can be delegated to the NFA matcher. At the moment, it is eager, and delegates as much as possible to the NFA engine.


iai looks really nice. From the README:

Iai is an experimental benchmarking harness that uses Cachegrind to perform extremely precise single-shot measurements of Rust code.