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

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.

3 Likes

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