On Mon, 2016-04-25 at 00:06 +0200, Kelong Cong wrote: > - Is it confirmed that we'll use gj going forward?
Appears not. :) I just had a very useful conversation with Florian who knows way more about this than I. As a first task, we should worry about doing the GNUnet style wire formats nicely, including endiannes. It appears gnunet-rs does not do this so well right now, so maybe much needs to change. I think our first task here is to figure out Rust's version of __attribute__((packed)) for structs in GCC 4s, known as #pragma pack(push,1) and #pragma pack(pop) elsewhere. I think repr(C) and repr(packed) together work : https://doc.rust-lang.org/nomicon/other-reprs.html Just fyi, the introduction to the Rustonomicon is cute : https://doc.rust-lang.org/nomicon/README.html There are more details here : https://github.com/rust-lang/rfcs/blob/master/text/1399-repr-pack.md It's worth noting that "Taking a reference into a struct marked repr(packed) [is] unsafe" and cannot store Drop types : https://github.com/rust-lang/rfcs/blob/master/text/1240-repr-packed-unsafe-ref.md As an aside, it's nice to clone a copy of https://github.com/rust-lang/rfcs to grep for shit like this. Also, the C type unions that just landed in Rust nightly* might help : https://github.com/rust-lang/rfcs/blob/master/text/1444-union.md ref. https://github.com/rust-lang/rust/issues/32836 https://github.com/rust-lang/rfcs/pull/1444 I'm not 100% sure how we expose these structs to Rust, maybe they should be copied into normal Rust structs without unsafe fields, but that keep around the original and "move" any large aligned fields, and replacing any unions with Rust style tagged unions similarly. Anyways, it's definitely our first priority to get this wire format stuff cleaned up nicely, maybe even "lightly script" the conversion. After that, we should try to emulate the GNUnet utils APIs relatively closely. I based my preference for promises/futures on my small amount of playing around inside GNUnet utils where all callbacks are single use, but Florian says the higher level stuff uses other patterns. We should still consider following this two-crate API and implementation model used by eventual and gj however, possibly even forking one of those to add what we need, but our prority should besticking close to the GNUnet utils API. As an aside, the only really intentionally multi-pattern thing I know is ZeroMQ, and I've heard their docs are ell written, so I'll try to skim that soonish : http://zguide.zeromq.org/page:all http://curvezmq.org/page:read-the-docs Also, Florian stressed that systems built on promises/futures do not necessarily support cancellation well. We've a long sorted history with cancellation apparently, so it's good to get that sorted out form the beginning. Finally, Florian singled out the statistics service as being rather simple but using many different asynchronous IO patterns, so doing bindings for that gives us a concrete goal that'll help us sort out the wider API correctly. Sound good? Jeff * I'm against trying to stick to stable Rust because too much important stuff depends on nightly, including mio.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
