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

#1

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

#2

Still focused on the DW1000 driver. Made a bunch of improvements to the API (1, 2, 3) and added support for more registers (1, 2). I expect more of the same this week, until Iā€™m capable of wirelessly communicating between two modules.

#3

Trying to get acpi into a useful state by parsing some more AML. This library is meant to fulfil a similar role to Intelā€™s ACPICA and can be dropped into a Rust kernel to provide ACPI support, but it needs far more work to be feature-complete.

An aside: we have a couple of easy issues (1, 2) if people wanted to get their feet wet with some kernel library development!

#4

Iā€™m still working on my weather station. Recently I have been trying to reduce the power consumption in idle. I managed to get it down from 150 mA to 2-3 mA with 150 mA bursts. This week, I might try to reduce it further by putting the CPU in STOP mode.

I would also like to improve the way I handle timer interrupts right now. My current strategy requires a static mut variable and a bit of unsafe.

#5

Working on my rendering engine and adding features. My top priority is to include the weighted screened Poisson reconstruction for my gradient-domain path tracer (G-PT). At the same time, I need to correct my G-PT as the direct light seems incorrect.

If I have a bit more time, I would like to look at how rs_rust load PBRT files to render more complex scenes.

#6

Iā€™ve started introducing another one of my colleagues to Rust (R.E.S.F. take note!), so he can use zlib (via zlib-sys) to write a bioinformatics tool to split fastq files.
This is harder than it sounds, because itā€™s a multiline format, thereā€™s two files you need to split in sync, and you can introduce downstream biases if you do the splitting naively/on the sorted data.

Itā€™s so much fun too show him all the wonderful resources Iā€™ve gotten to know over the years of being active here :slight_smile:
Heā€™s immediately dived into the whole FFI corner of the problem, and as such, his questions are also challenging me in a corner of Rust Iā€™ve avoided so far. :smiley:

#7

New Rustacean here, learning Rust one step at a time!

Iā€™m at chapter 9.3 in the book right now, while also working on ā€œsm ā€“ a static State Machine libraryā€, to apply what Iā€™ve learned from the book.

This week Iā€™m porting the library over to procedural macros, which is a lot of fun to experiment with (especially while using the syn library), it helps me understand Rustā€™s structure better, which in turn helps me better reason about my code.

Iā€™m also experimenting with the structure of my Rust open-source projects, what should be in the code of conduct, how to best use CI together with Rust, how to do testing and benchmarking, what to document where, how to set up Bors, release management, etc. Not always code-related, but equally (if not more) important for any open-source project in my opinion, and also fun to figure out.

All of this is part of a 2-3 year long project Iā€™ve started a month or so ago, towards building an open-source game about space engineering and exploration, written in Rust (working title: Rusty Rockets). Not much to share on that front yet (except for many pages of wiki-like documentation that Iā€™ll also open up a few months from now), but my intention is to use all of the tools/experiments I build while learning Rust towards building the final game(-engine).

#8

Making a map selection UI for my game, which happens to be refactoring code to an emerging pattern that supports:

  • toggling optional view crates (in terms of MVC). View crates can be UI, stdin, or some other connector
  • do that in ECS
#9

I may have a few answers although Iā€™m nowhere near the expert level of many Rust developers (contact: 6ftdan on Twitter). My FFI experience stems mostly from my Rutie project hooking Rust directly into the Rubyā€™s language C bindings. Rutie is a fork of Ruru and Iā€™m not the original author but have contributed much over the past year.

What Iā€™m working on this week is porting over the AEScrypt.com command line tool over to Rust as a library. Seeing as Iā€™ve learned most of C merely by reading Ruby source code Iā€™m having fun writing the Rust code with the same pointer logic that the C code in aescrypt is using such as using pointer addition. Once the program is ported over Iā€™ll be refactoring away from pointer logicā€¦ that is the plan anyways. Of course working with raw pointers this way is new to me so Iā€™m very much enjoying learning from this experience.

#10

I am still working on JNI binding for Zbox (a privacy-focused in-app file system). My goal is to make it to be able to run on Android. Java things are so tedious, luckily with help of jni crate, JNI binding for rust became easy.

#11

Iā€™m interested in contributing with FFI bindings for datrs/hypercore, specially for Java/Android.

