I didn’t actually enter the game jam. Honestly, I wasn’t sure I was going to write anything. But I had a bit of an idea and spent a few hours only on Sunday hammering something out:
Yeah, I did another cellular automata thing 😄
It’s not at all complete, but the basic idea is:
Generate a random level
See it with multiple players (colonies of bugs)
Each bug will send out waves of ‘shine’, expanding their territory
Take over the map to win
It’s sort of got that?
I’m using Rust as I’ve been doing a lot recently.
The main libraries are:
pixels for the rendering; it gives me direct access to a pixel buffer, which is my favorite
winit for windowing; this did require the feature rwh_05 to be properly compatible with pixels, which took a minute to track down
Other than, that, it’s straight custom code which you can see in it’s entirety on my github.
world.rs - runs the simulation mostly in an update function; with generation in new
I think that perhaps the only really interesting bit about the code is how the ‘shine waves’ work. Basically, I have a grid of the state of each cell, but I also have a Vec that tracks ‘active’ pixels. Those are the only ones that can update–which both helps performance and makes the simulation appear the way it does.
Overall, a nice quick project. More than anything, it actually convinced me to try setting up something that can render pixel buffers on Rust. And with a (very minimal) GUI, too! Both things I’ve been meaning to learn.
I probably won’t do anything more with this code, but it’s got the seeds of something more interesting. Keep an eye out. 😄
Classes: \d/\D for digits, \w/\W for ‘words’, and \s/\S for whitespace
Escape characters: \t\r\n\v\f
Control characters: \cX (I’ve never used these)
Hex and unicode literals: \hXX and \uXXXX
Disjunction: | (both in capture groups and not)
Groups and back references
Capture groups: (abc)
Named capture groups: (?<name>abc)
Non-capturing groups: (?:abc)
Flags: (?ims-ims:abc)
Both enabling and disabling
i and s but not m
Backreferences: \n
Named backreferences: \k<name>
Quantifiers
* for zero or more
+ for one or more
? for zero or one
*?, +?, and ?? for lazy / non-greedy matches
abc{n} exactly n matches
abc{n,} at least n matches
abc{,m} up to m matches
abc{n,m} at least n and up to m matches (inclusive)
Lazy matches for all of those
Most of those were fairly straight forward extensions of previous code. In think the most interesting ones were handling the parsing of all the different things that can go in groups (including flags).
For each of them, you can check my git commit history to see how I implemented specific things. It’s mostly one commit per feature, but not always.
Unsupported Regex Features (so far!)
Assertions:
Word boundaries (\b and \B)
Look ahead/behind (parsed but not matched)
Character classes
[\b] for backspace characters
Long unicode format: \u{XXXXX}
Unicode properties: \p{...}/\P{...}
Groups and back references:
m flag / mode: multiline matches
The look ahead/behind is the one I’m most interested in supporting. I don’t even think it will be that hard, I just honestly missed it.
The more interesting one will be the m flag. Currently, I only match lines, so that will be a decently large restructuring. We’ll see.
Supported CLI flags
I’ve made an awful lot of progress on this one too!
$ jp-grep --help
A custom grep implementation; always behaves as egrep
Usage: jp-grep [OPTIONS][PATTERN][PATHS]...
Arguments:
[PATTERN] The regular expression to evaluate; may also be specified with -e
[PATHS]... Paths to search for matches; if none are provided read from stdin
Options:
-A, --after-context <AFTER_CONTEXT>
Lines of context to print after each match
-B, --before-context <BEFORE_CONTEXT>
Lines of context to print before each match
-C, --context <CONTEXT>
Lines to print both before and after
-c, --count
Only print the matching count
-E, --extended-regexp
Extended regex mode (egrep); this option is ignored (always true) -e, --regexp <ADDITIONAL_PATTERNS>
Additional patterns, will return a line if any match
-h, --no-filename
Never print filenames
--help
Display this help message
-i, --ignore-case
Default to case insensitive match
-n, --line-number
Print line numbers before matches and context
-r, --recursive
Recursively add any directories (-R also works) -v, --invert-match
Invert the match; only print lines that don't match any pattern
-V, --version
Print version
Of those, the context flags (-A, -B, and -C) were probably the most tricky, since I basically had to implement a circular buffer for them. I could have just read the entire file into memory, but from the beginning, I didn’t want to do that.
-E is a little silly, since that’s the only grep pattern I support (and the only one I actually use in grep, so that’s fair).
So far as supporting multiple files, recursive search, and stdin, read the section on collecting files later.
So far as printing (handling line numbers and file names), read the section on printing lines.
Overall, pretty fun code.
Unsupported CLI flags
So far, there are a bunch of flags that I don’t support for grep. Of those, there are a bunch that I don’t intend to support (like built in compression support and properly dealing with symlinks).
The things that I would still like to support though are:
Input options:
-f file/--file=file - Read patterns from file
Output options:
-a/--text - Currently I always have this set; I don’t treat binary files differently
-L/--files-without-match - only print files that don’t match
-o/--only-matching - only print the matching groups; I have the groups for backreferences, use them!
File filtering - files to include/exclude (useful with recursive matches):
--exclude pattern
--exclude-dir pattern
--include pattern
--include-dir pattern
That’s not too bad, all things consider.
Error handling
One thing that I actually played a bit with this time around was custom error handling in the parser. Rather than just returning &str all over the place for Err types, I made my own:
The WithPosition type also lets me pinpoint exactly where in a pattern I failed:
jp-grep 'this is some long complicated pattern, \hXX see?'Error parsing regex: Invalid character 'X', expected hex digit
| this is some long complicated pattern, \hXX see?|^
That’s pretty neat and I hope helpful! 😄
Expanding past CodeCrafters
Overall, I’m pretty happy with this project. It’s got a pretty decent chunk of code, including…
$ jp-grep -c -v -e '//' -e '^\s*$' **/*.rs
1241
…over 1000 lines of Rust code, including tests but not blank lines or comments. 😄
I’ll probably pick this up at least once more.
Now… will I actually use this? Probably not. But it was certainly interesting to write.
Other than that, was CodeCrafters actually helpful for this? Middling. It was the kick I needed to actually do it (I’ve been meaning to write this for years at this point) and once I was started, I could finish it. On the other hand, the output format they require was a bit annoying at times, I’ve mostly moved away from that.
Still, worth I think. I’ll probably continue to do their free programs. Kafka is up next. Whee servers!
Didn’t I just do one of these? Well, yes. Yes I did. But I love building compilers and interpreters, so when I saw this one was in beta (and thus free 😉), I had to try it!
It’s directly an implemention of the Lox languages from the Crafting Interpreters website / book (my review), if incomplete. By the end of the lesson, we’ll have:
A tokenizer that handles parentheses, braces, operators (single and multiple character), whitespace, identifiers, string literals, numeric literals, and keywords A parser that can take those tokens and build an abstract syntax tree using recursive descent parsing A simple tree walking interpreter for some subset of the language It doesn’t handle all of the syntax (yet).
Another Rust Solvers puzzle: Cosmic Express. Basically, it’s a routefinding puzzle. You have a train that needs a track from entrance to exit, picking up and dropping off cargo on the way.
It’s actual a relatively simple puzzle, so far as things go, but one thing that’s interesting from a solving perspective is that branching paths really don’t work great with my solver code. Paths just have a crazy branching factor when compared to (for example) playing one of a handful of cards.
I recently stumbled across CodeCrafters again1. In a nutshell, they give a number of ‘Build Your Own…’ courses, each of which will automatically create a repo for you, guide you through solving the program step by step, and provide some feedback on the way.
On one hand, it’s a freemium (one problem a month is free) / paid service. I wish they had tiers. I really think their monthly fee is a bit steep for what they offer (we’ll come back to that). But on the other hand, it’s a neat tool and I’ve been wanting some more larger programming projects to learn more Rust on, so away we go!
One of the problems (of a sorts) I’ve been having with my series on Rust Solvers is that, for each input puzzle, I need a way to save one or more ‘known good’ solutions so that when I change and add new functionality, I can verify that I’ve either not changed the solution or found another valid one.
So far, I’d been building this into each solution. While this worked perfectly fine, it’s a bit annoying to copy and paste to each binary, and then have to edit each test case with the answers.
This time around, we’re going to solve Golf Peaks. I picked this up a while ago on iOS, but only recently on Steam. It’s a cute little puzzle game themed around minigolf.
Basically, you’re on a grid and you have to get the ball (in the bottom in that screenshot above) to the flag (currently at the top). You have a set list of moves you can take, styled as cards–all of which either move a certain number of tiles in a specific direction or possibly jump into the air (and fly over obstacles).
It gets more complicated from there, but hopefully you have the basic idea. 😄
The basic idea is you have a field of elements with (chemical accurate) free electrons):
Here we have 4 hydrogens (1 bond each) and a carbon (4 bonds). It should seem pretty obvious that the carbon should end up with a hydrogen on each end. The one last bit of interest: the element with the dashed border is the one we actually control, that will never change.
This eventually gets more complicated, adding:
Modifiers that are placed on the map between squares:
One that strengthens bonds, turning a single bond into double into triple
One that weakens bonds, turning triple to double to single or breaking single bonds
One that rotates bonds as you move by it
More elements, eventually hydrogen (1), oxygen (2), nitrogen (3), carbon (4), and helium (0)
Solutions that require forming multiple elements at the same time
It’s a pretty neat puzzle game with 144 levels of increasing difficulty. Perfect to solve.
I enjoy puzzle games. I especially enjoy letting computers solve them for me 😄. Once upon a time, I set up a framework for solving random things. Let’s solve some more.
It’s a Sokoban about making snowmen! You can push snowballs of three sizes around, collecting snow if you roll over it. You can push smaller snowballs onto bigger ones, stacking them. Or back off, in order to get around one another.
And that’s really it.
There are some interesting twists (multiple snowmen, the ability to leave and re-enter levels, and even a whole second ‘hard mode’), but at a basic level, it’s just pushing.
