If you're here from crates.io and wondering where GitHub is, it's gay and I refuse to use it.
This website doubles as a Cargo registry for some of the above
projects, if crates.io ever goes down (though I'm not mirroring
the dependencies... might be a good idea even if they'd massively bloat
everything).
Another caveat is I'm not gonna host each individual version of my
projects, only the latest, so you might need to update your
.lock file occasionally.
To use the registry, append this to your .cargo/config.toml, and when
adding dependencies with Cargo, use:
cargo add --repository tesseract ...
arg-kit
arg-kit is a featherweight library that helps parse
arguments using one of Rust's most versatile and powerful syntaxes:
match {}
Do you really need bloated proc macros when collecting arguments can
be simplified to a .next()
? You have zero indication of
what's going on under the hood, so you can't implement your own
behaviour.
That is why I don't call it an "argument parser" on its own. Your program parses the arguments, this just helps iterate over it, like so:
let mut argv = std::env::args();
for_args!(argv; {
arg!(-h | --help) => eprintln!("{HELP_TEXT}"),
arg!(-v | --value) => do_something(argv.next()?),
unknown => panic!("Unknown argument {unknown}"),
});
...which expands to:
let mut argv = std::env::args();
while let Some(args) = argv.next() {
for arg in args.as_arg() {
match arg {
...
}
}
}
mew
- Working, but WIP -
wgpu is a 1:1 API for the WebGPU standard. While that makes it very portable, versatile, and well-documented, since I'm not a hardcore graphics chud, I don't find it very intuitive to use.
My main problem with it is how many bloody times you need to define the same thing, and quadruple-check that all the layouts line up with each other. This library aims to, at least a little bit, make it easier to define all the related information in one place (in wrapper structs).
It primarily uses like 10 macro_rules!
to write
boilerplate that generates buffer, bind group, and pipeline layouts. It
also stores them in a convenient "render context" struct.
Again, the point isn't to create an entirely new graphics framework, but just to make it maybe easier for us mortals to keep on top of the rendering pipeline.