I’ve been working on my Bitcoin node a bit more over the past few weeks. Here are two new posts that (should) finish off the peer-to-peer networking portion of the project:
Limiting Peers with DynamicSupervisor Options - In which I realize that I duplicated a lot of work already done for me by the DynamicSupervisor module, and simplified my code quite a bit.
Here’s the FizzBuzz post I talked about previously. I basically use stream to replicate an interesting Clojure FizzBuzz solution. With a little cleanup, I actually prefer the Elixir version over the Clojure one (although being able to map over multiple collections is nice).
I also wrote a bit last week about improving my Bitcoin node’s receive loop by switching from using :gen_tcp in active mode to passive mode. This switch simplified things quite a bit and let me gut quite a bit of code from my project.
Nice! I feel like you’re reading my mind. I started to dive into contributing to Elixir when I thought I found a bug a couple weeks ago. I also found this Dockyard article to be very helpful.
Looking forward to part 2 where hopefully we find out how trains reconstruct their state in the event of a crash and how holders of stale train pids find the newly generated processes.
I’m pretty pumped about what I’ve got working so far, and plan to keep developing my ideas into something more useful in the future. Hopefully you think it’s as cool as I do.
Returning {:reply, reply, new_state, timeout} is similar to {:reply, reply, new_state} except handle_info(:timeout, new_state) will be called after timeout milliseconds if no messages are received.
handle_cast/2
Returning {:noreply, new_state, timeout} is similar to {:noreply, new_state} except handle_info(:timeout, new_state) will be called after timeout milliseconds if no messages are received.