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


#1

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


#2

Last week I merged all the elastic-rs repos together so now they all live in elastic. I was surprised how much stuff there is in there when all the crates were pulled together! Next step is to go put together a CONTRIBUTING.md and try make it friendlier to navigate, use and contribute to.

Also on my mind this week is cluster sniffing, so we can support round-robinning requests to either a fixed or dynamic set of node addresses. I also need to add a bunch more integration tests and add async support to the little benchmark harness.

The libz blitz evaluation for rayon is happening this week too, and there’s always room for more feedback :slight_smile:


#3

I will work on another test scene from here:

That will include some changes to the parser and adding another shape, a cone. Once it can render both lighting variants I will make another minor release. Last week I added a progress bar (because render times go up now and you would like to get an indication on how long you have to wait for a rendered image). I also got OpenEXR working as an output image format, but I deactivated it for now because it complicates the continous integration (CI) via Travis. Maybe I find a better way to solve the dependency on OpenEXR. I will need OpenEXR texture files as input for other scenes anyway, e.g. to simulate sun & sky shaders.


#4

Back from vacation (again, it’s a tough life) and getting back into uom (type-safe zero-cost dimensional analysis) work. Thermodynamic temperature/temperature difference work on hold while trying to make the underlying storage type based on traits in the Num crate instead of fixed f32 and f64 implementations.


#5

jvmkill is a Java Virtual Machine Tooling Interface (JVMTI) agent recently ported from C++ to Rust. jvmkill forcibly terminates the JVM when it is unable to allocate memory or create a thread, so that the JVM will be restarted by an external process manager.

jvmkill uses bindgen to generate FFI bindings to the JVMTI and Java Native Interface (JNI) C interfaces. Unfortunately, the JVMTI interface includes a bitfield of more than 64 bits, so we had to pin bindgen to an old version in order to set the first bit of the bitfield, since later versions no longer generate the necessary setter method.

This week I’m starting work on adding the missing bitfield support into bindgen. I’m grateful to some of the bindgen committers for giving me hints and for mentioning that bindgen is currently being weaned off the deprecated syntex crate. David Tolnay’s excellent talk Macros 1.1 + Syn + Quote gave me a good introduction to the replacement for syntex.


#6

I did the (minor) release:

More scenes to render :wink:


#7

I’m working on gnome-class, @nikomatsakis’s code generator for GObject implementations.

OK, that’s what I like to tell myself. In reality, I’m reading a lot of glib-rs and glib source code to really understand how to modify the existing gnome-class to move it to glib-rs’s scheme.


#8

I’ve been working on a Labview LVM parser. It needs polish / documentation so it isn’t ready for an official announcement yet, but I’m open to feedback and it works on the couple of samples I have right now.