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

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

2 Likes

I've been working on support for CUDA Arrays in RustaCUDA:
https://github.com/bheisler/RustaCUDA/pull/22

This will eventually include binding to CUDA Texture and Surface References and Objects.

Noob here. I'm making broot on evenings: GitHub - Canop/broot: A new way to see and navigate directory trees : https://dystroy.org/broot

The main initial goal was to learn Rust (trying to decide whether I switch my team to it or not) but it turns out to be a pretty usable tool in my opinion.

Feedback very welcome, including regarding code that would not be idiomatic or as efficient as possible :wink:

2 Likes

Last week I finished up FAT volume support in my cargo submmand for building Nintendo 64 ROMs. It’s available (along with a simple crt0 replacement) in the links below.

This week I am working on a few small examples that will eventually be used as the introduction for a book on writing Nintendo 64 games with Rust. First a minimal example that configures the video hardware interface and draws some static colored rectangles. Then a basic hello world (more work because it requires building a font and simple layout code). And finally, loading textures and sounds from the embedded file system!

3 Likes

So, this week I hope to finally get to the paint bucket tool for FlowBetween, finally. The idea is to use the ray-casting algorithms in flo_curves to trace the outline of the area the user clicks in as a series of points and then use the LMS fitting algorithm to generate the paths. It's probably going to need some sort of spacial data structure to run fast enough.

I did get the file management up and running over the last... few weeks. It turned into a bit more of a mission than anticipated as an updating bug turned out to be the thread that when pulled caused the whole jersey to unravel as it were. FlowBetween was originally built around a state machine that was replaced by a stream of updates: when I did this I left the state machine in place and just streamed out its changes, and this it turns out had a race condition that was harder to fix than just writing things the way I should have done in the first place. So, I've spent a bunch of time replacing the old state machine with three 'core' stream implementation (UI differences, canvas commands and viewmodel differences). That has proved far more reliable, although the file view is now broken in a new way: hopefully something a bit easier to debug than before.

One of the neat things about piping all the UI updates through a stream is being able to watch everything the UI is doing in one place, which lead to me discovering that FlowBetween was often sending more than one UI update per frame due to receiving more than one input event in the same time period. Fixing that was just a matter of waiting until the next frame before sending the events over: this seems to have made a pretty huge difference in how responsive the canvas is.

The last week I finished my fist API with rust, and this week I want to learn about rust-zmq (zeromq)

I've already written a Gotham fullstack website that uses Webpack for front end asset prep and the demo source code can be seen here: Gotham-Fullstack-Example. Now I'm trying out Diesel on the backend for a postgres database and a VueJS front end text entry system. The site I'm working on is a guitar tab site which will be designed to support the onsong file format.

A connection pool for MSSQL, using r2d2 and tiberius: https://github.com/brokenthorn/r2d2-tiberius