I knew that shell files, especially in build systems can get hard to read, but this was absolutely painful to look at from start to finish, even with the very helpful explanations in between. Of course the obfuscation is mostly done by design in this case.

OpenSuse Slowroll does pretty much that, a slightly delayed rolling release.

I don’t think there is a good way of having references within the same struct, but you could store reference counted matches:

matches: Vec<Rc<Match>>,
players: HashMap<String, Rc<Match>>,

You would still have to make sure that the players map is updated, maybe weak references are useful there.

Maybe you could also consider storing the players of a match in the match itself, not outside.

If there won’t be too many different plugins, maybe having a feature for each plugin would work. Then you could use --features=... when compiling to select the plugins you need.

Cat by C418 is literally the only piece in the list I recognize.

I like to look at Issues and Pull Requests on Github if a crate wasn’t updated for multiple years. If there are already problems like unsoundness, deprecation, or breaking bugs mentioned with no reaction shown by the maintainer, that is a good sign to look elsewhere instead. If everything seems fine and the crate isn’t very complex or security-critical, it is probably not an issue.

I am also very interested in seeing what the next generation of Rust-inspired languages will look like, and not because I am dissatisfied with Rust today. Rust has significantly raised the bar of how a good programming needs to work and any new language in the systems programming area (and beyond) will inevitably be compared to it.

I really like kitty. It is fast and simple but gives me all the features I would want.

Being active is probably most important.

Maybe it would be possible to get a link into a “This Week in Rust”?

lemmy.made.me.look.at.this.each.time.i.open.a.terminal

Hostnames can be up to 64 characters long in Linux.

I use Colemak where most punctuation is at the same place as in the US English layout, which programming languages seem to be optimized toward. For the layout I prefer ISO for the larger Enter key.

That’s sad that Mozilla has to take it into their own hands to provide a proper alternative to Snap Firefox.

Rust

I simply check each starting position individually for Part 2, I don’t know if there are more clever solutions. Initially that approach ran in 180ms which is a lot more than any of the previous puzzles needed, so I tried if I could optimize it.

Initially I was using two hash sets, one for counting unique energized fields, and one for detecting cycles which also included the direction in the hash. Going from the default rust hasher to FxHash sped it up to 100ms. Seeing that, I thought that this point could be further improved upon, and ended up replacing both hash sets with boolean arrays, since their size is neatly bounded by the input field size. Now it runs in merely 30ms, meaning a 6x speedup just by getting rid of the hashing.

You can create an array filled with all the same values in Rust, but only if all values have the same memory representation because they will be copied. That just doesn’t work with Vec’s, because they must all have their own unique pointer. And to have uninitialized values at first (think NULL-pointers for every Vec) while creating each Vec, something like this is apparently needed.

The appropriate way would certainly have been to store the map as a Vec> instead of an array, but I just wanted to see if could.

Rust

Part 1 was super simple with wrapping_add and wrapping_mul on a u8. Building an actual hash map in Part 2 was nice.

Rust

The trick for part 2 is obviously to check when the pattern repeats itself and then jump ahead to 1000000000.

My code allocates an entire new grid for every tilt, some in-place procedure would probably be more efficient in terms of memory, but this seems good enough.

Rust

Part 2 turned out easier than I thought initially. My code assumes that there is only 1 mirror in each field which means I don’t have to remember where the smudge is, I just have to find a mirror line where the two halves differ at exactly one spot.

I don’t think there are many significant optimizations with regards to reducing the search tree. It took me long enough to get behind it, but the “solution” (not saying there aren’t other ways) to part 2 is to not calculate anything more than once. Instead put partial solutions in a dict indexed by the current state and use that cached value if you need it again.

It seems like you are actually constructing all rows with replaced ?. This won’t be viable for part 2, your memory usage will explode. I have a recursive function that calls itself twice whenever a ? is encountered, once assuming it’s a ., and once a #.

Rust

Took me way too long, but I’m happy with my solution now. I spent probably half an hour looking at my naive backtracking program churning away unsuccessfully before I thought of dynamic programming, meaning caching all intermediate results in a hashtable under their current state. The state is just the index into the spring array and the index into the range array, meaning there really can’t be too many different entries. Doing so worked very well, solving part 2 in 4ms.

Adding the caching required me to switch from a loop to a recursive function, which turned out way easier. Why did no one tell me to just go recursive from the start?

Yeah, not gonna do that.