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


#1

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


#2

Finished updating docs and pushed out a new release of elastic. There’s always more docs to write so will keep working on them.

I had a play with the unstable rc_raw feature in my dependency injection experiment. I think it’s the least unsound it’s ever been!

Right now I’m working on redoing elastic's date parser in nom, and planning the next Rust Brisbane Meetup.


#3

Learning by porting Apple’s shell_cmds to Rust

Just about to post a request for help on how to test binaries intended to parse arguments and produce output to stdout. Not a great candidate for even integration tests, since handling arguments happens in the binary file, not the library file.


#4

Instrumenting rust code with systemtap/dtrace probes (https://github.com/Fiedzia/rust-usdt).


#5

Merged contributions to add weapon firing into rust-belt, a 2D game to learn Rust while developing.


#6

Re-linking for this week because it seems to have been missed in last week’s update (I may have gotten to it too late!): New Rustacean Crates You Should Know: clap.


#7

To learn Rust, I’m slowly working on swf-rs, a crate for reading and writing Adobe Flash SWF files. I’m coding it in a naive way until I get all of the SWF spec implemented, then I’m going to experiment with using nom.


#8

Working on the FFI for STRATIS to Unity3d, and am finding a whole slew of headaches in the C# ffi world. I finally figured out that passing a struct by reference to be filled (C# -> Rust -> C#) is the most sure way, Like this.
Returning structs with arrays from Rust -> C# is no easy feat (and I never figured it out,) despite the many C-based examples I found on MSDN.

I made a unit test project in visual studio to test the FFI and be sure of things, as it makes for rapid development versus executing the scripts directly in Unity to test. Building an ffi is much harder than I had originally figured, but am getting the hang of it so building this out further should be easier now.

My current dilemma is proving the IntPtr (the c# pointer for ffi) that I create is actually freed, and I’d like to prove that in the unit test. I believe it is, but to test it seems impossible, perhaps it has to do with the way Rust handles freeing memory.
See here for the drop in rust: https://github.com/viperscape/stratis/blob/19e11895373b4f935c7d674b714180f60138c487/unity/src/lib.rs#L46
The assert tests in c#: https://github.com/viperscape/stratis/blob/19e11895373b4f935c7d674b714180f60138c487/unity_ffi/UnitTest1.cs#L19

Interestingly, it returns that the pointer is not null, and c# agrees. Not sure how I feel about that, because the FFI examples for rust objects suggest this style of drop, and I have reworked it a few different ways hoping I could get a positive result.

The good part is unity is talking to my network server using the FFI, so there is shared rust code that ‘just works’ which is great, and I really like writing in rust so I’m glad this is now working!