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


#1

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


#2

Did some cleanup work in my procfs pseudo-file samplers:

  • Replaced unwraps with more self-documenting expects
  • Reworded some ambiguous, ill-written, or misleading comments
  • Extracted a number of smaller submodules from the unpleasantly large /proc/stat module
  • Looking for ways to refactor some almost identical code across samplers

Also started work on /proc/meminfo sampling, but that is for now very preliminary.

The middle-term plan after that is to also add some storage activity from /proc/diskstats and network activity from /proc/net/dev. Then, if all of this exhibits satisfactory performance, thus confirming that there is something interesting to be done with high-rate procfs sampling, finish interface cleanup, publish the sampler crate, and start working on a GUI.


#3

Picking up from where @jdub left off on incremental compilation in gcc-rs. I added support in the incremental branch for caching (some) build info, which brought the subsequent build time on a large, C-heavy project I’m working on down to under two minutes when rebuilding gcc-rs itself. Incremental compilation has been a long time coming, so hopefully we can land it soon!


#4

I’ve started playing with reqwests unstable async API and had a crack at making the response body decoder work for async responses too.

I’ll look at opening a tracking issue for the libz blitz for same-file this week so if anyone has any feedback to offer please jump on that thread! :slight_smile:

I’m doing a talk at a local Meetup about elastic this week and am working on a proposal for the RustFest CFP that will keep me busy for a while.

So probably not a lot of actual coding this week :smile:


#5

I’ve released the first version of easyfibers. An easy to use coroutine library that does not use closures and aims to be as easy to use and integrate as possible. Runs on top of mio and context-rs.


#6

I’m working on applicative_functor - adding applicative functor’s interface to existing monadic entities in Rust’s standard library. However, because of the lack of Higher-Order Types, my trait can’t be generic enough over the type returned by the ap method, so apparently I have to stay with OptionApplicativeFunctor for ap returning Option, etc.

Also, this is my first post here. Pleased to meet you all!


#7

I did fix a bug in the sampler code of rs_pbrt, so now I get a nearly perfect match between the C++ and Rust version. The remaining (5 of 65536) pixels which render differently, are probably caused by the usage of HDR (OpenEXR) on the C++ side.

There are a couple of things I could do the rest of the week:

  1. Add another sampler (see issues #9)
  2. Implement another accelerator (see issue #4)
  3. Fill in some gaps in the documentation.
  4. Work on another test scene.

I probably go for the last item, and create a Cornell Box for PBRT. I do have a Python script for Blender which allows me to export in various renderer related scene description file formats:

https://bitbucket.org/wahn/blender-add-ons/wiki/io_scene_multi

One of them is for Luxrender, which is based on an earlier version of PBRT, so that should be doable. To get the direct lighting working I probably just have to work on the area light code for meshes. Global illumination (GI) would be the next step, but that’s too much for this week :sweat_smile: