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
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.
sakila
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 . 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