What's everyone working on this week (22/2018)?


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


I was playing with Actix with Diesel as my ORM but then I updated my nightly and broke Diesel :expressionless:


Improved the responsiveness of diwata when scrolling the record list on mobile devices.

Added a bunch improvement of handling non-commonly used data types such as tsvector, points and time interval.

2 most notable/visible improvements:

Implemented a search/filter for tables

Implemented linking new or existing records to indirect record, a bunch of “magic” going under the hood

The demo is updated at least once a week and for every significant improvements.

There are now 4 sample database for the demo.
russian airlines data
dota2 game heroes
adempiere - a lot of tables


Syntax coloring on crates.rs.


I just created an issue about debugging differences of bootstrap samples (for MLT) between the C++ version and the Rust version of PBRT … I hope to get that fixed this week. I did parallelize this piece of code last week using multi-threading, but I don’t think this is related. Let’s see …


I haven’t had a lot of free time recently, but did get a PR from /u/Aehmlo with 8 new quantities merged into uom (type-safe zero-cost dimensional analysis) and am looking at a rustfmt PR now.


I’m back from RustFest with lots of new ideas! I’ve been stuck in this mindset, that the lpc82x-hal API can’t really know what state the hardware is initially in. Accommodating for this has caused quite a bit of complexity, as the API provides safety guarantess by tracking the hardware state at compile-time.

@japaric had a suggestion that should allow me to make sure the hardware is in its default state when the API is initialized. I haven’t finished implementing it, but it’s looking good so far!


Yesterday I managed to use monocle to debug the timing error I got when communicating with a dht22 humidity and pressure sensor, turns out I had turned off optimizations in release mode :upside_down_face:. At least it shows that monocle is actually useable now

This week I’ll probably do some more work on my weather station


Rewrote camera streams recorder (records HLS/MJPEG streams, process them, tar them, upload to S3, send SQS message) to Rust. It was fun, AWS costs are much lower and it looks like it’s rock stable when I compare it to the previous one written in JS. Tokio, Hyper, Rusoto, … easily handles 750 / 750 Mbps (rx / tx) 24/7 in one thread on r4.large. Looking forward to the new Tokio / Futures / Hyper where I can utilize all cores more easily (I can do it even now, but it’s not that straightforward).


Brought the difference between C++ and Rust down to 16 (out of 600.000) values. That gives me some hope to fix the problem this week …


(I asked you last week for the data)

Do you have a repo somewhere? I’d be happy to collaborate on it rather than start my own thing if you are ok with getting some UX/UI done


I’ll DM you to avoid adding noise to the thread.


I’m working on getting CI set up for other platforms on GitLab using Trust (tracking this in my trust_ci branch. But since that doesn’t support GitLab, it’s rough going. It relies on some special features of Travis. I’m hoping I can figure it out within the next couple of days as I really want to get the number of platforms supported by my crate beyond the big three (recently had a PR enabling musl support).

So if anyone has configured GitLab CI to test on a bunch of different platforms, I’d love to see your configuration.


I’ve started working on a tiny firmware for the Teensy 3.2, which is ARM Cortex-M4 based. So far, I’ve disabled the watchdog timer, can write to GPIO ports, and moved to using the PLL and external oscillator. Next is working out how to identify as a USB keyboard to the host!

This is my first experience programming a microcontroller, so any constructive criticism is also welcome :wink: