What's everyone working on this week (21/2019)?

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

So, I have a bunch of type T, U, V implementing various traits. Let's say that T: A and U: B + C.

I want to automatically generate a struct with fields of type T, U, V (let's say struct Composite(T, U, V) for example) which implements traits A, B and C by delegating the implementation of A to the inner object of type T, and the implementations of B and C to the inner object of type U, with minimal boilerplate.

This "delegation of implementation" problem is a classic in Rust. There have been various proposals to standardize a language construct for this, but with no success so far. Personally speaking, I don't mind implementing it in a library with a macro, but I'm a bit surprised that no one else seems to have done so already (searches for "composition", "delegation" and derivatives on crates.io turn up nothing), given how frequently the need for such a tool comes up.

Am I really the first to actually try to tackle this at the library level?

Just released sauron 0.7.0 today, with bunch of improvements of the api, most notably added Http for simple fetching of data in a rest api and injecting the data into the view seamlessly.

Hit a milestone in diwata rewriting the elm-client to sauron, with minimal changes to the existing html structure.

I've started working on a "Kafka/kinesis" similar written completely in Rust. The ideia is to have a disk-backed append-only commit log, as the essential unit for storage, and then move to implement "streams" and "shards" to improve performance and finally work my way towards good replication performance.

I would deeply appreciate reviews/feedback since I'm quite new to rust: https://github.com/14-bits/voik (I've only started the storage topics, having write/read from disk/mmap code).

I just added FBmTexture to rs-pbrt:

See issue #90 for details ...

3 Likes

:gear: Gearing up for a release / publish of my game:

1 Like

The problem with delegating traits via a macro is that macro now needs knowledge of every trait it may be asked to delegate (as there is no way for it to ask the compiler about the methods of the traits).

It does still seem worth it to me to have a macro that knows the standard library traits and can delegate just those (and could be extended with other very common libraries via feature flags).

Yup, I figured out as much while trying to design and implement this... And then I also figured out a rather general workaround, which only requires the definition of traits destined for derivation to be annotated.

But the implementation of that workaround is ridiculously complex so I will just wait for delegation or compile-time introspection to land into the language and use special-purpose constructs meanwhile :stuck_out_tongue:

This week, I have been finalizing my implementation of the Saber cryptographic key encapsulation mechanism: https://github.com/dsprenkels/saber-rust#saber-rust.

Intro

Quantum computers are coming. Although we don't know when they will come. Though when they do, they will break all of our public-key based crypto.

That is why a large part of the cryptographic community is devoted to inventing proper "Post-quantum cryptography". Post-quantum crypto is cryptography that is resistant to attacks from a quantum computer. Saber is one of the round-2 candidates of the NIST Post-Quantum Cryptography "competition", a competition with the goal to find the schemes that we should use for the next decades wherein quantum computers become viable.

Rust part

I have mainly been struggling with the lack of support for generic array lengths. If issue 44580 had already been implemented, I would have needed only one third of the lines of code that I needed now.

Also, it turns out rustc (really LLVM) can be very good at introducing side-channels in your code.

In any case. Rust is awesome. Everything is just safe. No out-of-bounds; no duplicate code for types that are almost (but not really) the same; proper built-in-testing, etc. :slight_smile:

1 Like

Today I fixed an issue about Shape "plymesh". Indices can be ply::Property::ListInt as well as ply::Property::ListUInt. While investigating what goes wrong with a test scene I found (and fixed) another bug regarding quads (and turning them into triangles). Nevertheless there is something else going wrong with that test scene, and I hope to fix this tomorrow.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.