New week, new Rust! What are you folks up to?
I have encountered several times now a situation where I need to count the number of bytes or characters of a stream per line, and it's a headache to have to look up the awk
function, or come up with the magical incantation of xargs
and wc
. Additionally, support for Unicode is iffy.
I figured this is a good opportunity to simultaneously learn Rust and more about Unicode, so I decided to write a utility like wc
, but has the ability to count things per line out of the box, and is Unicode-aware. I'm also thinking it may be a good candidate for parallelization with rayon
or something.
https://github.com/dead10ck/uwc/tree/develop
It's still in its very early stages, but I managed to get it counting things today. I've learned how unfortunately lacking Unicode support is in the Rust ecosystem. unicode-segmentation is helpful, and what I've decided to use for now, but it only exposes its functionality through iterators, which makes optimizations difficult. e.g., doing all the counting in a single pass is impossible, since I'd need to be able to tell the difference between a grapheme cluster that's a word separator and one that's not.
There's also rust-unic, which looks like it could be more useful, but its status is unclear; there appears to be two months of work in master that haven't been released yet.
I'm still working on my hardware abstraction layer for LPC82x microcontrollers. In fact, I just published it on GitHub this morning! It's a good first step, I think, but still lots to do.
Still working through tests on uom
(type-safe zero-cost dimensional analysis) to support integer storage types. Ended up implementing multiplication and division with a literal right-hand-side and cleaning up some float tests this last week.
I am still working on my big refactoring of clerk, but it's almost done now.
Here are some of the things that will/have improved:
- add implementation for 8 bit (data-lines) mode
- each
Pin
can have it's own type now (as suggested by @japaric, thanks for this) - additional high-level communication traits for sending, receiving data
with them it should be possible to use other connection methods (protocols) like I²C for example - internal type
Address
with 'software overflow' to simulate the behaviour of the real address counter when in write only mode
Thanks to all who helped out here or on IRC.
I was implementing MetalMaterial this week, and while working on it I noticed that the test scene is actually using depth of field, so I created another issue about it. Hopefully I find some time to work on it. Shouldn't be too hard to add ...