One of the earliest modules I wrote for Raku (then Perl 6) was ArrayHash. ArrayHash is basically a Hash that preserves key insertion order. I don’t remember what I originally wrote it to do, but I do still use it in one application I use every year or so to help me with a complicated task at work.

I don’t actually think the work itself is very interesting, but you might learn some bits about Raku internals through my work, so I hope this is useful to someone.

I am going to be honest and upfront with you. I have almost no opinion about the name change of Perl 6 to Raku. I can see going to war for something meaningful, like religion. I cannot imagine doing so for something trivial, like a programming language. I won’t be upset if you call my hammer a mallet. There are certainly advantages and disadvantages to the name change, but as far as I’m concerned, it was inevitable as long as the issue kept being brought up year after year.

First, I want to say thank you to Andy Lester who has been project lead on vim-perl6 as well as the other contributors, especially Hinrik Örn Sigurðsson, Rob Hoelz, and Patrick Spek.

The plugin will now be homed in the new Raku organization on github here:

https://github.com/Raku/vim-raku

As of right now, it has been updated such that it will handle the old Perl 6 filenames as well as the newer ones, so far identified as .raku, .rakutest, and .rakudoc. It also handles .t6 which is something that the plugin didn’t handle previously.

I hope this calendar has been of some use to you all. In any case:

Merry Christmas!

Lots of big words in the title. In simpler terms, it means running a program in the background and interacting with it as input and output becomes available. The tool in Raku for doing this work is called Proc::Async. If you’ve ever dealt with the pain of trying to safely communicate with an external process, writing to its input and reading from its output and error streams and hated it, I think you’ll like what Raku has built-in.

Raku actually provides two different locking classes. A Lock object provides a very standard locking mechanism. When .lock and .unlock are used or .protect is called, you get a section of code that pauses until the lock frees up, runs while holding the lock, and then frees the lock so other code that might be waiting on the lock can run.

However, the Lock class works in such a way that blocks the current thread. As I’ve pointed out earlier in this advent calendar, the purpose of threads is to do stuff, so blocking them from running is preventing them from fulfilling their purpose. Luckily, there is a solution.

What’s more asynchronous than socket communication? When two programs need to talk to each other, often from different computers on different networks in different parts of the world, you can connect using a socket. Whether an HTTP server or some custom protocol, you can implement both sides of that communication using IO::Socket::Async.

Let’s consider a simple calculator service. It listens for connections over TCP. When a connection is established, it takes lines of input over the connection and parses each line as a simple mathematic calculation like 2 + 2 or 6 * 7.

Iteration is slow. If you have N things to process in a loop, your loop will take N iterations to process. Slow. Sometimes that’s the only way, though, to solve a problem.

For example, let’s consider the case where we have a JSON log and we want a command to read each line, parse the JSON for that log, and summarize it showing the time stamp and message:

use JSON::Fast;
my $log-file = 'myapp.log'.IO;
for $log-file.lines -> $line {
  my %data = from-json($line);
  say "%data<timestamp> %data<message>";
}

If you have multiple cores on your system (and who doesn’t in 2019?), you can actually speed this up a little bit with a small change:

The goal of today’s article is to consider when you want to run your tasks simultaneously and how to do that. I am not going to give any rules for this because what works one time may not work the next. Instead, I will focus on sharing some guidelines that I have learned from personal experience.

Remember Your Promises

Whenever you use concurrency, you want to hold on to the related Promise objects. They are almost always the best way to rejoin your tasks, to cause the main thread to await completion of your concurrent tasks, etc.

As I have said several times before in this calendar, it is always best to avoid sharing state between running threads. Again, however, here is yet another way to share state, when you need to do it.

A few days ago, we considered monitors as a mechanism for creating a thread-safe object. Let’s consider the following monitor:

class BankBalanceMonitor {
    has UInt $.balance = 1000;
    has Lock $!lock .= new;

    method deposit(UInt:D $amount) {
        $!lock.protect: { $!balance += $amount };
    }

    method withdraw(UInt:D $amount) {
        $!lock.protect: { $!balance -= $amount };
    }
}

The day after that we considered the compare-and-swap operation, a.k.a. cas, and how to use it with any scalar variable in Raku. By using cas, we can actually create thread safe objects without using locks at all.