With Rust 1.48 out:
(If this is not visible, both points above are links to crates.io
)
From the ReadMe:
A set of macros for conveniently initializing Vec, HashMap, HashSet, BTreeMap, BTreeSet and iterators.
How does it differ from cargo-expand
?
cargo-expand
just expands out macros and inlines modules. cargo-inspect
will let you view what a for
loop desugars to, for example. Practical purpose for most people? Probably not a ton. But for nerds like me…it's interesting.
From the ReadMe:
Thermite is a WIP SIMD library focused on providing portable SIMD acceleration of SoA (Structure of Arrays) algorithms, using consistent-length1 SIMD vectors for lockstep iteration and computation.
From the ReadMe:
An Rust implementation of asynchronous parallel streams analogous to rayon.
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
andnix
- On Windows, x11rb depends on
winapi
andwinapi-wsapoll
(smaller wrapper crate that exposes a safe API to winapi'sWSAPoll()
) - With the
allow-unsafe-code
feature, the libxcb FFI needslibc::free()
and some type definitions fromlibc
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).
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:
nom-supreme is a crate of utilities for nom parsers, especially for great parse error handling.