pes18fan's posts

achieving true zen pt. 1: everything is an expression

Fri, 29 May 2026 00:00:00 GMT

This article is part of a series.

In 2023, I read this little book called Crafting Interpreters written by Bob Nystrom, intrigued by the concept of PL design and compilers. As the book intended, I worked parallely on writing the two interpreters designed in the book over the course of reading it. The first one, jlox, I designed as a Crystal interpreter named kaze. I've talked about in a previous blog, where I described how one could design a language to avoid semicolon terminators. But the second interpreter, clox, is where it got interesting for me. My implementation was now written in Odin, named zen.

Initially, it was just another form of clox with some small design differences, most notably the avoidance of semicolons, albeit in a different way as was described in my article, as I used automatic semicolon insertion (ASI) for it. However as the years passed, I just kept adding more and more features that were not in the toy language clox, like anonymous functions, lists, a featureful standard library, and proper modules, making it suspiciously like an actually useful programming language. This year, I finally shed the single-pass nature of clox for a real abstract syntax tree (AST); unlocking so much more possibilities for the language.

I now have decided on four concrete steps on how I can "achieve true zen". The first one is: making everything an expression.

But why?

There are two main reasons behind it.

Firstly, I think that it's just a really elegant design. Isn't something like

var something = if cond {
    thing
} else {
    fallback
}

a much cleaner design than the following?

var something = thing
if not cond {
    something = fallback
}

What if you forget that if check? Your logic has now become entirely flawed. The if being an expression also makes it far more ergonomic to read as its just something is value if cond and fallback otherwise, compared to the something is value, and if cond is not true put fallback in it. It just feels much more natural. Making statements like switch an expression can extend this idea even further.

The second reason, which is perhaps more important technically, is more specific to my plans, though. Before I even thought of doing this as a concrete idea, I was spending time teaching myself the Hindley-Milner type system, in order to implement it in zen and make it statically typed. However, once I finally set out to try and actually do it, I realized that it does not work very well for traditional imperative-type languages whose grammar separates expressions and statements, which zen was at that time.

Why?

To understand why, one needs to understand what Hindley-Milner originally was for. The basic Hindley-Milner type system is implemented for the lambda calculus, which can be considered as this extremely minimal "programming language"; essentially the first ever functional language, although it was not a programming language in the sense that we know it today but rather a method to represent computation, similar to a Turing machine. The lambda calculus has an exceedingly simple grammar with just expressions:

(* an expression can be: *)
e ::= x                 (* a variable *)
    | λx.e              (* a function with parameter x and body e *)
    | e e               (* a function (first e) called with an argument (second e) *)
    | let x = e in e    (* a let-in expression; binds an expression for use in another *)

Because HM's base is the lambda calculus, it works naturally with languages which have the functional idea of using expressions to denote everything. Run on an AST, it expects everything to be an expression that gives you a value of a certain type. Statements and declarations, which do not evaluate to anything break that idea; so you need to either special-case them which is annoying, or flatten the entire AST so that everything yields a value.

My choice among the two was the latter: just turn everything into an expression so that it works perfectly with HM!

zen has always had a bit of a functional touch. Instead of opting for something like uniform function call syntax or leaning into method chaining, I decided to borrow the pipe operator |> from Elixir instead. While Crafting Interpreters did give zen first-class functions, what it did not give it was anonymous functions as well as shorthand arrow functions. Therefore, this felt like a step in the right direction.

How exactly is it done?

The main idea is: you reinterpret every single AST node as something that returns a value. This means that a dichotomy of statements and expressions, or in zen's case a trichotomy with declarations, statements and expressions, flattens out into just expressions. How do you do this for each type of node?

Sequence expressions

The very first thing that is necessary to clear up is: how do you describe a program? If the program is only composed of expressions, does that mean the program is itself an expression? How does that work? How do you interpret all of the separate expressions that the program contains as that one big expression?

The answer to that is sequence expressions. I modeled a sequence expression as two expressions, separated by a specific separator token (in my case a newline or a semicolon). The grammar is thus like

sequence ::= expr ("\n" | ";") expr?

As it is an expression, it has to evaluate to something. How does it evaluate? Well, it evaluates the left expression, then discards that result, evaluates the right expression, and returns the value of that right expression as its value. The right expression is optional; if it doesn't exist the sequence evaluates to a null value. With this logic, something like

1; 2

naturally evaluates to the value 2, disregarding the evaluation of the previous expression 1. This is very similar to how Rust does things; almost everything in Rust is an expression as well, and the semicolon acts as a "discard" operator; resembling how in my model of the sequence a newline without a right expression evaluates to a null value as it has already "discarded" the previous expression.

There are a few really useful benefits to this approach. Firstly, it perfectly models normal statement-based code while still being a valid expression. You gotta make sure that the language can still feel familiar and "normal" even if it is different underneath, otherwise it will just be a nightmare to understand.

Secondly, it allows us to do really cool things like:

var a = {
    var b = 3
    b * 2
}

You can describe a variable as a chain of expressions. How cool is that?

But... how exactly do you model it in the parser (in this case, a Pratt parser)? Do you make the newline an infix operator with a defined precedence level in the parser? The answer is... sort of. Yes, the newline does indeed act as an infix operator, and it does have a precedence; it has the lowest possible precedence as it is the chainer of EVERY possible expression. However, it is not ideal to just slap it on the precedence list for the parser, as it is not something that should just be able to appear anywhere within a program. The better approach is to define two levels of expression-parsing function. In my parser, it looks something like:

parse :: proc(p: ^Parser) -> (expr: Expr, success: bool) {
    if parser_is_at_end(p) {
        return nil, true
    }
    return parse_expression_top(p), !p.had_error
}

parse_expression_top :: proc(p: ^Parser) -> Expr {
    fst := parse_expression(p)
    if !parser_match(p, .NEWLINE, .SEMI) {
        return fst
    }

    if p.panic_mode {
        parser_synchronize(p)
    }

    seq := new(SequenceExpr)
    seq.token = parser_previous(p)
    seq.left = fst
    seq.operator = parser_previous(p)
    if parser_is_at_end(p) || parser_check(p, .RSQUIRLY) {
        seq.right = nil
    } else {
        seq.right = parse_expression_top(p)
    }
    return seq
}

parse_expression :: proc(p: ^Parser) -> Expr {
    // ... Pratt parsing logic ...
}

