What's everyone working on this week (8/2016)?

Another week of joyful rusting! What are you folks up to?

I just released my first crate: intrusive-collections

It allows you to create intrusive linked lists and red-black trees, and have objects inserted into more than one collection at once.

1 Like

Various things for me as usually. Released GitHub - emoon/dynamic_reload: Dynamic reloading of shared libraries last week, Implemented more opcodes for GitHub - emoon/r68k: A m68k emulator in rust - let r68k = musashi.clone();. This week will be usual work on ProDBG, r68k and I will also add menu support to https://github.com/emoon/rust_minifb and add some more examples to it.

systemstat, a crate for getting system information like CPU load, load average, memory usage, filesystems… Only supports FreeBSD for now, will add OS X, OpenBSD and Linux eventually. Help with platform support is welcome :slightly_smiling: (Also: found an arithmetic underflow in bytesize while working on that.)

unixbar, a crate for making lemonbar/dzen2 status bars with systemstat and cargo-script. Better than shell scripts! :wink:

rusty-sandbox, a crate for, well, sandboxing. Unlike gaol, it's focused on simple self-sandboxing APIs, it doesn't create "heavy" / easily visible stuff like chroots and bind-mounts.
I've started with Capsicum, which is probably the strictest sandboxing model there is (you can't even whitelist directories – you have to open them as file descriptors and then openat from them).
Currently supports FreeBSD's Capsicum and OS X's Seatbelt. OpenBSD's pledge is coming. I guess Linux's seccomp-bpf too, but that won't support directories.

Playing around with getting a simple rotor-http server running in a docker container for running on a mesos cluster with marathon. I'm keen to see how it goes running a bunch of Rust services on the smallest, cheapest cloud servers I can find :slightly_smiling:

Just started zstd-rs, a rust binding to the very cool zstd compression library.

I just started learning this weekend and ported my voxel octree with ray-casting: [url]https://gist.github.com/anonymous/224fcfb0e171941715a6[/url]

This is also my first nontrivial project in Rust or indeed and non-GC'd language so any pointers or references are appreciated.

Talk, talk, talk. We're trying to knit the Rust Berlin community better and finally have some people at Mozilla to interact with face to face. Really happy to see where this is going.

Also: finally porting heka-rs to Rust stable (and the current luasandbox)

Still learning From the Book.
Finished the Syntax and Semantics chapter and starting Effective Rust, and I'm planning to try help in Cobalt.rs this week (=

There is a trick to make a struct unmovable in Rust: https://www.rust-lang.org/faq.html#how-can-i-define-a-struct-that-contains-a-reference-to-one-of-its-own-fields. Can it be used to increase the safety of intrusive collections?

That trick only works if the struct is bound to a stack variable. I did consider using this approach but it makes things much more complicated (or even impossible) for the common case where you are allocating objects on the heap and inserting those into multiple lists.

Yes, I see. Hm, and is it possible to create a Box like pointer, which cannot be moved from?

You need to prevent it from move and dropping, but only if the object is linked to a collection. Dropping and moving an object is perfectly fine as long as all its Links are unlinked.

The check for drop can be implemented at runtime (panic! if the object being droped is linked to a collection, or remove it from the collection), right? It shouldn't incur much overhead? Likewise, if there is a MyBox which can not be moved out by *, it can still have a take method with similar checks.

Sorry if I am suggesting something stupid, I have very little experience with intrusive data structures :slight_smile:

GitHub - Manishearth/humpty_dumpty: Implicit Drop/move protection for Rust (linear types) could be of interest to you.

Hmm I think I might do something like that, thanks for the ideas. The take method will still need to be unsafe though since an object can't be aware of all the links it has. The Adaptor trait is very flexible and even allows you to put the links outside the objects (see this).

Nice. I always thought that intrusive data structures are impossible to express in Rust without introducing segfaults to safe operations. But know I think that it may be possible to clearly express the unsafety boundary.

New Rustacean Interview 1::Part 2—the second half of my discussion with Sean Griffin! This weekend, I should be recording a long-overdue episode on type systems.

I'm making my very first Rust program! Particularly, trying to solve this.

I just love references... >__<

1 Like