Ljubljana is a city of lawyers - so it's no surprise that the earliest known mention of the town and the castle above it involves a certain Rudolphus Advocatus.

Click and let the kite take you back to the High Middle Ages, to the beginnings of Ljubljana castle and the triple town below it.

#kiteaerialphotography #KAP #kite #flying #aerial #history #archaeology #medieval #castle #town #Sponheim #Carniola #LjubljanskiGrad #Ljubljana #Slovenia

https://kapjasa.si/en/a-castle-in-the-clouds-of-history/

Thursday's long read: how we tried to colonize Ljubljana Marshes, why we kinda failed, and how we are now protecting this strange, wounded, beautiful ecosystem.

https://kapjasa.si/en/rewilding-a-tamed-wilderness-ljubljana-marshes/

#kite #kiteaerialphotography #KAP #kaerial #history #nature #colonization #marsh #moor #swamp #melioration #engineering #hydrology #rewilding #LjubljanaMarshes #LjubljanskoBarje #Barje #Ljubljana #Slovenia

Cabo Touriñan 2023

#KAP
#KiteAerialPhotography

https://xxoossee.com/projectes/kap

So, today I implemented indexed assignment in Kap. I have for the longest time avoided doing so, because the semantics of the language is immutable, but the syntax itself looks like it mutates an array. After all, that's what pretty much every other language does when faced with this kind of code.

To illustrate, what do you think the following code will return?

If you guessed 70, you'd be right.

If you guessed this is because the assignment on the second line makes a copy, you'd be wrong. foo and bar indeed shares a reference to the same object.

What actually happens is the when you assign to a bracket expression, a new array is created with the updated content, and the value of foo is replaced.

In other words, it's equivalent to the following expression (which is what you had to write before):

I.e. take element at index 1, replace it with 50 and put it back in the original array, finally assigning that result back to foo.

It turns out that in practice, you don't have to replace elements at specific locations very often, so explicit syntax for it wasn't really necessary.

But, as I was typing the new tutorial for the language, I realised that trying to explain structural under (i.e. ⍢) to a beginner is not something I want to do, so I just decided to implement the standard APL notation for this operation.

Now, to answer the obvious question why I was hesitating to do it earlier: The reason is that this is actually a very costly operation. The entire array is copied every time you replace a single element. It also prevents lazy evaluation, which is pretty bad, since that's what allows Kap to be fast.

Finally, a beginner user may use this in a loop to initialise an array, which would be a terribly slow.

I do have some ideas how to make the last case faster though. The idea is to allow an array to be mutable until any of its content is read. We'll see if it becomes necessary to implement this.

#kap #apl #programming

I've started a new effort to write a tutorial for Kap.

Do note it's not finished yet

But if anyone is willing to browse it to see if it's understandable, and even more importantly, interesting, please tell me if I'm on the right track.

https://kapdemo.dhsdevelopments.com/turbo-tutorial.html

#kap #apl #programming

Up until now it feels like the advent of code problems were designed for array languages.

There are certainly problems that takes multiple lines of code to solve (some of the early problems last year had that property). We'll see what happens in the next few days, but this one was remarkably concise when solved in Kap.

Here are two separate functions that solve the two parts:

Part 2 was even shorter than part 1.

In both problems, the general approach is the same: Iterate over the rows, and update the correct state based on the locations of the splitters.

The second problem keeps track of the number of ways in which a certain cell can be reached, which means that the location of a beam is no longer just a boolean value, but a number indicating the number of ways in which this position can be reached. The result is then simply the sum of all beam values in the last row.

I also note that so far, most of the problems have not had weird edge cases. For example, in today's problem there were no cases of two splitters next to each other, or were there any splitters at the beginning or end of a line. If that had been the case, the solutions would be a bit more complicated.

#adventofcode #programming #kap #apl

Day 6 was interesting. In part 2, you have to parse text vertically, in a way where array languages really shines (transposition of 2-dimensional data is just a single character).

The solution I came up with is... ok... I guess? It feels it should be possible to do it much more concisely than I did it, and I've seen solutions in other languages that are on the same order of magnitude in size compared to the Kap solution, which is not something you see very often.

In particular, I saw an amazing Ruby solution that puts mine to shame, and I say that even though I don't even know much Ruby and never really liked it that much.

I am kind of happy with the way I implemented the operation selection. I take advantage of the case function (docs). It computes both the sums and the multiplications, and then uses case to pick the correct set of results.

Kap can do this without computing the double computing results, since the results of the sums are lazy, and the individual results will only be computed when the result is read.

https://codeberg.org/loke/advent-of-code-kap/src/branch/master/advent-of-code-2025/part06.kap

#adventofcode #programming #kap #apl