mirror of
https://github.com/mfocko/blog.git
synced 2024-11-09 15:59:06 +01:00
chore: upgrade docusaurus and deps
Signed-off-by: Matej Focko <me@mfocko.xyz>
This commit is contained in:
parent
64a520eca5
commit
2d11a9dc27
21 changed files with 1528 additions and 346 deletions
|
@ -232,7 +232,7 @@ Since it might seem a bit scary, I will disect it by parts.
|
|||
|
||||
We pass to the sorting function **copy** of the numbers we got, this ensures that once we are checking the more strict postcondition, we can gather the necessary information even after sorting the list in-situ, i.e. we can check if the `result` is really a `permutation` of the `numbers` even though the sorting functions has modified the passed in list.
|
||||
|
||||
:::caution
|
||||
:::warning[caution]
|
||||
|
||||
Now we get to the more complicated part and it is the _decorators_.
|
||||
|
||||
|
|
|
@ -49,7 +49,7 @@ You can control the robot using the following interface:
|
|||
- `robot.left_is_clear()` — to check if you can step to the left
|
||||
- analogically for `front` and `right`
|
||||
|
||||
:::caution
|
||||
:::warning[caution]
|
||||
|
||||
Helper functions / procedures are allowed. Return values are allowed.
|
||||
|
||||
|
|
|
@ -140,7 +140,7 @@ If you wonder why, I'll try to describe it intuitively:
|
|||
binary tree of height `y`, in each node we do some work in constant time,
|
||||
therefore we can just sum the ones.
|
||||
|
||||
:::warning
|
||||
:::danger
|
||||
|
||||
It would've been more complicated to get an exact result. In the equation above
|
||||
we are assuming that the width of the pyramid is bound by the height.
|
||||
|
|
|
@ -126,7 +126,7 @@ the pyramid:
|
|||
it will be interleaved with the next step, therefore it is easier to keep the
|
||||
retrievals in the following point.
|
||||
|
||||
:::caution
|
||||
:::warning[caution]
|
||||
|
||||
You might have noticed it's still not that easy, cause we're not having full
|
||||
cache right from the beginning, but the sum of those logarithms cannot be
|
||||
|
@ -141,7 +141,7 @@ the pyramid:
|
|||
2. We retrieve it from the cache. Same as in first point, but only twice, so we
|
||||
get $2 \cdot \log_2{n}$.
|
||||
|
||||
:::caution
|
||||
:::warning[caution]
|
||||
|
||||
It's done twice because of the `.containsKey()` in the `if` condition.
|
||||
|
||||
|
@ -233,7 +233,7 @@ $$
|
|||
\sum_{y=0}^{\mathtt{pyramid.length} - 1} \mathtt{pyramid}\left[y\right]\mathtt{.length}
|
||||
$$
|
||||
|
||||
:::caution
|
||||
:::warning[caution]
|
||||
|
||||
If you're wondering whether it's correct because of the second `if` in our
|
||||
function, your guess is right. However we are expressing the complexity in the
|
||||
|
|
|
@ -70,7 +70,7 @@ Slide down in this case is equal to `1074`.
|
|||
|
||||
## Solving the problem
|
||||
|
||||
:::caution
|
||||
:::warning[caution]
|
||||
|
||||
I will describe the following ways you can approach this problem and implement
|
||||
them in _Java_[^1].
|
||||
|
|
|
@ -187,7 +187,7 @@ as it should be. However, there is one difference. Second path no longer satisfi
|
|||
the condition of a _leaf_. Technically it relaxes the 5th rule, because we leave
|
||||
out some of the nodes. We should probably avoid that.
|
||||
|
||||
:::caution
|
||||
:::warning[caution]
|
||||
|
||||
With the second idea, you may also feel that we are “bending” the rules a bit,
|
||||
especially the definition of the “leaf” nodes.
|
||||
|
|
|
@ -64,7 +64,7 @@ And then follow up on that with the actual backstory from Dijkstra himself:
|
|||
> — Edsger Dijkstra, in an interview with Philip L. Frana, Communications of the
|
||||
> ACM, 2001
|
||||
|
||||
:::caution Precondition
|
||||
:::warning Precondition
|
||||
|
||||
As our own naïve algorithm, Dijkstra's algorithm has a precondition that places
|
||||
a requirement of _no edges with negative weights_ in the graph. This
|
||||
|
|
|
@ -32,7 +32,7 @@ Let's be honest here, majority of the checks rely on the static analysis, cause
|
|||
you can't do anything else during the compile-time, right? Therefore we can
|
||||
basically say that we are relying on the compiler to “solve” all of our issues.
|
||||
|
||||
:::warning
|
||||
:::danger
|
||||
|
||||
I'm not doubting the fact that compiler can prevent **a lot** of the memory
|
||||
errors, I'm just saying it's not realistic to cover **everything**.
|
||||
|
@ -249,7 +249,7 @@ just worse for me, part of this post may be also influenced by this fact.
|
|||
|
||||
### Rust in Linux
|
||||
|
||||
:::caution
|
||||
:::warning[caution]
|
||||
|
||||
As someone who has seen the way Linux kernel is built in the RHEL ecosystem, how
|
||||
complex the whole thing is and how much resources you need to proceed, I have
|
||||
|
|
|
@ -25,7 +25,7 @@ This post is inspired/triggered by the following Mastodon post:
|
|||
|
||||
<!--truncate-->
|
||||
|
||||
:::caution Disclaimer
|
||||
:::warning Disclaimer
|
||||
|
||||
You may take my opinion with a grain of salt, since I'm affiliated with Red Hat,
|
||||
but at the same time I've also seen the other side of the fence, so I know how
|
||||
|
@ -175,7 +175,7 @@ that contain packages. The way you go around this is rather simple, you choose
|
|||
some set of _critical_ packages that you guarantee support for (like Linux
|
||||
kernel, openSSL, etc.) and maintain those with all the QA processes in place.
|
||||
|
||||
:::caution Unpopular opinion
|
||||
:::warning Unpopular opinion
|
||||
|
||||
This is also one of the reasons why I'm quite against packaging anything and
|
||||
everything into the Linux distribution. In my opinion it is impossible to
|
||||
|
|
|
@ -297,7 +297,7 @@ However after running that command, we will get the following:
|
|||
And the `color_eyre::install()?` is quite straightforward. We just initialize the
|
||||
error reporting by _color eyre_.
|
||||
|
||||
:::caution
|
||||
:::warning[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
|
||||
|
|
|
@ -153,7 +153,7 @@ println!("Common elements: {:?}", top.intersection(&bottom));
|
|||
Common elements: [3]
|
||||
```
|
||||
|
||||
:::caution
|
||||
:::warning[caution]
|
||||
|
||||
Notice that we need to do `&bottom`. It explicitly specifies that `.intersection`
|
||||
**borrows** the `bottom`, i.e. takes an immutable reference to it.
|
||||
|
|
|
@ -34,7 +34,7 @@ way:
|
|||
- checking whether they are correct indices for the `Vec<Vec<T>>`
|
||||
- indexing `Vec<Vec<T>>` with them
|
||||
|
||||
:::caution
|
||||
:::warning[caution]
|
||||
|
||||
I'm getting familiar with Rust and starting to “abuse” it… While doing so, I'm
|
||||
also uncovering some “features” that I don't really like. Therefore I will mark
|
||||
|
@ -142,7 +142,7 @@ where
|
|||
}
|
||||
```
|
||||
|
||||
:::caution **«↯»** Why can't we use one function?
|
||||
:::warning **«↯»** Why can't we use one function?
|
||||
|
||||
When we consider a `Vec<T>`, we don't need to consider containers as `T`, Rust
|
||||
implements indexing as traits `Index<T>` and `IndexMut<T>` that do the dirty work
|
||||
|
@ -382,7 +382,7 @@ fn day() -> String {
|
|||
}
|
||||
```
|
||||
|
||||
:::caution `type_name`
|
||||
:::warning `type_name`
|
||||
|
||||
This feature is still experimental and considered to be internal, it is not
|
||||
advised to use it any production code.
|
||||
|
|
|
@ -419,7 +419,7 @@ I think that we can definitely agree on the fact that `RefMut<'_, T>` is not the
|
|||
than implementing the interface, because it **cannot** satisfy the type requirements
|
||||
of the trait.
|
||||
|
||||
:::caution
|
||||
:::warning[caution]
|
||||
|
||||
I wonder how are we expected to deal with this conflict, if and when, we need
|
||||
both the `.borrow_mut()` of the trait and `.borrow_mut()` of the `RefCell<T>`.
|
||||
|
|
|
@ -24,7 +24,7 @@ the 2nd part…
|
|||
|
||||
:::
|
||||
|
||||
:::caution Rant
|
||||
:::danger Rant
|
||||
|
||||
This was the most obnoxious problem of this year… and a lot of Rust issues have
|
||||
been hit.
|
||||
|
@ -251,36 +251,38 @@ fun fact on top of that is the type of the comparator
|
|||
Once we remove the `dyn` keyword, compiler yells at us and also includes a way
|
||||
how to get a more thorough explanation of the error by running
|
||||
|
||||
$ rustc --explain E0782
|
||||
```shell
|
||||
$ rustc --explain E0782
|
||||
```
|
||||
|
||||
which shows us
|
||||
|
||||
Trait objects must include the `dyn` keyword.
|
||||
|
||||
Erroneous code example:
|
||||
|
||||
```
|
||||
trait Foo {}
|
||||
fn test(arg: Box<Foo>) {} // error!
|
||||
```
|
||||
|
||||
Trait objects are a way to call methods on types that are not known until
|
||||
runtime but conform to some trait.
|
||||
|
||||
Trait objects should be formed with `Box<dyn Foo>`, but in the code above
|
||||
`dyn` is left off.
|
||||
|
||||
This makes it harder to see that `arg` is a trait object and not a
|
||||
simply a heap allocated type called `Foo`.
|
||||
|
||||
To fix this issue, add `dyn` before the trait name.
|
||||
|
||||
```
|
||||
trait Foo {}
|
||||
fn test(arg: Box<dyn Foo>) {} // ok!
|
||||
```
|
||||
|
||||
This used to be allowed before edition 2021, but is now an error.
|
||||
> Trait objects must include the `dyn` keyword.
|
||||
>
|
||||
> Erroneous code example:
|
||||
>
|
||||
> ```
|
||||
> trait Foo {}
|
||||
> fn test(arg: Box<Foo>) {} // error!
|
||||
> ```
|
||||
>
|
||||
> Trait objects are a way to call methods on types that are not known until
|
||||
> runtime but conform to some trait.
|
||||
>
|
||||
> Trait objects should be formed with `Box<dyn Foo>`, but in the code above
|
||||
> `dyn` is left off.
|
||||
>
|
||||
> This makes it harder to see that `arg` is a trait object and not a
|
||||
> simply a heap allocated type called `Foo`.
|
||||
>
|
||||
> To fix this issue, add `dyn` before the trait name.
|
||||
>
|
||||
> ```
|
||||
> trait Foo {}
|
||||
> fn test(arg: Box<dyn Foo>) {} // ok!
|
||||
> ```
|
||||
>
|
||||
> This used to be allowed before edition 2021, but is now an error.
|
||||
|
||||
:::danger Rant
|
||||
|
||||
|
@ -319,7 +321,7 @@ you as you move.
|
|||
|
||||
:::
|
||||
|
||||
:::caution
|
||||
:::warning[caution]
|
||||
|
||||
It's second to last day and I went “_bonkers_” on the Rust :smile: Proceed to
|
||||
read _Solution_ part on your own risk.
|
||||
|
@ -343,7 +345,7 @@ and, well, let's use `z` for a timestamp, cause why not, right? :wink:
|
|||
|
||||
#### Evaluating the blizzards
|
||||
|
||||
:::caution
|
||||
:::warning[caution]
|
||||
|
||||
I think that this is the most perverted abuse of the traits in the whole 4 weeks
|
||||
of AoC in Rust…
|
||||
|
|
|
@ -7,7 +7,7 @@ last_update:
|
|||
date: 2023-03-07
|
||||
---
|
||||
|
||||
:::caution
|
||||
:::warning[caution]
|
||||
|
||||
Deadline for the submission of the bonus is **March 16th 24:00**.
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@ last_update:
|
|||
date: 2023-03-13
|
||||
---
|
||||
|
||||
:::caution
|
||||
:::warning[caution]
|
||||
|
||||
Deadline for the submission of the bonus is **March 23th 24:00**.
|
||||
|
||||
|
|
|
@ -9,7 +9,7 @@ last_update:
|
|||
|
||||
# Garbage Collection
|
||||
|
||||
:::caution Exam environment
|
||||
:::warning Exam environment
|
||||
|
||||
- During the exam you will be provided with a barebone _exam session_ on the
|
||||
_faculty computers_.
|
||||
|
@ -48,7 +48,7 @@ can see only two commands being used:
|
|||
- `..` that moves you up one level (in case you are in `/`, does nothing), or
|
||||
- is a valid directory in the current working directory.
|
||||
|
||||
:::caution
|
||||
:::warning[caution]
|
||||
|
||||
There are no guarantees or restrictions on the names of the files or
|
||||
directories!
|
||||
|
@ -144,13 +144,15 @@ $$
|
|||
You can have a look at the example usage of your program. We can run your
|
||||
program from the shell like
|
||||
|
||||
$ ./garbage_collect shell_history.txt -gt 10000000
|
||||
24933642 /d
|
||||
14848514 /b.txt
|
||||
48381165 /
|
||||
```
|
||||
$ ./garbage_collect shell_history.txt -gt 10000000
|
||||
24933642 /d
|
||||
14848514 /b.txt
|
||||
48381165 /
|
||||
|
||||
$ ./garbage_collect shell_history.txt -f 70000000 30000000
|
||||
24933642 /d
|
||||
$ ./garbage_collect shell_history.txt -f 70000000 30000000
|
||||
24933642 /d
|
||||
```
|
||||
|
||||
## Requirements and notes
|
||||
|
||||
|
|
|
@ -9,7 +9,7 @@ last_update:
|
|||
|
||||
# Watching Cams
|
||||
|
||||
:::caution Exam environment
|
||||
:::warning Exam environment
|
||||
|
||||
- During the exam you will be provided with a barebone _exam session_ on the
|
||||
_faculty computers_.
|
||||
|
@ -61,7 +61,9 @@ Each “scan” (i.e. reading) of the cameras consists of the following data:
|
|||
|
||||
And they are compiled into one reading such as:
|
||||
|
||||
camera_ID: plate timestamp
|
||||
```
|
||||
camera_ID: plate timestamp
|
||||
```
|
||||
|
||||
There should be always **at least one** space in between each part of the
|
||||
reading. Readings are separated by the commas, which may, but don't have to, be
|
||||
|
@ -126,37 +128,41 @@ of the output.
|
|||
You can also have a look at example usage of your program. We can run your
|
||||
program from the shell like
|
||||
|
||||
$ ./cams example_1.txt
|
||||
```
|
||||
$ ./cams example_1.txt
|
||||
```
|
||||
|
||||
And it will produce an output:
|
||||
|
||||
*** ABC-12-34 ***
|
||||
25: Fri Oct 1 10:50:56 2021
|
||||
```
|
||||
*** ABC-12-34 ***
|
||||
25: Fri Oct 1 10:50:56 2021
|
||||
|
||||
10: Sat Oct 1 09:18:32 2022
|
||||
16: Sat Oct 1 09:23:32 2022
|
||||
10: Sat Oct 1 09:18:32 2022
|
||||
16: Sat Oct 1 09:23:32 2022
|
||||
|
||||
19: Sat Oct 1 23:27:29 2022
|
||||
19: Sat Oct 1 23:27:29 2022
|
||||
|
||||
*** EL9-987 ***
|
||||
11: Thu Mar 23 04:15:38 2023
|
||||
*** EL9-987 ***
|
||||
11: Thu Mar 23 04:15:38 2023
|
||||
|
||||
*** Foo-666 ***
|
||||
2: Thu May 4 05:14:42 2023
|
||||
*** Foo-666 ***
|
||||
2: Thu May 4 05:14:42 2023
|
||||
|
||||
*** TryToCatchMe ***
|
||||
42: Wed Dec 21 07:00:19 2022
|
||||
42: Wed Dec 21 07:00:19 2022
|
||||
1234: Wed Dec 21 07:00:19 2022
|
||||
*** TryToCatchMe ***
|
||||
42: Wed Dec 21 07:00:19 2022
|
||||
42: Wed Dec 21 07:00:19 2022
|
||||
1234: Wed Dec 21 07:00:19 2022
|
||||
|
||||
*** XYZ-98-76 ***
|
||||
289: Mon Oct 10 17:40:17 2022
|
||||
*** XYZ-98-76 ***
|
||||
289: Mon Oct 10 17:40:17 2022
|
||||
|
||||
*** YouShould-not-pLaCe-4ny-expectations%on^the(input ***
|
||||
69: Sat Apr 1 02:13:14 2023
|
||||
*** YouShould-not-pLaCe-4ny-expectations%on^the(input ***
|
||||
69: Sat Apr 1 02:13:14 2023
|
||||
|
||||
*** YourMum ***
|
||||
42: Thu May 4 05:14:42 2023
|
||||
*** YourMum ***
|
||||
42: Thu May 4 05:14:42 2023
|
||||
```
|
||||
|
||||
## Requirements and notes
|
||||
|
||||
|
|
|
@ -13,7 +13,7 @@ last_update:
|
|||
Most likely WSL, VM or VPS. If you consider setting up either of those PITA, then
|
||||
VSCode + SSH to _aisa_ might be the best option for you.
|
||||
|
||||
:::caution VSCode @ aisa
|
||||
:::warning VSCode @ aisa
|
||||
|
||||
Be careful when using VSCode on aisa, most notably:
|
||||
|
||||
|
|
17
package.json
17
package.json
|
@ -14,10 +14,10 @@
|
|||
"write-heading-ids": "docusaurus write-heading-ids"
|
||||
},
|
||||
"dependencies": {
|
||||
"@docusaurus/core": "^3.1.1",
|
||||
"@docusaurus/plugin-client-redirects": "^3.1.1",
|
||||
"@docusaurus/preset-classic": "^3.1.1",
|
||||
"@docusaurus/theme-mermaid": "^3.1.1",
|
||||
"@docusaurus/core": "3.0.0",
|
||||
"@docusaurus/plugin-client-redirects": "3.0.0",
|
||||
"@docusaurus/preset-classic": "3.0.0",
|
||||
"@docusaurus/theme-mermaid": "3.0.0",
|
||||
"@mdx-js/react": "^3.0.0",
|
||||
"clsx": "^1.2.1",
|
||||
"docusaurus-plugin-sass": "^0.2.4",
|
||||
|
@ -27,12 +27,13 @@
|
|||
"prism-react-renderer": "^2.1.0",
|
||||
"react": "^18.2.0",
|
||||
"react-dom": "^18.2.0",
|
||||
"rehype-katex": "7",
|
||||
"remark-math": "6",
|
||||
"rehype-katex": "^7.0.0",
|
||||
"remark-math": "^6.0.0",
|
||||
"sass": "^1.63.6"
|
||||
},
|
||||
"devDependencies": {
|
||||
"@docusaurus/module-type-aliases": "^3.1.1"
|
||||
"@docusaurus/module-type-aliases": "3.0.0",
|
||||
"@docusaurus/types": "3.0.0"
|
||||
},
|
||||
"browserslist": {
|
||||
"production": [
|
||||
|
@ -47,6 +48,6 @@
|
|||
]
|
||||
},
|
||||
"engines": {
|
||||
"node": ">=16.14"
|
||||
"node": ">=18.0"
|
||||
}
|
||||
}
|
||||
|
|
Loading…
Reference in a new issue