New week, new Rust! What are you folks up to?
I was playing with
Diesel as my ORM but then I updated my nightly and broke
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.
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 . 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