New week, new Rust! What are you folks up to?
I always mean to do a lot, but end up doing so little...
Inspired by this blog post, I set out to setup Travis continuous integration for my two little Rust synchronization primitives, triple_buffer and spmc_buffer.
It was indeed as easy to enable as promised by the article, and I got to test my code on a new platform (macOS) and new compiler configurations (beta, nightly, older releases) for "free", which is also very nice. Along the way, I also uncovered a macOS-specific livelock in spmc_buffer, which I'll try to investigate further once I'll manage to borrow a Mac to someone. I suspect it might be triggered by differences in scheduling behaviour between Darwin and the Linux kernel, but what I do not understand then is how such differences could stall the process instead of merely slowing it down. So it looks like there is something fishier to investigate down there.
Re-reading the code while trying to investigate this livelock also led me to realize that I might want to write the testing code differently in order to be sure that what I test is truly the atomicity of my synchronization primitive, and not that of 64-bit writes on the x86 architecture.
So yeah, CI makes you run your testing code on more platforms and reflect more about it, which is A Good Thing.
On the negative side, running timing-dependent concurrent testing code on Travis' VMs sure is unpleasant. I don't know if they are oversubscribing physical CPU cores by allocating them to multiple VMs, or if they are doing something very wrong with thread locality (allocating hyperthreads as "cores", allocating cores across NUMA domain boundaries...), but the end result is that if you want an observer thread to closely follow the behavior of a worker thread without any explicit synchronization, in order to spot inconsistent states caused by errors in the synchronization primitive that is being tested, you need to wait some ~16ms between worker actions, where 1ms is more than sufficient on all the physical hosts I've tried before.
2 Likes
Finishing off a PR in elastic_responses to make fields private.
I've also got a PR in inlinable_string to add serde support that I'll try get merged in.
I'll try keep on top of the work following the walkdir libz blitz review. There's a bunch of things raised in the tracking issue if anyone is looking for something to do 
I need to spend some time playing with a crate for asserting Send / Sync and will use that to build a pre-RFC in the coming weeks.
I've also been thinking about a tokio-based API for elastic. I haven't worked out the best way to implement traits like Service for a client that accepts multiple request types and produces multiple response types. I'll spend some more time playing with it.
I just recently discovered this tool called heaptrack which has replaced massif as my go-to allocation tracker. I've been using that to keep an eye on elastic's memory usage. I want to keep it as low as possible.
All in all there's a lot going on
3 Likes
I'm planning to help out the guys at mdbook by refactoring/restructuring a lot of the internals to make it less coupled and easier to extend. So far I've done a little experimenting and feel like I've got a better idea of the task ahead.
I also want to edit a lot of the articles in a FFI guide I've been working on. My goal is to make it something people can point to when someone asks for an in-depth guide to doing FFI in Rust, with a particular emphasis on integrating Rust into existing codebases. If anyone has any ideas for articles or suggestions for improvements, feel free to let me know by opening an issue
3 Likes
I posted on reddit already but maybe some Windows users will see it here instead.
Going to release 0.0.7 of Gutenberg (https://github.com/Keats/gutenberg), a powerful static site engine inspired by Hugo but simpler, with which you can build pretty much anything: a landing page + blog + knowledge base should be pretty easy to do for example. You could probably do a site exactly like the ones from gitbook/mdbook as well without any issue.
Next, I'll try to have Sass built-in. Linux/OSX shouldn't be an issue for that but I didn't manage to have Sass building correctly on appveyor and I don't have a Windows machine available. See https://github.com/Keats/gutenberg/issues/73 for more details
And as always, I'm welcoming feedback on i18n: https://github.com/Keats/gutenberg/issues/13
2 Likes
I finished implementing all of the floating point operators for uom (type-safe zero-cost dimensional analysis) and next up I'll probably add a number of common quantities. Also considering using traits from the num crate.
I started using the pest parser generator to parse .pbrt files. Currently it can parse a simple example file, but there are problems with trailing whitespaces at the end of the file, which I will ignore for now, because I want to start on actually using the provided (or to be modified) library API from my crate rs_pbrt to create scenes. So far I had hardcoded some simple scenes into example Rust code, but even a simple (triangulated)
teapot scene takes far too long to compile (5 to 10 minutes). I probably need to investigate a bit if I have to use a crate like copy_arena for memory allocation, but right now the focus is to do something with the created tokens and work on the API, so the scenes can be created on the fly by reading a scene description ...
https://github.com/wahn/rs_pbrt
Current docs: https://www.janwalter.org/doc/rust/pbrt/index.html
1 Like
I'm working towards implementing an encrypted file brute force tool. It started with this issue: “How to brute-force a somewhat remembered aescrypt password?” .
Because of this I've implemented my base_custom tool this week as a Rust crate which I had previously written in Ruby and Crystal. It's a number base conversion system allowing you to define your own arbitrary numeric bases beyond binary, base 10, and base 64.
The next thing I'm starting on this week is implementing a “Card Flipper” (think brute force sequencing) which will take custom rule filters for the sequence to continue in such as crunch (wordlist generator) does with the -d flag to permit only X number of the same digits neighboring each other. I plan to use ArrayFire and Rayon to use my systems GPU and multi-threading capabilities. Ideally I'll be able to get to making a Rust wrapper for AESCrypt as well to inline directly, but that may be a bit beyond me at the moment.
I've been continuing to work on learn-opengl-rs, porting the awesome OpenGL tutorials from learnopengl.com to Rust.
3 Likes
Hi! I'm new to Rust and this forum. Enjoying the language and ecosystem so far. 
Started working on a small OSS project this WE: valeriansaliou/bloom
Called Bloom - "HTTP REST API caching middleware, to be used between load balancers and REST API workers."