New week, new Rust! What are you folks up to?
Starting to learn rustfmt and clippy (and loving both 
).
Found it was really easy to run them with rustup while still leaving stable Rust as my current default toolchain using rustup run nightly cargo ...
Using stable Rust
$ rustup show
Default host: x86_64-apple-darwin
installed toolchains
--------------------
stable-x86_64-apple-darwin (default)
...
Install nightly Rust
rustup toolchain install nightly
Install clippy
rustup run nightly cargo install clippy
Run clippy
rustup run nightly cargo clippy
Install rustfmt
rustup run nightly cargo install rustfmt
Run rustfmt
rustup run nightly cargo fmt -- --write-mode diff
1 Like
rustup also supports this via
cargo +nightly fmt -- --write-mode diff
it detects the +nightly arg then uses that toolchain and strips the arg before forwarding to the actual cargo.
Cool, thanks @Nemo157!
I am looking into what it would take to build a SOAP (XML web service) client library. At the moment, this primarily involves playing around with quick-xml, trying to make it 'composable'
The SOAP envelope parser/writer needs to interact with parser/writers for various body and header formats, possibly written by different authors (libraries).
1 Like
I am on building a little collection of types I am using often,
like 3D Meshes, Color (RGB(A), etc.) and a HTTP Request Parser.
I've been squirrelling away on elastic to get a decent API before giving a talk next month about Rust and Elasticsearch that'll cover it and rs-es.
I've also had @eddyb come along and thoroughly burst my bubble with non-static type_ids. There is a different and sound motivation though, so this week I'll update it around that and add notes that it needs documentation akin to mem::transmutes Here be daemons.
I'm slowly working on a collection of simple image reconstruction tools in Rust for the imaging modality I work on. My current workflow primarily uses Python and the NumPy ecosystem with some numba JIT for some computationally intensive tasks on the image reconstruction side. There's also a hard real-time side leveraging the usual suspect C that could also be a prime target for Rust some day. The tools I'm building leverage C FFI to call Rust from Python and are geared especially to assess/demonstrate why Rust could be a good choice for us.
I'm very much in the process of learning Rust, but super excited with it so far. I'll be looking into various numeric/signal processing/computational crates such as nalgebra, ndarray, and basic_dsp as well as parallelization platforms such as crossbeam (I'm having fun with this one currently) and rayon. I'm quite interested in developments in the numeric and computational space.
Short term I'm trying to become more and more competent with Rust. Long term, I'd like to convince my company to start integrating some Rust. I'd also like to contribute in this space in the future when a proper coalescing of time + skill level emerges (does that ever happen how you want? 
).
3 Likes
@dwhensley, I have similar interests for image reconstruction for 3d models, have you found any libraries for this? I also hope to write python modules with Rust. Good Luck!
Lee
I'm continuing to probe the depths of S-expressions, their encodings, unusual application-specific features and so on.
After testing some absolutely enormous sexps from an RFC2693 compatible service, I was forced to switch from from a classic "cons: car and cdr" representation to a Vec<Sexp> for lists with fallback for pairs (which are Option<Rc<Sexp>>)
This leaves me with a bad taste in my mouth: there is no clear way for an element of a S-expression list to refer back to a pair (and vice versa). Luckily, this is mostly only important to actual Lisps, and not for people using S-expression as a data-interchange and configuration storage format.
Lots of my testing macros also broke and I'm starting over from scratch in a lot of regards, but I didn't see a clear way forward to making the 'classic' representation suitable for 15Mb lists.
Currently actively working on a numtoa crate competing against the existing itoa crate. Performance with base 10 conversions is very slightly faster than itoa. It doesn't require the standard library, so it works with #![no_std] projects.
2 Likes
I'm still working on cpp_to_rust and a Qt wrapper. I'm currently removing clang dependency in the generated crate and trying to get some level of cross-platform support.
1 Like
Finally got round to updating cargo-lichking to use cargo 0.15 so it'll actually build and improved the code a bit. Gonna try and implement cargo-lichking#3 at some point to allow it to automatically generate third party license bundles and actually be a bit more useful.
Trying to learn more parser construction in nom by implementing sass. https://github.com/kaj/rsass . Fun thing with sass is a huge existing test suite to pick tests from. Also, I kind of almost need a sass implementation and the libsass wrapper lib seems a bit abandoned.
1 Like
@leegramling -- I have not yet explored the space in detail. However, I did notice the nalgebra crate specifically states that it is for general purpose linear algebra and "computer physics" with an online documentation shared with ncollide and nphysics crates. I also saw the rust-3d crate mentioned recently on the Rust subreddit.
For my part, I'm more in need of DSP and a powerful ndarray type on top of which to build somewhat niche reconstruction algorithms.
2 Likes
Working on SSL encrypted transport for CDRS, Cassandra driver. There were few options in front of me which lib to use. openssl was leveraged.
This week I almost finished my newbie take on writing a tutorial on how to create a basic conrod app, here.
1 Like