What's everyone working on this week (35/2018)?

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

It seems like I am writing a Rust compiler fronted, again? At least, I’ve just added local name resolution to libsyntax2 :smiley:


I've just added the implementation for drawing lines in svgbob. Demo



After a couple busy weeks of life and summer I’m back to uom (type-safe zero-cost dimensional analysis) and looking to get a feature hygiene fix and the thermodynamic temperature/temperature interval changes merged into master so I can release a new version in the next couple weeks.


I’m working on that : Servers for realtime AI simulation engine

Work on the DWM1001 and DW1000 crates is ongoing. I haven’t managed to send any wireless packages yet, unfortunately, but I got some of necessary improvements to the crates out of the way that should help me getting there. Also landed some pull requests in nrf52-hal.

Hopefully I’m getting my PR merged to nphysics ! https://github.com/sebcrozet/nphysics/pull/133 ; after that, I’ll continue my quest to make a generic 2d game server.


Implementing the skeleton of a character selection menu for my game. Tricky thing is coding it as a plugged-in system (as in ECS) to the character selection state.
Menus take ages!

1 Like

Doing some performance optimizations for lewton, an OGG Vorbis decoder written in 100% safe Rust.

Managed to improve performance by about 10%, simply by reducing allocations and using iterators instead of explicit loops.


Spent the weekend experimenting with OpenGL/SDL some more - I managed to get a simple sprite batcher working, based off the code from LibGDX, which was quite exciting!

The main pain point has been having to resist the urge to spend all my time writing a wrapper around OpenGL :stuck_out_tongue: At the minute I have a single OpenGLDevice struct which abstracts over the global state and just passes out handles to the buffers/textures - I’ve toyed with the idea of making it so I can do texture.set_data(...) rather than device.set_texture_data(&texture, ...), but then I have to figure out how to keep it linked to the device. I’d like to actually write a game rather than getting wrapped up in writing Glium Jr., so maybe I’ll stick with the simple solution for now!


Making usability improvements to the C2Rust transpiler such as

  1. better warnings using clang diagnostics for unsupported features
  2. running rustfmt on the transpiled output
  3. emailing folks I met at RustConf’18 to get feedback (which was great by the way!) :heart_eyes:

I am still working on issue 55 to be able to render a scene description from another renderer (in this case Arnold). The simplest scene (a Cornell Box) renders fine, but there’s much more work to do (more materials/settings/primitives etc.) … lets see what can be done in the rest of the week … :sweat_smile:


The goal is to use some of our production scenes with lots of textures, motion blur, depth of field etc. …


I just released a new version 0.6.0 for Zbox. Zbox is a zero-details, privacy-focused embeddable file system. Its goal is to help application store files securely, privately and reliably.

In this new version, volume, storage and transaction module have been re-designed and rewritten to be able to support more types of storage in the future.

I’ve just moved https://github.com/astro/tokio-xmpp from old tokio-core to tokio. I have to fully rewrite Happy Eyeballs algorithm so I’m not sure if I wrote it optimally.

I’m working on my new crate cgroups. It’s pure Rust crate that lets you create and manage control groups on Linux without using FFI.