Iridium

So, change of plans. I’ve been fighting with thrussh for hours now trying to get SSH working. The key exchange was failing, and I had no idea why. It turned out that even their example client/server didn’t work when I tried. Despite spending a lot of time going through the source, I couldn’t find the cause of the issue. The crate uses futures very heavily, which makes the program flow hard to follow, at least for me. I’m sure that somewhere in the world there is someone who has no problem following futures-based async, but it isn’t me. In light of this, I decided to go old school. I’m leaving the previous tutorial part up; I think its important to see this aspect of projects as well. Having to scrap something that doesn’t work out and pivot to something else.

Hello! In this post, our focus is going to be on starting to add some parallelism to the Iridium VM.

We’ve been having so much fun, we haven’t written any benchmarks! Though it isn’t the most exciting thing to write, they are important. == Benchmarks There’s two things to understand about benchmarks:

Hello! In this part, we’re going to factor out the command parsing done in the REPL for user input. Right now, there isn’t much flexibility; a user cannot type:

If you’ve been following the development of Iridium, you know how heavily it uses Nom to parse the assembly language. I hope you liked it, because we’re going to be using Nom for this as well. =)

In this tutorial, we’re going to start creating a language called Palladium that will compile down to the assembly code we’ve been using. Before we get started, please remember…​

Hey everyone! In this tutorial, we’ll add PID tracking to the Iridium VM. Please ensure you are starting from https://gitlab.com/subnetzero/iridium/tags/0.0.17. == PIDs There are two components we need to unique identify: