Repository files navigation

This package contains the framework and executable for myAdvent of Codeinteractive development environment and runner/tester/benchmarker. Networkingpowered byadvent-of-code-api library.

You write your solutions in theAOC.Challenge.DayXX modules, make sure touncomment the exports, and everything should be good to go for interactiverunning, testing, viewing of prompts --- as well as integration into theexecutable.

Designed to only accommodate development for a single year. If you want towork on multiple years, you should re-fork into a new directory andre-configure (and change the executable name).

The solutions expected in terms of a:~> record type:

dataa:~>b=MkSol{sParse::String->Maybea--^ parse input into an `a`    ,sSolve::a->Maybeb--^ solve an `a` input to a `b` solution    ,sShow::b->String--^ print out the `b` solution for submission}

Ana :~> b is a solution to a challenge expecting input of typea andproducing answers of typeb. It also packs in functions to parse aStringinto ana, and functions to show ab as aString to submit as an answer.

This is meant to help mentally separate out parsing, solving, and showing,allowing for some cleaner code and an easier time planning my solution.

Such a challenge can be "run" on string inputs by feeding the string intosParse, thensSolve, thensShow:

--| Run a ':~>' on some input, retuning 'Maybe'runSolution::Challenge->String->MaybeStringrunSolutionMkSol{..} s=do    x<- sParse s    y<- sSolve xpure$ sShow y

In the actual library, I haverunSolution return anEither so I can debugwhich stage the error happened in.

sSolve also supportsdyno_ :: Typeable a => String -> a -> a, which is howspecial test parameters are implemented. For example, 2018 Day 6 involvesfinding points that had a total distance of less than 10000, but for the testinput, we found the points that had a total distance of less than 32. So,dyno_ allows you to writedyno_ "limit" 10000. This will be10000 whenrunning on test input, but will be replaced by the "limit" key that test datais allowed to manually supply. (Seethis file for reference.)

It is common to want to use certain common "utility" functions betweendifferent tests. For this, you can add them to theAOC.Common module, andthese will be loaded as a part ofAOC.Prelude.

When you run theaoc-dev executable for the first time, it will generate adefault configuration file at./aoc-conf.yaml. At the moment, theconfiguration contains two fields:

1. session: the session key. Allows you to download input data, part 2prompts, and also submit challenges.

   Can be found by logging in on a web client and checking the cookies. Youcan usually check these with in-browser developer tools.

2. year: The year you are working on. Note that this project is designed toonly accommodate one "year" at a time. If you want to work on a differentyear, you should re-fork and start in a new project directory (and changehe executable name). Note that you can re-use session keys between years,provided that they have not expired.

TheAOC.Run.Interactive module has code (powered byadvent-of-code-api) for testing your solutions and submitting withinGHCI, so you don't have to re-compile. If you edit your solution programs, theyare automatically updated when you hit:r in ghci.

ghci> execSolution_$ solSpec 'day02a-- get answer for challenge based on solutionghci> testSolution_$ solSpec 'day02a-- run solution against test suiteghci> viewPrompt_$ solSpec 'day02a-- view the prompt for a partghci> waitForPrompt_$ solSpec 'day02a-- count down to the prompt for a partghci> submitSolution_$ solSpec 'day02a-- submit a solution

These are loaded with session key stored in the configuration file.

These identifiers (likeday02a) need to be exported and in scope for this towork. If they aren't, you can manually specify the day and part, by usingmkCS 2 Part1, etc.

Comes with test examples given in problems. The executable is namedaoc-devby default, but it is recommended that you change the name (inpackage.yaml)based on whatever year you are attempting.

$ aoc-dev --helpaoc-dev - Advent of Code 2018 challenge runnerUsage: aoc-dev [-c|--config PATH] COMMAND   Run, test, bench, challenges from Advent of Code, and view prompts.   Available days: 1, 2, 3 (...)Available options:  -c,--config PATH         Path to configuration file (default: aoc-conf.yaml)  -h,--help                Show this help textAvailable commands:  run                      Run, test, and benchmark challenges  view                     View a prompt for a given challenge  submit                   Test and submit answers for challenges  test                     Alias for run --test  bench                    Alias for run --bench  countdown                Alias for view --countdown$ aoc-dev run 3 b>> Day 03b>> [✓] 243

You can supply input via stdin with--stdin:

$ aoc-dev run 1 --stdin>> Day 01a+1+2+1-3<Ctrl+D>[?] 1>> Day 01b[?] 1

Benchmarking is implemented usingcriterion

$ aoc-dev bench 2>> Day 02abenchmarking...time                 1.317 ms   (1.271 ms .. 1.392 ms)                     0.982 R²   (0.966 R² .. 0.999 R²)mean                 1.324 ms   (1.298 ms .. 1.373 ms)std dev              115.5 μs   (77.34 μs .. 189.0 μs)variance introduced by outliers: 65% (severely inflated)>> Day 02bbenchmarking...time                 69.61 ms   (68.29 ms .. 72.09 ms)                     0.998 R²   (0.996 R² .. 1.000 R²)mean                 69.08 ms   (68.47 ms .. 69.99 ms)std dev              1.327 ms   (840.8 μs .. 1.835 ms)

Test suites run the example problems given in the puzzle description, andoutputs are colorized in ANSI terminals.

$ aoc-dev test 1>> Day 01a[✓] (3)[✓] (3)[✓] (0)[✓] (-6)[✓] Passed 4 out of 4 test(s)[✓] 416>> Day 01b[✓] (2)[✓] (0)[✓] (10)[✓] (5)[✓] (14)[✓] Passed 5 out of 5 test(s)[✓] 56752

This should only work if you're runningaoc-dev in the project directory.

To run on actual inputs, the executable expects inputs to be found in thefolderdata/XX.txt in the directory you are running in. That is, the inputfor Day 7 will be expected atdata/07.txt.

Session keys are required to download input data, "Part 2" prompts for eachchallenge, and also to submit.

You can "lock in" your current answers (telling the executable that those arethe correct answers) by passing in--lock. This will lock in any finalpuzzle solutions encountered as the verified official answers. Later, if youedit or modify your solutions, they will be checked on the locked-in answers.

These are stored indata/ans/XXpart.txt. That is, the target output for Day 7(Part 2,b) will be expected atdata/ans/07b.txt. You can also manuallyedit these files.

You can view prompts: (use--countdown to count down until a prompt isreleased, and display immediately)

$ aoc-dev view 3 b>> Day 03b--- Part Two -------------------Amidst the chaos, you notice that exactly one claim doesn't overlap byeven a single square inch of fabric with any other claim. If you cansomehow draw attention to it, maybe the Elves will be able to makeSanta's suit after all!For example, in the claims above, only claim `3` is intact after allclaims are made.*What is the ID of the only claim that doesn't overlap?*

You can also submit answers:

$ aoc-dev submit 1 a

Submissions will automatically run the test suite. If any tests fail, you willbe asked to confirm submission or else abort. The submit command will outputthe result of your submission: The message from the AoC website, and whether ornot your answer was correct (or invalid or ignored). Answers that areconfirmed correct will be locked in and saved for future testing against, incase you change your solution.

All networking features are powered byadvent-of-code-api.

Note also thatstack test,stack bench,cabal test,cabal bench, etc.are all convenient aliases ofaoc-dev test all andaoc-dev bench all. Thiscan be useful continuous integration purposes.