![\"Finished](\"https://blog.mfocko.dev/assets/images/calendar-5bf14f0b5491b4f8d192afa33ea4e5a6.png\")
After being a part of a Python-oriented team developing a CI for automating\nrelease syncing and shifting the testing process to left (to the original\nproject rather than at the distribution-level) for five and a half years I felt\nlike I need a bit of a change.
\nAnd that’s why I’ve seeked the opportunity to switch up for some time with\na colleague that felt in a similar way working on a different project within the\nRed Hat.
\nAnd that’s how I ended up for 2 quarters in the DNF Team working on dnf5. I’ll\ntry to sum up my experience over the 2 quarters.
\nAs of the time of me switching from the Packit Team to the DNF Team, our\norganization has been in the process of hiring a dedicated Scrum Master.
\nIn the Packit Team we are used to rotating the Kanban Lead role (among the\nother regular / maintainer roles) around the team.
It was my first time being a part of a team that has a dedicated agile\npractitioner. I was not used to this experience.
\nOn one hand it feels nice to have someone having your back and handling most\nof the annoying stuff, e.g., Jira shenanigans, or calendar and such, and, in\ngeneral, being in control of the whole agile process and ceremonies tied to\nit.
\nSadly I have to admit that as the Kanban Lead role grew in the Packit Team, I\nhave managed to forgotten smaller things here and there, e.g., least recently\nupdated issue (when the stand up took longer than usual), or posting the summary\nof merge requests waiting for review.
Even if your whole job revolves around the agile practice, Jira is a miraculous\ncreation that will pull the rug from under your feet one way or another…
In Packit we are using a scrumban1, so getting back to scrum kind of\nmade me relive some of the annoyances of scrum by itself, e.g., the time\nconstraint to 2 weeks.
\nSome time after I joined the DNF Team we have tried out the 3-week long sprint\ninstead of 2-week long.
It had quite a good reception, especially because of the lower frequency of\nplanning meetings.
AFAIK the 3-week sprints have been kept.
In general it is more common to shorten the “iterations” rather than prolong\nthem. Overall I think this impacts your capability of planning, because you’re\nplanning for a longer period of time and that, by definition, is less accurate.
Carrying tickets over to the next sprint is quite common and also pulling in\ntickets during the sprint too…
\nOne thing that caught me by surprise was the low amount of meetings, partially\ncontributed by the asynchronous stand ups2.
\nAlso the DNF team is spread across multiple time zones, so the meetings are set\nin the afternoon for the European folk.
\nAs always, estimation of size of tasks is quite relative thing. There are teams\nthat measure the story points by days, weeks, etc.
\nIn the Packit Team we’re using the Fibonacci scale with a few rules that give\nquite basic idea of the sizing.
\nAfter a quick glance through the DNF’s backlog I’ve noticed mostly higher points\nbeing assigned, which is totally OK, since it’s relative. However it also\nclashed a bit with my perception of sizing after 5 years in Packit 😁
\nAnother difference to Packit was the fact that the story points were assigned by\nthe colleagues that were triaging the new issues/tickets at the time. Because\nthere was no agreement across the team on the difficulty assessment, the story\npoints vary (IMO at least).
\nUnderstandably, both approaches have its merits:
when you assign points during triage
\nassigning points together — unfortunately consumes time, but instigates\na discussion over the topic
\nDeveloping for Linux on macOS can be challenging at times. One would expect that\ndeveloping service revolving around Linux packaging and testing would be\neven worse, but it’s not that problematic in reality, since everything is nicely\ncontainerized.
\nDeveloping a package manager on the other hand… is also not an issue, unless you\nneed to run the tests.
\nSetting everything up was a bit challenging. In the end I have settled for\na Fedora Rawhide container where I mounted both sources and tests4.
\nRunning the test suite based on behave was however not possible… Main cause\nof failure was coming from the fact there were some tests for testing\narchitecture fields in specfiles which, of course, breaks the assumptions on\nthe Macs. To be fair, the different architecture (Apple Silicon) is to blame,\nnot the OS itself.
\nIn my opinion, BDD is something that could probably simplify Packit Service\ntests, but at the same time… the time/cost of converting the test suite would be\ndisgraceful.
One of the other ARM5 quirks I hit, was not being able to utilize\nparallel builds. When I tried compiling with the classic make -j$(nproc) on\nLinux, it worked just fine. However from within the container on the Mac, it hit\nsome race conditions that caused the build to fail.
\n\nFor the first time in 5 years, I have been assigned a task that affected RHEL\ndirectly…
\n
Finding the issue and fixing it was probably the easiest part. Getting the fix\nall the way down to RHEL is where things complicate.
\nDNF Team handles the downstream patching in such way that they keep the RHEL\nbranches on the upstream. To these branch you backport (most commonly simple\ngit cherry pick) the fixes and then you can easily generate patches that are\nadded to the RHEL specfile.
\nThe whole process is simple and straightforward. Except… resolving the ticket\nconsists of:
\nEach of those MRs should be reviewed. Even if it has already been reviewed,\ncause, don’t forget, 2 of those are simple cherry picks and the specfiles, in\nthe end, consist again of the already reviewed patches.
\nAnd even then it took me additional two merge requests, because neither I, nor\nmy reviewer, have realized that I am missing part of the tests in the backport.\nThose have been added during the triage a long time before I got the ticket\nassigned.
\nUnderstandably, this “bureaucratic” work has no easy solution. The current\napproach is menial and annoying, but you’re guaranteed audit through the\nwhole process. And also it nicely prevents conflicts on the downstream when\nbackporting fixes.
Overall it was a very pleasant experience trying to onboard a different project\nwith different workflows and processes. Maybe I’m biased prior to my previous\nexperience, but the way we set up agile in Packit feels a lot more intuitive.
\nI’m also content that I was able to contribute to the package manager that I use\non a daily basis as a user.
\n\nLet's go through the final third of this year’s Advent of Code.
\nCovering the floor with red tiles… and maybe also some green in case it would\nbe too simple.
First part was pretty easy, very simple thing to literally brute-force. On the\nother hand… the second part was a bit worse.
\nMy idea was a pretty primitive one, just do the same thing as in the first part\nand filter out the options that are not valid.
\nTurns out that the process of deciding what is and what is not valid is the\nproblem.
\nIn the end I have managed to refactor the solution into:
\n@Override
Long part1() {
return getBiggestTriangle(_r -> true);
}
@Override
Long part2() {
return getBiggestTriangle(this::isValidRectangle);
}
This was the second day when I had to utilize the heap consumer1, so I have\ndecided to factor it out to the library. Since the method itself accepts\nan object implementing Queue<T> interface, I have renamed it\nto consumeQueue():
/**
* Creates a stream that consumes elements from a queue.
*
* @param <T> the type of elements in the queue
* @param queue the queue to consume elements from
* @return a stream of elements from the queue, in the order they are polled,
* terminating when the queue becomes empty (when {@code poll()} returns
* {@code null})
*/
public static <T> Stream<T> consumeQueue(Queue<T> queue) {
return Stream
.iterate(queue.poll(), _it -> queue.poll())
.takeWhile(it -> it != null);
}
pairs() and helpersFor iterating over the possible choices, in this puzzle, I had to generate all\npossible pairs from an input. Overall it made sense to just implement a method\nthat takes a stream and generates the pairs:
\npublic static <T> Stream<Pair<T, T>> pairs(Supplier<Stream<T>> xs) {
return zip(indices().boxed(), xs.get())
.flatMap(p ->
xs.get()
.skip(p.first() + 1)
.map(y -> Pair.of(p.second(), y)));
}
However, in the end, I needed some other helpers to get there… Namely it was\neasier to implement infinite indices() rather then iterate the stream twice.
Also you can notice that pairs() gets passed a Supplier<Stream<T>> rather\nthan the stream itself. That's coming from the fact that streams can be iterated\nthrough only once, so I need to have a functional object that generates a new\nstream each time I need it.
Pressing buttons to light up christmas lights in specific configuration. Until\nyou realize it's not about the on and off, but about the “joltage”…
This day… was a scam. For the first part you had to light up lights on the\nmachine in a specific configuration. Part of the input were buttons that contain\na list of lights that get toggled with each press.
\nA lot of people chose to go with integral representation of the lights and\nbuttons and then just applying simple XOR.
\nI didn't try to simplify the inputs, so I've ended up with lists (or sets) of\nintegers and used BFS for solving the first part.
\nAnd… second part is where the fun starts.
\nInput consisted of multitude of machines where each one is represented by:
For the part 2 you have to find minimal number of presses to raise joltage to\nthe seeked joltage…
\nThe search space for this problem is enormous… I've tried a very naïve approach\nof preprocessing the buttons for each machine in such order that narrows the\nsearch space. This approach was relatively effective, but not effective enough\n😄 To cut the story short, I've ended up with 97 % of the input processed,\nbut got stuck there for 3.5 hours after which I killed it.
\nOnce the solution has been running for about 30 minutes, I have started to pick\naway here and there to optimize bit by bit. And it was pretty effective! To sum\nit up:
\nI had a method to generate counters (i.e., long[] of zeros); in the initial\nsolution I used range().map().toArray(), switched it to simple new long[]
for read-only operations, where possible, I've switched to parallel streams\ninstead of sequential
\nchanged the strategy of exploring the search space; instead of going from\nminimum needed to maximum possible presses of a button, I've turned it around\nand went from maximum possible to minimum needed, which prunes the unreachable\nbranches quicker
\nand finally the recursive calls that get called for each button press…\nfor each of this calls I create a separate “goal” joltage the search is\nsupposed to address, that way I can paralelize those too
\nAnd this has gotten me from 3.5 hours (still missing the last 4 results) to 6\nminutes.
\nCounting possible paths through a network of devices.
Relatively easy way to solve this. Can be done recursively, it's basically just\ngoing through the graph, trying to find a way to the goal. And at the same\ntime counting how many ways there are…
\nI have to admit that I did not expect to get burnt at this Java-specific\nthing on the 11th day 😄 I've been teaching at Intro to programming for\nyears that sometimes it's not a good idea to use niche features specific only to\none or two languages, yet… At first I didn't realize at all that
\nif (from == sink) {
return 1l;
}
does something totally different than
\nif (from.equals(sink)) {
return 1l;
}
== compares references, and, as opposed to other languages like C++ or C#,\ncannot be overriden. However I noticed this mistake rather quickly, cause the\ngraph traversal doesn't terminate, duh…
I expected to make this mistake during the beginning, not at the second to last\nday.
\nPuzzle about tiling problem. However the challenge input is a bit more simpler\nthan the complicated sample…
At the first look, the problem looks extremely annoying. And it kinda is… The\nfun thing is that it is possible to solve simply by expecting a bit more area,\nas a buffer, to be occupied by the tiles and simply checking whether it could\nfit.
\nWhat's even more funny is the fact that the provided sample is quite picky about\nthis, i.e., you need to account for 20 % buffer to make it pass. However the\nchallenge input… that works without any buffer…
\nParser.of()I've tried to simplify the parser a bit, so I introduced a method Parser.of()\nto be able to construct instances of parsers without the need to use new and\n<> for type inference of the resulting types to be produced by parsing…
I have a bit of mixed feelings. Thankfully, this year, there was only one day\nthat was particularly obnoxious with regards to parsing.
\nThere were only 12 days instead of the usual 25. I have tried to solve all days\nat 6am (CET) and… I'm not very used to writing Java at 6am to be honest 😄\nSo I definitely don't mind an early end on that front 👀 Though it is quite\nknown that the complexity of the tasks grows towards the end of the AoC, so this\nyear might seem a bit easy-going? I can understand the need for a bit\nof a challenge.
\nEven though Java is the first language I've learnt and also learnt to hate\nfurther on, it was quite pleasent experience in my opinion. I confess to abusing\nthe streams and other FP-like “features”.
\nI definitely hate the boilerplate for each day… but looking back at it, it makes\nit quite customizable, so, for example, in day #8 I was able to simply add the\nconstraint (which was different for sample and challenge input) to constructor\nand it allowed pretty easy testing and computing the challenge at the same time.
\nI didn't feel comfortable working with either IDEA or VSCode. They each have\ntheir own quirks, e.g., not working completion (which is definitely helpful with\nstreams and data structures), or issues running the puzzles in a way that would\nfit my workflow.
\nOTOH it was a quite pleasant experience with testing (apart from constructors in\nclasses that are not instantiated) and also doc-generation. Though I feel that\njavadoc is still… bit obscure format for me.
\n\nLet's go through the second third of this year’s Advent of Code.
\nRanges??? AGAIN??? Bit more annoying than the last time though. For the part 1\nyou check how many items of your “shopping list” fall into any of the ranges.
And for the part 2, you get to find how many IDs are covered by those ranges.
Pretty eazy to solve, given that you chose a good representation for the input.\nEven spotless thought it's a good idea to keep the solution for part 1 on one\nline 😉
\nI have also tried using the IDEA instead of the VSCode, but… I've hit different\nissues with the IDE 🤦♂️
\nVSCode has trouble with the source dependencies defined by gradle and that's\nwhy any completion or type inference in the editor fails miserably :)
\nas for the IDEA… type inference and completion works, but it has the same\nproblem except for the fact that it »disassembles« compiled *.class files of\nthe library and that's how it gets type inference and completion to work, but…
still no javadoc and on top of that running the “app” is problematic, as I\nhave not been able to get any output from the app in case it fails with an\nexception 😄 not even with --stacktrace… the output just vanishes
So in the end I've decided to revert back to the VSCode, as running the app is\na bit more comfortable than fighting the runner in IDEA.
\nThis is the day when I decided to improve the parsing situation. From the\nprevious years and other languages I've noticed some patterns, with Java… I did\nnot notice any 👀
\nFor Rust there's a FromStr trait that allows you to use T::from_str() that\ncan either return the parsed structure or an error.
In Kotlin there was a funny “convention” of extending strings with a method\n.toSomething() which would allow you to do: \"1,2\".toPoint() or something\nsimilar.
In C# there's a pretty good construct of
\npublic static bool TryParse(string? s, out T result);
It seems a bit complex, but basically it allows you to get a result of the\nconversion as a return value (the bool indicates success or failure) and at\nthe same time you can populate an out variable with the parsed data. Overall\nit can be combined into:
var stringRepresentation = \"1,2\";
if (Point.TryParse(stringRepresentation, out var point)) {
Console.WriteLine($\"Parsed point of x={point.x} y={point.y}\");
} else {
Console.WriteLine($\"Failed to parse: ‹{stringRepresentation}›\");
}
As I have not been able to find any convention about that in Java, apart from\nthe parsing method for primitive data types: Integer.parseInt()\nor Long.parseLong(). I have decided to come up with something suitable for AoC\nmyself:
public abstract class StringParser<T> {
public abstract T from(String s);
public Stream<T> from(Stream<String> xs) {
return xs.map(it -> from(it));
}
public Stream<T> from(List<String> xs) {
return from(xs.stream());
}
public Stream<T> from(String[] xs) {
return from(Arrays.stream(xs));
}
}
We have a few adapters over the unimplemented method, so it is easy to parse\nmultiple values at once. And one abstract method that defines parsing from\na single string.
\nOf course, it is also possible to create anonymous objects of StringParser<T>\nthat don't have to be named, they just need to implement that .from() method.
During the testing I have found out that… it works well, but at the same time is\nquite verbose:
\n@Test
public void testParse() {
try (var input = new Input(69, \"regression\")) {
char[][] map =
new char[][] {
\"123049575901212312312313\".toCharArray(),
\"123123130999555554444433\".toCharArray(),
\"000111100022222330000000\".toCharArray(),
};
assertArrayEquals(
map,
input.parse(
new StringParser<char[][]>() {
@Override
public char[][] from(String s) {
return Arrays.stream(s.split(\"\\n\"))
.map(row -> row.trim().toCharArray())
.toArray(char[][]::new);
}
}));
}
}
As you can tell there's a lot of boilerplate still… And that's where I got\ninspired by the higher-order functions in Java. Even though they accept\n“callable” objects, you don't that much boilerplate around them. And the reason\nwhy you don't is a functional interface.
\nFunctional interface is a concept of an interface that has exactly one\nabstract method. Since there's exactly one method, you can create an instance\nof a functional interface with lambda, method or constructor reference.
Given this annotation, I have converted StringParser<T> into:
@FunctionalInterface
public interface StringParser<T> {
T from(String s);
}
And to be able to utilize the other methods, if needed:
\npublic class Parser<T> implements StringParser<T> {
private final StringParser<T> parser;
public Parser(StringParser<T> parser) {
if (parser == null) {
\t throw new IllegalArgumentException(\"‹parser› cannot be null\");
}
this.parser = parser;
}
public T from(String s) {
return parser.from(s);
}
public Stream<T> from(Stream<String> xs) {
return xs.map(it -> from(it));
}
public Stream<T> from(List<String> xs) {
return from(xs.stream());
}
public Stream<T> from(String[] xs) {
return from(Arrays.stream(xs));
}
}
And the parser above can now be written as:
\n@Test
public void testParse() {
try (var input = new Input(69, \"regression\")) {
char[][] map =
new char[][] {
\"123049575901212312312313\".toCharArray(),
\"123123130999555554444433\".toCharArray(),
\"000111100022222330000000\".toCharArray(),
};
assertArrayEquals(
map,
input.parse(
s -> {
return Arrays.stream(s.split(\"\\n\"))
.map(row -> row.trim().toCharArray())
.toArray(char[][]::new);
}));
}
}
For this day we also have a photo from this year's setup at 6am 😉
\n![](\"https://blog.mfocko.dev/assets/images/setup-b3368fdacc469985b433d916e396f50e.png\")
Advent of Parsing, here we go! Part 1? Easy! Part 2? You get to pay for your\nparsing decisions in the part 1 :)
Whole day is about a simple addition, or multiplication, of numbers in a column\nas you have definitely learned at the elementary schoold, but the part 2 shows\nyou that sometimes not everything is aligned as it's supposed to be…
And the old Advent of Parsing is back…
\n123 328 51 64
45 64 387 23
6 98 215 314
* + * +
Surely that whitespace around the numbers has no meaning, right? RIGHT?!?!
\nIt does… sigh
Part 1 was relatively OK, just treat the last row as special, since it has\noperators and then for the other rows, split on whitespace and trim all other\nwhitespace.
\nThis was the day when my column iterator came in handy 🎉
As for the second part… that was not fun… had to rewrite almost all of the\nparsing. After making up an algorithm for handling the different representation\nof numbers (one column of digits being a number), and still getting wrong\nresults, I noticed that the alignment from both sides matters 🤦♂️
\nHowever after the refactoring I got to a solution that accepts an operator and\na stream of numbers, so it boiled down to one function doing “the math” and the\ntwo other (for each part) just passing a stream of numbers to it…
\nSplitting beams, until… you're splitting timelines :)
Part 1 was not the easiest to comprehend when reading it for the first time.\nHowever if you get what you're supposed to do (and do not try to be smart about\nit), it is rather easy to solve.
\nDuring the refactoring I've done several improvements, though… I have to admit\nthat in the end I might've overdone it a bit and it's kinda… perverted.
\nSince you're splitting beams on the splitters, the initial solution contained\na following bit of copy-paste:
\nif (manifold[y][x - 1] == '.') {
// …
}
if (manifold[y][x + 1] == '.') {
// …
}
Which I have managed to refactor into:
\nfor (int dx : new int[] {-1, 1}) {
if (manifold[y][x + dx] != '.') {
continue;
}
// …
}
And I couldn't stop there… I have also decided to use switch-expressions where\npossible. For example the computation of possible timelines from part 2:
dp[y][x] =
switch (manifold[y][x]) {
case 'S', '|' -> get(y + 1, x);
case '^' -> get(y, x - 1) + get(y, x + 1);
default -> throw new IllegalStateException(\"no need to evaluate empty cells\");
};
Furthermore I have decided to convert the for-each-loop above into a stream…\nand once I got a knack for it… I have created an adapter for consuming the queue\nas a stream 🤦♂️
private <T> Stream<T> consumeHeap(Queue<T> heap) {
return Stream.iterate(
heap.poll(),
_it -> heap.poll()
)
.takeWhile(it -> it != null);
}
Fun thing is, since the stream is lazily evaluated, you can add more elements\nto the heap while iterating through it. So it basically can work as\na for-each-loop through the heap as long as there's something in it.
Pair.of()For the cases where it is possible to use type inference, I have stolen a helper\nfrom @semuil to avoid unnecessary clutter, i.e., new and <>:
new Pair<>(x, y)
// turns into
Pair.of(x, y)
Substituting for electricians and going through the piles of cables…
The core of this puzzle was to repeateadly connect the closest boxes together.
\nProbably the most appropriate way to approach this problem is to use union-find.\nSince it's something I'd include in the library, I've decided to just use\nmin-heap and go from there.
Now the first part was relatively easy to solve, though the abstraction hurt\na bit here. More specifically we want to partition the boxes into subsets in\nsuch order that the one with the closest distance are together in one subset.
\nSo… you need to be able to track to which partition each box belongs. Therefore\nthe easiest solution was to simply keep indices in the heap and keep an array\nwith “marks” for each partition.
\nAnd this is where I screwed up royally and was not able to find my mistake for\nsome time 😄
\nTo sum up what we're going to do:
\n\n\nWe pick the closest two boxes from the queue, if they're already in the same\npartition, we can safely ignore and proceed. Otherwise we need to merge the\npartitions into one.
\n
This should be achieved with the following code:
\nconsumeHeap(queue)
.limit(maxConnections)
.forEach(
it -> {
var a = it.first();
var b = it.second();
if (mapping[a] == mapping[b]) {
return;
}
for (var i = 0; i < mapping.length; ++i) {
if (mapping[i] == mapping[b]) {
mapping[i] = mapping[a];
}
}
});
Except for one smaller issue… that I was not able to find for the longest time\npossible 😄
\n// vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
if (mapping[i] == mapping[b]) {
mapping[i] = mapping[a];
}
// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
for-loop is supposed to take each box from the same partition as the latter\nbox from the two closest ones and move it to the partition of the first box. And\nit does that… but once it wipes the mark of the original parition, cause it is\nequal to itself (duh…), we lose the track and everything from that point onwards\nstays in the original partition.
That was a rookie and quite stupid mistake that cost a lot of time…
\nFun fact, if the indices were evaluated using the strict evaluation strategy,\nthe overwriting would happen afterwards and therefore this problem could've been\navoided. But… they're not, it's a for-loop with side effects.
And, even if, I used the streams, the stream of indices would've been evaluated\nlazily.
As both parts are quite similar, I have managed to refactor the common logic\ninto:
\n@Override
Long part1() {
consumeHeap(queue).limit(maxConnections).forEach(this::connect);
// construct the answer to part 1
}
@Override
Long part2() {
Pair<Integer, Integer> it = null;
while (sizes.size() != 1) {
it = queue.poll();
connect(it);
}
// construct the answer to part 2
}
Since the Euclidean distance used in this puzzle seemed handy, I moved it out\nto the library. Funnily as part of the optimization I've used the squared\nEuclidean distance throughout this puzzle, so the interface includes both actual\ndistance and the distance squared.
", "url": "https://blog.mfocko.dev/blog/aoc-2025/third-02/", "title": "Second third of Advent of Code ‘25 in Java", "summary": "Second third of Advent of Code ‘25.", "date_modified": "2025-12-10T03:14:00.000Z", "author": { "name": "Matej Focko", "url": "https://gitlab.com/mfocko" }, "tags": [ "advent-of-code", "advent-of-code-2025", "java" ] }, { "id": "https://blog.mfocko.dev/blog/aoc-2025/third-01/", "content_html": "Let's talk about the preparations for this year's Advent of Code and its\nfirst third.
\nAs usual I prepare the repo for the year and also some kind of a library with\nhelpers that I use regularly during the AoC challenges.
\nLibrary for AoC consists mostly of parsing helpers, as there's a long-going meme\nof referring to Advent of Code as Advent of Parsing. Additionally it's also\nhelpful to have 2D/3D vectors and maybe math functions or iterators.
\nBasic list of helpers I've prepared for myself for the Advent of Code in Java:
\nIO - for reading an input; as it has a common structure, the sample and the\nchallenge input itself
\niterators - implementation of the column iterators that are usually needed\nfor iterating over maps, if they occur in the challenge input
\nstreams - implementation of some algorithms that generate streams
\nmath - GCD and LCM implementations for now as they are not included in the\nJava itself
\nvectors - as always…
\nstatic classesYou can probably tell from the prrevious list of helpers that almost all of the\nrequired functionality does not depend on having an instance of a class itself.
\nFor example the GCD and LCM doesn't need any instance, they're just simple\nfunctions.
\nYet during the testing I've discovered that there's no easy way to deal with\nsuch thing. Classes in Java can be made static, but only if they're nested\nwithin some other class which makes them hidden from outside.
Fun thing stemming from this hinderance is the fact that it lowers the test\ncoverage, as the default constructor is made private and throws an exception\nto ensure the class cannot be initialized, as it doesn't even make sense…
One thing I hated the most about implementing the vectors is the fact that you\ncannot make the vectors generic…
\nThis is caused by non-existing interface for primitive data types. Therefore\nit's not possible to create a generic class for vector.
\nI had to result to implementing two different classes that differ only in the\nunderlying data type of the coordinates:
\n// Representing a 2D or 3D vector having the floating-point coordinates.
public class FVec {}
// Representing a 2D or 3D vector having the integral (as ‹Long›) coordinates.
public class IVec {}
I have started with a simple class that allows me to read the input by lines and\ndo very simple parsing.
\nDuring the testing I've found out that there's an issue with releasing the\nresources, if you read the input via stream, you might either close the file\nbefore finishing the reading, or don't close it at all.
The best solution to this is to implement an AutoCloseable interface and then\nyou can use the input class as:
try (var input = new Input(1, \"sample\")) {
// read whatever you want
}
I will leave out the boring technical part and just show how the input class\nworks:
\npublic Stream<String> lines() {
return bufferedReader.lines();
}
public String asString() {
return lines()
.reduce((a, b) -> String.format(\"%s\\n%s\", a, b))
.orElse(\"\");
}
public Stream<Integer> asInts() {
return lines().map(Integer::parseInt);
}
public Stream<Integer> asCommaSeparatedInts() {
return Arrays
.stream(asString().split(\",\"))
.map(Integer::parseInt);
}
Stream helpers from LeetCodeAlso I've been able to snatch some Stream helpers after doing the LeetCode\nchallenges. They cover the following functionality:
range() that generates a stream in a similar fashion as the Python function,\nyou might know, would
indices() that returns a stream of indices over an array or a List<T>
product() that takes two functions that can generate streams and returns\na stream of cartesian product over said streams
zip() that “zips” two streams; providing both customizable zipping and\nsimple zip that just returns pairs of values
Each day runs in the same way, the only difference is in the parsing and solving\nthe challenge itself. Each day has both parts, nowadays a sample input with\nprovided answers for testing. Therefore I have created for myself an abstract\nclass that takes care of these things:
\nabstract class Day<T1, T2> {
abstract void precompute();
abstract T1 part1();
abstract T2 part2();
abstract void runAll();
}
T1 and T2 represent return types of the results from the parts of the\nchallenge. They're usually the same type, but sometime they may differ.
I have added a precompute() method in case there are some things that could be\nprecomputed for both parts right after parsing.
Also with Java I've run into a limitation that doesn't allow me to test sample\ninputs and run for the challenge input without a lot of copy-paste, so I've\ncreated an abstract runAll() method which gets called when running the whole\napp and can be used in a following way:
@Override
void runAll() {
new Day01(\"sample\").test(42, 69);
new Day01(\"input\").run();
}
Still an annoying and technically a copy-paste, but somehow better.
\nSince it's Java and I have my own library in a separate repository there's\na need to use some kind of a build system and also other tools.
\nIt has already been some years I had Java course at the university, where we\nused Maven. And I've read some stuff about gradle, also it was used in the AoC\ntemplate for Kotlin done by the JetBrains, so it wasn't very hard to adapt.
\nThough there were some issues hit, I'll get to them later on.
\nWhile writing the library I noticed that it's rather hard to have consistent\nformatting and the VSCode extensions don't do a very good job with formatting\nand cleaning up imports and such. I searched a bit on 🦆 and found\nspotless.
\nLooking at the git repository now I have to admit that it can be applied to a\nmultitude of languages, so they must be doing something right…
\nFor the library I've decided to use whatever was in the gradle template for Java\nlibrary.
\nAs for the puzzle solutions themselves… That's rough to decide:
\nwith Kotlin it was a matter of simple check() statements that throw an\nexception if the assertion fails
with Rust I had a very good experience using my own macro machinery to create\na mod with tests for each day; I have to admit that this setup together with\nbacon has been the best I've ever achieved
\nThis time I have decided to go with two separate “runners” in the abstract class\nfor each day:
\nrun() that simply runs and reports from each part:
void run() {
System.out.format(\"\\n[TRACE] Running input:\\t‹%s›\\n\", inputType);
System.out.println(\" [INFO] Running precompute()\");
precompute();
System.out.print(\" [INFO] Part 1:\\t\");
System.out.println(part1());
System.out.print(\" [INFO] Part 2:\\t\");
System.out.println(part2());
}
and test(x, y) that does basically the same, but also checks the results:
void test(T1 answer1, T2 answer2) {
System.out.format(\"\\n[TRACE] Testing input:\\t‹%s›\\n\", inputType);
System.out.println(\" [INFO] Running precompute()\");
precompute();
if (answer1 != null) {
System.out.print(\" [INFO] Part 1:\\t\");
var result1 = part1();
if (!result1.equals(answer1)) {
System.out.printf(\"[KO] Given answer: ‹%s› (expected ‹%s›)\\n\", result1, answer1);
} else {
System.out.println(\"[OK]\");
}
}
if (answer2 != null) {
System.out.print(\" [INFO] Part 2:\\t\");
var result2 = part2();
if (!result2.equals(answer2)) {
System.out.printf(\"[KO] Given answer: ‹%s› (expected ‹%s›)\\n\", result2, answer2);
} else {
System.out.println(\"[OK]\");
}
}
}
void test(T1 answer1) {
test(answer1, null);
}
A sprinkling of modular arithmetics trying to crack a code to a vault.
I didn't expect to smack an enum class and record right away on the first\nday, but here we go.
Overall haven't hit any issues. Except for the fact that closures are something\nthat Java has never been designed for… Which means that you cannot modify\nreferences of higher data types or values of primitive data types of variables\nfrom an outer scope of a closure… This is something that I don't really like\nand it kinda defeats a purpose of .reduce() or .forEach().
Comma-separated ranges… Quite obvious int won't do here… Adjustment for\nsecond part can be a bit worse if you try to go for the simplest possible\nsolution :)
You could choose to solve this by having “fun” with strings, or if you are\ncapable of running the mental masturbation, you can also have fun with decimal\nnumeral system.
\nChosen the latter, though the adjustment for the second part was not that easy…
\nLeading zeroes were something that caused some trouble on my end, but I got over\nit.
\nMin-maxxing the joltage on the batteries. Starts to feel like there's a theme\nof screwing around with base 10 numeral system 👀
Part 1 was relatively easy… a lot of copy-paste in the first solution.
\nPart 2… that was not okay and it took some time to get over it. Probably had\na bad sleep or something, I knew what I want to do, but I just couldn't write it\nin the code and always hit some problem, almost felt like a whack-a-mole.
\nHaving fun with rolls of toilet paper on a 2D grid…
Pretty straightforward for solving… Initial solution contained quite a lot of\ncopy-paste, of course.
\nTrying to refactor the solution brought to surface first issues with Java… What\nI hate the most, is the fact that I am not able to make type aliases correctly.\nThe closest I've gotten to a type alias is something like:
\nprivate class Index extends Pair<Integer, Integer> {}
However that creates issues on its own, because, well, it utilizes the\ninheritance to construct a type alias. And the properties of the inheritance are\nthe issue here.
\nMore specifically, as you may know from OOP, you can reference objects of\nIndex as Pair<Integer, Integer> as they “extend” the latter type, but you\ncannot do that in the other way… Because Pair<Integer, Integer> doesn't have\nto, and usually doesn't, implement anything under the Index. Even though we\ndon't add anything, there's not an easy way to tell…
This is the first day where I started to abuse the relatively new Stream\nfeatures of Java 😉 More specifically, part 2 of the puzzle was to repeat\npart 1 until you run out of possible candidates. You can probably tell that the\nfirst go-to of anyone would be to go for do-while loop, which I did in the\ninitial solution, but then I thought that it might be possible to just “abuse”\nthe Stream 😈 so I did…
return Stream.iterate(
removableRoles().toList(),
indices -> !indices.isEmpty(),
indices -> {
indices.forEach(idx -> map[idx.first()][idx.second()] = 'x');
return removableRoles().toList();
})
.mapToLong(roles -> roles.size())
.sum();
Every now and then I get angry at something not working on the Raspberry and so\nI decide to swap the OSs. Now it's time for something new and not expected.
\n![\"fastfetch](\"https://i.imgur.com/svLIfIg.png\")
After I've subscribed a VPS at vpsfree.cz for myself, I got an opportunity to\ndrop using an old laptop for running a local “server”. At that point all I've\nhad was self-hosted Gitea, some aliases on nginx and that was all. Out with the\nold laptop and let's begin experimenting with the Raspberry, right?
\nThe first OS that got on the Raspberry was archLinux (BTW…). I've been using\nit for a long time and had the best experience with. I haven't hit any issues,\nbut at the same time, you need to keep in mind we're running it off the SD card\nand they are known to get worn out quickly, especially if you write a lot\nwhich… guess what, is quite common with rolling and bleeding-edge distribution\n😄 And the worst part is keeping up with the updates.
\nAnd that's how I migrated to openSUSE Leap :) I've been using openSUSE for at\nleast 4 years during the high school and a bit more before and after… openSUSE\nis very user-friendly (YaST is amazing) distribution and honestly just works.\nHowever the cost lies in Cockpit not being available1 and some weird design\ndecision, e.g., networking stack is very fragile2.
\nAnd I've got finished in the recent weeks with some issues during updates, but\nthose can be, of course, blamed on me, cause I don't watch over it as I should\n:)
\nI should probably sum up the latest state of what was running before I decided\nto go for a merciless wipe. So here it is:
\nI had the switch in mind for some time, but I couldn't decide on the\ndistribution… In the ideal world, I'd just slap CentOS Stream on it, but\nthere's no Raspberry “support” for CentOS3. So the other choices were plain\nDebian and something else from the RHEL-family which could be either Fedora4,\nAlmaLinux or Rocky Linux.
\nI should admit that I'm not a big Debian fan 😄 Even though 12 bookworm\nis relatively on the same terms as anything that tries to match RHEL9, it still\nfeels weird. That might be caused by the fact that I've switched RPM-based\ndistributions a long time ago (including screwing around with archLinux and\nJean Tux5) and never looked back (except for the desktop with NVIDIA GPU\nthat's pain in the 🍑 and only Ubuntu runs reasonably… well).
\nWearing the red fedora also ruled out the Rocky Linux 🙂\nas I don't endorse nor support their way of operation
\nSo AlmaLinux it is!
\nI'm going with AlmaLinux 9.4 on Raspberry Pi 3B. Opened the AlmaLinux's wiki and\nfirst thing I got slapped by is
\n\n\noriginal Raspberry Pi 3 (without \"+\" models) are not supported
\n
GREAT! I took the risk, installed it. And it didn't boot 😁 It turns out\nthat the WiFi kernel module caused a kernel panic on the boot. From some people\non Reddit I found that it caused some issues, but worked, so I've just\ndecided to pop the SD card back in a PC and deny the module from loading. Voilà!\nIt boots!
\nI suck as admin…
Both the Raspberry and my VPS are maintained in the caveman-style 😄 And\nthat's why I've decided to start with the less painful one (the Raspberry) to\nwrite the Ansible playbooks for :)
\nI have already managed to migrate my dotfiles and “bootstrap” to be run via\nAnsible, so I've just proceeded to extend that and also reorganize it a bit,\ncause the roles grew in size 👀
\nAnd I have to admit that I've been mostly successful. Let's delve into details!
\nYeah… that's something that hasn't been running on the openSUSE and I totally\nforgot that hardening the SSHD config (including port change) requires notifying\nSELinux about the port change :) Of course I managed to cut myself off 😄
\nCertbot was the service I feared the most, as there is no reasonable way to\nautomate this. You need to run it manually at least the first time. But in the\nend, it was quite OK.
\nOne downside of caveman-style administration is the fact that you forget about\nthe tweaking you do. Reverse proxy breaks Cockpit by default. I was reading\nthrough the documentation, but haven't managed to find the part that mentioned\nthe specific settings I had to change. When I was about to open the PR with\nproposed changes, I noticed that it was in a different chapter 🤦♂️
\nCups went rather smoothly… except for the fact that it doesn't work on the one\nand only Ubuntu desktop and there are no logs with reason why it fails to add\nthe printer 🙂
\nAdditionally installing the HP printer via hp-setup is very interesting\nexperience… I would've never expected the CLI to have a progress bar that opens\nup at 0% and then just switches into terms & conditions… Yes, that progress\nbar stayed at 0% even though it was downloading a PPD file and progressing.
I had smallish issue with deciding how to run the DDNS service. I went with\ndropping my own buggy script and had to choose a DDNS client. Found inadyn\n(that isn't built at all for Fedora and family) and ddclient. The ddclient\nhad some not very nice feedback, and the version that introduced the Cloudflare\nsupport I need, was not included, so I dropped that. inadyn is not packaged,\nso I've set it up as systemd timer spawning a container :)
\nOverall I've had a very pleasant experience setting up the AlmaLinux on the\nRaspberry. Even though I took a gamble with the officially unsupported model of\nRPi, it works. And it also seems to be filling the purpose it has!
\n\nI'd like to share my experience and views on some of the talks that I've\nattended on the DevConf.cz 2024.
\nLet's start with the first day which was Thursday this year as opposed to the\nprevious years when the conference started on Friday and finished on Sunday.
\nLet's start with the keynote. The keynote wasn't very interesting, at some of\nthe slides actually felt like advertisement for other talks on the topic of the\nAI…
\nNext talk about event-driven Ansible was way more interesting. It allows you\nto run Ansible playbooks after provisioning hosts, or on certain events, such as\ndiscovered vulnerabilities. On one hand it feels like a very nice thing, but on\nthe other one I can't help but to think how you need to write the playbooks, so\nthat they are generic enough. One more example that's been given comes from the\npossibility to react to tickets, e.g., outages and this feels like something\nthat could be abused to cause DoS.
\nAfterwards we've seen two lightning talks, one about\nchoosing the right OpenShift size which was a pretty quick, but listed all\nof the possible ways you can deploy OpenShift in detail. This lightning talk\nwas followed by the first AI (lightning) talk I've attended about\nrapid prototyping of the open-source AI models.
\nAs someone who's involved in the automation of the RPM packaging and testing, of\ncourse, we had to attend Learning from Nix. Nix has a very intriguing\nconcept which is pretty powerful, but painful at the same time. This can be\nsummed up pretty nicely by Tsoding who got asked about some tips & tricks for\nsomeone who wants to try out NixOS:
\n\n\nJust don't.
\n
And now we're moving into a section where everything revolves about the Packit\nTeam :)
\nFirst talk about changelogs was an interactive session that was (probably)\nmeant to share different approaches we take to handle this rather convoluted\ntopic that involves changelogs on both upstream and also on downstream with no\nrules1.
\n![\"changelogs\"](\"https://i.imgur.com/YHstMAt.jpg\")
Next one was about static analysis done by OpenScanHub. I like the idea of\nrunning the static analysis that can uncover nasty bugs (as it has been even\nshowed in the talk) at the same time as they are introduced. I gotta admit that\nafter seeing the UI of the deployed OpenScanHub on the Fedora Infra, I couldn't\nhelp but to think about the United States Graphics Company 😄 The UI is\nto the point, no fancy annoying shit, you get what you need, it's hard to get\nlost. Just simplicity. Best kind of UI/UX in my opinion.
\nAfter the OpenScanHub talk we're getting to talks that were taken in a totally\ndifferent direction from the usual talks you're used to 😉 First one was\ngiven title of “Indiana Jones and obsoleted projects” by Mirek. He talked\nabout projects that got obsoleted, but started with projects that had no\nrelation to IT field at all. I'd mark this talk as a stand up without any\nhesitation.
\nAnd finally we will wrap up the first day with the talk where speakers spoke the\nleast… “Let the users speak!” that involved users of both Packit and\nTesting Farm who spoke about their use case and benefits they gained from using\nboth services in a symbiosis.
\nOn the second day I've attended less talks to not burn myself out :) I've\nstarted with an AI-related talk with title “AI: Open source will save us!”,\neven though this talk has been improvised, as the speakers from the schedule\ncouldn't have attended, it provided a nice overview what InstructLab can do\nand how can you “feed” the relevant info into the language models by yourself.
\nAfter that I attended a “coffee enthusiasts Meetup” which was very nice and,\nof course, an organized chaos 😉
\nBefore attending the social event I wrapped up the second day with a lightning\ntalk about recent updates in Toolbx. I've used both toolbx and\ndistrobox, so it's nice to see the improvements in progress and also that both\nprojects are well and lively.
\nOn the third day I've attended only in the afternoon. “Started” my day with\na discussion “Leadership: Where people skills meet programmers” which was\nvery nice for gaining an insight into how developer, manager and QE lead roles\noverlap.
\nThat talk has been followed up by a talk about role rotation in our Packit\nTeam. I would say it is a nice “upgrade” to the agile process which allows you\nto not create a single point of failure in the mundane and repetitive processes\nwithin your team.
\nAnd this day has been finished off with a talk about shifting left in Podman.\nIt's nice to see how other teams utilize our Packit Service and also the\nservices we rely on, such as Copr or Testing Farm. With the help of Cockpit\ntests they can catch breaking changes early on, or even bugs that have been\nintroduced and break usage of the dependent projects.
\n![\"shifting](\"https://i.imgur.com/bp6FxT9.jpg\")
On the Tuesday, during our Packit stand up, I have managed to abuse my\nKanban Lead role to collect some of the talks that each of us would recommend:
\nI have to admit that these 3 days have been pretty exhaustive, including\ninformation overload 😄 but at the same time it was really nice to meet\nwith the colleagues and at least some of our users who are not based in Brno.
\n\nLinux distributions are a common choice for running the servers. There's a wide\nvariety of distributions, but on the servers majority is made by only a few.
\nSome corporations also profit from the support of the “big” distributions. Let's\ndive into the pros, cons and peculiarities of such business.
\nThis post is inspired/triggered by the following Mastodon post:\n![\"Mastodon](\"https://i.imgur.com/mh5RAlV.png\")
You may take my opinion with a grain of salt, since I'm affiliated with Red Hat,\nbut at the same time I've also seen the other side of the fence, so I know how\nit works from the perspective of the provider/maintainer.
If you are not very oriented in the matters of Linux distributions and\nmaintaining of packages, I suggest looking at the glossary at the\nend to have a better grasp of the terms that are used throughout the post.
First thing I'd like to point out is the point of the Linux distributions. What\nbenefit do they provide? And why there are so many of them…
\nAs it has been brought up many times by the rms1, Linux by itself is not\nenough, it's just the kernel that does the underlying work. We need more\nsoftware to utilize the hardware. That's the gap that Linux distributions bridge\nby providing the Linux and much more other software that we need.
\nEach distribution is unique in its own way. Some prefer different ways of\nhandling the software (like Gentoo that allows you to compile it yourself) and\nothers stable releases of software (like Debian).
\nIn the end it mostly boils down to the packaging. I, as a user, want to do\nsomething like
\n$ sudo dnf5 install firefox
and not bother about anything else. I don't want to open browser to look the\nthing up, download it and then click mindlessly 500× “Next”. I just want to run\none command and when the maintainers decide it's time to move on, another one to\nupgrade the software to the newer version.
\nOf course, for some use cases you want to minimize the latter. And even make\nsure that it's safe to do it when you need to. You don't want to break your\nproduction deployment just because someone decided it's time to push something\nout.
\nThat's when the maintainers come in. They take upon themselves the\nresponsibility of maintaining the packages. If you've ever used the Debian, you\nknow very well how old the software is, but that's what you might need for\nyour servers.
\nPackaging software is not cost-free. You may as well have 80 % of packages\nthat don't need much care and it's rather easy to push them forward, but those\nremaining, which are complicated and raise issues regularly, will make it up and\ntake a lot of time and also pain.
\nLibraries are the most common example that might not need much work to be done.\nOn the other hand, Linux kernel itself is a rather complicated machinery that\nis patched a lot and its build process is not simple either.
\nEven if you consider just those easily-maintainble packages, the process can\nbe tedious, boring and overall time consuming.
\nPackit can help tremendously with the easily-maintainable packages, since it\ncan be automated.
Now it's time to talk about whole ecosystems that have some kind of a packaging\nby themselves. Yes, I mean Python (with its continuous stream of different\npackage managers), Rust, Go, etc.
\nWhole point of packaging is to have some form of gating. In other words, you\nwant some kind of quality control when pushing changes into the Linux distros.
\nIf you want to package some tool (or even library) from the aforementioned\necosystems, you need to package all of the dependencies to make sure something\ndoesn't get updated in the meantime (and also that you can safely reproduce the\nbuilds, if need be).
\nI've tried to package some utilities for EPEL both in Rust and Go. Dependencies\nform a DAG2 and in case of Rust, it's very similar to the way npm does\nits packaging.
You get a lot of dependencies. And since it's a tree of dependencies, there may\nbe a lot of them.
I have no clue how do the Rust maintainers operate, but I'm tipping my fedora in\ntheir direction, since it must be a pain in the ass.
\nYou can find few Linux distributions that are “paid”. I'm very well aware of the\nfact I've used quotes around the word, cause it's not that easy and not even\nsame for all of the distributions that involve some kind of a payment.
\nOne of the first non-free distributions I've come into contact was Zorin OS\nwhich basically tries to be the best transition solution when moving away from\nthe Windows or macOS. If you have a look at the perks of its Pro version\nthat's paid, you may as well decide they are rather questionable…
\nIt's time to move into the Ubuntu Pro, RHEL and SLE territory. What's the\npoint of those? They definitely offer different kind of, let's say,\nnon-free experience.
\nWith those you are paying mainly for the support and bug/security patches.
\nThere's no mention of any kind of support on the Zorin page… Apart from the fact\nthat you are supporting the Zorin development.
As I have mentioned above, the three services3 I mentioned are providing\nsupport with regards to bugs and security vulnerabilites. Therefore it makes\nsense to have some kind of a process in place when you're pushing changes\n(either updates, patches or security patches) to the distribution. And yes,\nthese processes are in place.
\nIf you think about the amount of packages that is present in the community\ndistributions like archLinux (14,830 packages) or Fedora (74,309 packages),\nit is safe to come to a conclusion that there's no way to support all of them.
\nIt may seem that archLinux contains rather small set of packages, but one of the\nkiller features of archLinux lies in the AUR (archLinux User Repository) where\nyou can find additional 93,283 packages.
That's why the Linux distributions have some structure to their repositories\nthat contain packages. The way you go around this is rather simple, you choose\nsome set of critical packages that you guarantee support for (like Linux\nkernel, openSSL, etc.) and maintain those with all the QA processes in place.
\nThis is also one of the reasons why I'm quite against packaging anything and\neverything into the Linux distribution. In my opinion it is impossible to\nproperly maintain huge set of packages and enforce some kind of\nquality control.
Ubuntu has pretty granular structure of their repositories, namely:
\nmain containing the “core” of the Ubuntu that is maintained by the Canonical,universe containing literally the “universe”, packages that everyone likes,\nbut they're not crucial, this repo is maintained mostly by the community,multiverse containing packages with some license or copyright issues, andrestricted containing proprietary packages like nvidia drivers and such.By briefly checking my Ubuntu 23.10 installation, here are stats of packages in\ntheir respective repositories:
\nmain with 6,128 packages,universe with 63,380 packages,multiverse with 997 packages, and finallyrestricted with 784 packages.As you can see, if we sum them up, they are relatively similar to the Fedora\nnumbers.
\nCentOS on the other hand has a bit simpler structure with BaseOS for the base\nand AppStream for additional packages:
\nbaseos with 1,058 packages,appstream with 5,646 packages, andextras-common with 42 packages.Overall they make up the similar number as the Ubuntu's main repository. And\nyou can also notice that there are no additional repositories.
There's also a CRB (CodeReady Builder) repository with dev packages like headers\nand such.
And you can also enable EPEL (Extra Packages for Enterprise Linux) which is\ncommunity-supported and provides another 19,903 packages.
Now it's time to get back to the Ubuntu Pro. There are multiple points that need\nto be taken in account to be either positive or negative about it…
\nWe can start with the way Ubuntu is released and maintained. Ubuntu has regular\n6-month release cycle and biannual LTS release. Releases are normally supported\nfor 9 months with the exception of the LTS releases being supported for 5 years.
\nIf you check out the Ubuntu Pro website, you can find the following\nstatement:
\n\n\nUbuntu Pro
\nThe most comprehensive subscription for open-source software security
\n30-day trial for enterprises. Always free for personal use.
\n
Ubuntu Pro for personal use consists of 5 installations and in case of the\ncommunity ambassadors 50.
Overall if you try to find what is included in the Ubuntu Pro:
\nIf we get back to the screenshot all the way at the beginning of the post:\n
and try to look up to which repository the packages mentioned in the screenshot\nbelong, we will find out that they belong to universe repository which is\nmaintained by the community. Not to mention nature of the packages: multimedia.
You may think about this as a scam, but considering repository consisting of 70k\npackages, it is not an easy task to do. And with LTS releases we're talking\nabout 5+ years of support.
\nTry to compare this state to Fedora. It also has a 6-month release cycle, but\nthere are no LTS releases and each release is supported only for a year.
Common strategy, at this point, is to pull out the open-source. Yes, we are\nstill dealing with the open-source, but keep in mind that you're trying to patch\nsome issue in a version that's 5 years old, upstream definitely doesn't care\nanymore4, the development didn't stop 5 years ago, it's going on and fixing\nthis issue in a release from 5 years is not the same as fixing it in the current\nrelease. At this point, if you are paying for such support, you are actually\npaying for someone to do software archaeology which can be non-trivial\nto do.
\nIn the case of Ubuntu Pro we're talking about community support and best-effort\nsupport by Canonical for the paying customers. And that makes sense to me,\nrunning LTS distro for 5+ years on a desktop seems like an odd choice, even\nwith the help of podman and distrobox or toolbx that allow us to use\nstable or LTS distro as a base and containerized development environments on top\nof that.
\nRHEL ecosystem is much more complicated in this matter. However it's very\nsimilar to the way SUSE operates with few exceptions.
\nYou can see a flow diagram here:
\n\nKey things to take and not to take from the flow diagram:
\nI'll also include a SUSE flow, so you can compare:
You can notice, as opposed to the RHEL ecosystem, some changes are being\nbackported to the openSUSE Leap.
However this is subject to change as there is a new ALP project arising which\nis, more than likely, going to replace the Leap.
The flow I've shown above is in effect since late ‘20 and early ‘21. I hope you\ncan see that it is quite similar to the way SUSE operates too. Before late ‘20\nthe flow was following:
\n\nCentOS was the last distribution in that “chain”. This provides some benefits\nand some negatives.
\nFrom the point of a developer, unless you have some kind of an early access to\nRHEL, you don't see the changes until they land and are already released. This\nimpairs your ability to test and verify your software before shipping it to your\nclients that use RHEL.
\nFrom the point of a user, there is one positive, you basically get “free RHEL”\nwithout the support. This also allowed you to report bugs against the RHEL,\nsince they were 1:1 distros (minus the branding and support). So you'd\ntechnically get RHEL free of charge.
\nBenefit of such project, except for the cost, is questionable. The main issue,\nwhich actually became even more apparent after changing the flow, is someone\nelse repackaging your own product and selling it again.
\nFirst of all, the current flow counters the issue mentioned above. You can test\nyour projects against the next minor RHEL release. CentOS Stream is free, so\nyou can freely incorporate it into your CI pipelines.
\nAgain, Packit can help you on upstream to verify that you're not breaking your\nRPM builds and on top of that you can also use Testing Farm to run tests on a\nspecific Fedora or CentOS Stream releases.
\nGreen tests may not be green everywhere and catching such issues as soon as\npossible costs much less than catching them further down the chain.
\n
There are many people thinking that RHEL has become closed-source. It is not.\nThe development happens out in the open, it's more open that it was before.\nHowever with the cost of not getting the exact same thing for free. You can get\nthe next minor RHEL, not the same that's normally paid for. Packit is an\nexample of a service that is deployed on the CentOS 9 Stream and even used to be\ndeployed on Fedora, but the regular 6-month release cycle caused some minor\nissues here and there.
\nProduction-ready is something that heavily depends on the context…
\nAfter this change so-called free “clones” emerged. I have to admit that in\ncase of AlmaLinux I can see some benefits e.g., pushing for live images and\nsupport of various desktop environments, Raspberry Pi support or even WSL images\nbeing present in the M$ Store and easy to install.
Overall I don't think that paying for the support of 5 years old non-critical\npackages is going against the open-source. It is a non-trivial work that, in\nmajority of cases, cannot be included in the upstream, therefore the benefit is\nreapt only by the paying customers. I have to admit that in the case of the\nUbuntu Pro it may seem a bit weird (hiding patches behind the paywall). However\nwe're still talking about rather big set of packages that will affect a minority\nof server workloads, if any.
\nrolling release - continuously released without “significant milestones”
\nAs an example of rolling distribution you can take archLinux, openSUSE\nTumbleweed, Fedora Rawhide, or even CentOS 9 Stream.
As en example of not rolling distribution you can take Ubuntu, openSUSE\nLeap or Fedora.
bleeding edge - contains the latest versions as they are released on the\nupstream
\nAs an example you can take archLinux, openSUSE Tumbleweed or Fedora Rawhide.\nYou can also notice how common it is to combine rolling release with\nbleeding edge.
upstream & downstream
\nYou're most likely to meet these terms in the meaning of upstream being the\nproject itself and downstream being the packaging of said project in some\ndistribution.
\nHowever this can also apply to distributions like openSUSE Tumbleweed with\nopenSUSE Leap, Fedora with CentOS Stream, or even CentOS Stream with\nRHEL. This basically means that the packages/software is being released into\nthe upstream (Tumbleweed, Fedora, or even CentOS) and then after being tested\nis taken further down into their respective downstreams (Leap, CentOS, RHEL).
\nRust has become a rather popular language these days. I've managed to get my\nhands dirty with it during Advent of Code ‘22 and partially ‘23. I've also\nused it for few rounds of Codeforces and I have to try very hard to maintain\nsome variety of languages for LeetCode challenges along with Rust. I'll disclaim\nup front that I won't be only positive, since this post is a result of multiple\ndiscussions about Rust and I stand by “All that glitters is not gold”, so if\nyou can't stand your favorite language being criticized in any way, don't even\nproceed. 😉
\nI'll start by kicking the biggest benefit of the language, the memory safety.\nLet's be honest here, majority of the checks rely on the static analysis, cause\nyou can't do anything else during the compile-time, right? Therefore we can\nbasically say that we are relying on the compiler to “solve” all of our issues.
\nI'm not doubting the fact that compiler can prevent a lot of the memory\nerrors, I'm just saying it's not realistic to cover everything.
I guess we can safely1 agree on the fact that we 100% rely on the compiler to\nhave our back. Is the compiler bug-free? I doubt it. This is not meant in an\noffensive way to the Rust compiler developers, but we need to be realistic here.\nIt's a compiler, even older and larger projects like gcc or llvm can't avoid\nbugs to appear.
\nWhen I was trying out Rust for some of the LeetCode challenges I've stumbled\nupon the following warning:\n![\"Example](\"https://i.imgur.com/NfPLF6o.png\")
The issue here comes from the fact that we have 2 simultaneous references to the\nsame memory (one is mutable and one immutable). If you cannot think of any way\nthis can break, I'll give you a rather simple example from C++ where this could\ncause an issue.
Imagine a function that has some complex object and also calls a coroutine which\nutilizes read-only reference to that object. When the coroutine suspends, the\ncaller can modify the object. This can break the integrity of data read by the\ncoroutine.
Fixing this bug is not backwards compatible, cause you're covering a case that\nhasn't been covered before.
One of the ways Rust enforces the safety is by restricting what you can do, like\nthe example above. Aforementioned issue can happen, but doesn't have to.\nRule of the thumb in the Rust compiler is to “block” anything that can be an\nissue, static analysis can't do much more, it cannot decide whether it's safe to\ndo it or not.
\nSatisfying the Rust compiler is sometimes a brutal pain in the ass, because you\ncannot do things like you're used to, you need to work around them somehow.
\nKey difference between Rust and C or C++ lies in the fact that Rust chooses to\nban all “potentially offensive” actions, C and C++ relies on you to be\nsure it's safe to do.
![\"C++](\"https://i.imgur.com/0vbkYPp.png\")
Where are we heading with this approach of “if it compiles, it runs” though?\nIn this aspect I have a rather similar opinion as with regards to the ChatGPT\nand its derivatives.
\nIf you teach people to 100% depend on the compiler, they will do it, cause it's\neasy. All you need to do is make the compiler shut up2. Giving up the\nintellectual masturbation about the memory safety will make you lose your edge\nover the time. When we get to the point of everyone being in the mindset\nmentioned above, who's going to maintain the compiler? This is the place where\nyou need to think about the memory safety and furthermore in a much more\ngeneral way than in your own projects, because it is the thing that everyone\nblindly believes in in the end.
\nI'm not saying that everyone should give up Rust and think about their memory\nmanagement and potential memory issues. I'm just saying that going the easy way\nwill make people dull and they should think about it anyways, that's how the\nissue above has been discovered. If everyone walked past and didn't think about\nit, no one would discover this issue till it bit them hard.
\nEven the standard library is littered with unsafe blocks that are prefixed\nwith comments in style:
// SAFETY: …
The fact that the casual Rust dev doesn't have to think much about safety,\ncause the compiler has their back, doesn't mean that the Rust compiler dev\ndoesn't either.
I gotta admit that I adopted this concept in other languages (even in Python),\ncause you can encounter situations where it doesn't have to be clear why you\ncan do what you're doing.
Development of Rust is… very fast. One positive is that they're trying to be as\nbackward compatible as possible at least by verifying against all the published\ncrates in the process. Of course, you cannot be backward compatible about fixing\nthe bugs that have been found, but such is life.
\nOne of the negatives of the fast development cycle is the fact that they're\nusing the latest features already in the next release of Rust. Yes, it is\nsomething that you can use for verifying and testing your own changes, but at\nthe same time it places a requirement of the latest release to compile the next\none.
\nIf you check gcc for example, they have a requirement of minimal version of\ncompiler that you need for the build. Though gcc's requirement is not so needy\nas the Rust one.
One of the other negatives is the introduction of bugs. If you're pushing\nchanges, somewhat mindlessly, at such a fast pace, it is inevitable to introduce\na bunch bugs in the process. Checking the GitHub issue tracker with
\nis:issue is:open label:C-bug label:T-compiler
yields 2,224 open issues at the time of writing this post.
\nYou can find a lot of RFCs for Rust. Some of them are more questionable than\nthe others. Fun thing is that a lot of them make it to the nightly builds, so\nthey can be tested and polished off. Even the questionable ones… I'll leave\na few examples for a better understanding.
\nOne of such features is the do yeet expression:
#![feature(yeet_expr)]
fn foo() -> Result<String, i32> {
do yeet 4;
}
assert_eq!(foo(), Err(4));
fn bar() -> Option<String> {
do yeet;
}
assert_eq!(bar(), None);
It allows you to “yeet” the errors out of the functions that return Result or\nOption.
One of the more recent ones is\nthe ability to include Cargo manifests into the sources, so you can do something\nlike:
\n#!/usr/bin/env cargo
---
[dependencies]
clap = { version = \"4.2\", features = [\"derive\"] }
---
use clap::Parser;
#[derive(Parser, Debug)]
#[clap(version)]
struct Args {
#[clap(short, long, help = \"Path to config\")]
config: Option<std::path::PathBuf>,
}
fn main() {
let args = Args::parse();
println!(\"{:?}\", args);
}
I would say you can get almost anything into the language…
\nRust community is a rather unique thing. A lot of people will hate me for this,\nbut I can't help, but to compare them to militant vegans. I'll go through some\nof the things related to it, so I can support my opinion at least.
\nRust is the best language. It is not. There is no best language, each has its\nown positives and negatives, you need to choose the language that's the most\nsuitable for your use case. There are areas where Rust excels, though I have\nto admit it's very close to being a universal hammer regardless of how suitable\nit is. There is a very steep learning curve to it, beginnings in Rust are very\npainful.
\nRewrite everything in Rust. Just no. There are multiple feedbacks on doing\nrewrites, it is very common to fix N bugs with a rewrite while introducing\nN + 1 other bugs in the process. It doesn't solve anything unless there are\nsome strong reasons to go with it. Majority of such suggested rewrites don't\nhave those reasons though.
\nLanguage ‹x› is bad, though in Rust… Cherry-picking one specific pain point of\none language and reflecting how it is better in other language can go both ways.\nFor example it is rather easy to pick the limitations imposed by Rust compiler\nand show how it's possible in other languages 🤷♂️
\nI don't mind any of those opinions, you're free to have them, as long as you\ndon't rub them in my face which is not the usual case… This experience makes it\njust worse for me, part of this post may be also influenced by this fact.
\nAs someone who has seen the way Linux kernel is built in the RHEL ecosystem, how\ncomplex the whole thing is and how much resources you need to proceed, I have\nvery strong opinions on this topic.
It took years of work to even “incorporate” Rust into the Linux codebase, just\nto get the “Hello World!”. I don't have anything against the idea of writing\ndrivers in Rust, I bet it can catch a lot of common mistakes, but still\nintroducing Rust to the kernel is another step to enlarge the monster.
\nI have to admit though that the Apple GPU driver for Linux written in Rust is\nquite impressive. Apart from that there are not so many benefits, yet…
\nI'll divide the packaging into the packaging of the language itself and the\nprograms written in Rust.
\nLet's start with the cargo itself though. Package managers of the languages\nusually get a lot of hate (you can take npm or pip as examples3). If\nyou've ever tried out Rust, I bet you already know where I'm going with this.\nYes, I mean the compilation times, or even Cargo downloading whole index of\ncrates just so you can update that one dependency (and 3 millions of indirect\ndeps). When I was doing AoC ‘22 in Rust, I've set up sccache right away on the\nfirst day.
Let's move to the packaging of the Rust itself, it's tedious. Rust has a very\nfast development cycle and doesn't even try to make the builds backward\ncompatible. If there is a new release of Rust, there is a very high chance that\nyou cannot build that release with anything other than the latest Rust\nrelease. If you have ever touched the packaging, you know that this is something\nthat can cause a lot of problems, cause you need the second-to-latest version to\ncompile the latest version, don't forget that this applies inductively… People\nrunning Gentoo could tell you a lot about this.
\nCompiling the compilers takes usually more time than compiling the kernel\nitself…
I cannot speak about packaging of Rust programs in other than RHEL-based\ndistros, though I can speak about RHEL ecosystem. Fedora packaging guidelines\nspecify that you need to build each and every dependency of the program\nseparately. I wanted to try out AlmaLinux and install Alacritty there and I\nfailed miserably. The solution that worked, consisted of ignoring the packaging\nguidelines, running cargo build and consuming the binaries afterwards.\nDependencies of the Rust programs are of a similar nature as JS dependencies.
\n\nI'm tipping my fedora1 in the general direction of the maintainers of Rust\npackages in RHEL ecosystem. I wouldn't be able to do this without losing my\nsanity.
\n
If you've come all the way here and you're a Rustacean, I believe I've managed\nto get your blood boiling, so it's time to finish this off by stuff I like about\nRust. I doubt I will be able to cover everything, but I can try at least. You\nhave to admit it's much easier to remember the bad stuff as opposed to the good.\n😉
\nI prefered using Rust for the Advent of Code and Codeforces as it provides\na rather easy way to test the solutions before running them with the challenge\ninput (or test runner). I can give an example from the Advent of Code:
\nuse aoc_2023::*;
type Output1 = i32;
type Output2 = Output1;
struct DayXX {}
impl Solution<Output1, Output2> for DayXX {
fn new<P: AsRef<Path>>(pathname: P) -> Self {
let lines: Vec<String> = file_to_lines(pathname);
todo!()
}
fn part_1(&mut self) -> Output1 {
todo!()
}
fn part_2(&mut self) -> Output2 {
todo!()
}
}
fn main() -> Result<()> {
DayXX::main()
}
test_sample!(day_XX, DayXX, 42, 69);
This was the skeleton I've used and the macro at the end is my own creation that\nexpands to:
\n#[cfg(test)]
mod day_XX {
use super::*;
#[test]
fn part_1() {
let path = DayXX::get_sample(1);
let mut day = DayXX::new(path);
assert_eq!(day.part_1(), 42);
}
#[test]
fn part_2() {
let path = DayXX::get_sample(2);
let mut day = DayXX::new(path);
assert_eq!(day.part_2(), 69);
}
}
When you're solving the problem, all you need to do is switch between\ncargo test and cargo run to check the answer to either sample or the\nchallenge input itself.
Introduce bacon and it gets even better. Bacon is a CLI tool that wraps around\nthe cargo and allows you to check, run, lint or run tests on each file save.\nIt's a very pleasant thing for a so-called compiler-assisted development.
Speaking of linting from within the bacon, you cannot leave out the clippy.\nNot only it can whip your ass because of errors, but it can also produce a lot\nof helpful suggestions, for example passing slices by borrow instead of\nborrowing the Vec itself when you don't need it.
There's a lot included in the standard library. It almost feels like you\nhave all you need4. I like placeholders (like todo!(), unreachable!(),\nunimplemented!()) to the extent of\nimplementing them as exceptions in C++.
You can find almost anything. Though you can also hit some very weird issues\nwith some of the nuances of the type system.
\nunsafeThis might be something that people like to avoid as much as possible. However I\nthink that forming a habit of commenting posibly unsafe operations in any\nlanguage is a good habit, as I've mentioned above. You should be able to argue\nwhy you can do something safely, even if the compiler is not kicking your ass\nbecause of it.
\nExcerpt of such comment from work:
\n# SAFETY: Taking first package instead of specific package should be
# safe, since we have put a requirement on »one« ‹upstream_project_url›
# per Packit config, i.e. even if we're dealing with a monorepo, there
# is only »one« upstream. If there is one upstream, there is only one
# set of GPG keys that can be allowed.
return self.downstream_config.packages[
self.downstream_config._first_package
].allowed_gpg_keys
One of the other things I like are the traits. They are more restrictive than\ntemplates or concepts in C++, but they're doing their job pretty good. If you\nare building library and require multiple traits to be satisfied it means a lot\nof copy-paste, but that's soon to be fixed by the trait aliases.
\nOn Wikipedia I've seen trait being defined as a more restrictive type class as\nyou may know it from the Haskell for example. C++ isn't behind either with its\nconstraints and concepts. I would say that we can order them in the following\norder based on the complexity they can express:
Rust's trait < Haskell's type class < C++'s concept
You can also hit some issues, like me when trying to support conversions between\nunderlying numeric types of a 2D vectors or support for using an operator from\nboth sides (I couldn't get c * u to work in the same way as u * c because\nthe first one requires you to implement the trait of a built-in type).
Implementing traits lies in
impl SomeTrait for SomeStruct {
// implementation goes here
}
One of the things I would love to see is being able to define the helper\nfunctions within the same block. As of now, the only things allowed are the ones\nthat are required by the trait, which in the end results in a randomly lying\nfunctions around (or in a implementation of the structure itself). I don't like\nthis mess at all…
You can see a big influence of the functional paradigm. Not only in iterators,\nbut also in the other parts of the language. For example I prefer Option<T> or\nResult<T, E> to nulls and exceptions. Pattern matching together with\ncompiler both enforces handling of the errors and rather user-friendly way of\ndoing it.
Not to mention .and_then() and such. However spending most of the time with\nthe AoC you get pretty annoyed of the repetitive .unwrap() during parsing,\nsince you are guaranteed correct input.
Macros are a very strong pro of Rust. And no, we're not going to talk about the\nprocedural macros…
\nAs I've shown above I've managed to “tame” a lot of copy-paste in the tests for\nthe AoC by utilizing a macro that generated a very basic template for the tests.
\nAs I have mentioned the traits above, I cannot forget to give props to derive\nmacro that allows you to “deduce” the default implementation. It is very helpful\nfor a tedious tasks like implementing Debug (for printing out the structures)\nor comparisons, though with the comparisons you need to be careful about the\ndefault implementation, it has already bitten me once or twice.
Overall there are many things about the Rust I like and would love to see them\nimplemented in other languages. However there are also many things I don't like.\nNothing is exclusively black and white.
\n\nWhen you decide to run Fedora on your VPS, you might get screwed over by using\nrandom repositories…
\nWhen I “reserved” my VPS1 back in June '20, I slapped Fedora on it without\nthinking. I bet 99% of people would say that I'm crazy for doing such thing2,\nBUT I've been using Fedora on my PCs for some time already and it felt very\nstable and natural to just use, even for VPS.
\nOne of the first things I've done was setting up a mail server. You may guess\nwhat's the fun part about having a mail server… Yes, it's all the spam you\nreceive and only then you realize how much “crap” gets filtered on free mail\nservices. To battle this problem I chose to use\nrspamd that had CentOS support, but someone\nhad a Copr repository that I used to\ninstall it.
\nIf you have ever used Ubuntu, you might be familiar with the concept since it is\nvery close to PPAs.
\ntl;dr of the whole process consists of
\nSo in shell you would do
\n# dnf copr enable ‹copr-repository›
# dnf install ‹package-from-the-repository›
And… that's it! Nothing else needed! Simple, right? And literally same process\nas you would do for the PPA.
\nOn the other hand, if you are familiar with the archLinux, you definitely know\nAUR and what it can do for you. Copr repository is pretty similar, but the\npackages are prebuilt in Copr and Copr repositories can carry the required\ndependencies for said packages, which simplifies the distribution, and can even\nhelp with installing singular packages (when you just need the dependency, not\neverything).
Now you might wonder how would I use it on my VPS. It's rather simple, once in\n6 months a new Fedora release comes out. And you need to upgrade to newer\nrelease… You don't need to do it right away and for such setup it probably isn't\neven recommended.
\nFedora releases are supported for a year, i.e. they live 6 months till the next\nrelease and then another 6 months till another release.
Some people prefer to run one version “behind”. If you ever decide to run it on\nyour home server or in a similar setup, it might be a pretty good idea to\nfollow. I'm using the “latest greatest”, cause why not 😄
One way or another, you still need to bump the release every six months, unless\nyou'd bump 2 releases at once every year, which would be a decision, since, at\nleast I, cannot see any benefits in it… You don't go for “stability”, cause once\na year you switch to the latest release and then, before you bump, you use one\nyear old software, so you're not even using the latest.
Fast-forward 2 years in the future, new Fedora release came out (October '22)\nand I was doing an upgrade. Dependencies of the rspamd have been updated and\nrspamd builds in Copr have failed and no one fixed it. Cool, so now I can\nupgrade, but can either ignore the dependencies or uninstall the rspamd…
\nI have managed to find\nspecfile for the\nrspamd package that they use for CentOS. There were some files apart from the\nspecfile, so I had to make an SRPM locally and then… I just uploaded the SRPM\nto the Copr to\nbuild\nan RPM.
\nI have switched the previous Copr repository for rspamd with my own and happily\nproceeded with the upgrade.
\nCopr is heavily used for testing builds on the upstream with\nPackit. However, as you can see, it is possible to use it\nvery well for packaging your own stuff and avoiding issues (such as the one\nI have described above), if need be.
\n\nLet's go through the fourth week of Advent of Code in Rust.
\nSimulating a movement on a 2D map with given instructions. Map becomes a cube in\nthe 2nd part…
This was the most obnoxious problem of this year… and a lot of Rust issues have\nbeen hit.
It seems like a very simple problem to solve, but with very obnoxious changes in\nthe 2nd part and also it's relatively hard to decompose »properly«.
\nIn the first part of the problem it was needed to know the boundaries of each\nrow and column, since I stored them in Vec<Vec<char>> and padded with spaces\nto ensure I have a rectangular 2D “array”. However when you wanted to go through\neach row and column to determine the boundaries, it was very easy to do for the\nrows (cause each row is a Vec element), but not for the columns, since they\nspan multiple rows.
For this use case I have implemented my own column iterator:
\npub struct ColumnIterator<'a, T> {
map: &'a [Vec<T>],
column: usize,
i: usize,
}
impl<'a, T> ColumnIterator<'a, T> {
pub fn new(map: &'a [Vec<T>], column: usize) -> ColumnIterator<'a, T> {
Self { map, column, i: 0 }
}
}
impl<'a, T> Iterator for ColumnIterator<'a, T> {
type Item = &'a T;
fn next(&mut self) -> Option<Self::Item> {
if self.i >= self.map.len() {
return None;
}
self.i += 1;
Some(&self.map[self.i - 1][self.column])
}
}
Given this piece of an iterator, it is very easy to factor out the common\nfunctionality between the rows and columns into:
\nlet mut find_boundaries = |constructor: fn(usize) -> Orientation,
iterator: &mut dyn Iterator<Item = &char>,
upper_bound,
i| {
let mut first_non_empty = iterator.enumerate().skip_while(|&(_, &c)| c == ' ');
let start = first_non_empty.next().unwrap().0 as isize;
let mut last_non_empty = first_non_empty.skip_while(|&(_, &c)| c != ' ');
let end = last_non_empty.next().unwrap_or((upper_bound, &'_')).0 as isize;
boundaries.insert(constructor(i), start..end);
};
And then use it as such:
\n// construct all horizontal boundaries
(0..map.len()).for_each(|row| {
find_boundaries(
Orientation::horizontal,
&mut map[row].iter(),
map[row].len(),
row,
);
});
// construct all vertical boundaries
(0..map[0].len()).for_each(|col| {
find_boundaries(
Orientation::vertical,
&mut ColumnIterator::new(&map, col),
map.len(),
col,
);
});
Once the 2nd part got introduced, you start to think about a way how not to\ncopy-paste a lot of stuff (I haven't avoided it anyways…). In this problem, I've\nchosen to introduce a trait (i.e. interface) for 2D and 3D walker.
\ntrait Wrap: Clone {
type State;
// simulation
fn is_blocked(&self) -> bool;
fn step(&mut self, steps: isize);
fn turn_left(&mut self);
fn turn_right(&mut self);
// movement
fn next(&self) -> (Self::State, Direction);
// final answer
fn answer(&self) -> Output;
}
Each walker maintains its own state and also provides the functions that are\nused during the simulation. The “promised” methods are separated into:
\n.fold()Both 2D and 3D versions borrow the original input and therefore you must\nannotate the lifetime of it:
\nstruct Wrap2D<'a> {
input: &'a Input,
position: Position,
direction: Direction,
}
impl<'a> Wrap2D<'a> {
fn new(input: &'a Input) -> Wrap2D<'a> {
// …
I have used a lot of closures for this problem and once I introduced a parameter\nthat was of unknown type (apart from the fact it implements a specific trait), I\ngot suggested a “fix” for the compilation error that resulted in something that\nwas not possible to parse, cause it, more than likely, violated the grammar.
\nIn a similar fashion, I have been suggested changes that led to a code that\ndidn't make sense by just looking at it (there was no need to try the changes),\nfor example one suggested change in the closure parameter caused disapperance of\nthe parameter name. 😄
\nI have to admit that Clippy was rather helpful here, I'll include two examples\nof rather smart suggestions.
\nWhen writing the parsing for this problem, the first thing I have spotted on the\nchar was the .is_digit() function that takes a radix as a parameter. Clippy\nnoticed that I use radix = 10 and suggested switching to .is_ascii_digit()\nthat does exactly the same thing:
- .take_while(|c| c.is_digit(10))
+ .take_while(|c| c.is_ascii_digit())
Another useful suggestion appeared when working with the iterators and I wanted\nto get the n-th element from it. You know the .skip(), you know the\n.next(), just “slap” them together and we're done for 😁 Well, I got\nsuggested to use .nth() that does exactly the combination of the two mentioned\nmethods on iterators:
- match it.clone().skip(skip).next().unwrap() {
+ match it.clone().nth(skip).unwrap() {
Simulating movement of elves around with a set of specific rules.
There's not much to mention since it's just a cellular automaton simulation\n(even though the AoC rules for cellular automatons usually get out of hand\n😉).
\nAlthough I had a need to determine boundaries of the elves' positions and ended\nup with a nasty DRY violation. Knowing that you you're looking for maximum and\nminimum that are, of course, exactly the same except for initial values and\ncomparators, it looks like a rather simple fix, but typing in Rust is something\nelse, right? In the end I settled for a function that computes both boundaries\nwithout any duplication while using a closure:
\nfn get_bounds(positions: &Input) -> (Vector2D<isize>, Vector2D<isize>) {
let f = |init, cmp: &dyn Fn(isize, isize) -> isize| {
positions
.iter()
.fold(Vector2D::new(init, init), |acc, elf| {
Vector2D::new(cmp(acc.x(), elf.x()), cmp(acc.y(), elf.y()))
})
};
(f(isize::MAX, &min::<isize>), f(isize::MIN, &max::<isize>))
}
This function returns a pair of 2D vectors that represent opposite points of the\nbounding rectangle of all elves.
\nYou might ask why would we need a closure and the answer is that positions\ncannot be captured from within the nested function, only via closure. One more\nfun fact on top of that is the type of the comparator
&dyn Fn(isize, isize) -> isize
Once we remove the dyn keyword, compiler yells at us and also includes a way\nhow to get a more thorough explanation of the error by running
$ rustc --explain E0782
which shows us
\n\n\nTrait objects must include the
\ndynkeyword.Erroneous code example:
\n\ntrait Foo {}
fn test(arg: Box<Foo>) {} // error!Trait objects are a way to call methods on types that are not known until\nruntime but conform to some trait.
\nTrait objects should be formed with
\nBox<dyn Foo>, but in the code above\ndynis left off.This makes it harder to see that
\nargis a trait object and not a\nsimply a heap allocated type calledFoo.To fix this issue, add
\ndynbefore the trait name.\ntrait Foo {}
fn test(arg: Box<dyn Foo>) {} // ok!This used to be allowed before edition 2021, but is now an error.
\n
Not all of the explanations are helpful though, in some cases they might be even\nmore confusing than helpful, since they address very simple use cases.
As you can see, even in this case there are two sides to the explanations:
dyn, butBox<T>\nthat, as you can see in my snippet, does not apply here 😄 IMO it's\ncaused by the fact that we are borrowing it and therefore we don't need to\ncare about the size or whereabouts of it.If you dive into the explanation above, you can notice that the Box<dyn Trait>\npattern is very helpful for using types that are not known during compile-time.\nYou would use a very similar approach in C++ when parsing some data structure\nfrom input (let's say JSON for example).
On the other hand, in this case, it doesn't really make much sense, cause you\ncan clearly see that the types are known during the compile-time, which in\nC++ could be easily resolved by templating the helper function.
Navigating your way through a basin with series of blizzards that move around\nyou as you move.
It's second to last day and I went “bonkers” on the Rust 😄 Proceed to\nread Solution part on your own risk.
You are given a map with blizzards all over the place and you're supposed to\nfind the minimum time it requires you to walk through the basin without getting\nin any of the blizzards.
\nRelatively simple, yet a bit annoying, approach can be taken. It's technically\na shortest-path algorithm implementation with some relaxation restrictions and\nbeing able to stay on one position for some time, so each vertex of the graph\nis determined by the position on the map and the timestamp. I have chosen to\nuse Vector3D<usize>, since x and y attributes can be used for the position\nand, well, let's use z for a timestamp, cause why not, right? 😉
I think that this is the most perverted abuse of the traits in the whole 4 weeks\nof AoC in Rust…
The blizzards move along their respective directions in time and loop around in\ntheir respective row/column. Each vertex holds position and time, so we can\njust index the basin with the vertex itself, right? Yes, we can 😈
\nWhile writing this part, I've recognized unnecessary verbosity in the code and\ncleaned it up a bit. The changed version is shown here and the original was just\nmore verbose.
I'll skip the boring parts of checking bounds and entry/exit of the basin 😉\nWe can easily calculate positions of the blizzards using a modular arithmetics:
\nimpl Index<Position> for Basin {
type Output = char;
fn index(&self, index: Position) -> &Self::Output {
// ‹skipped boring parts›
// We need to account for the loops of the blizzards
let width = self.cols - 2;
let height = self.rows - 2;
let blizzard_origin = |size, d, t, i| ((i - 1 + size + d * (t % size)) % size + 1) as usize;
[
(
index.y() as usize,
blizzard_origin(width, -1, index.z(), index.x()),
'>',
),
(
index.y() as usize,
blizzard_origin(width, 1, index.z(), index.x()),
'<',
),
(
blizzard_origin(height, -1, index.z(), index.y()),
index.x() as usize,
'v',
),
(
blizzard_origin(height, 1, index.z(), index.y()),
index.x() as usize,
'^',
),
]
.iter()
.find_map(|&(y, x, direction)| {
if self.map[y][x] == direction {
Some(&self.map[y][x])
} else {
None
}
})
.unwrap_or(&'.')
}
}
As you can see, there is an expression for calculating the original position and\nit's used multiple times, so why not take it out to a lambda, right? 😉
\nI couldn't get the rustfmt to format the for-loop nicely, so I've just\ndecided to go with iterating over an elements of a slice. I have used, once\nagain, a combination of two functions (find_map in this case) to do 2 things\nat once and at the end, if we haven't found any blizzard, we just return the\nempty space.
I think it's a very nice (and naughty) way how to use the Index trait, don't\nyou think?
For the shortest path you can choose and adjust any of the common shortest-path\nalgorithms, in my case, I have decided to use A* instead of Dijkstra's\nalgorithm, since it better reflects the cost function.
\nWith the Dijkstra's algorithm I would proceed with the time attribute used as\na priority for the queue.
Whereas with the A*, I have chosen to use both time and Manhattan distance\nthat promotes vertices closer to the exit and with a minimum time taken.
Cost function is, of course, a closure 😉
\nlet cost = |p: Position| p.z() as usize + exit.y().abs_diff(p.y()) + exit.x().abs_diff(p.x());
And also for checking the possible moves from the current vertex, I have\nimplemented, yet another, closure that yields an iterator with the next moves:
\nlet next_positions = |p| {
[(0, 0, 1), (0, -1, 1), (0, 1, 1), (-1, 0, 1), (1, 0, 1)]
.iter()
.filter_map(move |&(x, y, t)| {
let next_p = p + Vector3D::new(x, y, t);
if basin[next_p] == '.' {
Some(next_p)
} else {
None
}
})
};
In this case I had a need to use the priority queue taking the elements with the\nlowest cost as the prioritized ones. Rust only offers you the BinaryHeap and\nthat is a max-heap. One of the ways how to achieve a min-heap is to put the\nelements in wrapped in a Reverse (as is even showed in the linked docs of\nthe BinaryHeap). However the wrapping affects the type of the heap and also\npopping the most prioritized elements yields values wrapped in the Reverse.
For this purpose I have just taken the max-heap and wrapped it as a whole in a\nseparate structure providing just the desired methods:
\nuse std::cmp::{Ord, Reverse};
use std::collections::BinaryHeap;
pub struct MinHeap<T> {
heap: BinaryHeap<Reverse<T>>,
}
impl<T: Ord> MinHeap<T> {
pub fn new() -> MinHeap<T> {
MinHeap {
heap: BinaryHeap::new(),
}
}
pub fn push(&mut self, item: T) {
self.heap.push(Reverse(item))
}
pub fn pop(&mut self) -> Option<T> {
self.heap.pop().map(|Reverse(x)| x)
}
}
impl<T: Ord> Default for MinHeap<T> {
fn default() -> Self {
Self::new()
}
}
Rest is just the algorithm implementation which is not that interesting.
\nPlaying around with a numbers in a special base.
Getting flashbacks to the IB111 Foundations of Programming… Very nice “problem”\nwith a rather easy solution, as the last day always seems to be.
\nImplementing 2 functions, converting from the SNAFU base and back to the SNAFU\nbase representation. Let's do a bit more though! I have implemented two functions:
\nfrom_snafuto_snafuNow it is apparent that all I do is number to string and string to number. Hmm…\nthat sounds familiar, doesn't it? Let's introduce a structure for the SNAFU numbers\nand implement the traits that we need.
\nLet's start with a structure:
\n#[derive(Debug, PartialEq, Eq, PartialOrd, Ord)]
struct SNAFU {
value: i64,
}
&strWe will start by implementing the FromStr trait that will help us parse our input.\nThis is rather simple, I can just take the from_snafu function, copy-paste it\ninto the from_str method and the number I get will be wrapped in Result and\nSNAFU structure.
StringThis is more fun. In some cases you need to implement only one trait and others\nare automatically implemented using that one trait. In our case, if you look in\nthe documentation, you can see that ToString trait is automatically implemented\nfor any type that implements Display trait.
Let's implement the Display trait then. We should be able to use the to_snafu\nfunction and just take the self.value from the SNAFU structure.
And for the convenience of tests, we can also implement a rather simple From<i64>\ntrait for the SNAFU.
After those changes we need to adjust the code and tests.
\nParsing of the input is very easy, before we have used the lines, now we parse\neverything:
\n fn parse_input<P: AsRef<Path>>(pathname: P) -> Input {
- file_to_lines(pathname)
+ file_to_structs(pathname)
}
Part 1 needs to be adjusted a bit too:
\n fn part_1(input: &Input) -> Output {
- to_snafu(input.iter().map(|s| from_snafu(s)).sum())
+ SNAFU::from(input.iter().map(|s| s.value).sum::<i64>()).to_string()
}
You can also see that it simplifies the meaning a bit and it is more explicit than\nthe previous versions.
\nAnd for the tests:
\n #[test]
fn test_from() {
- for (n, s) in EXAMPLES.iter() {
- assert_eq!(from_snafu(s), *n);
+ for (&n, s) in EXAMPLES.iter() {
+ assert_eq!(s.parse::<SNAFU>().unwrap().value, n);
}
}
#[test]
fn test_to() {
- for (n, s) in EXAMPLES.iter() {
- assert_eq!(to_snafu(*n), s.to_string());
+ for (&n, s) in EXAMPLES.iter() {
+ assert_eq!(SNAFU::from(n).to_string(), s.to_string());
}
Let's wrap the whole thing up! Keeping in mind both AoC and the Rust…
\n![\"Finished](\"https://blog.mfocko.dev/assets/images/calendar-f891b624f3e0efb34bba582100a7d8df.png\")
This year was quite fun, even though most of the solutions and posts came in\nlater on (cough in '23 cough). Day 22 was the most obnoxious one… And also\nit feels like I used priority queues and tree data structures a lot 👀
\nI must admit that a lot of compiler warnings and errors were very useful. Even\nthough I still found some instances where they didn't help at all or cause even\nworse issues than I had. Compilation times have been addressed with the caching.
\nBuilding my first tree data structure in Rust has been a very “interesting”\njourney. Being able to write a more generic BFS algorithm that allows you to not\nduplicate code while still mantaining the desired functionality contributes to\na very readable code.
\nI am definitely much more aware of the basic things that bloated Python is\nmissing, yet Rust has them…
\nUsing explicit types and writing down placeholder functions with todo!()\nmacros is very pleasant, since it allows you to easily navigate the type system\nduring the development when you don't even need to be sure how are you going to\nput the smaller pieces together.
I have used a plethora of traits and also implemented some of them to either be\nidiomatic, or exploit the syntactic sugar they offer. Deriving the default trait\nimplementation is also very helpful in a lot of cases, e.g. debugging output,\ncopying, equality comparison, etc.
\nI confess to touching more “cursed” parts of the Rust, such as macros to\ndeclutter the copy-paste for tests or writing my own structures that need to\ncarry a lifetime for their own fields.
\ntl;dr Relatively pleasant language until you hit brick wall 😉
\nSee you next year! Maybe in Rust, maybe not 🙃
", "url": "https://blog.mfocko.dev/blog/aoc-2022/4th-week/", "title": "4th week of Advent of Code '22 in Rust", "summary": "Surviving fourth week in Rust.", "date_modified": "2023-07-07T15:14:00.000Z", "author": { "name": "Matej Focko", "url": "https://gitlab.com/mfocko" }, "tags": [ "advent-of-code", "advent-of-code-2022", "rust" ] }, { "id": "https://blog.mfocko.dev/blog/aoc-2022/3rd-week/", "content_html": "Let's go through the third week of Advent of Code in Rust.
\nTriangulating a distress beacon based on the information from the sensors.
Relatively easy thing to implement, no major Rust issues hit.
\nFinding a max flow in a graph given some time constraints.
I have used some interesting things to implement this and make it easier for me.
\nI have come across a situation where I needed to keep more information regarding\nthe graph… In that case you can, of course, create a structure and keep it in,\nbut once you have multiple members in the structure it gets harder to work with\nsince you need to address the fields in the structure. When you work with graph,\nyou frequently need to access the vertices and in this case it felt a lot easier\nto implement the indexing in a graph, rather than explicitly access the\nunderlying data structure.
\nHere you can see a rather short snippet from the solution that allows you to\n“index” the graph:
\nimpl Index<&str> for Graph {
type Output = Vertex;
fn index(&self, index: &str) -> &Self::Output {
&self.g[index]
}
}
During the implementation I had to utilize Floyd-Warshall algorithm for finding\nthe shortest path between pairs of vertices and utilized the iproduct! macro\nfrom the itertools. It is a very useful higher-order function that allows\nyou to keep the nesting of the loops at a minimum level while still maintaining\nthe same functionality.
For the second part, you get to split the work between 2 actors. That way you\ncan achieve higher efficiency of the whole process that you're planning, but it\nalso makes it harder to evaluate algorithmically, since you need to check the\ndifferent ways the work can be split.
\nBeing affected by functional programming brain damage™️, I have chosen to\ndo this part by function that returns an iterator over the possible ways:
\nfn pairings(
valves: &BTreeSet<String>,
) -> impl Iterator<Item = (BTreeSet<String>, BTreeSet<String>)> + '_ {
let mapping = valves.iter().collect_vec();
let max_mask = 1 << (valves.len() - 1);
(0..max_mask).map(move |mask| {
let mut elephant = BTreeSet::new();
let mut human = BTreeSet::new();
for (i, &v) in mapping.iter().enumerate() {
if (mask & (1 << i)) == 0 {
human.insert(v.clone());
} else {
elephant.insert(v.clone());
}
}
(human, elephant)
})
}
Simulating an autonomous Tetris where pieces get affected by a series of jets of\nhot gas.
Similarly to the previous day I have created some iterators 😄
\nOnce you need to check for collisions it is very helpful to be able to just\niterate through the positions that can actually collide with the wall or other\npiece.
\nTo get the desired behaviour, you can just compose few smaller functions:
\nfn occupied(shape: &[Vec<char>]) -> impl Iterator<Item = Position> + '_ {
shape.iter().enumerate().flat_map(|(y, row)| {
row.iter().enumerate().filter_map(move |(x, c)| {
if c == &'#' {
Some(Vector2D::new(x as isize, y as isize))
} else {
None
}
})
})
}
In the end, we get relative positions which we can adjust later when given the\nspecific positions from iterator. You can see some interesting parts in this:
\n.enumerate() allows us to get both the indices (coordinates) and the line\nor, later on, the character itself,.flat_map() flattens the iterator, i.e. when we return another iterator,\nthey just get chained instead of iterating over iterators (which sounds pretty\ndisturbing, doesn't it?),.filter_map() which is pretty similar to the “basic” .map()\nwith a one, key, difference that it expects the items of an iterator to be\nmapped to an Option<T> from which it ignores nothing (as in None 😉)\nand also unwraps the values from Some(…).In the solution we cycle through both Tetris-like shapes that fall down and the\njets that move our pieces around. Initially I have implemented my own infinite\niterator that just yields the indices. It is a very simple, yet powerful, piece\nof code:
\nstruct InfiniteIndex {
size: usize,
i: usize,
}
impl InfiniteIndex {
fn new(size: usize) -> InfiniteIndex {
InfiniteIndex { size, i: size - 1 }
}
}
impl Iterator for InfiniteIndex {
type Item = usize;
fn next(&mut self) -> Option<Self::Item> {
self.i = (self.i + 1) % self.size;
Some(self.i)
}
}
However when I'm looking at the code now, it doesn't really make much sense…\nGuess what, we can use a built-in function that is implemented on iterators for\nthat! The function is called .cycle()
On the other hand, I am not going to switch to that function, since it would\nintroduce an another myriad of issues caused by the fact that I create iterators\nright away in the constructor of my structure and the iterators would borrow\nboth the jets and shapes which would introduce a lifetime dependency into the\nstructure.
\nLet's compute a surface area of some obsidian approximated via coordinates of\ncubes.
This day is kinda interesting, because it shows how easily you can complicate the\nproblem and also how much can you screw yourself over with the optimization and\n“smart” approach.
\nFor the first part you need to find the surface area of an obsidian that is\napproximated by cubes. Now, that is a very easy thing to do, just keep the track\nof already added cubes, and check if the newly added cube touches any face of any\nother cube. Simple, and with a BTreeSet relatively efficient way to do it.
However the second part lets you on a secret that there may be some surface area\nfrom the “inside” too and you want to know only the one from the outside of the\nobsidian. I have seen some solutions later, but if you check your data, you might\nnotice that the bounding box of all the cubes isn't that big at all. Therefore I\nchose to pre-construct the box beforehand, fill in the cubes and then just run a\nBFS turning all the lava on the outside into the air. Now you just need to check\ncubes and count how many of their faces touch the air.
\nFinding out the best strategy for building robots to collect geodes.
Not much interesting stuff to mention apart from the suggestion to never believe\nthat the default implementation given by derive macro is what you want, it\ndoesn't have to be. 😄
Shuffling around the circular linked list to find the coordinates.
Now, small rant for this day is in place. They've never mentioned that coordinates\ncan repeat and therefore the values are non-unique. This is something that did\nnot happen in the given sample, but was present in the user input. It took »a lot«\nto realize that this is the issue.
\nI have tried implementing a circular linked list for this… and I have failed\nmiserably. To be fair, I still have no clue why. It was “fun” to play around with\nthe Rc<RefCell<T>>. In the end I failed on wrong answer. I have also encountered\na rather interesting issue with .borrow_mut() method being used on Rc<RefCell<T>>.
.borrow_mut()Consider the following snippet of the code (taken from the documentation):
\nuse std::cell::{RefCell, RefMut};
use std::collections::HashMap;
use std::rc::Rc;
// use std::borrow::BorrowMut;
fn main() {
let shared_map: Rc<RefCell<_>> = Rc::new(RefCell::new(HashMap::new()));
// Create a new block to limit the scope of the dynamic borrow
{
let mut map: RefMut<_> = shared_map.borrow_mut();
map.insert(\"africa\", 92388);
map.insert(\"kyoto\", 11837);
map.insert(\"piccadilly\", 11826);
map.insert(\"marbles\", 38);
}
// Note that if we had not let the previous borrow of the cache fall out
// of scope then the subsequent borrow would cause a dynamic thread panic.
// This is the major hazard of using `RefCell`.
let total: i32 = shared_map.borrow().values().sum();
println!(\"{total}\");
}
We allocate a hash map on the heap and then in the inner block, we borrow it as\na mutable reference, so that we can use it.
\nIt is a very primitive example for Rc<RefCell<T>> and mutable borrow.
If you uncomment the 4th line with use std::borrow::BorrowMut;, you cannot\ncompile the code anymore, because of
Compiling playground v0.0.1 (/playground)
error[E0308]: mismatched types
--> src/main.rs:10:34
|
10 | let mut map: RefMut<_> = shared_map.borrow_mut();
| --------- ^^^^^^^^^^^^^^^^^^^^^^^ expected struct `RefMut`, found mutable reference
| |
| expected due to this
|
= note: expected struct `RefMut<'_, _>`
found mutable reference `&mut Rc<RefCell<HashMap<_, _>>>`
error[E0599]: no method named `insert` found for struct `RefMut<'_, _>` in the current scope
--> src/main.rs:11:13
|
11 | map.insert(\"africa\", 92388);
| ^^^^^^ method not found in `RefMut<'_, _>`
error[E0599]: no method named `insert` found for struct `RefMut<'_, _>` in the current scope
--> src/main.rs:12:13
|
12 | map.insert(\"kyoto\", 11837);
| ^^^^^^ method not found in `RefMut<'_, _>`
error[E0599]: no method named `insert` found for struct `RefMut<'_, _>` in the current scope
--> src/main.rs:13:13
|
13 | map.insert(\"piccadilly\", 11826);
| ^^^^^^ method not found in `RefMut<'_, _>`
error[E0599]: no method named `insert` found for struct `RefMut<'_, _>` in the current scope
--> src/main.rs:14:13
|
14 | map.insert(\"marbles\", 38);
| ^^^^^^ method not found in `RefMut<'_, _>`
Some errors have detailed explanations: E0308, E0599.
For more information about an error, try `rustc --explain E0308`.
error: could not compile `playground` due to 5 previous errors
It might seem a bit ridiculous. However, I got to a point where the compiler\nsuggested use std::borrow::BorrowMut; and it resulted in breaking parts of the\ncode that worked previously. I think it may be a good idea to go over what is\nhappening here.
.borrow_mut() on Rc<RefCell<T>>Let's consider a variable x of type Rc<RefCell<T>>. What happens when you\ncall .borrow_mut() on it? We can look at the Rc type, and… hang on! There is\nneither .borrow_mut() method or BorrowMut trait implemented. How can we do it\nthen?
Let's go further and we can see that RefCell<T> implements a .borrow_mut()\nmethod. OK, but how can we call it on the Rc<T>? Easily! Rc<T> implements\nDeref<T> and therefore you can call methods on Rc<T> objects as if they were\nT objects. If we read on Deref coercion, we can see the following:
\n\nIf
\nTimplementsDeref<Target = U>, …:\n
\n- …
\n- \n
Timplicitly implements all the (immutable) methods of the typeU.
What is the requirement for the .borrow_mut() on RefCell<T>? Well, it needs\n&self, so the Deref implements the .borrow_mut() for the Rc<RefCell<T>>.
BorrowMut traitI have not been able to find a lot on this trait. My guess is that it provides a\nmethod instead of a syntactic sugar (&mut x) for the mutable borrow. And also\nit provides default implementations for the types:
impl BorrowMut<str> for String
impl<T> BorrowMut<T> for &mut T
where
T: ?Sized,
impl<T> BorrowMut<T> for T
where
T: ?Sized,
impl<T, A> BorrowMut<[T]> for Vec<T, A>
where
A: Allocator,
impl<T, A> BorrowMut<T> for Box<T, A>
where
A: Allocator,
T: ?Sized,
impl<T, const N: usize> BorrowMut<[T]> for [T; N]
Now the question is why did it break the code… My first take was that the type\nRc<RefCell<T>> has some specialized implementation of the .borrow_mut() and\nthe use overrides it with the default, which is true in a sense. However\nthere is no specialized implementation. Let's have a look at the trait and the\ntype signature on the RefCell<T>:
// trait
pub trait BorrowMut<Borrowed>: Borrow<Borrowed>
where
Borrowed: ?Sized,
{
fn borrow_mut(&mut self) -> &mut Borrowed;
}
// ‹RefCell<T>.borrow_mut()› type signature
pub fn borrow_mut(&self) -> RefMut<'_, T>
I think that we can definitely agree on the fact that RefMut<'_, T> is not the\nRefCell<T>.
In my opinion, RefCell<T> implements a separate .borrow_mut() rather\nthan implementing the interface, because it cannot satisfy the type requirements\nof the trait.
I wonder how are we expected to deal with this conflict, if and when, we need\nboth the .borrow_mut() of the trait and .borrow_mut() of the RefCell<T>.
I was suggested by the compiler to do use std::borrow::BorrowMut; and break the\ncode.
So much for the almighty and helpful compiler…
Computing an expression tree and then also finding ideal value for a node.
Relatively simple, until you get to the 2nd part where you start to practice\na lot of the copy-paste. I have managed to sneak some perverted stuff in there\nthough :) Let's go through the details.
\nDefault traitFor the first time and twice I had a need to have a default value for my types,\nenumerations in this case. Rust offers a very nice trait1 that is described\nas:
\n\n\nA trait for giving a type a useful default value.
\n
I guess it sums it up nicely. The more interesting part about this is the fact\nthat you can use the macro machinery to save yourself some typing. If you have\nenumeration of which the default value doesn't bear any parameter, you can just\ndo2:
\n#[derive(Default)]
enum Color {
#[default]
White,
Gray,
Black,
}
If you want to use a unary minus operator on your own type, you can implement\na Neg trait3. I was dealing with a binary tree and needed a way how to look\nat the other side, so I have just implemented the negation for flipping between\nleft and right 😄
Let's try to solve one of the LeetCode challenges in easy and hard mode at the\nsame time.
\nA matrix diagonal is a diagonal line of cells starting from some cell in\neither the topmost row or leftmost column and going in the bottom-right direction\nuntil reaching the matrix's end. For example, the matrix diagonal starting\nfrom mat[2][0], where mat is a 6 x 3 matrix, includes cells mat[2][0],\nmat[3][1], and mat[4][2].
Given an m x n matrix mat of integers, sort each matrix diagonal in ascending\norder and return the resulting matrix.
![\"Image](\"https://assets.leetcode.com/uploads/2020/01/21/1482_example_1_2.png\")
We are given the following skeleton for the C++ and the given challenge:
\nclass Solution {
public:
vector<vector<int>> diagonalSort(vector<vector<int>>& mat) {
}
};
The task is to sort the passed matrix diagonally and then return it. First of all,\nI don't like to solve this in a web browser, so we'll need to adjust it accordingly\nfor running it locally. We'll start by including the vector header and using\nfully-qualified namespaces1 and also adding few tests:
#include <cassert>
#include <vector>
using matrix = std::vector<std::vector<int>>;
class Solution {
public:
matrix diagonalSort(matrix& mat)
{
}
};
static void test_case_1()
{
// Input: mat = [[3,3,1,1],[2,2,1,2],[1,1,1,2]]
// Output: [[1,1,1,1],[1,2,2,2],[1,2,3,3]]
Solution s;
assert((s.diagonalSort(std::vector { std::vector { 3, 3, 1, 1 },
std::vector { 2, 2, 1, 2 },
std::vector { 1, 1, 1, 2 } })
== std::vector { std::vector { 1, 1, 1, 1 },
std::vector { 1, 2, 2, 2 },
std::vector { 1, 2, 3, 3 } }));
}
static void test_case_2()
{
// Input: mat =
// [[11,25,66,1,69,7],[23,55,17,45,15,52],[75,31,36,44,58,8],[22,27,33,25,68,4],[84,28,14,11,5,50]]
// Output:
// [[5,17,4,1,52,7],[11,11,25,45,8,69],[14,23,25,44,58,15],[22,27,31,36,50,66],[84,28,75,33,55,68]]
Solution s;
assert((s.diagonalSort(std::vector { std::vector { 11, 25, 66, 1, 69, 7 },
std::vector { 23, 55, 17, 45, 15, 52 },
std::vector { 75, 31, 36, 44, 58, 8 },
std::vector { 22, 27, 33, 25, 68, 4 },
std::vector { 84, 28, 14, 11, 5, 50 } })
== std::vector { std::vector { 5, 17, 4, 1, 52, 7 },
std::vector { 11, 11, 25, 45, 8, 69 },
std::vector { 14, 23, 25, 44, 58, 15 },
std::vector { 22, 27, 31, 36, 50, 66 },
std::vector { 84, 28, 75, 33, 55, 68 } }));
}
int main()
{
test_case_1();
test_case_2();
return 0;
}
We need to return the matrix, but we're given a reference to the input matrix. We\ncan easily abuse the C++ here and just switch the reference to value, this way\nthe matrix will be copied when passed to the function, we can sort the copy and\njust return it back. And we also get yelled by the compiler for the fact that the\nmethod doesn't return anything yet, so to make it “shut up” we will just return\nthe input for now:
\n- matrix diagonalSort(matrix& mat)
+ matrix diagonalSort(matrix mat)
{
+ return mat;
}
Now, we get the copy and we're good to go.
\nAs you may know, C++ offers a plethora of functions that can be used to your\nadvantage, given that you know how to “bend” the data structures accordingly.
\nWhat does that mean for us? Well, we have an std::sort, we can use it, right?\nLet's have a look at it:
template< class RandomIt >
void sort( RandomIt first, RandomIt last );
This overload is more than we need. What does it do? It just sorts the elements\nin the range [first, last) using operator< on them. We can't sort the whole\nmatrix using this, but… we can sort just »one« diagonal without doing much work\non our end.
What is the RandomIt type though? If we look more into the documentation, we\ncan easily find the requirements for it and also learn that it's a random access\niterator and allows swapping its values at the same time.
What is the random access iterator though? We can find it in a documentation\nand see the following description:
\nA LegacyRandomAccessIterator is a LegacyBidirectionalIterator\nthat can be moved to point to any element in constant time.
\n
After that we can see all the requirements for it being listed. I don't feel like\nreading them right now, so we will just use it and see where the compilation blows\nup, i.e. “compiler-assisted development”2 if you will ;)
Now we know that we can use std::sort to sort the diagonal itself, but we also\nneed to get the diagonals somehow. I'm rather lazy, so I'll just delegate it to\nsomeone else3. And that way we get
matrix diagonalSort(matrix mat)
{
// we iterate over the diagonals
for (auto d : diagonals(mat)) {
// and we sort each diagonal
std::sort(d.begin(), d.end());
}
// we take the matrix by copy, so we can sort in-situ and return the copy
// that we sorted
return mat;
}
This solution looks very simple, doesn't it? Well, cause it is.\nLet's try compiling it:
\nmatrix-sort.cpp:11:23: error: use of undeclared identifier 'diagonals' [clang-diagnostic-error]
for (auto d : diagonals(mat)) {
^
Found compiler error(s).
make: *** [makefile:14: tidy] Error 1
OK, seems about right. We haven't implemented the diagonals yet. And based on\nwhat we've written so far, we need a function or a class diagonals that will\ngive us the diagonals we need.
diagonalsCool, so we need the function that will let us go through each and every diagonal\nin our matrix. We use the for-range loop, so whatever we get back from the\ndiagonals must support .begin() and .end(). Since I am a masochist, we will\ndo such functionality for a matrix of any type, not just the int from the challenge.
As I said, we need to be able to
\ntemplate <typename T>
class diagonals {
using matrix_t = std::vector<std::vector<T>>;
matrix_t& _matrix;
public:
diagonals(matrix_t& m)
: _matrix(m)
{
}
diagonals_iter begin()
{
/* TODO */
}
diagonals_iter end()
{
/* TODO */
}
};
Now we have a diagonals that we can use to go through the diagonals. We haven't\nimplemented the core of it yet. Let's go through what we have for now.
We have a templated class with templated T that is used as a placeholder for any\ntype we would store in the matrix. Because I'm lazy, I have defined the matrix_t\ntype that is a “shortcut” for std::vector<std::vector<T>>, so I don't have to\ntype it out all the time. Of course, we need to store the matrix, we are given,\nas a private attribute. And then just have the constructor and the 2 methods we\nneed for the for-range.
Now that we have an object that will allow us to iterate through the diagonals,\nwe need to implement the iterating itself. We need to go through all of them, so\nwe have multiple options how to do so. I have decided to start from the “main”\ndiagonal that starts at (0, 0) index and then proceed with the diagonals starting\nin the first row, followed by the rest of the diagonals in the first column.
We need to be able to tell that we've iterated through all of them, and also we\nneed to know which diagonal is next. For that purpose we will pass the indices\nof the first cell on the diagonal. That way we can always tell how to move forward.
\nWe will start by updating the begin and end to reflect our choice accordingly.
diagonals_iter begin() { return diagonals_iter { _matrix, 0, 0 }; }
diagonals_iter end() { return diagonals_iter { _matrix, 0, _matrix.size() }; }
For the begin we return the first diagonal that starts at (0, 0). And because\nwe have decided to do the diagonals in the first column at the end, the first\ndiagonal that is not a valid one is the one at (0, height). Apart from the\nindices, we also need to pass reference to the matrix itself.
You may have noticed that we also include the diagonals that have length 1,\nspecifically the ones at (0, height - 1) and (width - 1, 0). We are implementing\nan iterator that should not care about the way it's being used. Therefore, we\ndon't care about the fact they don't need to be sorted.
Cool, let's leave the iterator itself to someone else, right?4
\nWe can start with a simple skeleton based on the information that we pass from\nthe diagonals. Also to utilize the matrix_t and also contain implementation\ndetails hidden away, we will put this code into the diagonals class.
class diagonals_iter {
matrix_t& m;
std::size_t x;
std::size_t y;
public:
diagonals_iter(matrix_t& matrix, std::size_t x, std::size_t y)
: m(matrix)
, x(x)
, y(y)
{
}
};
In this case we will be implementing a “simple” forward iterator, so we don't\nneed to implement a lot. Notably it will be:
\nclass diagonals_iter {
matrix_t& m;
std::size_t x;
std::size_t y;
public:
diagonals_iter(matrix_t& matrix, std::size_t x, std::size_t y)
: m(matrix)
, x(x)
, y(y)
{
}
bool operator!=(const diagonals_iter& rhs) const
{
// iterators are not equal if they reference different matrices, or
// their positions differ
return m != rhs.m || x != rhs.x || y != rhs.y;
}
diagonals_iter& operator++()
{
if (y != 0) {
// iterating through diagonals down the first column
y++;
return *this;
}
// iterating the diagonals along the first row
x++;
if (x == m.front().size()) {
// switching to diagonals in the first column
x = 0;
y++;
}
return *this;
}
diagonal<T> operator*() const { return diagonal { m, x, y }; }
};
Let's go one-by-one. Inequality operator is rather simple, just compare iterator's\nattributes field-by-field. If you think about it, checking inequality of two 2D\nvectors may be a bit inefficient, therefore, we can swap around and check it as\na last thing.
\n- return m != rhs.m || x != rhs.x || y != rhs.y;
+ return x != rhs.x || y != rhs.y || m != rhs.m;
Preincrementation is where the magic happens. If you have a better look, you can\nsee two branches of this operation:
\ny != 0 (we're iterating over the diagonals in the first column)\nIn this case, we just bump the row and we're done.y == 0 (we're iterating over the diagonals in the first row)\nIn this case, we bump the column and check if we haven't gotten out of bounds,\ni.e. the end of the first row. If we get out of the bounds, we're continuing\nwith the second diagonal in the first column.Dereferencing the iterator must “yield” something. In our case it will be the\ndiagonal that we want to sort. For sorting we need just the iterators that can\nmove around said diagonal. The simplest thing, we can do, is to delegate it to\nsomething else. In our case it will be a class called diagonal.
diagonal itselfAfter implementing the iterator over diagonals, we know that all we need to describe\na diagonal is the matrix itself and the “start” of the diagonal (row and column).\nAnd we also know that the diagonal must provide some iterators for the std::sort\nfunction. We can start with the following skeleton:
template <typename T>
class diagonal {
using matrix_t = std::vector<std::vector<T>>;
matrix_t& matrix;
std::size_t x;
std::size_t y;
public:
diagonal(matrix_t& matrix, std::size_t x, std::size_t y)
: matrix(matrix)
, x(x)
, y(y)
{
}
diagonal_iter begin() const { return diagonal_iter { matrix, x, y }; }
diagonal_iter end() const
{
auto max_x = matrix[y].size();
auto max_y = matrix.size();
// we need to find the distance in which we get out of bounds (either in
// column or row)
auto steps = std::min(max_x - x, max_y - y);
return diagonal_iter { matrix, x + steps, y + steps };
}
};
Initialization is rather simple, we just “keep” the stuff we get, begin is the\nsimplest, we just delegate.
In case of the end, it gets more complicated. We need to know where is the “end”\nof the diagonal. Since end should point to the first element “after” the iterable,\nwe know that it's the first position of the iterator where either y becomes\nmatrix.size() or x becomes matrix[y].size(). Also we are moving along diagonal,\nduh, therefore we can deduce the first “position” afterwards by minimal amount of\nsteps to get out of the any column or row, hence std::min(max_x - x, max_y - y).\nFinal position is then computed simply by adding the steps to the beginning of\nthe diagonal.
Now we just need to finish the iterator for the diagonal itself and we're done.
\ndiagonal_iterThis part is the hardest from all we need to do. It's because of the requirements\nof the std::sort that requires us to implement a random access iterator. I have\nbriefly described it above, and “in a nutshell” it means that we need to implement\nan iterator that can move in constant time along the diagonal in any amount of\nsteps.
Let's go through all of the functionality that our iterator needs to support to\nbe used in std::sort. We need the usual operations like:
We will also add all the types that our iterator uses with the category of the\niterator, i.e. what interface it supports:
\nclass diagonal_iter {
// we need to keep reference to the matrix itself
matrix_t& m;
// we need to be able to tell our current position
std::size_t x;
std::size_t y;
public:
using difference_type = std::ptrdiff_t;
using value_type = T;
using pointer = T*;
using reference = T&;
using iterator_category = std::random_access_iterator_tag;
diagonal_iter(matrix_t& matrix,
std::size_t x,
std::size_t y)
: m(matrix)
, x(x)
, y(y)
{
}
bool operator==(const diagonal_iter& rhs) const
{
return x == rhs.x && y == rhs.y && m == rhs.m;
}
diagonal_iter& operator++()
{
// we are moving along the diagonal, so we increment both ‹x› and ‹y› at
// the same time
x++;
y++;
return *this;
}
reference operator*() const { return m[y][x]; }
};
This is pretty similar to the previous iterator, but now we need to implement the\nremaining requirements of the random access iterator. Let's see what those are:
\nLet's fill them in:
\nclass diagonal_iter {
// we need to keep reference to the matrix itself
matrix_t& m;
// we need to be able to tell our current position
std::size_t x;
std::size_t y;
public:
using difference_type = std::ptrdiff_t;
using value_type = T;
using pointer = T*;
using reference = T&;
using iterator_category = std::random_access_iterator_tag;
diagonal_iter(matrix_t& matrix,
std::size_t x,
std::size_t y)
: m(matrix)
, x(x)
, y(y)
{
}
bool operator==(const diagonal_iter& rhs) const
{
return x == rhs.x && y == rhs.y && m == rhs.m;
}
diagonal_iter& operator++()
{
// we are moving along the diagonal, so we increment both ‹x› and ‹y› at
// the same time
x++;
y++;
return *this;
}
reference operator*() const { return m[y][x]; }
// exactly opposite to the incrementation
diagonal_iter operator--()
{
x--;
y--;
return *this;
}
// moving ‹n› steps back is same as calling decrementation ‹n›-times, so we
// can just return a new iterator and subtract ‹n› from both coordinates in
// the matrix
diagonal_iter operator-(difference_type n) const
{
return diagonal_iter { m, x - n, y - n };
}
// here we assume that we are given two iterators on the same diagonal
difference_type operator-(const diagonal_iter& rhs) const
{
assert(m == rhs.m);
return x - rhs.x;
}
// counterpart of moving ‹n› steps backwards
diagonal_iter operator+(difference_type n) const
{
return diagonal_iter { m, x + n, y + n };
}
// we compare the coordinates, and also assume that those 2 iterators are
// lying on the same diagonal
bool operator<(const diagonal_iter& rhs) const
{
assert(m == rhs.m);
return x < rhs.x && y < rhs.y;
}
};
At this point we could probably try and compile it, right? If we do so, we will\nget yelled at by a compiler for the following reasons:
\n/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_algo.h:1792:11: error: object of type 'diagonal<int>::diagonal_iter' cannot be assigned because its copy assignment operator is implicitly deleted [clang-diagnostic-error]
__last = __next;
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_algo.h:1817:11: note: in instantiation of function template specialization 'std::__unguarded_linear_insert<diagonal<int>::diagonal_iter, __gnu_cxx::__ops::_Val_less_iter>' requested here
std::__unguarded_linear_insert(__i,
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_algo.h:1849:9: note: in instantiation of function template specialization 'std::__insertion_sort<diagonal<int>::diagonal_iter, __gnu_cxx::__ops::_Iter_less_iter>' requested here
std::__insertion_sort(__first, __first + int(_S_threshold), __comp);
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_algo.h:1940:9: note: in instantiation of function template specialization 'std::__final_insertion_sort<diagonal<int>::diagonal_iter, __gnu_cxx::__ops::_Iter_less_iter>' requested here
std::__final_insertion_sort(__first, __last, __comp);
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_algo.h:4820:12: note: in instantiation of function template specialization 'std::__sort<diagonal<int>::diagonal_iter, __gnu_cxx::__ops::_Iter_less_iter>' requested here
std::__sort(__first, __last, __gnu_cxx::__ops::__iter_less_iter());
^
matrix-sort.cpp:161:18: note: in instantiation of function template specialization 'std::sort<diagonal<int>::diagonal_iter>' requested here
std::sort(d.begin(), d.end());
^
matrix-sort.cpp:17:19: note: copy assignment operator of 'diagonal_iter' is implicitly deleted because field 'm' is of reference type 'diagonal<int>::matrix_t &' (aka 'vector<std::vector<int>> &')
matrix_t& m;
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_algo.h:1830:2: error: no matching function for call to '__unguarded_linear_insert' [clang-diagnostic-error]
std::__unguarded_linear_insert(__i,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_algo.h:1850:9: note: in instantiation of function template specialization 'std::__unguarded_insertion_sort<diagonal<int>::diagonal_iter, __gnu_cxx::__ops::_Iter_less_iter>' requested here
std::__unguarded_insertion_sort(__first + int(_S_threshold), __last,
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_algo.h:1940:9: note: in instantiation of function template specialization 'std::__final_insertion_sort<diagonal<int>::diagonal_iter, __gnu_cxx::__ops::_Iter_less_iter>' requested here
std::__final_insertion_sort(__first, __last, __comp);
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_algo.h:4820:12: note: in instantiation of function template specialization 'std::__sort<diagonal<int>::diagonal_iter, __gnu_cxx::__ops::_Iter_less_iter>' requested here
std::__sort(__first, __last, __gnu_cxx::__ops::__iter_less_iter());
^
matrix-sort.cpp:161:18: note: in instantiation of function template specialization 'std::sort<diagonal<int>::diagonal_iter>' requested here
std::sort(d.begin(), d.end());
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_algo.h:1782:5: note: candidate template ignored: substitution failure [with _RandomAccessIterator = diagonal<int>::diagonal_iter, _Compare = __gnu_cxx::__ops::_Val_less_iter]
__unguarded_linear_insert(_RandomAccessIterator __last,
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_algo.h:1923:11: error: object of type 'diagonal<int>::diagonal_iter' cannot be assigned because its copy assignment operator is implicitly deleted [clang-diagnostic-error]
__last = __cut;
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_algo.h:1937:9: note: in instantiation of function template specialization 'std::__introsort_loop<diagonal<int>::diagonal_iter, long, __gnu_cxx::__ops::_Iter_less_iter>' requested here
std::__introsort_loop(__first, __last,
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_algo.h:4820:12: note: in instantiation of function template specialization 'std::__sort<diagonal<int>::diagonal_iter, __gnu_cxx::__ops::_Iter_less_iter>' requested here
std::__sort(__first, __last, __gnu_cxx::__ops::__iter_less_iter());
^
matrix-sort.cpp:161:18: note: in instantiation of function template specialization 'std::sort<diagonal<int>::diagonal_iter>' requested here
std::sort(d.begin(), d.end());
^
matrix-sort.cpp:17:19: note: copy assignment operator of 'diagonal_iter' is implicitly deleted because field 'm' is of reference type 'diagonal<int>::matrix_t &' (aka 'vector<std::vector<int>> &')
matrix_t& m;
^
That's a lot of noise, isn't it? Let's focus on the important parts:
\n/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_algo.h:1792:11: error: object of type 'diagonal<int>::diagonal_iter' cannot be assigned because its copy assignment operator is implicitly deleted [clang-diagnostic-error]
…
matrix-sort.cpp:17:19: note: copy assignment operator of 'diagonal_iter' is implicitly deleted because field 'm' is of reference type 'diagonal<int>::matrix_t &' (aka 'vector<std::vector<int>> &')
matrix_t& m;
^
Ah! We have a reference in our iterator, and this prevents us from having a copy\nassignment operator (that is used “somewhere” in the sorting algorithm). Well…\nLet's just wrap it!
\n# we need to keep a different type than reference
- matrix_t& m;
+ std::reference_wrapper<matrix_t> m;
# in comparison we need to get the reference out of the wrapper first
- return x == rhs.x && y == rhs.y && m == rhs.m;
+ return x == rhs.x && y == rhs.y && m.get() == rhs.m.get();
# same when we return a reference to the “cell” in the matrix
- reference operator*() const { return m[y][x]; }
+ reference operator*() const { return m.get()[y][x]; }
# and finally in the assertions that we set for the “distance” and “less than”
- assert(m == rhs.m);
+ assert(m.get() == rhs.m.get());
We're done now! We have written an iterator over diagonals for a 2D vector. You can have a look at the final result here.
Let's go through the second week of Advent of Code in Rust.
\nWe get a forest and we want to know how many trees are visible from the outside.\nApart from that we want to find the best view.
Nothing interesting. We are moving around 2D map though. And indexing can get a\nbit painful when doing so, let's refactor it a bit ;) During the preparation for\nthe AoC, I have written Vector2D and now it's time to extend it with indexing\nof Vec of Vecs. In my solution I was manipulating with indices in the following\nway:
Vec<Vec<T>>Vec<Vec<T>> with themI'm getting familiar with Rust and starting to “abuse” it… While doing so, I'm\nalso uncovering some “features” that I don't really like. Therefore I will mark\nall of my rants with thicc «↯» mark and will try to “lock” them into their\nown “box of hell”.
Relatively simple implementation, just take the values, swap them and return new\nvector.
\nimpl<T: Copy> Vector2D<T> {
pub fn swap(&self) -> Self {
Self {
x: self.y,
y: self.x,
}
}
}
Pretty straight-forward implementation, but let's talk about the T: Copy. We\nneed to use it, since we are returning a new vector, with swapped values.\nIf we had values that cannot be copied, the only thing we could do, would be a\nvector of references (and it would also introduce a lifetime, to which we'll get\nlater on). This is pretty similar with the operations on sets from the first week.
VecI will start with the indexing, cause bound-checking is a bit more… complicated\nthan I would like to.
\npub fn index<'a, T, U>(v: &'a [Vec<U>], idx: &Vector2D<T>) -> &'a U
where
usize: TryFrom<T>,
<usize as TryFrom<T>>::Error: Debug,
T: Copy,
{
let (x, y): (usize, usize) = (idx.x.try_into().unwrap(), idx.y.try_into().unwrap());
&v[y][x]
}
Let's talk about this mess… Body of the function is probably the most easy part\nand should not be hard to understand, we just take the x and y and convert\nthem both to usize type that can be used later on for indexing.
The type signature of the function is where the fun is at 😉 We are trying\nto convert unknown type to usize, so we must bound the T as a type that can\nbe converted to usize, that's how we got usize: TryFrom<T> which basically\nsays that usize must implement TryFrom<T> trait and therefore allows us to\nconvert the indices to actual usize indices. Using .unwrap() also forces us\nto bound the error that can occur when converting T into usize, that's how\nwe get <usize as TryFrom<T>>::Error: Debug which loosely means
\n\nerror during conversion of
\nTintousizemust implementDebug,\ni.e. can be printed in some way or other
T: Copy is required by .try_into() which takes T by-value.
And now we are left only with the first line of the definition.
\nSkilled Rustaceans might notice that this implementation is rather flaky and can\nbreak in multiple places at once. I'll get back to it…
Let's split it in multiple parts:
\nv: &'a [Vec<U>] represents the 2D Vec, we are indexing, Vec implements\nSlice trait and clippy recommends using &[T] to &Vec<T>, exact details\nare unknown to meidx: &Vector2D<T> represents the indices which we use, we take them by\nreference to avoid an unnecessary copy-> &'a U means that we are returning a reference to some value of type U.\nNow the question is what does the 'a mean, we can also see it as a generic\ntype declared along T and U. And the answer is relatively simple, 'a\nrepresents a lifetime. We take the v by a reference and return a reference,\nborrow checker validates all of the borrows (or references), so we need to\nspecify that our returned value has the same lifetime as the vector we have\ntaken by a reference, i.e. returned reference must live at least as long as the\nv. This way we can “be sure” that the returned reference is valid.First issue that our implementation has is the fact that we cannot get a mutable\nreference out of that function. This could be easily resolved by introducing new\nfunction, e.g. index_mut. Which I have actually done while writing this part:
pub fn index_mut<'a, T, U>(v: &'a mut [Vec<U>], idx: &Vector2D<T>) -> &'a mut U
where
usize: TryFrom<T>,
<usize as TryFrom<T>>::Error: Debug,
T: Copy,
{
let (x, y): (usize, usize) = (idx.x.try_into().unwrap(), idx.y.try_into().unwrap());
&mut v[y][x]
}
When we consider a Vec<T>, we don't need to consider containers as T, Rust\nimplements indexing as traits Index<T> and IndexMut<T> that do the dirty work\nbehind syntactic sugar of container[idx].
However, implementing of traits is not allowed for external types, i.e. types\nthat you haven't defined yourself. This means that you can implement indexing\nover containers that you have implemented yourself, but you cannot use your own\ntypes for indexing “built-in” types.
Another part of this rabbit hole is trait SliceIndex<T> that is of a relevance\nbecause of
impl<T, I> Index<I> for [T]
where
I: SliceIndex<[T]>
impl<T, I, A> Index<I> for Vec<T, A>
where
I: SliceIndex<[T]>,
A: Allocator
impl<T, I, const N: usize> Index<I> for [T; N]
where
[T]: Index<I>
In other words, if your type implements SliceIndex<T> trait, it can be used\nfor indexing. As of now, this trait has all of its required methods experimental\nand is marked as unsafe.
Another problem is a requirement for indexing either [Vec<T>] or Vec<Vec<T>>.\nThis requirement could be countered by removing inner type Vec<T> and constraining\nit by a trait Index (or IndexMut respectively) in a following way
pub fn index<'a, C, T>(v: &'a [C], idx: &Vector2D<T>) -> &'a C::Output
where
usize: TryFrom<T>,
<usize as TryFrom<T>>::Error: Debug,
T: Copy,
C: Index<usize>
{
let (x, y): (usize, usize) = (idx.x.try_into().unwrap(), idx.y.try_into().unwrap());
&v[y][x]
}
Given this, we can also give a more meaningful typename for indexing type, such\nas I.
Now we can get to the boundary checks, it is very similar, but a more… dirty.\nFirst approach that came up was to convert the indices in Vector2D to usize,\nbut when you add the indices up, e.g. when checking the neighbors, you can end\nup with negative values which, unlike in C++, causes an error (instead of underflow\nthat you can use to your advantage; you can easily guess how).
So how can we approach this then? Well… we will convert the bounds instead of\nthe indices and that lead us to:
\npub fn in_range<T, U>(v: &[Vec<U>], idx: &Vector2D<T>) -> bool
where
usize: TryInto<T>,
<usize as TryInto<T>>::Error: Debug,
T: PartialOrd + Copy,
{
idx.y >= 0.try_into().unwrap()
&& idx.y < v.len().try_into().unwrap()
&& idx.x >= 0.try_into().unwrap()
&& idx.x
< v[TryInto::<usize>::try_into(idx.y).unwrap()]
.len()
.try_into()
.unwrap()
}
You can tell that it's definitely a shitty code. Let's improve it now! We will\nget back to the original idea, but do it better. We know that we cannot convert\nnegative values into usize, but we also know that conversion like that\nreturns a Result<T, E> which we can use to our advantage.
pub fn in_range<T, U>(v: &[Vec<U>], idx: &Vector2D<T>) -> bool
where
T: Copy,
usize: TryFrom<T>,
{
usize::try_from(idx.y)
.and_then(|y| usize::try_from(idx.x).map(|x| y < v.len() && x < v[y].len()))
.unwrap_or(false)
}
Result<T, E> is a type similar to Either in Haskell and it allows us to chain\nmultiple operations on correct results or propagate the original error without\ndoing anything. Let's dissect it one-by-one.
try_from is a method implemented in TryFrom trait, that allows you to convert\ntypes and either successfully convert them or fail (with a reasonable error). This\nmethod returns Result<T, E>.
We call and_then on that result, let's have a look at the type signature of\nand_then, IMO it explains more than enough:
pub fn and_then<U, F>(self, op: F) -> Result<U, E>
where
F: FnOnce(T) -> Result<U, E>
OK… So it takes the result and a function and returns another result with\ndifferent value and different error. However we can see that the function, which\nrepresents an operation on a result, takes just the value, i.e. it doesn't care\nabout any previous error. To make it short:
\n\n\n\n
and_thenallows us to run an operation, which can fail, on the correct result
We parsed a y index and now we try to convert the x index with try_from\nagain, but on that result we use map rather than and_then, why would that be?
pub fn map<U, F>(self, op: F) -> Result<U, E>
where
F: FnOnce(T) -> U
Huh… map performs an operation that cannot fail. And finally we use\nunwrap_or which takes the value from result, or in case of an error returns the\ndefault that we define.
How does this work then? If y is negative, the conversion fails and the error\npropagates all the way to unwrap_or, if y can be a correct usize value, then\nwe do the same with x. If x is negative, we propagate the error as with y,\nand if it's not, then we check whether it exceeds the higher bounds or not.
Relatively simple, you just need follow the rules and not get too smart, otherwise\nit will get back at you.
\nWe get a rope with knots and we want to track how many different positions are\nvisited with the rope's tail.
By this day, I have come to a conclusion that current skeleton for each day\ngenerates a lot of boilerplate. And even though it can be easily copied, it's\njust a waste of space and unnecessary code. Let's “simplify” this (on one end\nwhile creating monster on the other end). I've gone through what we need in the\npreparations for the AoC. Let's sum up our requirements:
\nParsing and implementation of both parts is code that changes each day and we\ncannot do anything about it. However running and testing can be simplified!
\nLet's introduce and export a new module solution that will take care of all of\nthis. We will start by introducing a trait for each day.
pub trait Solution<Input, Output: Display> {
fn parse_input<P: AsRef<Path>>(pathname: P) -> Input;
fn part_1(input: &Input) -> Output;
fn part_2(input: &Input) -> Output;
}
This does a lot of work for us already, we have defined a trait and for each day\nwe will create a structure representing a specific day. That structure will also\nimplement the Solution trait.
Now we need to get rid of the boilerplate, we can't get rid of the main function,\nbut we can at least move out the functionality.
fn run(type_of_input: &str) -> Result<()>
where
Self: Sized,
{
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 = Self::parse_input(format!(\"{}s/{}.txt\", type_of_input, Self::day()));
info!(\"Part 1: {}\", Self::part_1(&input));
info!(\"Part 2: {}\", Self::part_2(&input));
Ok(())
}
fn main() -> Result<()>
where
Self: Sized,
{
Self::run(\"input\")
}
This is all part of the Solution trait, which can implement methods while being\ndependent on what is provided by the implementing types. In this case, we just\nneed to bound the Output type to implement Display that is necessary for the\ninfo! and format string there.
Now we can get to first of the nasty things we are going to do… And it is the\nday() method that you can see being used when constructing path to the input\nfile. That method will generate a name of the file, e.g. day01 and we know that\nwe can somehow deduce it from the structure name, given we name it reasonably.
fn day() -> String {
let mut day = String::from(type_name::<Self>().split(\"::\").next().unwrap());
day.make_ascii_lowercase();
day.to_string()
}
type_nameThis feature is still experimental and considered to be internal, it is not\nadvised to use it any production code.
And now we can get to the nastiest stuff 😩 We will generate the tests!
\nWe want to be able to generate tests for sample input in a following way:
\ntest_sample!(day_01, Day01, 42, 69);
There's not much we can do, so we will write a macro to generate the tests for us.
\n#[macro_export]
macro_rules! test_sample {
($mod_name:ident, $day_struct:tt, $part_1:expr, $part_2:expr) => {
#[cfg(test)]
mod $mod_name {
use super::*;
#[test]
fn test_part_1() {
let sample =
$day_struct::parse_input(&format!(\"samples/{}.txt\", $day_struct::day()));
assert_eq!($day_struct::part_1(&sample), $part_1);
}
#[test]
fn test_part_2() {
let sample =
$day_struct::parse_input(&format!(\"samples/{}.txt\", $day_struct::day()));
assert_eq!($day_struct::part_2(&sample), $part_2);
}
}
};
}
We have used it in a similar way as macros in C/C++, one of the things that we\ncan use to our advantage is defining “type” of the parameters for the macro. All\nparameters have their name prefixed with $ sign and you can define various “forms”\nof your macro. Let's go through it!
We have following parameters:
\n$mod_name which represents the name for the module with tests, it is typed\nwith ident which means that we want a valid identifier to be passed in.$day_struct represents the structure that will be used for tests, it is typed\nwith tt which represents a token tree, in our case it is a type.$part_X represents the expected output for the Xth part and is of type expr\nwhich literally means an expression.Apart from that we need to use #[macro_export] to mark the macro as exported\nfor usage outside of the module. Now our skeleton looks like:
use aoc_2022::*;
type Input = String;
type Output = String;
struct DayXX;
impl Solution<Input, Output> for DayXX {
fn parse_input<P: AsRef<Path>>(pathname: P) -> Input {
file_to_string(pathname)
}
fn part_1(input: &Input) -> Output {
todo!()
}
fn part_2(input: &Input) -> Output {
todo!()
}
}
fn main() -> Result<()> {
// DayXX::run(\"sample\")
DayXX::main()
}
// test_sample!(day_XX, DayXX, , );
Not much to talk about, it is relatively easy to simulate.
\nEmulating basic arithmetic operations on a CPU and drawing on CRT based on the\nCPU's accumulator.
In this day I have discovered an issue with my design of the Solution trait.\nAnd the issue is caused by different types of Output for the part 1 and part 2.
Problem is relatively simple and consists of simulating a CPU, I have approached\nit in a following way:
\nfn evaluate_instructions(instructions: &[Instruction], mut out: Output) -> Output {
instructions
.iter()
.fold(State::new(), |state, instruction| {
state.execute(instruction, &mut out)
});
out
}
We just take the instructions, we have some state of the CPU and we execute the\ninstructions one-by-one. Perfect usage of the fold (or reduce as you may know\nit from other languages).
You can also see that we have an Output type, so the question is how can we fix\nthat problem. And the answer is very simple and functional. Rust allows you to\nhave an enumeration that can bear some other values apart from the type itself.
We could've seen something like this with the Result<T, E> type that can be\ndefined as
enum Result<T, E> {
Ok(T),
Err(E)
}
When we have an Ok value, it has the result itself, and when we get an Err\nvalue, it has the error. This also allows us to handle results in a rather\npretty way:
match do_something(x) {
Ok(y) => {
println!(\"SUCCESS: {}\", y);
},
Err(y) => {
eprintln!(\"ERROR: {}\", y);
}
}
My solution has a following outline:
\nfn execute(&self, i: &Instruction, output: &mut Output) -> State {
// execute the instruction
// collect results if necessary
match output {
Output::Part1(x) => self.execute_part_1(y, x),
Output::Part2(x) => self.execute_part_2(y, x),
}
// return the obtained state
new_state
}
You might think that it's a perfectly reasonable thing to do. Yes, but notice\nthat the match statement doesn't collect the changes in any way and also we\npass output by &mut, so it is shared across each iteration of the fold.
The dirty and ingenious thing is that xs are passed by &mut too and therefore\nthey are directly modified by the helper functions. To sum it up and let it sit
\n\nWe are collecting the result into an enumeration that is shared\nacross all iterations of
\nfold.
Similar to Day 9, but there are some technical details that can get you.
\nSimulation of monkeys throwing stuff around and measuring your stress levels\nwhile your stuff is being passed around.
I think I decided to use regular expressions here for the first time, cause\nparsing the input was a pain.
\nAlso I didn't expect to implement Euclidean algorithm in Rust…
\nAgain, we're just running a simulation. Though I must admit it was very easy to\nmake a small technical mistakes that could affect the final results very late.
\nFinding shortest path up the hill and also shortest path down to the ground while\nalso rolling down the hill…
As I have said in the tl;dr, we are looking for the shortest path, but the start\nand goal differ for the part 1 and 2. So I have decided to refactor my solution\nto a BFS algorithm that takes necessary parameters via functions:
\nfn bfs<F, G>(
graph: &[Vec<char>], start: &Position, has_edge: F, is_target: G
) -> Option<usize>
where
F: Fn(&[Vec<char>], &Position, &Position) -> bool,
G: Fn(&[Vec<char>], &Position) -> bool
We pass the initial vertex from the caller and everything else is left to the BFS\nalgorithm, based on the has_edge and is_target functions.
This was easy! And that is not very usual in Rust once you want to pass around\nfunctions. 👀
\nLooking for the shortest path… Must be Dijkstra, right? Nope! Half of the\nReddit got jebaited though. In all fairness, nothing stops you from implementing\nthe Dijkstra's algorithm for finding the shortest path, but if you know that\nall connected vertices are in a unit (actually d=1) distance from each other,\nthen you know that running Dijkstra is equivalent to running BFS, only with worse\ntime complexity, because of the priority heap instead of the queue.
\nProcessing packets with structured data from the distress signal.
You can implement a lot of traits if you want to. It is imperative to implement\nordering on the packets. I had a typo, so I also proceeded to implement a Display\ntrait for debugging purposes:
impl Display for Packet {
fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
match self {
Packet::Integer(x) => write!(f, \"{x}\"),
Packet::List(lst) => write!(f, \"[{}]\", lst.iter().map(|p| format!(\"{p}\")).join(\",\")),
}
}
}
A lot of technical details… Parsing is nasty too…
\nLet's simulate falling sand grain-by-grain.
Again, both parts are relatively similar with minimal changes, so it is a good\nidea to refactor it a bit. Similar approach to the BFS above. Also this is the\nfirst day where I ran into efficiency issues and had to redo my solution to speed\nit up just a bit.
\nTedious.
\nI was asked about the indexing after publishing the blog. And truly it is rather\ncomplicated topic, especially after releasing SliceIndex<I> trait. I couldn't\nleave it be, so I tried to implement the Index and IndexMut trait.
I have also mentioned that the SliceIndex trait is unsafe, but truth be told,\nonly unsafe part are the 2 methods that are named *unchecked*. Anyways, I will\nbe implementing the Index* traits for now, rather than the SliceIndex.
It's relatively straightforward…
\nimpl<I, C> Index<Vector2D<I>> for [C]
where
I: Copy + TryInto<usize>,
<I as TryInto<usize>>::Error: Debug,
C: Index<usize>,
{
type Output = C::Output;
fn index(&self, index: Vector2D<I>) -> &Self::Output {
let (x, y): (usize, usize) =
(index.x.try_into().unwrap(), index.y.try_into().unwrap());
&self[y][x]
}
}
impl<I, C> IndexMut<Vector2D<I>> for [C]
where
I: Copy + TryInto<usize>,
<I as TryInto<usize>>::Error: Debug,
C: IndexMut<usize>,
{
fn index_mut(&mut self, index: Vector2D<I>) -> &mut Self::Output {
let (x, y): (usize, usize) =
(index.x.try_into().unwrap(), index.y.try_into().unwrap());
&mut self[y][x]
}
}
We can see a lot of similarities to the implementation of index and index_mut\nfunctions. In the end, they are 1:1, just wrapped in the trait that provides a\nsyntax sugar for container[idx].
I have also switched from using the TryFrom to TryInto trait, since it better\nmatches what we are using, the .try_into rather than usize::try_from.
Also implementing TryFrom automatically provides you with a TryInto trait,\nsince it is relatively easy to implement. Just compare the following:
pub trait TryFrom<T>: Sized {
type Error;
fn try_from(value: T) -> Result<Self, Self::Error>;
}
pub trait TryInto<T>: Sized {
type Error;
fn try_into(self) -> Result<T, Self::Error>;
}
OK, so we have our trait implemented, we should be able to use container[index],\nright? Yes… but actually no 😦
error[E0277]: the type `[std::vec::Vec<i8>]` cannot be indexed by `aoc_2022::Vector2D<usize>`
--> src/bin/day08.rs:26:18
|
26 | if trees[pos] > tallest {
| ^^^ slice indices are of type `usize` or ranges of `usize`
|
= help: the trait `std::slice::SliceIndex<[std::vec::Vec<i8>]>` is not implemented for `aoc_2022::Vector2D<usize>`
= note: required for `std::vec::Vec<std::vec::Vec<i8>>` to implement `std::ops::Index<aoc_2022::Vector2D<usize>>`
error[E0277]: the type `[std::vec::Vec<i8>]` cannot be indexed by `aoc_2022::Vector2D<usize>`
--> src/bin/day08.rs:30:28
|
30 | max(tallest, trees[pos])
| ^^^ slice indices are of type `usize` or ranges of `usize`
|
= help: the trait `std::slice::SliceIndex<[std::vec::Vec<i8>]>` is not implemented for `aoc_2022::Vector2D<usize>`
= note: required for `std::vec::Vec<std::vec::Vec<i8>>` to implement `std::ops::Index<aoc_2022::Vector2D<usize>>`
error[E0277]: the type `[std::vec::Vec<i8>]` cannot be indexed by `aoc_2022::Vector2D<isize>`
--> src/bin/day08.rs:52:28
|
52 | let max_height = trees[position];
| ^^^^^^^^ slice indices are of type `usize` or ranges of `usize`
|
= help: the trait `std::slice::SliceIndex<[std::vec::Vec<i8>]>` is not implemented for `aoc_2022::Vector2D<isize>`
= note: required for `std::vec::Vec<std::vec::Vec<i8>>` to implement `std::ops::Index<aoc_2022::Vector2D<isize>>`
Why? We have it implemented for the slices ([C]), why doesn't it work? Well,\nthe fun part consists of the fact that in other place, where we were using it,\nwe were passing the &[Vec<T>], but this is coming from a helper functions that\ntake &Vec<Vec<T>> instead. And… we don't implement Index and IndexMut for\nthose. Just for the slices. 🤯 What are we going to do about it?
We can either start copy-pasting or be smarter about it… I choose to be smarter,\nso let's implement a macro! The only difference across the implementations are\nthe types of the outer containers. Implementation doesn't differ at all!
\nImplementing the macro can be done in a following way:
\nmacro_rules! generate_indices {
($container:ty) => {
impl<I, C> Index<Vector2D<I>> for $container
where
I: Copy + TryInto<usize>,
<I as TryInto<usize>>::Error: Debug,
C: Index<usize>,
{
type Output = C::Output;
fn index(&self, index: Vector2D<I>) -> &Self::Output {
let (x, y): (usize, usize) =
(index.x.try_into().unwrap(), index.y.try_into().unwrap());
&self[y][x]
}
}
impl<I, C> IndexMut<Vector2D<I>> for $container
where
I: Copy + TryInto<usize>,
<I as TryInto<usize>>::Error: Debug,
C: IndexMut<usize>,
{
fn index_mut(&mut self, index: Vector2D<I>) -> &mut Self::Output {
let (x, y): (usize, usize) =
(index.x.try_into().unwrap(), index.y.try_into().unwrap());
&mut self[y][x]
}
}
};
}
And now we can simply do
\ngenerate_indices!(VecDeque<C>);
generate_indices!([C]);
generate_indices!(Vec<C>);
// generate_indices!([C; N], const N: usize);
The last type (I took the inspiration from the implementations of the Index and\nIndexMut traits) is a bit problematic, because of the const N: usize part,\nwhich I haven't managed to be able to parse. And that's how I got rid of the error.
If I were to use 2D-indexing over [C; N] slices, I'd probably just go with the\ncopy-paste, cause the cost of this “monstrosity” outweighs the benefits of no DRY.
This issue is relatively funny. If you don't use any type aliases, just the raw\ntypes, you'll get suggested certain changes by the clippy. For example if you\nconsider the following piece of code
\nfn get_sum(nums: &Vec<i32>) -> i32 {
nums.iter().sum()
}
fn main() {
let nums = vec![1, 2, 3];
println!(\"Sum: {}\", get_sum(&nums));
}
and you run clippy on it, you will get
\nChecking playground v0.0.1 (/playground)
warning: writing `&Vec` instead of `&[_]` involves a new object where a slice will do
--> src/main.rs:1:18
|
1 | fn get_sum(nums: &Vec<i32>) -> i32 {
| ^^^^^^^^^ help: change this to: `&[i32]`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_arg
= note: `#[warn(clippy::ptr_arg)]` on by default
warning: `playground` (bin \"playground\") generated 1 warning
Finished dev [unoptimized + debuginfo] target(s) in 0.61s
However, if you introduce a type alias, such as
\ntype Numbers = Vec<i32>;
Then clippy won't say anything, cause there is literally nothing to suggest.\nHowever the outcome is not the same…
", "url": "https://blog.mfocko.dev/blog/aoc-2022/2nd-week/", "title": "2nd week of Advent of Code '22 in Rust", "summary": "Surviving second week in Rust.", "date_modified": "2022-12-25T23:15:00.000Z", "author": { "name": "Matej Focko", "url": "https://gitlab.com/mfocko" }, "tags": [ "advent-of-code", "advent-of-code-2022", "rust" ] }, { "id": "https://blog.mfocko.dev/blog/aoc-2022/1st-week/", "content_html": "Let's go through the first week of Advent of Code in Rust.
\nI will try to summarize my experience with using Rust for the AoC. Trying it out\nages ago, I believe it will be pain and suffering, but we will see. For each\nday I will also try to give a tl;dr of the problem, so that you can better imagine\nthe relation to my woes or 👍 moments.
\nAs the name suggests, we get the calories of the food contained in the elves\nbackpacks and we want to choose the elf that has the most food ;)
\n\nWakey wakey!
\n
Programming in Rust at 6am definitely hits. I've also forgotten to mention how I\nhandle samples. With each puzzle you usually get a sample input and expected\noutput. You can use them to verify that your solution works, or usually doesn't.
\nAt first I've decided to put asserts into my main, something like
assert_eq!(part_1(&sample), 24000);
info!(\"Part 1: {}\", part_1(&input));
assert_eq!(part_2(&sample), 45000);
info!(\"Part 2: {}\", part_2(&input));
However, once you get further, the sample input may take some time to run itself.\nSo in the end, I have decided to turn them into unit tests:
\n#[cfg(test)]
mod tests {
use super::*;
#[test]
fn test_part_1() {
let sample = parse_input(\"samples/day01.txt\");
assert_eq!(part_1(&sample), 24000);
}
#[test]
fn test_part_2() {
let sample = parse_input(\"samples/day01.txt\");
assert_eq!(part_2(&sample), 45000);
}
}
And later on I have noticed, it's hard to tell the difference between the days,\nso I further renamed the mod from generic tests to reflect the days.
Also after finishing the first day puzzle, I have installed an sccache to\ncache the builds, so that the build time is lower, cause it was kinda unbearable.
Well, it's a pretty simple problem. You just take the input, sum the calories and\nfind the biggest one. However, if we try to generalize to more than the biggest\none, the fun appears. We have few options:
\nYou want to know what score did you achieve while playing Rock Paper Scissors.\nAnd then you want to be strategic about it.
Apart from the technical details of the puzzle, it went relatively smooth.
\nI took relatively naïve approach and then tried to simplify it.
\nLet's go reorganize elves' backpacks! Each backpacks has 2 compartments and you\nwant to find the common item among those compartments. Each of them has priority,\nyou care only about the sum.
This is the day where I started to fight the compiler and neither of us decided\nto give up. Let's dive into it \\o/
\nFighting the compiler took me 30 minutes.
We need to find a common item among 2 collections, that's an easy task, right?\nWe can construct 2 sets and find an intersection:
\nlet top: HashSet<i32> = [1, 2, 3].iter().collect();
let bottom: HashSet<i32> = [3, 4, 5].iter().collect();
Now, the first issue that we encounter is caused by the fact that we are using\na slice (the […]), iterator of that returns references to the numbers.\nAnd we get immediately yelled at by the compiler, because the numbers are discarded\nafter running the .collect. To fix this, we can use .into_iter:
let top: HashSet<i32> = [1, 2, 3].into_iter().collect();
let bottom: HashSet<i32> = [3, 4, 5].into_iter().collect();
This way the numbers will get copied instead of referenced. OK, let's find the\nintersection of those 2 collections:
\nprintln!(\"Common elements: {:?}\", top.intersection(&bottom));
Common elements: [3]
Notice that we need to do &bottom. It explicitly specifies that .intersection\nborrows the bottom, i.e. takes an immutable reference to it.
That's what we want, right? Looks like it! \\o/
\nNext part wants us to find the common element among all of the backpacks. OK, so\nthat should be fairly easy, we have an intersection and we want to find intersection\nover all of them.
\nLet's have a look at the type of the .intersection
pub fn intersection<'a>(
&'a self,
other: &'a HashSet<T, S>
) -> Intersection<'a, T, S>
OK… Huh… But we have an example there!
\nlet intersection: HashSet<_> = a.intersection(&b).collect();
Cool, that's all we need.
\nlet top: HashSet<i32> = [1, 2, 3, 4].into_iter().collect();
let bottom: HashSet<i32> = [3, 4, 5, 6].into_iter().collect();
let top_2: HashSet<i32> = [2, 3, 4, 5, 6].into_iter().collect();
let bottom_2: HashSet<i32> = [4, 5, 6].into_iter().collect();
let intersection: HashSet<_> = top.intersection(&bottom).collect();
println!(\"Intersection: {:?}\", intersection);
Intersection: {3, 4}
Cool, so let's do the intersection with the top_2:
let top: HashSet<i32> = [1, 2, 3, 4].into_iter().collect();
let bottom: HashSet<i32> = [3, 4, 5, 6].into_iter().collect();
let top_2: HashSet<i32> = [2, 3, 4, 5, 6].into_iter().collect();
let bottom_2: HashSet<i32> = [4, 5, 6].into_iter().collect();
let intersection: HashSet<_> = top.intersection(&bottom).collect();
let intersection: HashSet<_> = intersection.intersection(&top_2).collect();
println!(\"Intersection: {:?}\", intersection);
And we get yelled at by the compiler:
\nerror[E0308]: mismatched types
--> src/main.rs:10:58
|
10 | let intersection: HashSet<_> = intersection.intersection(&top_2).collect();
| ------------ ^^^^^^ expected `&i32`, found `i32`
| |
| arguments to this function are incorrect
|
= note: expected reference `&HashSet<&i32>`
found reference `&HashSet<i32>`
/o\\ What the hell is going on here? Well, the funny thing is, that this operation\ndoesn't return the elements themselves, but the references to them and when we pass\nthe third set, it has just the values themselves, without any references.
\nIt may seem as a very weird decision, but in fact it makes some sense… It allows\nyou to do intersection of items that may not be possible to copy. Overall this is\na “tax” for having a borrow checker drilling your ass having your back and\nmaking sure you're not doing something naughty that may cause an undefined\nbehavior.
To resolve this we need to get an iterator that clones the elements:
\nlet top: HashSet<i32> = [1, 2, 3, 4].into_iter().collect();
let bottom: HashSet<i32> = [3, 4, 5, 6].into_iter().collect();
let top_2: HashSet<i32> = [2, 3, 4, 5, 6].into_iter().collect();
let bottom_2: HashSet<i32> = [4, 5, 6].into_iter().collect();
let intersection: HashSet<_> = top.intersection(&bottom).cloned().collect();
let intersection: HashSet<_> = intersection.intersection(&top_2).cloned().collect();
let intersection: HashSet<_> = intersection.intersection(&bottom_2).cloned().collect();
println!(\"Intersection: {:?}\", intersection);
Intersection: {4}
The approach is pretty simple, if you omit the 1on1 with the compiler. You just\nhave some fun with the set operations :)
\nElves are cleaning up the camp and they got overlapping sections to clean up.\nFind how many overlap and can take the day off.
RangeInclusive is your friend not an enemy :)
Relatively easy, you just need to parse the input and know what you want. Rust's\nRangeInclusive type helped a lot, cause it took care of all abstractions.
Let's play with stacks of crates.
Very easy problem with very annoying input. You can judge yourself:
\n [D]
[N] [C]
[Z] [M] [P]
1 2 3
move 1 from 2 to 1
move 3 from 1 to 3
move 2 from 2 to 1
move 1 from 1 to 2
Good luck transforming that into something reasonable :)
\nTook me 40 minutes to parse this reasonably, including fighting the compiler.
For the initial solution I went with a manual solution (as in I have done all\nthe work. Later on I have decided to explore the std and interface of the\nstd::vec::Vec and found split_off which takes an index and splits (duh)\nthe vector:
let mut vec = vec![1, 2, 3];
let vec2 = vec.split_off(1);
assert_eq!(vec, [1]);
assert_eq!(vec2, [2, 3]);
This helped me simplify my solution a lot and also get rid of some edge cases.
\nFinding start of the message in a very weird protocol. Start of the message is\ndenoted by N unique consecutive characters.
A lot of different approaches, knowing that we are dealing with input consisting\nsolely of ASCII letters, I bit the bullet and went with sliding window and\nconstructing sets from that window, checking if the set is as big as the window.
\nOne possible optimization could consist of keeping a bit-vector (i.e. usize\nvariable) of encountered characters and updating it as we go. However this has\na different issue and that is removal of the characters from the left side of the\nwindow. We don't know if the same character is not included later on.
Other option is to do similar thing, but keeping the frequencies of the letters,\nand again knowing we have only ASCII letters we can optimize by having a vector\nof 26 elements that keeps count for each lowercase letter.
\nLet's simulate du to get some stats about our file system and then pinpoint\ndirectories that take a lot of space and should be deleted.
\n\nI was waiting for this moment, and yet it got me!\nimagine me swearing for hours
\n
We need to “build” a file system from the input that is given in a following form:
\n$ cd /
$ ls
dir a
14848514 b.txt
8504156 c.dat
dir d
$ cd a
$ ls
dir e
29116 f
2557 g
62596 h.lst
$ cd e
$ ls
584 i
$ cd ..
$ cd ..
$ cd d
$ ls
4060174 j
8033020 d.log
5626152 d.ext
7214296 k
There are few ways in which you can achieve this and also you can assume some\npreconditions, but why would we do that, right? :)
\nYou can “slap” this in either HashMap or BTreeMap and call it a day.\nAnd that would be boring…
BTreeMap is quite fitting for this, don't you think?
I always wanted to try allocation on heap in Rust, so I chose to implement a tree.\nI fought with the Box<T> for some time and was losing…
Then I looked up some implementations of trees or linked lists and decided to try\nRc<Cell<T>>. And I got my ass whopped by the compiler once again. /o\\
Box<T> represents a dynamically allocated memory on heap. It is a single pointer,\nyou can imagine this as std::unique_ptr<T> in C++.
Rc<T> represents a dynamically allocated memory on heap. On top of that it is\nreference counted (that's what the Rc stands for). You can imagine this as\nstd::shared_ptr<T> in C++.
Now the fun stuff. Neither of them lets you mutate the contents of the memory.
Cell<T> allows you to mutate the memory. Can be used reasonably with types that\ncan be copied, because the memory safety is guaranteed by copying the contents\nwhen there is more than one mutable reference to the memory.
RefCell<T> is similar to the Cell<T>, but the borrowing rules (how many mutable\nreferences are present) are checked dynamically.
So in the end, if you want something like std::shared_ptr<T> in Rust, you want\nto have Rc<RefCell<T>>.
So, how are we going to represent the file system then? We will use an enumeration,\nhehe, which is an algebraic data type that can store some stuff in itself 😩
\ntype FileHandle = Rc<RefCell<AocFile>>;
#[derive(Debug)]
enum AocFile {
File(usize),
Directory(BTreeMap<String, FileHandle>),
}
Let's go over it! FileHandle represents dynamically allocated AocFile, not\nmuch to discuss. What does the #[derive(Debug)] do though? It lets us to print\nout the value of that enumeration, it's derived, so it's not as good as if we had\nimplemented it ourselves, but it's good enough for debugging, hence the name.
Now to the fun part! AocFile value can be represented in two ways:
File(usize), e.g. AocFile::File(123) and we can pattern match it, if we\nneed toDirectory(BTreeMap<String, FileHandle>) will represent the directory and will\ncontain map matching the name of the files (or directories) within to their\nrespective file handlesI will omit the details about constructing this file system, cause there are a lot\nof technicalities introduced by the nature of the input. However if you are\ninterested, you can have a look at my solution.
\nWe need to find small enough directories and also find the smallest directory that\nwill free enough space. Now the question is, how could we do that. And there are\nmultiple ways I will describe.
\nI have chosen to implement tree catamorphism 😩. It is basically a fold\nover a tree data structure. We descent down into the leaves and propagate computed\nresults all the way to the root. You can also notice that this approach is very\nsimilar to dynamic programming, we find overlapping sections of the computation\nand try to minimize the additional work (in this case: we need to know sizes of\nour descendants, but we have already been there).
\nAnother approach that has been suggested to me few days later is running DFS on\nthe graph. And, funnily enough, we would still need to combine what we found in\nthe branches where we descent. So in the end, it would work very similarly to my\nsolution.
\nOne of the more exotic options would be precomputing the required information at\nthe same time as parsing. That could be done by adding additional fields to the\nnodes which would allow storing such information and updating it as we construct\nthe file system.
\nThings that have been brought up in the discussion later on.
\nRc<T> vs Rc<RefCell<T>>It has been brought up that I have a contradicting statement regarding the\ndynamically allocated memory. Specifically:
\nRc<T> as an std::shared_ptr<T> (in C++)std::shared_ptr<T>, you want to use\nRc<RefCell<T>>Now, in Rust it is a bit more complicated, because the type that represents the\n“shared pointer” is Rc<T>. What RefCell<T> does is making sure that there is\nonly one “owner” of a mutable reference at a time (and dynamically, as opposed\nto the Cell<T>).
Therefore to be precise and correct about the equivalents of std::shared_ptr<T>\nin Rust, we can say that
Rc<T> is an equivalent of a const std::shared_ptr<T>,Rc<RefCell<T>> is an equivalent of a std::shared_ptr<T>.You can easily see that they only differ in the mutability. (And even that is not\nas simple as it seems, because there is also Cell<T>)
Let's talk about the preparations for this year's Advent of Code.
\nWhen choosing a language for AoC, you usually want a language that gives you a\nquick feedback which allows you to iterate quickly to the solution of the puzzle.\nOne of the most common choices is Python, many people also use JavaScript or Ruby.
\nGiven the competitive nature of the AoC and popularity among competitive programming,\nC++ might be also a very good choice. Only if you are familiar with it, I guess…
\nIf you want a challenge, you might also choose to rotate the languages each day.\nThough I prefer to use only one language.
\nFor this year I have been deciding between Rust, C++ and Pascal or Ada.
\nI have tried Rust last year and have survived with it for 3 days and then gave\nup and switched to Kotlin, which was pretty good given it is “Java undercover”.\nI pretty much like the ideas behind Rust, I am not sure about the whole cult and\nimplementation of those ideas though. After some years with C/C++, I would say\nthat Rust feels too safe for my taste and tries to “punish me” even for the\nmost trivial things.
\nC++ is a very robust, but also comes with a wide variety of options providing you\nthe ability to shoot yourself in the leg. I have tried to solve few days of previous\nAdvent of Code events, it was relatively easy to solve the problems in C++, given\nthat 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\npretty nice standard library that offers enough to be able to quickly solve some\nproblems in it. However the toolkit is questionable :/
\nAll of the sources, later on including solutions, can be found at my\nGitLab.
\nSince we are using Rust, we are going to use a Cargo and more than likely VSCode\nwith rust-analyzer. Because of my choice of libraries, we will also introduce\na .envrc file that can be used by direnv, which allows you to set specific\nenvironment variables when you enter a directory. In our case, we will use
# 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\nthe inputs instead of “clicking, opening and copying to a file”1. There is\nno need to be fancy, so we will adjust Python script by Martin2.
\n#!/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\nsystem, so we do not need to change the day every morning. It also requires a\nconfiguration file:
\n# env.yaml
session: ‹your session cookie›
year: 2022
Looking at the list of the libraries, I have chosen “a lot” of them. Let's walk\nthrough each of them.
\ntracing and tracing-subscriber are the crates that can be used for tracing\nand logging of your Rust programs, there are also other crates that can help you\nwith providing backtrace to the Sentry in case you have deployed your application\nsomewhere and you want to watch over it. In our use case we will just utilize the\nmacros for debugging in the terminal.
thiserror, anyhow and color-eyre are used for error reporting.\nthiserror is a very good choice for libraries, cause it extends the Error\nfrom the std and allows you to create more convenient error types. Next is\nanyhow which kinda builds on top of the thiserror and provides you with simpler\nerror handling in binaries3. And finally we have color-eyre which, as I found\nout later, is a colorful (wink wink) extension of eyre which is fork of anyhow\nwhile supporting customized reports.
In the end I have decided to remove thiserror and anyhow, since first one is\nsuitable 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\ncombination. lazy_static allows you to have static variables that must be initialized\nduring runtime.
itertools provides some nice extensions to the iterators from the std.
When creating the crate for this year's Advent of Code, I have chosen a library\ntype. Even though standard library is huge, some things might not be included and\nalso we can follow KISS. I have 2 modules that my “library” exports, one for\nparsing and one for 2D vector (that gets used quite often during Advent of Code).
\nKey part is, of course, processing the input and my library exports following\nfunctions that get used a lot:
\n/// 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\naddition of the vectors for now and accessing the elements via functions x()\nand y(). Also the vector is generic, so we can use it with any numeric type we\nneed.
We can also prepare a template to quickly bootstrap each of the days. We know\nthat each puzzle has 2 parts, which means that we can start with 2 functions that\nwill solve them.
\nfn part1(input: &Input) -> Output {
todo!()
}
fn part2(input: &Input) -> Output {
todo!()
}
Both functions take reference to the input and return some output (in majority\nof puzzles, it is the same type). todo!() can be used as a nice placeholder,\nit also causes a panic when reached and we could also provide some string with\nan explanation, e.g. todo!(\"part 1\"). We have not given functions a specific\ntype and to avoid as much copy-paste as possible, we will introduce type aliases.
type Input = String;
type Output = i32;
This allows us to quickly adjust the types only in one place without the need to\ndo regex-replace or replace them manually.
For each day we get a personalized input that is provided as a text file. Almost\nall the time, we would like to get some structured type out of that input, and\ntherefore it makes sense to introduce a new function that will provide the parsing\nof the input.
\nfn parse_input(path: &str) -> Input {
todo!()
}
This “parser” will take a path to the file, just in case we would like to run the\nsample instead of input.
\nOK, so now we can write a main function that will take all of the pieces and\nrun them.
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\nuse them. In this part we are going to utilize tracing (for tracing, duh…)\nand color-eyre (for better error reporting, e.g. from parsing).
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\nterminal, based on the environment variable. We also change the formatting a bit,\nsince we do not need all the fancy features of the logger. Pure initialization\nwould get us logs like this:
\n2022-12-11T19:53:19.975343Z INFO day01: Part 1: 0
However after running that command, we will get the following:
\n INFO src/bin/day01.rs:35: Part 1: 0
And the color_eyre::install()? is quite straightforward. We just initialize the\nerror reporting by color eyre.
Notice that we had to add Ok(()) to the end of the function and adjust the\nreturn type of the main to Result<()>. It is caused by the color eyre that\ncan be installed only once and therefore it can fail, that is how we got the ?\nat the end of the ::install which unwraps the »result« of the installation.
Overall we will get to a template like this:
\nuse 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(())
}