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

community
1

New week, new Rust! What are you folks up to?

2

There's a whole lot of PRs to review from the libz blitz of walkdir. I think we'll need to start getting those merged in so we don't end up blocked.

I'm working on getting date math added to elastic_types and am currently shaving yaks to make some of the generic traits nicer to work with.

I've also started working on a more complete aggregations parser for elastic_responses which should nicely support the various kinds of spongy aggregations Elasticsearch can spit at you, and be more efficient if you use the typed_keys query parameter.

Now that reqwest has an unstable async API I want to start playing with that in elastic_reqwest and see how jarring it is to support both a synchronous and asynchronous API there.

1 Like
3

I'm on my quest of adding an ECS to my prototype project https://github.com/tanis2000/minigame-rust

I started porting my own C++ implementation but it doesn't really fit the way Rust code should work like so I'm exploring lots of different solutions to make it more Rust-alike.

2 Likes
4

A project I call "rhxd." It's a would-be server for an old chat/file sharing/BBS called Hotline. The name itself is homage to a Unix open source server program made for it called hxd. Though, with Tokio inevitably putting a knot in my brain come time to develop the asynchronicity of file transfers, I'm bracing myself.

5

I'm still working on the parser for rs_pbrt:

https://github.com/wahn/rs_pbrt/commit/8a6a9acf9bbb538ec44ff949f92c2ff97bdfdf24

The simple test scene (file with scene description) gets parsed, tokens get generated, and in the pest's crate !process section the read parameters can be used to print the read information out with slightly different formatting. So, what I'm working on is the API of my library to more or less call a API function for each read statement, store the information in a global state until you read the WorldEnd token and you are ready to render the generated scene multi-threaded.

If you look at the link above it points to a checkin, where I had to switch to Rust unstable because of the #![feature(drop_types_in_const)]. I was not able to find a better way for storing the parsed information in some global struct and paramters. Basically I wanted kind of a NULL pointer, which later points to the global struct:

...
#![feature(drop_types_in_const)]
...
static mut RENDER_OPTIONS: Option<Box<RenderOptions>> = None;
...
fn main() {
...
                unsafe {
                    // render options
                    RENDER_OPTIONS = Some(Box::new(RenderOptions::default()));
                    // parser
                    let mut parser = Rdp::new(StringInput::new(&str_buf));
...
                }
...
}

If somebody knows a better way to do this with Rust stable, please let me know !

6

Had some fun building a purposely racey, yet legal container in testbench for the purpose of improving triple_buffer and spmc_buffer's unit tests. Now, if there's a failure in the synchronization protocol which exposes a half-written buffer, the unit tests should detect it.

I still don't have an explanation for the macOS-specific spmc_buffer unit test failures on Travis, but I found a way to get my SSH-hands on a Mac, so I should be able to figure it out at some point during this month :slight_smile:

And... hopefully, this week, I should be able to get started again on my Linux GUI system performance monitoring tool project!

7