This week Iā€™m trying to get started with a JNA (instead of JNI) library for Java and Android using Gradle and multi-projects and it is not being quite simple so far.

Iā€™ll definitely want to check how your integration is doing and learn from :slight_smile:

#12

Still working on my roguelike when I can spare the hours. Itā€™s not yet all that cool to play with.

Right now Iā€™ve implemented menu systems (but I want to make them a little nicer). I have designed the framework and interface for the World component and the WorldChunks that it manages.

Iā€™m looking at examples of how people have used entity-component systems in games. Itā€™s at once familiar and different. Iā€™m exploring what the best way to implement one is in Rust and for my purposes (not necessarily needing to be some super abstract and portable library. maybe I can benefit from trait monomorphization?).

#13

Have you looked at the specs crate? Iā€™m not at a point yet where I can use the crate, but itā€™s definitely on my list of things to check out.

#14

Fixing up a few minor issues that I skipped for my cgroups crate. By the end of the week, Iā€™ll add a builder pattern so that itā€™s even easier (and more ergonomic as a result) to use control groups.

Other than this, Iā€™m working on a network bridging crate. Hopefully, we will be able to use bridges in rust networking code soon.

Thatā€™s all for this week, Iā€™m travelling the whole next week, so most of my week is preparingā€¦

#15

I definitely will, but part of my objective is to get some solid Rust experience. I think this is a fun thing to experiment with.

There also might be facets of my particular game that would lend to a more optimal fit if rolled myself. This is a hobby project, so I can microoptimize any silly thing I want (and ignore things I find tedious).

In the end, using libraries instead of implementing everything is generally a good idea. Iā€™m using pancurses and serde-cbor already (those are the tedious things I donā€™t want to bother with).

Iā€™m looking forward to seeing your work come to fruition as well! Good to see others with similar goals.

And itā€™s also good to see such a wide variety of work going on. This is a diverse set of things people are working on.

#16

I agree, and a big part of the fun of learning Rust while developing a game is the freedom to do whatever you want with your piece of software and the time you invest in it. Like I said in my ā€œwhat have you been working onā€ post, Iā€™ve spend the last two weeks working on, and refining my static state machine library, not because there are none available, but because I want to learn, and try to get as much performance out of it while fully utilising Rustā€™s type system.

So yeah, perhaps when the time comes, and thereā€™s Specs, and youā€™ve written your ECS library, Iā€™ll go forth and write my own as well :grin: itā€™s all in good fun, and writing these small units of code certainly improves and refines your Rust skills, which is exactly what you want, as you build up to the more complex layers of your game.

#17

Still working on Bezier curve algorithms for FlowBetween. Iā€™ve got 60% of a GraphPath type implemented (representing the intersections between two paths), but Iā€™d originally written a curve-curve intersection algorithm based on bounding boxes expecting the problems to be mainly around performance but found that accuracy is a big issue too, so Iā€™m adding the classic Bezier clipping algorithm to flo_curves.

To put things in context, hereā€™s a sketch of FlowBetweenā€™s mascot, made in FlowBetween:

image

This is a good test for me because itā€™s around the level of complexity of things that I want to work well in FlowBetween.

As itā€™s a sketch, itā€™s made up of a lot of Bezier curves and right now renders too slowly. Iā€™d like to be able to render things of this complexity at 60fps ideally but around 12fps is the minimum target. Right now, this gets around 3fps. Partly thatā€™s due to the line offsetting algorithm Iā€™m using, but also even though chromeā€™s canvas is pretty fast itā€™s not really happy with rendering several hundred paths (incidentally the performance is about the same in Safari on an iPad Pro as it is in Chrome on an iMac, which is impressive). The fix Iā€™m working on is to add all of the curves together and generate more complex but fewer paths so the renderer can do everything at once (which also provides a way to bypass the slow offsetting algorithm if the result is cached)

This is also something that would be useful for the final SVG output as even after a sketch like this is cleaned up itā€™s usually necessary to simplify the vectors and this is a way to do that automatically. Even though itā€™s a vector tool, I want it to be usable in as ā€˜painterlyā€™ way as possible.

#18

Watch this Video https://youtu.be/aKLntZcp27M I think this will help you a lot as the Talker is from Chucklefish

#19

Here we go, itā€™s the end of the week (in NZ):

perhaps next time Iā€™ll just post at the end of the week