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

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

Just started a new job so probably won't have much time this week, but I will find some downtime to work on mentoring instructions for a couple of the bigger issues from the semver evaluation. We've also got env_logger pretty well ready for a new release once log does which is exciting.


Solar Position Algorithm library version 0.1.0 has been released: https://crates.io/crates/spa The library provides functionality to calculate sunrise-sunset and azimuth-zenith for a specific geo-position and time (UTC). Use cases are solar-panel-alignment, simulation, or planning of resource consumption with first daylight at a geo-position. This week I will enhance unit-tests and documentation.


So far I kept the whole rs_pbrt library in a single file (with 13280 lines of code).

Time to split it into several modules before it's getting too hard to edit :blush:

Maybe that helps bringing down the compile time as well ...


Studying @fyl2xp1's own take on the triple buffering problem helped me figure out a way to extend triple_buffer's interface so that expert users can manipulate the data structure more efficiently when they need to, without harming the user experience of those who don't need to care about the low-level details. Thanks for the fresh look, @fyl2xp1!

Along the way, I also tagged v1.0.0 because I figured out there was no good reason not to (people have had plenty of time to submit design feedback, and the remaining upstream issues that I'm waiting for will not have an effect on the API).

So the interface extensions will hopefully be integrated in v1.1.0. After that, I'll need to figure out to which extent I want to propagate those changes to spmc_buffer. Basically, the tradeoff is that in spmc_buffer, allowing the consumer to write into its own buffer is much more costly than in triple_buffer, because there has to be a memory copy involved somewhere in order to avoid a data race between consumers.

EDIT: Also, while I had a look at triple_buffer, found a nasty memory safety bug lurking around in spmc_buffer. Until this one is patched, please refrain from creating an SPMCBuffer<Cell<T>>, which is currently not illegal but should be :disappointed_relieved:

EDIT #2: Fixed in spmc_buffer v0.4.2.


Another week working on uom (type-safe zero-cost dimensional analysis). This week I got tests compiling for all primitive storage types. Not sure what to do about other types like BigInt and Rational as I'm using quickcheck and the Arbitrary trait isn't defined for these types.


Preparing examples (and fixing ergonomics issues) for CNTK wrapper:
https://github.com/usamec/cntk-rs/tree/master/examples (https://crates.io/crates/cntk).

1 Like

I wrote what was supposed to be my first RFC but got moved over to an Style Guide / Idiom “Idiom: Prefer Guard Clause over Nested Conditionals” and have also created my first Pre-RFC: Allow Pattern Matching after Guard Clause all in the hopes of creating better code practices and easier ways for beginners to learn Rust.

I'm implementing a resume-work feature for my abrute decryption tool since I have power outages every now and then.

And I need to deploy Rust to a web host production environment for research for my next blog post soon.


I've almost done refactoring of tk-pool (connection pools for tokio). The type signatures became quite complex, but I'm pretty much satisfied with the whole lot of things it can support now.


So, I think I got the raw interface rolling in triple_buffer v1.1.0, but I'm still fighting with cargo features and their interactions with cargo doc and cargo test at the moment. For example, I don't manage to cleanly state that a doctest requires a certain cargo feature, to make sure that a test runs if and only if a feature is enabled, or to tell something like docs.rs that it should render the docs with specific optional features enabled...

Will take a closer look at this when I have more time. In meantime, I'm working around this by building a private interface which is effectively the implementation of the optional public interface, and testing this instead of the real thing. And disabling the doctest. But it all feels very dirty :frowning: