Only when I die 
…
7 Likes
1 Like
As long as it’s not “lawyers guns and money”, cause the SH*$ has hit the fan 
one of my favourites
3 Likes
This excitable boy has just failed to work up a joke about headless Thompson gunners
1 Like
I think you may need to wait till tomorrow for the master branch of vault as it’s all renamed and we need to push a routing crate as well. If you want working versions of any of this though all the stable branches are there (0.2 was latest stable API branch in vaults if you want that, but sprint is closing and there are API changes). If you are desperate though you can get the stable versions.
Qi will be starting in an hour or so and will be in vaults tying in the new routing API. Perhaps it will be OK in a few hours.
2 Likes
No worries - I just keep testing every day - happy to keep on the bleeding edge if it helps the cause . .
3 Likes
All helpful, sprint end is a stressful time though, it’s manic 
2 Likes
so great! nice job! let’s change the world.
1 Like
We will for sure try This delivery is a hard one, baby steps for sure, but will allow us to then stabilise the delivery quickly (1-3 weeks to stabilise and iron out bugs etc.) , then move on. It will help everyone and certainly speed up the network being stable and we can all focus on features
5 Likes
Great work! Is there a way to measure the amount of nodes which are participating? And is there a limit to the amount of testers it can handle? Hence, can we scream it from the rooftops?
5 Likes
I would wait for a few weeks and let us see how it reacts. We still have not integrated utp and hole punching properly so we will do that and get the app launcher up to speed via installers (again). the next sprint will be a stabilisation one to get all the bugs ironed out, then we can start showing people how real this is and also importantly how well it will grow. Scott is taking on the horrendous task of graphically documenting “the language of the network”, we caught him earlier heading for the sea, Reggie Perrin like, but he will get there
So stability, clarity and very clean documentation will let us show everyone the clear road ahead. It’s way less scary now by a long way. Been a very interesting last few months. So expect these installers to be still dev like, not for end users just yet. When we stabilise them, we can let end users get at them and start the network running. It’s the interesting time now.
21 Likes
So for any project directory (unless you change it) Cargo will always get the (latest) published version on crates.io. So for routing it will use the latest Crust version published on crates;
Safe_vault and safe_client depend on routing, so it will use the latest published version of routing from crates.io. Here is the bottleneck; routing has been rewritten (published version 0.3.1 today!!! ), so up to a few days ago routing would be on the version 0.2.8 (which was almost two, three(?) weeks old) and that old version of routing depended on an even older version of Crust, which because of rust nightlies was broken after if got published.
So there is certainly something we have to improve on the stacking of published dependencies; priority number one is getting CRUST of the rust nightlies to beta and stable!
5 Likes
If all works out with SAFE and the singularity, perhaps you won’t get that chance 
6 Likes
OK, I thought that was the case.
Why is it set up like that? Why not just use the current versions of crust and routing that have just been built? Can I do that? - or will that just cause the builds of the other things to break in a different way?
Of course.
OK, so it seems for me to continue testing the bleeding edge, the daily procedure should be:
As root:
curl -sSf https://static.rust-lang.org/rustup.sh | sh -s – --channel=nightly
For dirs in the order:
crust routing . . others
Do as phil:
cargo clean ; cargo update ; cargo build
?
Thanks,
Phil.
2 Likes
the projects are versioned (in the conventional way) with a major.minor.patch number; so we try to observe now that the public API of a library only changes on the increment of a minor version number; so e.g. for routing v0.3.1 and up coming v0.3.2 will have the same public API; so users of a library can set their dependency for their version to “routing = 0.3.*”; so when routing publishes a new patch the user libraries will automatically use this new patch; however if the API changes of a library you depend on, then that would cause a compilation error for the user, so a user needs to minimally increment the patch number of their project that includes an increment in the minor number of the dependency.
This is quite a sensible way of standardising and automating dependencies and it is implied/forced by cargo; the biggest problem we currently face is that our lowest library needs to be built by the nightly version of rust, which itself still strongly changes.
OK, I think it all makes sense now - so at some point the crust development settles down and stabilises (or at least doesn’t change so dramatically) and then that stability will flow on to everything else?
P.
1 Like
sort of. Crust in itself depends on features of the standard library in rust are marked as “unstable” i.e. they still change themselves very strongly, or might be deprecated soon. Building your project with rust beta or rust stable does not allow you to use such features that are marked unstable. Building with rust beta / stable only allows one to use the more limited stable set of features. So crust changing a lot is not a bad thing, depending on features of the compiler that are marked as “will change” is a bad thing, as we daily update to the latest nightly version of that compiler - hence the retro-active breaking of published versions
that retro-active breaking of the lowest library then breaks the whole upwards dependency chain, which is very slow to update; as crust needs to fix it, potentially forcing routing to update and publish (if we are in the middle of minor number version bumps that take a long time to complete and be publishable) and then vaults/clients need to update and publish (again also delayed if the project itself is in the middle of a refactoring)
so we’re discovering the problems as we go along, but this should be resolvable
Thanks for all that Ben!
you’re welcome, and you were also right. The rust compiler is rapidly becoming more stable, and so are our lower libraries, crust and routing. So as the stability expands in all these projects, it does flow up and settling the dust
4 Likes
Perfect!
Keep up the good work
2 Likes