New week, new Rust! What are you folks up to?
Exploring some fun aspects of drawing function plots with non-negligible line width. For example:
- The human eye perceives line width with respect to the normal to a line, not with respect to the y axis of the plot. This has many consequences.
- Correct line joints are a Hard Problem, problem-specific “good enough” approximations are hard too.
- There is a good reason why GPU have some built-in antialiasing capabilities. Implementing a more accurate antialiasing algorithm in a fragment shader is hard.
I just created a branch for issue #39 because I expect to work on it for a longer time frame. Basically I want to upgrade the pest crate to version 1.0 (or later). So far I was still using
"^1.0.0-beta". I also decided that it’s time to rename the main executable to rs_pbrt (instead of
pest_test), independent of the underlying parser technology being used. Coincidentally, since Rust 1.27 was released my code compiles with all three Rust version now (stable, beta, nightly). I haven’t done performance tests yet, but for now I will stay with stable, until I detect some serious performance problems … Once issue #39 is resolved I will merge the branch back into the
master branch and update the Wiki and README.md file.
Finally could contribute to a project in Rust and I now have couple of PRs waiting to be merged!
Work on my GSM-connected temperature sensor is ongoing. I confirmed that part of the reason it’s broken are timing issues when talking to the GSM modem. There are various options to fix this, but I decided to take the long way and use DMA for all UART communication (modem and debug output). I’ve had a first success (debug output now uses DMA), but more work is required to use the new DMA code for the modem, too.
Working through bugs and items to fix for the OPC UA for Rust 0.4 release. Probably a week or two more before I release it.
I’m continuing work toward my eventual goal of having a VCR-style HTTP interception/recording/replay library in Rust.
I haven’t posted in one of these threads before, so here’s a summary of my progress up to now.
- Created the memsocket crate. This is an in-memory implementation of an asynchronous socket interface. I needed this so I could connect a hyper client to a hyper server without needing to bind a port or spawn a new process. I tweeted about it and it got a decent few GitHub stars!
- Created the hyper-stub crate. This provides functions that will generate hyper clients that convert requests to responses through an arbitrary struct/function you supply rather than touching the network. This is implemented on top of memsocket and lets you stub out HTTP interactions to test behavior of code that makes HTTP requests.
The next step is, hopefully, to write the record/playback library. I’ve started this, but have only managed to get a couple of hours of work into this layer of the project, because before I could start I had to write hyper-stub, and before I could start that I had to write memsocket. I ended up programming at a much lower level than I had expected to have to deal with for this project, but I think that rabbit hole is pretty much done with now and I should be able to focus on the high-levzel API for the record/playback library.
I’m really excited to finish the project because I’ve found being able to test HTTP interactions really useful in other languages and was surprised that Rust doesn’t have this already. I bet there’s a ton of Rust code out there that isn’t tested because it’s not feasible currently without hitting the network.
These are the first Rust crates I’ve ever published, so if anybody has any feedback on my code / approach / anything I’d really love to hear it! I’m qyliss on IRC or you can mail firstname.lastname@example.org or open a GitHub issue.
I’ve been blown away by how welcoming the Rust community has been to me, btw, so great job everyone. <3