Advent of code in SPL - 2025 day 1

Advent of code is a series of Christmas-themed programming challenges that's been running for more than 10 years now. While SPL is not exactly a fully-fledged programming language, I had heard in the past of at least one person (thank you Paul Dean for the idea!) attempting to do the challenges in SPL and this year I thought I would give it a go.

I know it's more than a month too late, but this is the first of a series of articles tackling 2025's challenges in SPL. We won't manage all of them, and some of them will be extraordinarily gore, but we will learn along the way. And please do comment or contact me if you have alternative/better ways to get to the answers!

Start here, even if you don't want to play along, as it'll make no sense otherwise: https://adventofcode.com/2025/day/1

As with all the challenges, the first step is always to save the data to a csv file, use a text editor to add a header (i.e. give a name to the field(s)), and import it into splunk:

Now before we start applying all these rotations, the safe dial starts on position 50, so let's set that up:

Now we're in a good position to take advantage of the streaming nature of SPL. But first let's massage the rotation so we can do maths:

Notice I didn't put the rotation +/- value in a separate field from offset. This is now a perfect use case for streamstats, which performs stats in a streaming "you can see what I'm doing as I go" manner:

Now of course a safe dial doesn't go negative or higher than 99, so let's do more maths:

Now we have the position of the safe dial at every step! We'll build on this for the 2nd part, but first we can find the solution to the first part: 

That was quite nice and it worked well in SPL. Let's move on to part 2.

In part 2, it's no longer enough to look at the position of the dial at each step, we need to compare with where it was in the previous step. A very useful trick is to bring the previous value in the current event with another use of streamstats, this time with current=false and last(...):

Now all we have to do is figure out how many times we go through a number dividable by zero when going from previous_running_offset to running_offset. I thought that was going to be easy, but there's a lot of edge cases:

• for instance, going from 550 to 350, we go through 500 and 400, it feels like abs( floor(running_offset/100) - floor(previous_running_offset/100) ) should do it

• but going from 550 to 300, we have to add 1 more because we go through 500, 400 and 300

• but that's not the case if we go from 300 to 550 where it's more like going from 350 to 550

I thought I had it several time, and it did my head in. After a lot of trial and error, with a truth table on paper and a set of edge case to test systematically, I settled on this gore:

The field that matters is pwd_count_tot but I left the others in for debugging purposes. Amazingly this worked and all we have to do is sum it up:

That concludes day 1! Luckily it was well suited to being approached in SPL. Maybe you've learned something about streamstats. Let me know if you have a different approach to solving the challenge!