What's everyone working on this week (51/2017)?


New week, new Rust! What are you folks up to?


I haven’t being doing much in Rust lately, but at least I am keep solving the daily programming challenges from the Advent Of Code 2017 using Rust — which helps in keeping the cogs well oiled :wink:


Lots of work on uom (type-safe zero-cost dimensional analysis) this last week. I have tests cleaned up (still failures for non-float types, but I’m going to punt on fixing them until then next release), replaced compile_fail dependency with the new compilefail doc tests, and started reviewing documentation and the changelog. I’m planning to work on the last two tasks this week and hopefully release a new version.


I’m working on polishing up the colouring API in env_logger to make it public and will push out another release candidate for peeps to try out and comment on.

I’ll also try find time to screencast using failure better in a sample webapp. Right now I’m just returning Errors, but want to start using contexts and a sprinkling of concrete error types, logging errors, and returning appropriate HTTP responses from rocket depending on the kind of error.


Hey @iliekturtles, today I’m finally gonna try using your dev-num branch in my project to manage distance. I’ll let you know if I have any problems. Thanks for your work!


Excellent. Let me know any issues you run into. Once I release the current changes items like Eq, PartialEq, Ord, PartialOrd are next on my list.


@iliekturtles: Just a list of papercuts so far:

  • At first, being new to uom, I was surprised about how an implicit “base unit” is used for representation, instead of the unit passed as the type argument to new – this is usually no big deal with float types, but it surprised me with the new integral types, since I tried representing 1 cm and got 0 meters. I suppose this is just an education/documentation issue. I eventually figured out I had to generate my own types with ISQ!.

  • In addition to the basic num traits, it would also be nice to have num::Saturating since I use it in a few places sorry, I was confused about the traits :slight_smile:

  • I also think I’ll want Serde support, too – while Serde has fairly good support for remote crates (https://serde.rs/remote-derive.html), it’d be nice if uom supported serde directly with an optional feature. Does that sound reasonable?

I’ll see how far I can get, and if these points seem reasonable, I may be able to submit some PRs!


With the winapi 0.3 release, I’ve just released version 2.0 of serialport-rs, a low-level serial port library. This library and my serial terminal app Gattii need some love and attention with minor bug fixes, CI improvements, etc. I’ll probably put out another Gattii release that fixes some crashing bugs that I’d prefer not to have in it.


I prepared a new test scene and crated an issue to implement MixMaterial:


That’s what I’m going to work on …


Nothing yet but on Friday I will finally start working on some of my Rust projects again! First up is to work on my Qt bindings for Rust (I’m rolling my own as it’s a API on top of Qt and not a 1:1 wrapper and I have some more requirements on it)

After that I will do a big stab on my debugger project and it’s also going to be used in another (yet unannounced project, watch this space!)

I have from Jan decided to take 3 (or 6 depends on how I want to do) months off from work to invest time in (mostly) these projects which are both written in Rust.

So exiting times going forward :slight_smile:


Going down the rabbit hole and analyzing Linux perf samples (after perf script preprocessing) to figure out why only ~80% of my call graph samples are attributed to the program that I am running.

Rust is pretty wonderful at this kind of large-scale structured text processing tasks. It will also be the second time that I get to use it at work, so… :tada:


I wrote a little tool while on a plane trip last week to do source-interleaved disassembly of binaries. I was motivated to do so after trying to coerce objdump to do this and getting frustrated with what a crummy interface objdump provides. As an offshoot of that work I fleshed out a start to the moria crate, to locate debug symbols for stripped binaries (the original problem I was trying to solve was to get source-interleaved disassembly for a Firefox Nightly build, which would have this problem).

After showing rust-disasm to a group of colleagues last week at the Mozilla All Hands and getting lots of positive feedback I decided to start an informal Rust debugger tools interest group. So far it’s just an IRC channel and a small curated list of useful crates, but I think things are in a really great place to do exciting things there in Rust!


Still working on lpc82x-hal. I’ve mainly been working on safety improvements. The goal is to use Rust’s type system to make it impossible to use the hardware incorrectly through the HAL API.

There’s still a lot of work to do, but it will have to wait, as I’ve started my end-of-year vacation. I’ll be back in January.


Two weeks ago, I wrote

I wrote an initial version of my RPi3 Rust project, project Ada, conforming to this design4 back in August.

The plan to achieve loose coupling was to use constructor dependency injection. And I ran into the twin brick walls of dynamic dispatch (undesirable for project Ada) and limitations of object-safety (irreconcilable, AFAICT with a fluent API, which loves to return Self).

So I had to retool to figure out a way to do static dependency injection, which would bypass both issues.

This week (and possibly next), refactor project Ada to use this static dependency injection technique and maybe also add concurrency.

I’m happy to say that just yesterday, I succeeded in connecting all the pieces to prove Project Ada’s software design using (primitive) static dependency injection! :tada:

Adding concurrency in that same timeframe was wildly optimistic–that will likely take me two to three weeks on its own, but is not a must-have just yet.

The major accomplishment of my past 15 months of investment with Rust has been accomplished–I’m both proud of myself for embarking on this expedition (turns out you can teach an old dog new tricks) and extremely pleased with Rust-- it’s not every programming language that can support building statically polymorphic constructor dependency injected, lock-free, SOLID, BDD code with (hand-rolled) mocks, zero runtime overhead, plus all of Rust’s safety guarantees–that’s really quite astonishing, IMHO. And, as I mentioned above, I’m quite confident (dare I say fearless?) that adding concurrency will not destabilize my codebase.

This week will be a bit of minor cleanup before moving from my current development phase (Tools) to the 2nd phase of development: Board, where my focus will shift to manipulating physical hardware (currently a Raspberry Pi 3). The Board phase should be more interesting to show progress on (as opposed to source code), so in the new year, I’ll try to find a way to share meaningful progress with the community–perhaps with a short video.

I kept fairly close tabs on C++17 developments for years looking for many of the capabilities I am currently enjoying in my language of choice for this project before discovering Rust. With the above achievement proving out Rust’s capability, I have to say that if I were, say, an aging, general-interest magazine with a 2017 Technology-of-the-Year award, Rust would be taking home the honors. :slight_smile:


I added a few new features to my abrute decryption tool. Mainly it comes down to this…

  • Computer Cluster support and reporting via JSON endpoint
  • Custom CLI reporter visualizations including ticker tape and spinner reporters

I’m considering implementing a web client to build and report the data from cluster nodes.


I’ve made the first release of mrkl, a generic, optionally parallelized realization of a Merkle tree, AKA hash tree.


Thanks for your great work with env_logger!


Just published this one if anyone is curious: https://github.com/HadrienG2/perf-script-analyze .