You parse the first expression using the existing expression parsing logic. Then, you check if there actually is a newline or semicolon afterward, and if not, just return. Remember, your program is entirely allowed to be just a single random expression (even though that's never really useful). If you DO see a newline, we actually have an actual sequence, and we look for the second operand.

But you have to be careful here as well. What if the program just goes to EOF immediately after (or if we're at the end of a block; we'll get to that later)? In that case the second operand doesn't exist, so you just return the one-armed sequence. If it DOES exist, you parse it as well.

Note how the left one just parses an expression, but the right one recursively calls parse_expression_top. This is to allow that sequence of expressions to actually be a sequence; something like 1; 2; 3; 4 gets parsed as (seq 1 (seq 2 (seq 3 4))), allowing the entire program to just be one huge expression. That is just immensely satisfying.

As I stated earlier, while the parser is a Pratt parser with every operator having its own separate parsing rule, this one specific part of the parser is not a part of that logic; the newline is not given a Pratt infix rule. Why?

This is because the sequence expression must appear only in specific cases. Specifically, the sequence expression must appear in the top level (global scope) as the single expression connecting all global expressions, and inside blocks connecting the sequential operations. The sequence expression should not be usable as just another general-purpose expression. Why? Well, it was mainly just a design decision; it doesn't really make any sense to use a sequence expression outside these two contexts.

if/switch

The branching statements; these always tend to be the ones appreciated a lot when given expression forms. This is because they just are so useful and intuitive in that form.

For the if expression, the idea was pretty simple; it evaluates to whatever value the matching branch returns.

val hello = if happy { "hey!" } else { "hi." }

The more interesting case is when there is no else branch at all. What do you evaluate to? The obvious idea would be "evaluate to the if branch if that matches, otherwise return a nil value". But that's rather unpredictable; you want your expressions to give you predictable values as far as possible. One approach you could take is just disallow one-armed if when it is used as a value entirely. This means

val something = if cond { "hi" }

would crash with a compile error. This is what Rust does, and it is reasonable; it doesn't really make sense to assign the value of a condition without any fallback. But I felt that this was too restrictive, plus finding out when a value is "being used" is actually rather annoying; there's a lot of cases! So in the end, I decided the best approach would be to just always return nil for one-armed if. The one-armed if cannot really be considered as a proper "expression", but more of an effect. So, in the previous code example, something would evaluate to nil, even if cond was true.

This approach can be annoying if the user expects the if to return some value when the condition is true only; but when the typechecker is here, it can enforce the rule to disallow you from using the resultant nil of a one-armed if in contexts that it doesn't make sense in.

The switch statement is pretty simple. Whatever case matches, the switch statement evaluates to:

// `switch` evaluates to whatever case `day`'s matching value is associated with
val message = switch day {
    "friday" => "yay weekend!"
    "saturday" => "still weekend!"
    else => "ugh"
}

The switch statement is a little stricter than the if. Switch statements are exhaustive in zen, albeit naïvely, means the compiler doesn't actually know if you covered all the cases of a switch, it just always wants an else fallback. This still does make the switch far more predictable though; it ALWAYS returns a valid value and not some sentinel like nil (unless you explicitly returned that).

about `nil`

One thing I'd like to clear up right now is my idea of nil in zen. In many languages, nil is something that can implicitly coerce to any type and thus a valid value of any type. Technically, zen does do that right now, but that is simply the consequence of the fact that it is a dynamic language. nil is intended as the unit type: similar to () in Rust, where it has its own type where nil is the only valid value, and you can't set something of another type to nil. This makes it a perfect candidate to describe effect-y expressions like the one-armed if. In the future I'll probably turn it into a type like () anyways, but that is when I have proper record/tuple types in the language.

blocks

This one is pretty cool! The expression basis now allows you to do this like in Rust:

var a = {
    var b = 6
    var c = 7
    b * c
}

As described in the part about sequence expressions, blocks are the only place other than the global scope which can contain sequence expressions (or any other expression really, as parse_expression_top() will just return a non-sequence expression if there is no sequence). Hence, the block doesn't really have any logic of its own; it can be considered as a way to enclose sequence expressions to make them usable as values. Blocks evaluate to whatever expression is inside of them; which means visually they appear to evaluate to whatever is the last expression, as sequence expressions do exactly that, and other expressions in a block will always be the "last expression" in the block anyways.

However, they also add something really important to the base concept of the sequence expression; scoping. As always, the variables inside a block cannot be used anywhere outside, making them useful for adding little isolated computation blocks.

One issue I faced when making blocks expressions was something I like to call "return value erasure". Every time a block goes out of scope, it pops off all of its local variables from the stack. Consider that small example from before. Right as that block's execution is done, the VM's value stack looks something like

[ b ] [ c ] [ b * c ]

I'm massively oversimplifying of course, there's some other things in there; but for now just consider those three values; the b and c being the local variables declared in the block living on the stack, and the b * c being the intended return value of the block.

The block's scope now ends. In the old zen, by the time a block's scope ended, everything coming from computations in the scope was not on the stack anymore, and the only things left were its local variables; so the VM would just blindly pop as many values off the stack as there were local variables in the block, and it was safe.

But now, the return value is on top of the stack, and obviously it can't be just thrown off to make way for the locals to be cleared, because we need it in the context after the stack ends. To fix this issue, I added a new field, or should I call "register", to my VM struct called save. It has this hyper-specific purpose: guard a block's return value as its scope is being torn down.

So, right before the block scope ending causes the block scope to be cleared, an OP_SET_SAVE instruction grabs the top of the stack and puts it in the save register, thus turning the stack just into

[ b ] [ c ]

The block can now safely pop off these local variables, emptying the stack. Then the value inside save is immediately put back on the stack, getting

[ b * c ]

Solving the whole issue with ease!

The one unfortunate result of this is that it is an additional two cycles on the VM, which has some real performance implications. It definitely feels like a bit of a temporary fix than anything else; hence I'm still thinking of more optimized approaches to this idea, perhaps like a dedicated block scope ending opcode.

while/for/for-in

I thought about what would be a logical thing for a loop to evaluate to. Then I realized; there really isn't anything that makes sense. Some accumulated value? Not all loops accumulate values. The index? Not all loops care about the index. Anything else is too weird of a choice.

Except one that almost made sense: returning a value via a break. Rust actually does this for its loop expressions. However, I realized that doesn't actually make sense for the while, for and for-in loops that zen has at all.

The loop statement in Rust can actually be represented with a concrete type, which would be whatever type of the value the break has inside it, and in all other cases it just never returns so it gets the type of the diverging expression, which in Rust is called !. The latter is also called the never type or the bottom type, more on it later.

So in the end, I decided that all loops should just evaluate to nil; that is the only idea that makes sense; not everything has a natural value it evaluates to. It is a bit unfortunate but that's just how it is, loops are not values, they're effects.

var/val

The var and val declarations return nil. I considered making them return what they bound; but decided that didn't really make a lot of sense since again, they're more like side effects rather than something that directly returns some sensible value. This declaration is kind of like the let x = e part of the let-in lambda calculus expression; it doesn't make sense to break that apart and get a value-returning expression does it? Same logic.

func

This was something I did a little trick for. For variable declarations, I had taken the VarDecl declaration node and turned it into a VarDeclExpr that evaluates to nil. I could've done the same thing for the FuncDecl since its the same concept... but then I realized... yep, its the same concept; hence they can just be merged into one. The function declarations func name() {} are now parsed as VarDeclExprs that bind an anonymous function to a name. This means that function declarations are just syntactic sugar for a variable declaration binding a lambda.

This was a very seamless and satisfying merger that only needed minimal adjustments to make sure function name printing worked (you wouldn't want your named function to be printed as <func lambda> now would you?)

print

I thought about exactly how to go about this for a while. The actual implementation is trivial, so that was not the worry; the worry was: do I really need this? I could just get rid of this and create a native function for printing instead, just like how puts exists now. But I decided to keep it anyways. It felt like some sort of "heritage" I inherited from clox.

One thing I did with this that some might find interesting is its return value. You'd expect a printing expression or function to usually return nil; that is what they tend to do. But, the print expression actually returns what it printed instead. This was a choice directly inspired from nushell. Honestly I'm not fully sure if its the best of choices, and I may revisit it later, but for now, its there.

break/continue/return/exit

These are the juicy ones. What the hell do these even return?

The answer is: literally nothing. But you might ask, "hey, the loops and variable declarations didn't return anything either!" And you would be... somewhat correct; yes, logically they're just effects but there is no harm or weirdness in making them return some unit value nil anyways. This is not the case for these four expressions.

Take this expression:

var a = exit

What is the value of a? Nothing, because the entire program exited before that binding could even be processed!

Therefore, these four are the only expressions that don't actually leave any tangible value on the stack, because the control flow never gets there:

continue quits the entire iteration before its context is evaluted
break quits the entire loop
return quits the entire function
and exit quits the entire program!

You might be thinking, "Well, this sounds like a nightmare to represent with types? What the hell is the type of an exit expression?" In fact, it is actually trivial to represent these expressions as types. They are a classic case of the never or ! type: the type of a "diverging" expression that never returns to its origin of evaluation. It can also be thought of as the type of a value that can never exist, or a type which no value ever has.

Functions like panic which are used to instantly crash a program also are associated with this type; they are treated as functions which return a value of type never; basically saying "this function doesn't just return nothing, it NEVER returns in the first place".

In type theory, never is what we call a "bottom type"; a type that is compatible with every other type. It is why a function like

func f() {
    if cond {
        return value
    }

    panic("some error")
}

has a return type which is the return type of value; the never type of the panic call at the end of the function happily fits with the type of value, because if cond is satisfied you'll get something with the type of value and if not the whole program will crash anyways!

discard

One annoying consequence of everything being an expression is unintentional return values. Consider a function like

func f() {
    some_numeric_computation()
}

where some_numeric_computation() does that particular numeric computation and returns some value. f() is just meant to be an abstraction for that computation action rather than actively returning a value. However, as some_numeric_computation() returns a value and it is at the end of its block, f() will also unintentionally return that value, because blocks evaluate to whatever is at the end of them. That is not what we wanted. This is where the newly added discard operator comes in.

Now consider that same function modified as

func f() {
    discard some_numeric_computation()
}

discard is a very simple concept; it is an expression that takes any other expression within it, runs whatever is in that expression, and as it says, throws that value away. The discarded value is replaced with nil. Hence, f() now returns nil rather than whatever some_numeric_computation() returned.

The choice of making the discard operation a keyword was inspired by Nim.

Things that don't make sense now

In the statement realm, one pervasive concept is the expression statement, which is basically just an expression wrapped around in statement clothing, allowing things like function calls which are naturally expressions to live in the statement world and be parsed as a step in that set of steps. But now that the sequence expression handles parsing expressions as a set of steps without any need to wrap them in anything, this is a concept that just doesn't make sense and can safely disappear.

Another thing that disappeared was this thing called the EmptyStmt. It was a concept somewhat similar to Python's pass, which is basically just a statement that doesn't do anything, emitted when a ; is parsed in statement position. It was a bit spurious and now disappears; a ; appearing randomly in expression position is now a parse error.

Some things I traded off

The expression model is not really without its faults. I have touched on some of them beforehand; but I'd like to expand on those a bit.

The first and more obvious one is the spurious values returned by the expressions that really aren't natural expressions. Loops don't return values. Variable declarations don't evaluate to something. The solution to all this was to return the unit nil to say "it returns nothing" but that just feels a bit bizzare for sure; why return anything at all? This has real performance implications as well, because whenever the value of the expression is unused (which would usually be how these expressions are used) you have a unnecessary VM cycle emitting the nil return value on the stack. Someday, perhaps I could work in some optimizations to help clean this issue up, but it is an unfortunate thing that was always gonna be here.

Similar to the previous point, the next one is: sure, everything evaluates to something, but you don't need everything all the time. And whenever you don't need something, you have to force it off of yourself because the language pushes you towards it. That push is for good reason because a lot of times the expression's value is something you do need or would be well off with; but for those cases you have to deal with the whole discard fiasco. In the end, this is just another tradeoff.

There's the cases where returning values fights the mechanics of the concept itself, like the save register with the blocks. Though, this is something that could be fixed with cleanup in the design of zen in the future; as a lot of zen's semantics are still carried over from the statement-based land of clox.

The truth of the matter is that full expression-orientedness didn't turn out to be as much of an "elegant solution covering all bases" as I imagined, there are always some ugly corners with everything. However, I still think the parts that are indeed elegant, and there are a lot, are fully worth all of it. The whole program is now just one expression; ensuring that a potential type checker has a very simple job: just evaluate that one expression's type recursively. Very elegant, indeed. But that's for the next part.

converting AD to Bikram Sambat

Sat, 23 Mar 2024 00:00:00 GMT

In Nepal, the Bikram Sambat calendar sees very common use. Therefore, conversions between AD and BS are done often, and a lot of the time people have no idea what is going on under the hood to get it done. That included me, until yesterday when I made the decision to create a little terminal app called ncal, which is a very basic, small calendar for BS.

I plan on adding a few more features and probably work on a mobile app for a Nepali calendar to learn mobile development as well as to finally have a non-bloated Nepali calendar app for once.

Anyways, making this little program gave me some insight into how the conversion is done, and it's not pretty, I promise you.

The process I utilized is one that is used to convert BS to AD, documented in this repository and all I did was reverse it for my purposes.

initial steps

The thing is, the Bikram Sambat is a lunisolar calendar with a really complicated set of properties that make determining the length of each month ridiculously difficult mathematically, unlike AD where each month has a fixed number of days (barring February in a leap year). I'm not sure if its impossible or not, but regardless I didn't want to put in way too much work for a simple project like this. Perhaps I'll try to figure out a way to do it sometime, but not for now.

So, the only option left is to use a lookup table, which includes the length of each month in a set of specific years. For ncal, this set is from the year 2000 to 2090.

A lookup table is also required to get the English date that corresponds to the first day of each of the Nepali years that we've selected in this set. Data for this was only available from 2000 to 2090, so even though the month length set was available upto 2100, I only took the set from 2000 to 2090. The month lengths being available do mean that I can calculate the first days myself, which I might do in the future.

getting the year

This part is the easiest. Just take the Gregorian year and add 56 or 57 to it.

nep_year = if gregorian < Globals.first_day[gregorian.year + 57]
             year + 56
           else
             year + 57
           end

Whether you add 56 or 57 is based on whether the Gregorian date is before or after the Nepali new year for its corresponding year. For instance, say we want to convert the date 2024-1-1 to BS. Adding 57 to its year yields 2081, and the English date for the first day of that year is 2024-4-13. Obviously, January 1st is before the 13th of April of 2024, thus our Nepali year is 2024 + 56 = 2080. And if we were to provide, say, 2024-5-5 as the date, we'd get the correct answer of 2081 as the year since May 5th is after April 13th.

getting the month and day

This part is a bit trickier. First, we get the English date for the first day of the Nepali year we just found out:

first_day_of_nep_year = Globals.first_day[nep_year]

Then, we find the number of days between the input date and this first date.

# converted to Int32 since the value may come out as either Int32 or Int64
gregorian_day_gap = (gregorian - first_day_of_nep_year).days.to_i32

Now, loop over the big hash table with the years as the keys and an array of the month lengths as the values. For each month, subtract the number of days of that month from your gregorian_day_gap. Do this till this number is less than the number of days in the current month.

Globals.month_length[nep_year].each_with_index do |days, i|
  if gregorian_day_gap < days
    nep_month = i + 1
    nep_day = gregorian_day_gap + 1
    break
  end

  gregorian_day_gap -= days
end

I'm adding 1 to the nep_month since the nep_month is a zero-based index. I'm doing the same for the nep_day since humans generally don't call the first day of some month as the "0th".

All that's left is to package this data neatly in any form you like. My code here is inside of a private function of a class called NepaliDate and is called by two of the three constructors used to create a NepaliDate. It returns the data to them as a NamedTuple, which in Crystal is basically a tuple with names for each field.

conclusion

Well, that's it! A convoluted process for sure and not one I would recommend trying to figure out at 12 AM, but in the end it works!

Making brightness work on Linux

Wed, 05 Jun 2024 00:00:00 GMT

I recently switched entirely to Linux, specifically Arch, due to issues I had been facing as of late on Windows. When I tried reinstalling Windows, all my drivers were gone including wifi drivers and I couldn't get them working again, so I decided to just use Linux where the drivers just worked. Funny, considering I use an NVIDIA GPU.

Anyways, even before this I had been trying Linux out in dual boot and stuff. I enjoyed it quite a bit, but there was one glaring issue: brightness couldn't be adjusted. There didn't seem to be any error or anything that described why this happened, so I just lived with it while using the AlphaTint GNOME extension to artificially change brightness.

That was until recently. I assume many of you know of systemd. It's a suite of programs that basically opens from the bootloader and starts all necessary aspects of the system. Some like it, some hate it, I personally don't care much. Regardless, the hackerman-like wall of text you get in some distros when they boot up and shut down is a log of what systemd is doing.

Within this wall of text, I, by accident, discovered a bit of text that said "backlight" and "nvidia". I instantly realized that this might be a log of an error regarding the screen backlight, and of course it's goddamn NVIDIA. I looked into this, and thankfully found a bit of info from the Arch Wiki about this. I had to set some kernel parameters to get it to work. Set one of these three and see which one works:

acpi_backlight=video
acpi_backlight=vendor
acpi_backlight=native

To set a kernel parameter, first find the configuration file for your bootloader. In my case, for systemd-boot, it should be in /boot/loader/entries. The bootloader config file's name seems to depend on the distro. For Arch Linux, most sites will say it's named arch.conf, but in my case I used archinstall, so the file was named something like YYYY-MM-DD_XX-XX-XX_linux.conf, which includes the date you installed Arch Linux and the Xs are replaced with some numbers that I couldn't really tell the meaning of. Perhaps they were the time or something.

In my case, the native parameter was the one that worked. What a relief.

If it's not working for you still, you can check out the whole backlight page on the Arch Wiki. Even if you don't use Arch this may be of help.

Using btrfs snapshots

Sun, 23 Nov 2025 00:00:00 GMT

import { Image } from "astro:assets"; import systemdJournalError from "../../assets/systemd_journal_liberrors.jpg"

Yesterday, I spent the whole day fixing a huge mess in my computer, caused due to circumstances I'll elaborate on in a bit. Regardless, this all could have been fixed easily if I made use of the snapshot feature provided by the btrfs filesystem, which my device was (and is) using. I learned my lesson, and I have decided to finally come out of hibernation to teach it to others.

So what happened yesterday?

I was watching some YouTube, when suddenly, the whole UI froze completely with the audio still playing. This wasn't new to me; this is a known kernel bug related to AMD iGPUs, that is especially prevalent on KDE Plasma, which I was using at that time. It had hit my system a few times before too, but I hadn't bothered actually working around it because that would mean disabling some AMD GPU features which I did not wish to do. So, like always... I just forced the computer off via the power key. It turned off succesfully, and I turned it on again to get back to it.

Lo and behold, the computer failed to boot up to the GUI. The bootup systemd logs were weird; NetworkManager had failed to start for whatever reason and instead of the logs clearing the way for SDDM like before, the screen just got stuck there. After a bit of confusion, I got into a rescue shell and checked the systemd journals... then I found this.

All those "file too short" errors you see with the libraries? Seems like that force shutdown I did before corrupted a bunch of important libraries and prevented the system from booting entirely. After some extra investigation it turns out pacman was doing some updates when I did the shutdown, which might have caused this, though I'm not sure how exactly.

Anyways, I desparately tried for the next few hours to fix this problem... to no avail. Eventually I just had to reinstall everything. Thankfully I had backed everything up so I didn't lose much in terms of data, and I also decided to move to Hyprland for now; I already had a basic config ready beforehand and now after some extra quality-of-life tweaks to it, I've decided to stay with it for the time being.

How I could have fixed it easily

I mentioned btrfs before. It is one of the most popular filesystems being used on Linux systems nowadays. This is mainly because of a snazzy feature it has: snapshots. You can think of a filesystem snapshot as a git commit; each snapshot corresponds to a particular state of your filesystem, and you can revert to it whenever you want. This is a huge win for data protection in case of things getting all messed up like what happened to me.

I was using btrfs at that time... but the problem is, I wasn't using snapshots at all. I didn't even bother. This time though, I decided not to make the same mistake, and looked into how snapshots are done.

There are two programs used to set up snapshots that I know of: snapper and btrbk. Looking into these, I found this post by Herman Õunapuu, that described why btrbk turns out to be better than snapper. While I'm new to this and don't understand it all too well, the basic gist is that btrbk is generally better because it is easier to set up and more convinient in some ways.

While Õunapuu also described how to set up btrbk in their post, said post assumes you already know a bit about brtfs; so I'll try to explain it as simply as possible.

Firstly, check what subvolumes your system has:

sudo btrfs subvolume list /

You should get an output similar to this:

ID 256 gen 1160 top level 5 path @
ID 257 gen 1161 top level 5 path @home
ID 258 gen 1145 top level 5 path @cache
ID 259 gen 1161 top level 5 path @log

Each of these are separate logical partitions in a single btrfs filesystem. They are NOT separate partitions and don't create separate block devices (as in those devices like /dev/sda or /dev/nvme0n1 that represent storage devices). They simply separate system data, home data, log data et cetera in one filesystem.

Now, based on what you have here, you need to create a config file for btrbk to tell it how you want it to make snapshots. You can theoretically put this config anywhere, but the ideal place for it is /etc/btrbk/. btrbk provides a btrbk.conf.example there already with descriptions of various options and some useful examples, however it is a bit dense so I'll show what I personally use, adapted from Õunapuu's config.

timestamp_format        long

volume /
  snapshot_dir /btrbk_snapshots
  subvolume /
    snapshot_preserve_min   12h
    snapshot_preserve       24h
  subvolume /home
    snapshot_preserve_min   48h
    snapshot_preserve       7d

timestamp_format is used to determine the name of the created snapshot subvolumes: for example, with the long format, a snapshot of /home will look like home.20250825T1531.

volume / tells btrbk that our filesystem root is at /. Within it, we elaborate further. We tell it to put the snapshots in a folder called /btrbk_snapshots, but you can use any folder with any name you'd like. Within, we now tell it which subvolumes we want to preserve.

This is where it gets a bit more complicated, with the difference between snapshot_preserve_min and snapshot_preserve.

Take the /home subvolume.

snapshot_preserve_min is set to 48h, which means that all snapshots from the last 48 hours are kept; no snapshot younger than 48 hours is ever deleted.
snapshot_preserve is set to 7d, which means that there is at least one snapshot for every day of a weekly schedule.

Imagine you made several snapshots every day for the past week. By the end of the week, what will happen is that all of those several snapshots you made over the last two days (last 48 hours) will stay there, and for each of the other days of the past week, there will be one representative snapshot.

Similarly, for the / subvolume in the config, this means that all snapshots younger than 12 hours are preserved, and for each hour of the last day, there is one representative snapshot.

You can modify these preservation settings as you wish, but this is good enough for me.

Now you're ready to create a snapshot! To test if everything is working, try a dry run first. It will simply test if all the settings are OK and won't actually touch anything.

sudo btrbk -c /etc/btrbk/btrbk.conf run --dry-run --progress

If everything is OK, create a snapshot by running

sudo btrbk -c /etc/btrbk/btrbk.conf run --progress

You should get an output that looks like this:

--------------------------------------------------------------------------------
Backup Summary (btrbk command line client, version 0.32.6)

    Date:   Sun Nov 23 21:41:29 2025
    Config: /etc/btrbk/btrbk.conf

Legend:
    ===  up-to-date subvolume (source snapshot)
    +++  created subvolume (source snapshot)
    ---  deleted subvolume
    ***  received subvolume (non-incremental)
    >>>  received subvolume (incremental)
--------------------------------------------------------------------------------
/
+++ /btrbk_snapshots/ROOT.20251123T2141

/home
+++ /btrbk_snapshots/home.20251123T2141

Automating it

It would get pretty annoying to have to manually snapshot things again and again, and plus you could very well forget to do it. So, it is highly advised to set up a timer service that will automatically set up snapshots for you. You can use systemd timers for this purpose. If you don't use systemd, well... you're probably capable enough to figure out timers for your specific system yourself.

If you are indeed using systemd, first create a system service to create snapshots by creating a .service file in /etc/systemd/system; in my case I made a file named /etc/systemd/system/btrbk-snapshot.service. It is a very simple service that is like this:

[Unit]
Description=Run btrbk snapshots

[Service]
Type=oneshot
ExecStart=/usr/bin/btrbk -c /etc/btrbk/btrbk.conf run --progress

It is a basic service that simply executes the snapshot-taking command.

To make this timed, you have to create a corresponding timer service. Do this by creating a corresponding .timer file with the same name as the .service file; in my case I created /etc/systemd/system/btrbk-snapshot.timer. It looks like this:

[Unit]
Description=Periodic btrbk snapshots

[Timer]
OnCalendar=*:0/30
Persistent=true

[Install]
WantedBy=timers.target

This timer sets the corresponding service, in our case the btrbk-snapshot.service, to run on minute 0 and 30 of every hour, thus creating a new snapshot every thirty minutes. The Persistent=true setting is used to ensure that if the system was off or the timer missed during any moment when the service should've run, the service will run immediately on the next boot so that it can "catch up".

To get this running, reload the systemd daemon and enable the service.

sudo systemctl daemon-reload
sudo systemctl enable --now btrbk-snapshot.service

Now you finally have some peace of mind, knowing you can always revert if your computer ever decides to corrupt all its libraries because of a forced reboot. Unless it corrupts the snapshots. I hope that's not a thing.

Restoring backups

Fortunately, I haven't had to restore a snapshot just yet. But someday, being a Linux user, I probably will, so I gotta know how.

Thankfully, the btrbk docs tell you how it's done. The process is described in detail here.

Basically, btrbk itself does not provide any restoration mechanism so you must restore manually. The process is basically finding out which snapshot you want to restore, create a read-write subvolume out of it and get rid of the old broken subvolume.

I hope this was helpful!

hello

Sun, 09 Apr 2023 00:00:00 GMT

Hello there! I'm pes18fan and I do... well, whatever I like to. I consider myself a pretty impulsive person... not a very good trait for a developer eh? Well, anyways, I'll just be posting whatever random stuff I get into and want to post here in this blog. I'm a pretty bad developer so I doubt you'll learn anything out of it, but I hope you do regardless.

getting rid of semicolons

Sat, 13 May 2023 00:00:00 GMT

I've been working on an interpreter for a simple toy language that I call Kaze recently, following the amazing book Crafting Interpreters by Bob Nystrom. In one of the early chapters of the book, Bob states something along the lines of "if you're building a language today, make sure it doesn't use semicolons". But making sure that was the case was trickier than expected. Here's how I did it.

meet Kaze

Here's a simple hello world in Kaze:

print("hello, world!\n")

(I know, the syntax highlighting is a bit off, I'm not very experienced with TextMate grammar okay?)

Anyways, as you can see from this simple example, we don't need a semicolon. But this one-liner doesn't quite show what that can mean. Check this fizzbuzz out:

var str = ""

for var i = 1; i <= 100; i = i + 1 
begin
    str = ""

    if i % 3 == 0 then str = str + "fizz"
    if i % 5 == 0 then str = str + "buzz"

    print(str + i + "\n")
end

As you can see, the syntax is kinda like Pascal, but that's not the point. The point is, we don't need any semis! How? To find that out, we need to peer into how the language is implemented.

no semis? how?

You'd think getting rid of semis would be easy, since you'd think "we could just remove them from the grammar!" Not quite. The entire reason semis exist in programming languages is to prevent parser ambiguity. For example, look at this:

x = 1
-1

What do you think this gets parsed as? Is it two things: var x = 1 and -1, or var x = 1 - 1? That's where this issue lies.

Languages have tried to get around this in many ways. Python makes newlines and whitespace significant, and JavaScript inserts semicolons behind the scenes. I dislike both approaches, so I went with what Lua, which does not need any special formatting or semis whatsoever, does. For example, this is fully valid:

a = 2 b = 3 print(a + b)

It will print 5, as expected. How?

how do you do it, Lua?

There's an excellent article by 17cupsofcoffee that fully explains this, but in short, Lua does this by dropping expression-statements. What are those, you ask? An expression statement is simply put, an expression parsed as a statement, which allows you to use an expression (something that returns a value) in a place where you're supposed to use a statement (something that well... does something). Expression statements could, for example, allow you to use the short circuting behavior of logical operators to execute something conditionally, as in:

true && someFunction();

Of course, this is not all they can do.

Lua doesn't allow expression statements at all. This makes sure that the ambiguous example stated previously is always parsed as x = 1 - 1. This does mean that if you need to use an expression statement as above, you'll need to put it in a temporary variable, like:

_ = true and someFunction()

I did the same thing with Kaze, so in that language it would look something like:

var _ = true and someFunction()

But, there's still one big issue.

return statements

The parser issue got somewhat fixed here, but it still remains in a small capacity with return statements.

Previously, I said that we removed expression statements. Well, not quite. There are actually a few expressions that still should be usable as statements, for example function calls or assignments. Wouldn't it be awkward to have to assign a variable to even do those? So, I allowed them here too, and now we have a problem. Take a look at this:

fun foo
begin
  return
  bar()
end

Is this returning nothing or is it returning bar()? The parser will normally just think that it's the latter case, but that may not be true. So how do we fix this?

Lua does so by only allowing return statements at the end of a block. That is, a return statement must always be followed by a corresponding end statement. Thus, let's say we have this code:

function foo()
  return
  bar()
end

As return statements must always be at the end of a block, anything after the return statement must be for that statement. So, the example is parsed as a return statement that returns bar(). How do we implement the ability to check if the return statement is at the end of a block, though?

In my parser, written in Crystal, this is how I did it:

# Parse a return statement.
# A return statement must always be at the end of a block.
private def return_statement : Stmt
  keyword = previous
  value = nil
  unless check?(TT::END)
    value = expression

    unless check?(TT::END)
      raise error(keyword, "Return statement must be at the end of a block.")
    end
  end

  Stmt::Return.new(keyword, value)
end

Let me explain this a little bit.

This is a recursive descent parser, i.e. it recursively creates an abstract syntax tree based on the tokens it encounters. This is the function invoked when the parser encounters a return token, represented by TT::RETURN. All the tokens are prefixed with TT:: where TT is just an alias for the enum TokenType.

Anyways, what it does here is that it firstly assigns the keyword token (I keep that to pinpoint the location of a possible error), then it initializes the return value as nil. After that, it checks if the next token is TT::END. If it is, it simply returns a Stmt::Return object without doing anything else. The interesting thing happens if it doesn't find that token. Here's what happens next:

- It tries to parse whatever is in front as an expression. If it's a statement, we'll just get an "Expect expression" error. If it's not, we're all good and we keep going.
- Then it looks for the TT::END token again! If it doesn't find it yet again, we know that the return statement is definitely not at the block's end. Thus, we raise an exception.

If everything was all good, we return from the function with the expression to return.

Pretty cool, right?

how to singly linked list??? (in Crystal)

Mon, 10 Apr 2023 00:00:00 GMT

So recently, I found this awesome video by Low Level Learning where he speaks on singly linked lists (unfortunately the video is unavailable as of January 2025). With my terrible, or should I say, almost non-existent knowledge of data structures, I decided to follow the video to learn about one of them. The code in the video was written in C, however I wanted to be ✨different✨ and to use another language. I picked Crystal, mainly because:

- I wanted to use a different language, as I said, so that I don't end up just copy pasting everything into C.
- Rust was an alternative but I'm really not good at it at all.
- I like Crystal and have used it before.

This was the start of a very interesting journey (should I even call it journey? It was done in a few hours, after all...). Well, in either case, I'll recap what happened here. While the code might be in Crystal, I'll be trying to explain it in a language-agnostic way, so I hope this helps other people to learn a bit about how singly linked lists (I'll call them SLLs from here since the phrase is too long) work.

humble beginnings

Everything began with the definition of a struct for a node. In a SLL, every item is called a node, which each has a pointer to the next item in the list. This was fairly straightforward:

struct Node
  property nxt, data

  def initialize(@nxt : Pointer(Node)?, @data : Int32)
  end
end

I had to name the variable for the next node's pointer as nxt since next is a reserved keyword in Crystal.

The next thing to do was to create a variable that holds the head of the SLL. The head is a pointer which points to the first node in the list. This is not specific to a node, so it had to be global; however the problem is that Crystal doesn't have global variables, at least not directly. So, I created a module with a class variable (represented by @@ at the front) which are variables of a class or module itself instead of instances.

module Globals
  extend self

  @@head : Pointer(Node)? = nil

  def head
    @@head
  end

  def set_head(value : Pointer(Node)?)
    @@head = value
  end
end

I also created a set_head method so as to change the value of head from outside the class.

user interface

Now that the basics were done, the next thing to do was to create a simple UI for the user to figure out how to work with the list.

def print_menu
  puts "You have the following options."
  puts "\t1. To add a node to the list."
  puts "\t2. To remove a node from the list."
  puts "\t3. Insert a node between two nodes in the list."
  puts "\t4. Print your list."
  puts "\t5. Quit."
end

Super simple, nothing too fancy.

I next created the handlers for the options:

option = -1

while option != 5
  print_menu
  option = gets(chomp: true).to_s.to_i

  if option > 0 && option <= 5
    case option
    when 1
      # add operation
    when 2
      # remove operation
    when 3
      # insert operation
    when 5
      # do nothing
    end
  end
end

functions

Time for the functions. Three functions were implemented in the video, and I'll go over each one.

adding a node

Let's begin with the function to add a node.

To add a node, we could go in two directions. One would be to add the node to the back, but in that case we'd have to traverse the whole list to find where the list ends, which makes the time complexity O(n). That would cause the program to slow down a lot if there are many elements. Thus, it's a better idea to add to the front, which will provide a constant time complexity of O(1). For this, we first allocate the memory for a new node, then check for two edge cases as follows:

- If the list is empty, i.e. head is null or in the case of Crystal, nil, make the head point to the new node instead.
- If the list is not empty, i.e. head already points to some node, make the new node pointer point to that node, and then make head point to the new one.

All that can be implemented in a function as follows:

# add a node to the list
def add_node(data : Int32) : Pointer(Node)?
  new : Pointer(Node)? = nil

  # two cases:
  # if the list is empty
  if Globals.head == nil
    new = Pointer(Node).malloc(sizeof(Node))

    return nil if new == nil

    # set the head to point to the new node
    new.value.data = data
    Globals.set_head(new)
    new.value.nxt = nil
    # if list is not empty
  else
    new = Pointer(Node).malloc(sizeof(Node))

    return nil if new == nil

    # set the new node pointer to point to the existing head, then make the head point to it
    new.value.data = data
    new.value.nxt = Globals.head
    Globals.set_head(new)
  end

  return new
end

We then add the necessary code into the case handler to run the function via the UI.

# ...
when 1
  # add operation
  puts "What data should I insert?"
  data_to_insert = uninitialized Int32

  loop do
    begin
      data_to_insert = gets(chomp: true).to_s.to_i
    rescue
      puts "Data must be a 32-bit integer. Try again!"
    else
      break
    end
  end

  new : Pointer(Node)? = add_node(data_to_insert)
when 2
# ...

Note the use of the loop and the begin block. I did that in order to handle cases when a non-integer value was inputted, otherwise the program would just crash.

Easy!

removing a node

Next, removing a node.

To remove a node, we need to remove the link that the previous node has with it. We need to make it so that the link points to the element after the one that we are removing, effectively making the node inaccessible. After that, we free the memory of that node.

In code, it would be implemented as such:

# remove a node from the list
def remove_node(data : Int32) : Int32
  # set current and previous nodes as head
  current : Pointer(Node)? = Globals.head
  prev : Pointer(Node)? = Globals.head

  # loop while the current and previous nodes are not nil
  while current && prev
    if current.value.data == data
      # if current node is the list head
      if current == Globals.head
        Globals.set_head(current.value.nxt)
        # if current node is not list head
      else
        prev.value.nxt = current.value.nxt
        # free the memory for current at this point
      end

      return 0 # found the element
    end

    # move each pointer to their next one after every iteration
    prev = current
    current = current.value.nxt
  end

  return 1 # element not found
end

This function returns a 0 if the node was found and removed, and returns 1 if it wasn't found. This helps in handling of the function.

Do note that if you're using C or any other language without a garbage collector, you need to free the memory for the removed node to prevent a memory leak. Crystal has a garbage collector, so that's not necessary here.

We then create the handler for the function:

# ...
when 2
  # remove operation
  puts "What data should I remove?"
  data_to_remove = uninitialized Int32

  loop do
    begin
      data_to_remove = gets(chomp: true).to_s.to_i
    rescue
      puts "Data must be a 32-bit integer. Try again!"
    else
      break
    end
  end

  return_value = remove_node(data_to_remove)

  if return_value == 1
    puts "Element not found"
  end
when 3
# ...

That's it!

inserting a node

By inserting a node, we mean putting a node in between two existing ones.

Let's call the new node N. Say, that the linked list we currently have has three nodes A, B and C with indexes 0, 1 and 2 as such:

A:0 -> B:1 -> C:2

If N is going to be inserted at position 1, we will insert it in front of B, and then cut the current link between B and C such that the list becomes this:

A:0 -> B:1 -> N:2 -> C:3

This would be implemented in code as follows:

# insert a node to a position in the list
def insert_node(data : Int32, position : Int32) : Pointer(Node)?
  # set head as current node
  current = Globals.head

  # check if the position is too far into the list
  while current && position != 0
    position -= 1
    current = current.value.nxt
  end

  if position != 0
    puts "Requested position is too far into the list"
    return nil
  end

  # if the position is in the list, continue as such:
  new : Pointer(Node)? = Pointer(Node).malloc(sizeof(Node))

  return nil if new == nil

  if current
    new.value.data = data
    new.value.nxt = current.value.nxt
    current.value.nxt = new
  end

  return new
end

We return the new node if the insertion succeeded, and return nil if it didn't, possibly because of the position being too high.

We handle the function as follows:

# ...
when 3
  # insert operation
  puts "What data should I insert?"
  data_to_insert = uninitialized Int32
  position = uninitialized Int32

  loop do
    begin
      data_to_insert = gets(chomp: true).to_s.to_i
    rescue
      puts "Data must be a 32-bit integer. Try again!"
    else
      break
    end
  end

  puts "What position?"
  loop do
    begin
      position = gets(chomp: true).to_s.to_i
    rescue
      puts "Position must be a 32-bit integer. Try again!"
    else
      break
    end
  end

  new = insert_node(data_to_insert, position)

  if new == nil
    puts "Failed to insert into list."
  end
when 4
# ...

And we're done!

printing the list

Don't forget to do this! For this, simply loop over the list and print each node's data.

# print out the list
def print_list
  current : Pointer(Node)? = Globals.head

  while current
    print "#{current.value.data}->"
    current = current.value.nxt
  end

  puts ""
end

Handle it in the case block:

# ...
when 4
  # print the list
  print_list
when 5
# ...

And we're done! Run the program and check out this fancy new data structure you've just learned about.

If you're still not sure, you can check out the GitHub Gist for this program.

switching to lazy.nvim

Sun, 10 Mar 2024 00:00:00 GMT

Been a long time since I posted anything! Well, here I am now, bringing you the story of how I finally decided to drink the Kool-Aid by switching to lazy.nvim from packer.

If you didn't know yet, yes I use neovim. Some might claim I'm using it just to look cool, and to be honest I can't really refute that. Regardless, once I got used to it I realized there was much more to it than just looking like a CIA hacker. The efficiency and sheer speed boost you get from switching is incredible, but I digress. We're here to talk about my package manager switch.

beginnings with packer

When I first started using neovim for real, I watched a video by ThePrimeagen where he sets up a nice neovim config using packer with lsp, treesitter, you name it. The configuration was great, I set it up for myself and changed up a few things as per my needs. It served me well for a long time, and there wasn't no issue in particular with it, so one could argue, "why would you need to switch to lazy in the first place?"

Apparently, lazy is much faster than packer, and it also has a nice UI along with a lockfile system to ensure that your configs don't get messed up if you switch your device. Those three points were enough to make me switch. Additionally, packer is not being maintained anymore (which is something I only just realized), so that's another reason to switch.

getting started

First thing I did was create a lazy.lua file replacing the original packer.lua to place the plugin information in. It begins with this bit of bootstrapping code from the lazy.nvim readme:

local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "https://github.com/folke/lazy.nvim.git",
    "--branch=stable", -- latest stable release
    lazypath,
  })
end
vim.opt.rtp:prepend(lazypath)

The bootstrapper will ensure that you don't have to reinstall lazy again if you're on a new system, since it will reinstall itself from here.

I followed this with all of my plugins:

require("lazy").setup({
    -- plugins here...
    -- for example
    "jiangmiao/auto-pairs",

    -- or for more advanced configuration...
    {
        "nvim-lualine/lualine.nvim",
        dependencies = { "nvim-tree/nvim-web-devicons" }
    },
})

The configuration for adding a plugin is not much different in packer and lazy, usually its just some different words. You can check out this portion of the lazy.nvim readme for more information about which packer command is which in lazy, or you can check out my own configuration as a reference.

lazy loading

One of the best things about lazy.nvim is in its name; it can load plugins lazily to improve performance. You can set it so that certain plugins only load when they are needed in the editor. To do this all you need to do is set lazy to true when adding a plugin:

{
    "nvim-telescope/telescope.nvim", tag = "0.1.5",
    dependencies = { "nvim-lua/plenary.nvim" },
    lazy = true,
}

Another useful option is to set the plugin to load only after a certain event occurs. For instance, you can set GitHub Copilot to only load after you enter insert mode:

{
    "zbirenbaum/copilot.lua",
    event = "InsertEnter",
}

There's also a VeryLazy option that apparently only loads a plugin once neovim is fully loaded, but I haven't tried that out yet.

plugin structuring

According to the readme for lazy, structuring for plugins can be done by using a Lua module with various files for each module. This is pretty nice since to add new plugin files all you need to do is add a new file. As I'm adapting ThePrimeagen's setup where he put all his plugin configuration in the nvim/after folder and it still works with lazy, I don't see the need to do this myself. Perhaps there's better performance or something of that sort, maybe someone can let me know in the comments.

super slow startups

After I had set up whatever I had to in lazy and opened neovim with it for the first time, the startup time seemed to have changed. And not in a good way. In fact, on checking startup times and comparing with packer's, I discovered something horrific.

Lazy was making neovim load many, many times slower than packer.

On checking the startup times, neovim loaded in 65 milliseconds with packer. But with lazy, it took a ridiculous 1021 (!) milliseconds to load!

Upon further research, I found that for some reason nvim-treesitter was causing the issue. While I tried to figure out how to fix it, eventually the problem just fixed itself. That was a weird one.

get rid of packer remnants

One thing that would be good to not forget to do is getting rid of remnants of packer. If you run :checkhealth lazy in neovim, you can see that it will tell you to get rid of the packer_compiled.lua file and the packer files. Just a little detail to remember.

conclusion

Well, despite the really weird stuff happening at first, switching to lazy was... pretty easy! I'm not really sure why I was avoiding it so much so far. I think it's really nice, and at the end of the day, I did get a performance boost! With packer, as I stated before it took neovim 65 milliseconds to load, but now with lazy, I got it down to 46. Not a lot, but it's an improvement! Perhaps I might be able to get it down even further later on as I keep using it, since I've seen people load neovim in less than 20 milliseconds with a lot more plugins than I'm using. Hopefully I can figure out some ways to get that to happen.

pes18fan's posts

achieving true zen pt. 1: everything is an expression

But why?

How exactly is it done?

Sequence expressions

if/switch

about nil

blocks

while/for/for-in

var/val

func

print

break/continue/return/exit

discard

Things that don't make sense now

Some things I traded off

converting AD to Bikram Sambat

initial steps

getting the year

getting the month and day

conclusion

Making brightness work on Linux

Using btrfs snapshots

So what happened yesterday?

How I could have fixed it easily

Automating it

Restoring backups

hello

getting rid of semicolons

meet Kaze

no semis? how?

how do you do it, Lua?

return statements

how to singly linked list??? (in Crystal)

humble beginnings

user interface

functions

adding a node

removing a node

inserting a node

printing the list

switching to lazy.nvim

beginnings with packer

getting started

lazy loading

plugin structuring

super slow startups

get rid of packer remnants

conclusion

about `nil`