Raft Hack Download

[Amie Mandy]

Trappedon a small raft with nothing but a hook made of old plastic, players awake on a vast, blue ocean totally alone and with no land in sight! With a dry throat and an empty stomach, survival will not be easy!

Joy of the land, of the food and wine we can produce, and of the joy we have when we share around the table. My journey to get here revolved around the table, and the community that I shared the table with. This community is my raft, keeping me afloat every step of the way.

I'd like to put down a one or two layer raft to help with adhesion. I cannot find a way to do this. Ideally, this highlighted area in yellow would be rafted - i.e. a raft essentially covering the area inside the brim.

No, rafts are just for parts. You cant add a raft for supports. Just increase the first layer expansion of the supports though if you want more support base area. Its an option under supports, although its a Expert/red setting so make sure you are in Expert mode to see it. By default its set to 3mm but you can change it to whatever you want. Increase it large enough and the bases will merge. Its not a setting for organic supports but for ALL support types.

Hi folks,

As an exploration exercise for myself, I look into server-side swift and try Swift outside apps world. I have decided to implement a Raft consensus Raft is easy to understand but still provide many puzzles to solve.

A raft implementation for swift is very interesting to us. I'll watch the repo and perhaps can make some time to help out a bit. I worked on an implementation a few (many) years ago and made tons of small little mistakes in it along the way -- the protocol is seemingly "simple" but there's a ton of subtle things to get wrong in it Happy to help getting it correct and efficient.

I would really encourage expressing the protocol implementation in terms of actors (you can download a snapshot toolchain here Swift.org - Download Swift and enable them by passing -enable-experimental-concurrency. You can enable it for your package by following: Can "-Xfrontend -enable-experimental-concurrency" be enabled in a Package? - #3 by Diggory

Since you say this is a project to explore and exercise, let's not stick to pre-actors world as there's no necessity for doing so I assume? On the other hand, modeling these protocols as actors is absolutely going to be the future IMHO.

I would suggest focusing on the core algorithm and building a large test suite confirming its correctness first, and we'll get it distributed soon enough A strong test suite exercising the protocol as expressed as actors could be invaluable If you'd need any help how to get things set up let me know -- for now you'd need to use runAsyncAndBlock ... in the XCTests, but this will not be necessary eventually.

API wise I think there's two options, either -nio/docs/current/NIO/Structs/NonBlockingFileIO.html but it's API is a bit limited (on purpose kind of I guess), so perhaps you can get away with it. Otherwise I agree that the "right" API to use here is Swift System, althoughit is multi-platform not cross-platform so we're likely to need some small shim over it to issue "append to log" commands etc. But this should be easy enough to build as the number of operations you'd need for the log are not too crazy.

Eventually I'd hope Swift System or some other "async" APIs for IO to be provided by Swift to fit into the new async/await world, but we're not there yet. So all those calls will be blocking, so you'll need to put those "somewhere" in order not to block the event loop. For that purpose you could use a dedicated "IO" thread pool, by creating an instance of: -nio/docs/current/NIO/Classes/NIOThreadPool.html and using it everywhere you'd need to perform this IO work.

There are good ways to integrate EventLoopFuture with async/await so you can await elf on it -- let me know if you get to that point and happy to help, but it boils down to copy pasting this snippet: -nio/pull/1701

NIO of course is an excellent choice for the networking, but we should try to keep distributed protocol implementations somewhat independent of NIO. You could have a look how we built such distributed protocol implementations in GitHub - apple/swift-cluster-membership: Distributed Membership Protocol implementations in Swift

There we implemented SWIM in a way that does not expose the fact it uses NIO in the "core protocol" implementation. That amount of separation may be too annoying here, but I think it would already be fantastic if we modelled peers as Actors with async functions on them, and implement the messaging they do there with NIO as a start. (so a peer would take some "transport" object that has NIO inside and send messages through that etc).

I'll watch the repo and perhaps can make some time to help out a bit. I worked on an implementation a few (many) years ago and made tons of small little mistakes in it along the way -- the protocol is seemingly "simple" but there's a ton of subtle things to get wrong in it Happy to help getting it correct and efficient.

This is actually a great suggestion. I will take a look at how to move to actors and also extract NIO part into a separate target.

Tests are must in such project. I have started with implementation to see that it actually works :) And if move the protocol outside of NIO it will be easy to model events and state.

API wise I think there's two options, either NonBlockingFileIO Structure Reference but it's API is a bit limited (on purpose kind of I guess), so perhaps you can get away with it. Otherwise I agree that the "right" API to use here is Swift System, althoughit is multi-platform not cross-platform so we're likely to need some small shim over it to issue "append to log" commands etc. But this should be easy enough to build as the number of operations you'd need for the log are not too crazy.

Sure, I have started using NIO directly mostly because it was easy as I used Swift-gRPC server/client. I have saw SWIM implementation and I think it's possible to do such kind of separation. Especialy if model all async operations with actors model.

Swift System is fairly new and there's still large swaths of API we have yet to develop: API Roadmap. I'd be very interested to know your experience using System and what you find lacking in it. We have a subforum here.

Swift System is fairly new and there's still large swaths of API we have yet to develop: API Roadmap . I'd be very interested to know your experience using System and what you find lacking in it. We have a subforum here .

Sure, give me some time to play with the library. On the first note, I don't know if this is a knowing issue, but swift crash when building a project with SwiftSystem dependencies (Snapshot toolchain, Swift System from the master, not 0.0.1). Tring to understand why.

There was an assert that got fixed in SILGen: Fix assertion failure when accessing a property with a __consuming getter [5.4] by slavapestov Pull Request #35897 apple/swift GitHub, but I don't know if that has gotten incorporated into a recent snapshot.

This commit is the latest commit that doesn't hit that error, but it doesn't have all the FilePath convenient operations on it. You can workaround the compiler error by manually removing __consuming from the computed var here.

Hi @ktoso, I have made a PR Extract consensus logic into separate target by makadaw Pull Request #1 makadaw/swift-raft GitHub to separate consensus logic from NIO.

I hope I have understood you correctly. Please, can you take a look if it makes seans?

Have started to use SwiftSystem for FS access. @Michael_Ilseman. After using Swift snapshot 2021-02-16 master compiled without any problems. The package provides almost everything that I need, and all missing parts are in the roadmap. Temporary I have implemented those methods with FileManager (need directory operations and access cache folder for tests). Have found an issue with the group/others right on file creation and raised an ticket at the GtiHub.

An interactive workbench for any language to poke around and test distributed systems algs, including simulated latencies, message loss and visualizations of message exchanges It would be most fantastic to find a way to use the workbench with this raft implementation. I ticketified that Consider using the jepsen workbench: maelstorm with swift-raft Issue #7 makadaw/swift-raft GitHub

There was an assert that got fixed in SILGen: Fix assertion failure when accessing a property with a __consuming getter [5.4] by slavapestov Pull Request #35897 apple/swift GitHub , but I don't know if that has gotten incorporated into a recent snapshot.

This commit is the latest commit that doesn't hit that error, but it doesn't have all the FilePath convenient operations on it. You can workaround the compiler error by manually removing __consuming from the computed var here .

The package provides almost everything that I need, and all missing parts are in the roadmap. Temporary I have implemented those methods with FileManager (need directory operations and access cache folder for tests).

Separate logic of the protocol from a time. Now it's 2 separate modules, one own only logic and another integrate with NIO Event Loop to control time.

Protocol logic is pure actors implementation. And then it glues with NIO Event Loop in

3a8082e126