What's everyone working on this week? (Week 36, 2015)


Hi everyone,

we started an informal collection of “what is everyone working on this week” last week. This post will come up regularly, every Monday.

The idea is to have an informal soapbox to talk about anything you do, big and small (from “writing a new operating system” to "I’m just starting). This allows others to see what is happening, ask questions and maybe find contact points and opportunities for collaboration.

Feel free to just write a short sentence, but novels are also appreciated.

So: What are you doing this week?

Florian (Rust community team)

pinned globally #2


Porting poly2tri to Rust.


I just started a project to provide basic Rust support for the Qt Creator IDE. It is my IDE of choice to work with C++, and I use it to work with Rust code, too (it has syntax highlight thanks to the people who wrote the Kate syntax description file).

I don’t have much time to work on side projects, but the short term plan is to:

  1. Allow the user to open a Cargo.toml file as a Qt Creator project file.
  2. Setup the compile/run targets to use the corresponding Cargo commands
  3. Interpret the output of rustc to extract errors/warnings and link them to the editor
  4. Provide a project creation wizard, which will be a simple wrapper around Cargo new
  5. Tweak various default configurations so that it is easy to work with Rust code out of the box

In the future, I’d like to integrate Racer for the auto-completion/navigation, but I haven’t looked at its capabilities yet.

Qt Creator for Rust development

I’m working on extending my arrayref crate, which enables zero-cost abstractions involving array references where otherwise one might be tempted to use slices, which would require more run-time checks. Most recently, I’ve written a macro to split a single larger array reference into N (where N is arbitrary, but each must be individually enumerated) smaller array references that do not overlap, but do cover the entire original array.

My plan is that this will make it easier and simpler to ensure with the compiler’s help that byte layouts are correct and consistent, with less human counting and addition required. This comes out of my work on a cryptographic library and protocol (which is incomplete), where I’ve found it way more convenient to deal with array references than slices, because then I can see in the type signature what is expected, and discover at compile time when I’ve messed up an argument by giving it the wrong size data.


I’m sincerely hoping this is all for a rewrite of my favourite version control system in Rust. :wink:


Currently working on an Iron webserver to run on a Raspberry Pi and provide a frontend for various command-line tools.


Windows things.


So, here’s my list:

  • Finally work out a convenient and good Key abstraction for databases (currently residing in https://github.com/skade/db-key)
  • Prepare for OpenSourceBash (http://www.opensourcebash.org/) (an event that wants to get new people into Open Source, I’ll be presenting Rust)
  • More switchboard work for the Rust community. Currently, I’m searching for people that picked up working on the compiler, but stopped.



I’m working on a sparse matrix library, with support for CSR/CSC matrices, algebraic operations and eventually some linear algebra algorithms (Cholesky factorisation, LU,…).


I’m doing a few things:

  • After I do some paperwork, I have a cool announcement. Can’t say till it’s signed…
  • I want to do some investigations into the Rust ecosystem and the long tail of docs. Someone told me last week that there’s a bit of a lop-sidedness.to it, and that the official docs are so good that it set them up for disappointment in the broader Rust ecosystem. I want to try to figure out a way to evaluate this claim…


My Rust learning project is a GUI to keep track of what happens in a high-school classroom: who is present or absent, what was the homework and who did it, etc. For obvious reasons, it has to be already usable in 65 hours.


This week, I’m writing issue 94 of This Week in Rust. Also planning to fix some layout issues in Gmail Android app for upcoming newsletter.


I’m working on parview, a particle viewer written in Rust. I really need something like this for the simulations I do, and its already started making the stuff I do easier!

It’s still not quite finished, and the docs are not very good. But it does work, and you can even make movies from it!


Last week I got a sort-of working prototype of cargo-open going, but in order to make it work in all cases, I needed more information out of cargo. A few yaks later, I made a PR to cargo that just got in, and I think this week I can start popping the yak stack and hopefully get back to cargo-open :smile:


I’m adding debug drawing to my game to help visualize otherwise invisible things in the scene. I’m starting to work on collision detection and I needed a way visualize collision volumes.

  • Finishing up a packfile library for the Super Secret Game Project (which will be released separately. but it’s pretty crappy.)
  • Prototyping the mobile renderer for the Super Secret Game Project.
  • Doing lots of homework (ugh).
  • If I have time, working on Visual Rust some more.


Working on xml5_draft. It shows no changes, but I’m slowly chipping away at DOCTYPE states.


I’m implementing “named wildcards” (in need of a more appropriate name) for TreeRouter in Rustful. They are like path variables (/products/:id, where :id will capture the last section of the requested path in a variable), but they will instead capture a subsequence of a path. You can have a route like this: /head/*tail and request the path /head/a/b/c/d, and the router will capture a/b/c/d in a variable called tail.


Trying to call some compiled Rust code from Arduino C++ because I’m tired of C’s arrays. Not working so far.