New week, new Rust. So what are you folks up to?
1 Like
I will probably start writing a BNF/EBNF/ABNF parser in LALRPOP.
I see you are working on PCMCIA-Support.
For me, it's work on writing, and maybe playing around with ANT+, if I can get hold of a device. Let's see.
I've been working on a crate that implements (more or less) accurate floating-point algorithms, so far for sums and dot products. The algorithms seem to perform as intended (the documentation has figures of the achieved accuracy). Now comes the time to benchmark and optimize. AddAssign should come in handy here once it is stable. The public interface could probably also use some more thought.
My MPI crate is slowly accumulating the feature list that would make a sensible 1.0, but I fear it is up for a safety review first.
Crosspost from reddit:
Been working on a template engine based on jinja2/django GitHub - Keats/tera: A template engine for Rust based on Jinja2/Django
Missing inheritance/blocks template and any kind of error handling so not usable yet.
I'm not planning to do an exact copy of jinja2/django so if you used them and liked/disliked some things, let me know.
The current code is quite horrible so I could use some help! (don't look at the ==/!= handling in the rendering, shudders)
Looking for more crates/types to add support to multipart for. Goes without saying that I'm taking requests!
First on the list is Hyper's client::RequestBuilder, which requires a lazy approach instead of the current eager one--ironically, multipart's client implementation used to be lazy, so maybe I'll go back to that or somehow provide both. I want to try static chaining a la std::io::Chain to avoid both allocations and dynamic dispatch, but I'll probably have to provide some sort of dynamically dispatched fallback for requests which need to be built dynamically (e.g. adding fields based on runtime data).
And another feature I have in mind which I'll need specialization for: being able to create sized requests without having to write the entire request into memory to measure it. I'll have a trait inheriting from Read which adds a function that returns an Option<u64>, with a default impl that returns None and specialized impls which return Some(size) if they can accurately get the number of bytes in the reader, e.g. like &[u8] or File for finite-sized files. If all readers added to the request returned Some(size), then the total size of the request must be the sum of all these values plus all the HTTP boilerplate, which is relatively easy to measure.
Seems like a good project for me to get into. I've starred it and will take a look after work 
Not really my week's work, but since I need it, I just wrote a crate to schedule callbacks for execution at a given timestamp/after a given delay. It's called timer.
1 Like
I've been doing some stuff with JNI, so I dumped jni.h into a -sys crate: https://crates.io/crates/jni-sys. I have some higher level wrappers over the raw API that I want to clean up and put into a crate as well.
JNI does have the largest struct definition I've ever seen: jni_sys::JNINativeInterface_ - Rust
2 Likes
When I was working with SAP, we had the joke "How do you tell it's a Business Object? It has more then a hundred members."
2 Likes
Trying to get my learning library (https://github.com/xetra11/renderay.rs) migrated to Rust...love it!
I published Parts 12 and 13 of my ongoing series comparing Rust and Swift, looking at properties and methods in both languages respectively.
(The series is my attempt to describe the two fairly and with an eye to their relative strengths and weaknesses, and while I like Rust a bit better, I have lots of good things to say about Swift as well. Also, I'm happy to add corrections or clarifications if people see things that are incorrect or just unclear!)
The current WEWOTW is over here: What's everyone working on this week (10/2016)? - #2 by skade
1 Like