Crate of the Week


#161

json rust: The propably fastest json serializer and parser implementation. At least faster than serde!


#162

json-benchmark, which shows the opposite :wink:


#163

Oh, you catched up! :slight_smile:


#164

Still faster than Serde for DOM except for that damn canada.json benchmark ;).

I really like how beneficially this whole benchmarking endeavour has been for both libraries thus far.


#165

Since there have been a few exciting low-level networking posts recently (as in the last few months), how about libpnet, the crate that the community is coalescing around for this kind of work?


#166

I’m going to go ahead and put my trace library out there. trace is a syntax extension for tracing the execution of functions in your code. I’ve found it very useful for debugging complex recursive programs, where I normally would have inserted print statements everywhere for seeing which functions were being called.


#167

I was recently happy to discover lru_time_cache by maidsafe. It’s a useful least recently used cache crate that implements the entry API.


#168

I’d like to announce a project I’ve been working on for a while:

git-series provides a tool for managing patch series with git, tracking the “history of history”. git series tracks changes to the patch series over time, including rebases and other non-fast-forwarding changes. git series also tracks a cover letter for the patch series, formats the series for email, and prepares pull requests. This makes it easier to collaborate on a patch series, distribution package, backport, or any other development process that includes rebasing or non-fast-forward development.

A patch series typically goes through multiple iterations before submission; the path from idea to RFC to [PATCHv12 1/8] includes many invocations of git rebase -i. However, while Git tracks and organizes commits quite well, it doesn’t actually track changes to a patch series at all, outside of the ephemeral reflog. This makes it a challenge to collaborate on a patch series, distribution package, backport, or any other development process that includes rebasing or non-fast-forward development.

Typically, tracking the evolution of a patch series over time involves moving part of the version control outside of git. You can move the patch series from git into quilt or a distribution package, and then version the patch files with git, losing the power of git’s tools. Or, you can keep the patch series in git, and version it via multiple named branches; however, names like feature-v2, feature-v3-typofix, and feature-v8-rebased-4.6-alice-fix sound like filenames from corporate email, not modern version control. And either way, git doesn’t track your cover letter at all.

git-series tracks both a patch series and its evolution within the same git repository. git-series works entirely with existing git features, allowing git to push and pull a series to any git repository along with other branches and tags. Each time you change the patch series, whether fast-forwarding or not, you can “git series commit” a new version of the patch series, complete with commit message.


#169

Edit: this project has been renamed to rst (from rsk)

I’d like to announce the beta release of my rust project and submit it for crate of the week.

rst is a requirements tracking tool made for developers. It is cmd line and text based, integrating easily with the work flows of unit testing and revision control. It allows you to easily write, view, and track the completion of your requirements, design-specs, and tests. Check it out!


#170

Nominating RustType!

It’s an easy to use, well documented, efficient, pure-rust alternative to libraries like FreeType by @dylanede .

We recently adopted it within Conrod as a replacement for FreeType and as the final piece to our pure-rust puzzle. It will make life a lot easier for new users (especially on windows) now that we no longer require any external libraries to be installed.


#171

How does this compete with font-rs?


#172

Please see the crate ‘crashtag’. Crashtags are strings being embedded into crash-files (core files) of aborting applications, for example release information or runtime environment of the application. Receiving just the core-file, the crashtags can be extracted with simple expression: ‘cat core | strings | grep MY_TAG’

https://crates.io/crates/crashtag


#173

For the next iteration I nominate cursive - A TUI (Text User Interface) library focused on ease-of-use.


#174

rq, like jq but even more awesome.


#175

I’d like to submit dynasm: A plugin for assembling code at runtime:

https://users.rust-lang.org/t/announcing-dynasm-rs-a-compiler-plugin-for-assembling-and-executing-code-at-runtime/7088


#176

That’s a cool program but it’s not a crate. At least, it’s not on crates.io.


#177

It is implemented as the dynasm and dynasmrt crates, which are available on crates.io.


#178

I was replying to @stebalien regarding rq.


#179

It’s still a crate, crates don’t have to be on crates.io (crate is just the unit of compilation in rust).


#180

I’d like to nominate ring as it will enable more work on modern, robust security-focused applications (e.g. moving away from OpenSSL).