From 933dcc83aca1b035737d9a54aee61535af64ba45 Mon Sep 17 00:00:00 2001 From: Matej Focko Date: Sun, 1 Jan 2023 22:42:05 +0100 Subject: [PATCH] blog(aoc-2022): fix typos Signed-off-by: Matej Focko --- blog/aoc-2022/01-week-1.md | 16 ++++++++-------- blog/aoc-2022/02-week-2.md | 8 ++++---- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/blog/aoc-2022/01-week-1.md b/blog/aoc-2022/01-week-1.md index de517a6..6e111c6 100644 --- a/blog/aoc-2022/01-week-1.md +++ b/blog/aoc-2022/01-week-1.md @@ -227,7 +227,7 @@ It may seem as a very weird decision, but in fact it makes some sense… It allo you to do intersection of items that may not be possible to copy. Overall this is a „tax“ for having a borrow checker ~~drilling your ass~~ having your back and making sure you're not doing something naughty that may cause an **undefined** -**behaviour**. +**behavior**. ::: @@ -328,7 +328,7 @@ A lot of different approaches, knowing that we are dealing with input consisting solely of ASCII letters, I bit the bullet and went with sliding window and constructing sets from that window, checking if the set is as big as the window. -One possible optimization could consist of keeping a bitvector (i.e. `usize` +One possible optimization could consist of keeping a bit-vector (i.e. `usize` variable) of encountered characters and updating it as we go. However this has a different issue and that is removal of the characters from the left side of the window. We don't know if the same character is not included later on. @@ -341,7 +341,7 @@ of 26 elements that keeps count for each lowercase letter. :::info tl;dr -Let's simulate [`du`] to get some stats about our filesystem and then pinpoint +Let's simulate [`du`] to get some stats about our file system and then pinpoint directories that take a lot of space and should be deleted. ::: @@ -351,7 +351,7 @@ directories that take a lot of space and should be deleted. ### Solution -We need to „_build_“ a filesystem from the input that is given in a following form: +We need to „_build_“ a file system from the input that is given in a following form: ``` $ cd / $ ls @@ -401,7 +401,7 @@ Then I looked up some implementations of trees or linked lists and decided to tr `Box` represents a dynamically allocated memory on heap. It is a single pointer, you can imagine this as `std::unique_ptr` in C++. -`Rc` represents a dynamically allocated mmemory on heap. On top of that it is +`Rc` represents a dynamically allocated memory on heap. On top of that it is _reference counted_ (that's what the `Rc` stands for). You can imagine this as `std::shared_ptr` in C++. @@ -419,7 +419,7 @@ to have `Rc>`. ::: -So, how are we going to represent the filesystem then? We will use an enumeration, +So, how are we going to represent the file system then? We will use an enumeration, hehe, which is an algebraic data type that can store some stuff in itself :weary: ```rust type FileHandle = Rc>; @@ -443,7 +443,7 @@ Now to the fun part! `AocFile` value can be represented in two ways: contain map matching the name of the files (or directories) within to their respective file handles -I will omit the details about constructing this filesystem, cause there are a lot +I will omit the details about constructing this file system, cause there are a lot of technicalities introduced by the nature of the input. However if you are interested, you can have a look at my solution. @@ -466,7 +466,7 @@ solution. One of the more exotic options would be precomputing the required information at the same time as parsing. That could be done by adding additional fields to the nodes which would allow storing such information and updating it as we construct -the filesystem. +the file system. ## Post Mortem diff --git a/blog/aoc-2022/02-week-2.md b/blog/aoc-2022/02-week-2.md index fa3364d..88f6fba 100644 --- a/blog/aoc-2022/02-week-2.md +++ b/blog/aoc-2022/02-week-2.md @@ -93,7 +93,7 @@ them both to `usize` type that can be used later on for indexing. The type signature of the function is where the fun is at :wink: We are trying to convert unknown type to `usize`, so we must bound the `T` as a type that can be converted to `usize`, that's how we got `usize: TryFrom` which basically -says that `usize` must implement `TryFrom` trait vand therefore allows us to +says that `usize` must implement `TryFrom` trait and therefore allows us to convert the indices to actual `usize` indices. Using `.unwrap()` also forces us to bound the error that can occur when converting `T` into `usize`, that's how we get `>::Error: Debug` which loosely means @@ -107,7 +107,7 @@ And now we are left only with the first line of the definition. :::note -Skilled Rustaceans might notice that this implemention is rather flaky and can +Skilled Rustaceans might notice that this implementation is rather flaky and can break in multiple places at once. I'll get back to it… ::: @@ -358,7 +358,7 @@ where ``` This is all part of the `Solution` trait, which can implement methods while being -dependant on what is provided by the implementing types. In this case, we just +dependent on what is provided by the implementing types. In this case, we just need to bound the `Output` type to implement `Display` that is necessary for the `info!` and format string there. @@ -589,7 +589,7 @@ also rolling down the hill… As I have said in the _tl;dr_, we are looking for the shortest path, but the start and goal differ for the part 1 and 2. So I have decided to refactor my solution -to a BFS algorithm that takes neccessary parameters via functions: +to a BFS algorithm that takes necessary parameters via functions: ```rust fn bfs( graph: &[Vec], start: &Position, has_edge: F, is_target: G