mirror of
https://github.com/mfocko/blog.git
synced 2024-11-10 08:19:07 +01:00
blog(aoc-2022): add initro
Signed-off-by: Matej Focko <mfocko@redhat.com>
This commit is contained in:
parent
5aeeb1142f
commit
9019b2809d
1 changed files with 364 additions and 0 deletions
364
blog/aoc-2022/00-intro.md
Normal file
364
blog/aoc-2022/00-intro.md
Normal file
|
@ -0,0 +1,364 @@
|
||||||
|
---
|
||||||
|
title: Advent of Code '22 in Rust
|
||||||
|
description: Preparing for Advent of Code '22.
|
||||||
|
date: 2022-12-14T21:45
|
||||||
|
slug: aoc-2022/intro
|
||||||
|
authors:
|
||||||
|
- name: Matej Focko
|
||||||
|
title: "a.k.a. @mf"
|
||||||
|
url: https://gitlab.com/mfocko
|
||||||
|
image_url: https://github.com/mfocko.png
|
||||||
|
tags:
|
||||||
|
- aoc-2022
|
||||||
|
- advent-of-code
|
||||||
|
- rust
|
||||||
|
hide_table_of_contents: false
|
||||||
|
---
|
||||||
|
|
||||||
|
Let's talk about the preparations for this year's [_Advent of Code_].
|
||||||
|
|
||||||
|
<!--truncate-->
|
||||||
|
|
||||||
|
## Choosing a language
|
||||||
|
|
||||||
|
When choosing a language for AoC, you usually want a language that gives you a
|
||||||
|
quick feedback which allows you to iterate quickly to the solution of the puzzle.
|
||||||
|
One of the most common choices is Python, many people also use JavaScript or Ruby.
|
||||||
|
|
||||||
|
Given the competitive nature of the AoC and popularity among competitive programming,
|
||||||
|
C++ might be also a very good choice. Only if you are familiar with it, I guess…
|
||||||
|
|
||||||
|
If you want a challenge, you might also choose to rotate the languages each day.
|
||||||
|
Though I prefer to use only one language.
|
||||||
|
|
||||||
|
For this year I have been deciding between _Rust_, _C++_ and _Pascal_ or _Ada_.
|
||||||
|
|
||||||
|
I have tried Rust last year and have survived with it for 3 days and then gave
|
||||||
|
up and switched to _Kotlin_, which was pretty good given it is „Java undercover“.
|
||||||
|
I pretty much like the ideas behind Rust, I am not sure about the whole cult and
|
||||||
|
implementation of those ideas though. After some years with C/C++, I would say
|
||||||
|
that Rust feels _too safe_ for my taste and tries to „_punish me_“ even for the
|
||||||
|
most trivial things.
|
||||||
|
|
||||||
|
C++ is a very robust, but also comes with a wide variety of options providing you
|
||||||
|
the ability to shoot yourself in the leg. I have tried to solve few days of previous
|
||||||
|
Advent of Code events, it was _relatively easy_ to solve the problems in C++, given
|
||||||
|
that I do not admit writing my own iterator for `enumerate`…
|
||||||
|
|
||||||
|
Pascal or Ada were meme choices :) Ada is heavily inspired by Pascal and has a
|
||||||
|
pretty nice standard library that offers enough to be able to quickly solve some
|
||||||
|
problems in it. However the toolkit is questionable :/
|
||||||
|
|
||||||
|
## Choosing libraries
|
||||||
|
|
||||||
|
## Preparations for Rust
|
||||||
|
|
||||||
|
All of the sources, later on including solutions, can be found at my
|
||||||
|
[GitLab].
|
||||||
|
|
||||||
|
### Toolkit
|
||||||
|
|
||||||
|
Since we are using Rust, we are going to use a [Cargo] and more than likely VSCode
|
||||||
|
with [`rust-analyzer`]. Because of my choice of libraries, we will also introduce
|
||||||
|
a `.envrc` file that can be used by [`direnv`], which allows you to set specific
|
||||||
|
environment variables when you enter a directory. In our case, we will use
|
||||||
|
```bash
|
||||||
|
# to show nice backtrace when using the color-eyre
|
||||||
|
export RUST_BACKTRACE=1
|
||||||
|
|
||||||
|
# to catch logs generated by tracing
|
||||||
|
export RUST_LOG=trace
|
||||||
|
```
|
||||||
|
|
||||||
|
And for the one of the most obnoxious things ever, we will use a script to download
|
||||||
|
the inputs instead of „_clicking, opening and copying to a file_“[^1]. There is
|
||||||
|
no need to be _fancy_, so we will adjust Python script by Martin[^2].
|
||||||
|
```py
|
||||||
|
#!/usr/bin/env python3
|
||||||
|
|
||||||
|
import datetime
|
||||||
|
import yaml
|
||||||
|
import requests
|
||||||
|
import sys
|
||||||
|
|
||||||
|
|
||||||
|
def load_config():
|
||||||
|
with open("env.yaml", "r") as f:
|
||||||
|
js = yaml.load(f, Loader=yaml.Loader)
|
||||||
|
return js["session"], js["year"]
|
||||||
|
|
||||||
|
|
||||||
|
def get_input(session, year, day):
|
||||||
|
return requests.get(
|
||||||
|
f"https://adventofcode.com/{year}/day/{day}/input",
|
||||||
|
cookies={"session": session},
|
||||||
|
headers={
|
||||||
|
"User-Agent": "{repo} by {mail}".format(
|
||||||
|
repo="gitlab.com/mfocko/advent-of-code-2022",
|
||||||
|
mail="me@mfocko.xyz",
|
||||||
|
)
|
||||||
|
},
|
||||||
|
).content.decode("utf-8")
|
||||||
|
|
||||||
|
|
||||||
|
def main():
|
||||||
|
day = datetime.datetime.now().day
|
||||||
|
if len(sys.argv) == 2:
|
||||||
|
day = sys.argv[1]
|
||||||
|
|
||||||
|
session, year = load_config()
|
||||||
|
problem_input = get_input(session, year, day)
|
||||||
|
|
||||||
|
with open(f"./inputs/day{day:>02}.txt", "w") as f:
|
||||||
|
f.write(problem_input)
|
||||||
|
|
||||||
|
|
||||||
|
if __name__ == "__main__":
|
||||||
|
main()
|
||||||
|
```
|
||||||
|
|
||||||
|
If the script is called without any arguments, it will deduce the day from the
|
||||||
|
system, so we do not need to change the day every morning. It also requires a
|
||||||
|
configuration file:
|
||||||
|
```yaml
|
||||||
|
# env.yaml
|
||||||
|
session: ‹your session cookie›
|
||||||
|
year: 2022
|
||||||
|
```
|
||||||
|
|
||||||
|
### Libraries
|
||||||
|
|
||||||
|
Looking at the list of the libraries, I have chosen „a lot“ of them. Let's walk
|
||||||
|
through each of them.
|
||||||
|
|
||||||
|
[`tracing`] and [`tracing-subscriber`] are the crates that can be used for tracing
|
||||||
|
and logging of your Rust programs, there are also other crates that can help you
|
||||||
|
with providing backtrace to the Sentry in case you have deployed your application
|
||||||
|
somewhere and you want to watch over it. In our use case we will just utilize the
|
||||||
|
macros for debugging in the terminal.
|
||||||
|
|
||||||
|
[`thiserror`], [`anyhow`] and [`color-eyre`] are used for error reporting.
|
||||||
|
`thiserror` is a very good choice for libraries, cause it extends the `Error`
|
||||||
|
from the `std` and allows you to create more convenient error types. Next is
|
||||||
|
`anyhow` which kinda builds on top of the `thiserror` and provides you with simpler
|
||||||
|
error handling in binaries[^3]. And finally we have `color-eyre` which, as I found
|
||||||
|
out later, is a colorful (_wink wink_) extension of `eyre` which is fork of `anyhow`
|
||||||
|
while supporting customized reports.
|
||||||
|
|
||||||
|
In the end I have decided to remove `thiserror` and `anyhow`, since first one is
|
||||||
|
suitable for libraries and the latter was basically fully replaced by `{color-,}eyre`.
|
||||||
|
|
||||||
|
[`regex`] and [`lazy_static`] are a very good and also, I hope, self-explanatory
|
||||||
|
combination. `lazy_static` allows you to have static variables that must be initialized
|
||||||
|
during runtime.
|
||||||
|
|
||||||
|
[`itertools`] provides some nice extensions to the iterators from the `std`.
|
||||||
|
|
||||||
|
### My own „library“
|
||||||
|
|
||||||
|
When creating the crate for this year's Advent of Code, I have chosen a library
|
||||||
|
type. Even though standard library is huge, some things might not be included and
|
||||||
|
also we can follow _KISS_. I have 2 modules that my „library“ exports, one for
|
||||||
|
parsing and one for 2D vector (that gets used quite often during Advent of Code).
|
||||||
|
|
||||||
|
Key part is, of course, processing the input and my library exports following
|
||||||
|
functions that get used a lot:
|
||||||
|
```rust
|
||||||
|
/// Reads file to the string.
|
||||||
|
pub fn file_to_string<P: AsRef<Path>>(pathname: P) -> String;
|
||||||
|
|
||||||
|
/// Reads file and returns it as a vector of characters.
|
||||||
|
pub fn file_to_chars<P: AsRef<Path>>(pathname: P) -> Vec<char>;
|
||||||
|
|
||||||
|
/// Reads file and returns a vector of parsed structures. Expects each structure
|
||||||
|
/// on its own line in the file. And `T` needs to implement `FromStr` trait.
|
||||||
|
pub fn file_to_structs<P: AsRef<Path>, T: FromStr>(pathname: P) -> Vec<T>
|
||||||
|
where
|
||||||
|
<T as FromStr>::Err: Debug;
|
||||||
|
|
||||||
|
/// Converts iterator over strings to a vector of parsed structures. `T` needs
|
||||||
|
/// to implement `FromStr` trait and its error must derive `Debug` trait.
|
||||||
|
pub fn strings_to_structs<T: FromStr, U>(
|
||||||
|
iter: impl Iterator<Item = U>
|
||||||
|
) -> Vec<T>
|
||||||
|
where
|
||||||
|
<T as std::str::FromStr>::Err: std::fmt::Debug,
|
||||||
|
U: Deref<Target = str>;
|
||||||
|
|
||||||
|
/// Reads file and returns it as a vector of its lines.
|
||||||
|
pub fn file_to_lines<P: AsRef<Path>>(pathname: P) -> Vec<String>;
|
||||||
|
```
|
||||||
|
|
||||||
|
As for the vector, I went with a rather simple implementation that allows only
|
||||||
|
addition of the vectors for now and accessing the elements via functions `x()`
|
||||||
|
and `y()`. Also the vector is generic, so we can use it with any numeric type we
|
||||||
|
need.
|
||||||
|
|
||||||
|
### Skeleton
|
||||||
|
|
||||||
|
We can also prepare a template to quickly bootstrap each of the days. We know
|
||||||
|
that each puzzle has 2 parts, which means that we can start with 2 functions that
|
||||||
|
will solve them.
|
||||||
|
```rust
|
||||||
|
fn part1(input: &Input) -> Output {
|
||||||
|
todo!()
|
||||||
|
}
|
||||||
|
|
||||||
|
fn part2(input: &Input) -> Output {
|
||||||
|
todo!()
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Both functions take reference to the input and return some output (in majority
|
||||||
|
of puzzles, it is the same type). `todo!()` can be used as a nice placeholder,
|
||||||
|
it also causes a panic when reached and we could also provide some string with
|
||||||
|
an explanation, e.g. `todo!("part 1")`. We have not given functions a specific
|
||||||
|
type and to avoid as much copy-paste as possible, we will introduce type aliases.
|
||||||
|
```rust
|
||||||
|
type Input = String;
|
||||||
|
type Output = i32;
|
||||||
|
```
|
||||||
|
|
||||||
|
:::tip
|
||||||
|
|
||||||
|
This allows us to quickly adjust the types only in one place without the need to
|
||||||
|
do _regex-replace_ or replace them manually.
|
||||||
|
|
||||||
|
:::
|
||||||
|
|
||||||
|
For each day we get a personalized input that is provided as a text file. Almost
|
||||||
|
all the time, we would like to get some structured type out of that input, and
|
||||||
|
therefore it makes sense to introduce a new function that will provide the parsing
|
||||||
|
of the input.
|
||||||
|
```rust
|
||||||
|
fn parse_input(path: &str) -> Input {
|
||||||
|
todo!()
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
This „parser“ will take a path to the file, just in case we would like to run the
|
||||||
|
sample instead of input.
|
||||||
|
|
||||||
|
OK, so now we can write a `main` function that will take all of the pieces and
|
||||||
|
run them.
|
||||||
|
```rust
|
||||||
|
fn main() {
|
||||||
|
let input = parse_input("inputs/dayXX.txt");
|
||||||
|
|
||||||
|
println!("Part 1: {}", part_1(&input));
|
||||||
|
println!("Part 2: {}", part_2(&input));
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
This would definitely do :) But we have installed a few libraries and we want to
|
||||||
|
use them. In this part we are going to utilize _[`tracing`]_ (for tracing, duh…)
|
||||||
|
and _[`color-eyre`]_ (for better error reporting, e.g. from parsing).
|
||||||
|
```rust
|
||||||
|
fn main() -> Result<()> {
|
||||||
|
tracing_subscriber::fmt()
|
||||||
|
.with_env_filter(EnvFilter::from_default_env())
|
||||||
|
.with_target(false)
|
||||||
|
.with_file(true)
|
||||||
|
.with_line_number(true)
|
||||||
|
.without_time()
|
||||||
|
.compact()
|
||||||
|
.init();
|
||||||
|
color_eyre::install()?;
|
||||||
|
|
||||||
|
let input = parse_input("inputs/dayXX.txt");
|
||||||
|
|
||||||
|
info!("Part 1: {}", part_1(&input));
|
||||||
|
info!("Part 2: {}", part_2(&input));
|
||||||
|
|
||||||
|
Ok(())
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
The first statement will set up tracing and configure it to print out the logs to
|
||||||
|
terminal, based on the environment variable. We also change the formatting a bit,
|
||||||
|
since we do not need all the _fancy_ features of the logger. Pure initialization
|
||||||
|
would get us logs like this:
|
||||||
|
```
|
||||||
|
2022-12-11T19:53:19.975343Z INFO day01: Part 1: 0
|
||||||
|
```
|
||||||
|
|
||||||
|
However after running that command, we will get the following:
|
||||||
|
```
|
||||||
|
INFO src/bin/day01.rs:35: Part 1: 0
|
||||||
|
```
|
||||||
|
|
||||||
|
And the `color_eyre::install()?` is quite straightforward. We just initialize the
|
||||||
|
error reporting by _color eyre_.
|
||||||
|
|
||||||
|
:::caution
|
||||||
|
|
||||||
|
Notice that we had to add `Ok(())` to the end of the function and adjust the
|
||||||
|
return type of the `main` to `Result<()>`. It is caused by the _color eyre_ that
|
||||||
|
can be installed only once and therefore it can fail, that is how we got the `?`
|
||||||
|
at the end of the `::install` which _unwraps_ the **»result«** of the installation.
|
||||||
|
|
||||||
|
:::
|
||||||
|
|
||||||
|
Overall we will get to a template like this:
|
||||||
|
```rust
|
||||||
|
use aoc_2022::*;
|
||||||
|
|
||||||
|
use color_eyre::eyre::Result;
|
||||||
|
use tracing::info;
|
||||||
|
use tracing_subscriber::EnvFilter;
|
||||||
|
|
||||||
|
type Input = String;
|
||||||
|
type Output = i32;
|
||||||
|
|
||||||
|
fn parse_input(path: &str) -> Input {
|
||||||
|
todo!()
|
||||||
|
}
|
||||||
|
|
||||||
|
fn part1(input: &Input) -> Output {
|
||||||
|
todo!()
|
||||||
|
}
|
||||||
|
|
||||||
|
fn part2(input: &Input) -> Output {
|
||||||
|
todo!()
|
||||||
|
}
|
||||||
|
|
||||||
|
fn main() -> Result<()> {
|
||||||
|
tracing_subscriber::fmt()
|
||||||
|
.with_env_filter(EnvFilter::from_default_env())
|
||||||
|
.with_target(false)
|
||||||
|
.with_file(true)
|
||||||
|
.with_line_number(true)
|
||||||
|
.without_time()
|
||||||
|
.compact()
|
||||||
|
.init();
|
||||||
|
color_eyre::install()?;
|
||||||
|
|
||||||
|
let input = parse_input("inputs/dayXX.txt");
|
||||||
|
|
||||||
|
info!("Part 1: {}", part_1(&input));
|
||||||
|
info!("Part 2: {}", part_2(&input));
|
||||||
|
|
||||||
|
Ok(())
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
[^1]: Copy-pasting might be a relaxing thing to do, but you can also discover
|
||||||
|
nasty stuff about your PC. See [this Reddit post and the comment].
|
||||||
|
[^2]: [GitHub profile](https://github.com/martinjonas)
|
||||||
|
[^3]: Even though you can use it even for libraries, but handling errors from
|
||||||
|
libraries using `anyhow` is nasty… You will be the stinky one ;)
|
||||||
|
|
||||||
|
[_Advent of Code_]: https://adventofcode.com
|
||||||
|
[GitLab]: https://gitlab.com/mfocko/advent-of-code-2022
|
||||||
|
[Cargo]: https://doc.rust-lang.org/cargo/
|
||||||
|
[`rust-analyzer`]: https://rust-analyzer.github.io/
|
||||||
|
[`direnv`]: https://direnv.net/
|
||||||
|
[`tracing`]: https://crates.io/crates/tracing
|
||||||
|
[`tracing-subscriber`]: https://crates.io/crates/tracing-subscriber
|
||||||
|
[`thiserror`]: https://crates.io/crates/thiserror
|
||||||
|
[`anyhow`]: https://crates.io/crates/anyhow
|
||||||
|
[`color-eyre`]: https://crates.io/crates/color-eyre
|
||||||
|
[`regex`]: https://crates.io/crates/regex
|
||||||
|
[`lazy_static`]: https://crates.io/crates/lazy_static
|
||||||
|
[`itertools`]: https://crates.io/crates/itertools
|
||||||
|
[this Reddit post and the comment]: https://www.reddit.com/r/adventofcode/comments/zb98pn/comment/iyq0ono
|
Loading…
Reference in a new issue