Great question! This is a program meant to run on the awesome Flipper Zero that will calculate the answers to the just as awesome Advent of Code puzzles (2022 edition) graciously offered each year by Eric Wastl.
Nope. At least not directly: you would first need to port all the Flipper-specific bits to your environment.
C. Github is not lying. I did take advantage of mlib to ease the pain, as it is already used in the Flipper Zero firmware.
It is based on a STM32WB55RG chip: 32-bit 64 MHz CPU, 256 KB RAM.
However the aim here was to make a program that can be dynamically loaded by a running Flipper (i.e. a FAP), and so the actual available memory is closer to 100 KB... Which was the main challenging constraint here (besides working with plain C).
Most days are solved fairly quickly (fraction of a second). A few however take a while. Day 23 — part 2, for instance, takes about 20 seconds. Again, the aim here wasn't speed, but simply trying to fit the problem onto the limited space of a Flipper Zero.
The easiest is to first clone/check out the official firmware (version 0.75.0 would be the one this application was tested with), and then add this here repository as a submodule.
Inside the flipperzero-firmware top-level directory:
$ git submodule add -f https://github.com/itizir/advent-of-code-2022.git applications_user/advent_of_code_2022
Follow the instructions on how to build and run FAPs. For instance
$ ./fbt COMPACT=1 DEBUG=0 launch_app APPSRC=applications_users/advent_of_code_2022
I recommend compiling with those flags indeed (see point about bugs below).
The program will be installed in the Games Applications folder.
Then after obtaining puzzle inputs from the AOC website, save them as .txt files on the Flipper's SD card under /advent/2022, naming them after the corresponding day number. E.g. /advent/2022/13.txt.
The risk of your Flipper catching fire because of it is... very low. And it won't steal your grandma's date of birth either.
Still, use it at your own risk!
The chances of your Flipper crashing or hanging because of it are high! Especially since most of the solvers simply assume correctly formed input data, and appropriately sized problems, without checking.
Yes. Just as I was preparing this release, I realised day 14 does not safely run if the release COMPACT=1 and DEBUG=0 flags are not used, as the recursion then seems to lead to a stack overflow. I may or may not get round to fixing this. 🤷
It is also not currently possible to interrupt long calculations (e.g. pressing the 'back' button), which would be a nice addition.
And then obviously there are always unknown bugs and issues...
Please do let me know if you find some, in particular if wrong answers are produced: the puzzle inputs are not all identical for everybody, so there may well be bugs I didn't notice because I was lucky with my input.