Today, @fredowald and me released the v0.2.0 of cursive-async-view. 🦀 🎉
Views which are not `Send` can now be async loaded with the new API. Also, we added the possibility to display an error message, when the child view fails to load.
As the new version introduces breaking API changes, we added a small migration guide to the changelog (located in the repo).
@fredowald and me finished adding error handling to the cursive-async-view #rust crate. We added a small animation to display an error message. The program shown is the `timeout` example from the git repository:
I am currently looking into removing the `Send` trait restriction for async loaded views in `cursive-async-view`.
I faced some problems regarding the callback sink of #cursive. I will look into a "good" solution tomorrow. But maybe someone here has a good idea to solve this...
I filed an issue describing my problem:
In the last few days @fredowald and me were going crazy on #travisci for #rustlang. We created a CI configuration which produces badges from #shields.io for cargo nightly and stable builds, cargo test results, and our cargo integrated end-to-end tests running in #tmux
We did our CI experiments on the cursive-multiplex repository. 🦀
(Yes, tests are currently failing, the project is under active development 😉 )
After finishing my raft-node prototype I will move on scratching up a distributed #WAMP router based on that raft-node.
The router will support only publish/subscribe for now. The complete core profile will be eventually implemented when vertical prototyping is finished.
Also, the projects involved into this prototyping lack all kinds of documentation. Documenting and cleaning up the code base of all these projects will be number one priority after prototyping the WAMP-router.
I continued development of my raft-node implementation in #rust and finally finished introducing TCP transports!
However, the implementation still contains some hacks and is definitely unstable.
A working TCP transport can be found under examples/tcp.rs on github:
The overall performance is now a lot better. However, writes are still quite slow, although I managed to track the problem down to the raft-rs implementation.
Additionally, the raft cluster is crashing and getting very slow when doing many state-change proposals at once.
I think it is now time to look again into properly implementing the ready state processing. Currently it is quite hacky and likely the source of all my raft related problems :D
I added async support for the machine implementation. I am using the new async/await syntax from nightly and it looks very good so far. The rustasync/runtime executor works like a charm!
I have also added #serde support for the machine trait to support building a machine from a storage snapshot and entries. However, I am not quite happy with the type constraints on my machine. It feels like a hack and will probably cause problems in the future!
However, the implementation is currently very slow. All operations on the machine are blocking for now and lead to the whole cluster processing only one state change per tick (100ms).
This can be changed by introducing an asynchronous API, which will be implemented later.
Today I worked on a new Machine trait for my raft Node. The new trait introduces the possibility to store and read state from the machine.
This was previously only possible through the node itself and very unhandy. The machine can now be accessed on the same thread where the node was created.
I was able to do this without using any locks (Mutex, etc.). All inter-thread communication is done with channels so far.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!