Stream: advent of code

Topic: AoC Template


view this post on Zulip Luke Boswell (Nov 25 2023 at 13:37):

I've noticed people posting templates in Reddit for AoC. I'd like to put one together and do the same.

I have some opinions about what makes a good template already. Like ingesting the input file bytes. Printing to the terminal with nice colors. Setting up the tasks so the errors compose nicely etc. Timing the processing stages. Parsing example. 2D array example?

It's pretty similar to the Task example tbh.

What do people here think? Any advice or ideas from last year?

Can you think of a good way to present a template? Is it better just as one big file or maybe a repository with different examples?

view this post on Zulip Elias Mulhall (Nov 25 2023 at 13:54):

I was thinking about this in the context of that other thread you made about fixing the opaque type open-by-default-in-output-position issue. I think it's perfectly reasonable for an AoC solution to have a main task and no other tasks, since you can read the input files at compile time. That sidesteps the issue of composing error tags.

view this post on Zulip Elias Mulhall (Nov 25 2023 at 14:00):

Similarly this thread came up because @drew wanted to build an AoC template where everything is one application and you provide a cli arg for the day you want to run. I think that's a cool idea, but it might be best to steer new people away from that pattern. Roc still has some pretty bad crash/error messages, so keeping everything in one application could make it harder to debug problems.

view this post on Zulip Elias Mulhall (Nov 25 2023 at 14:02):

I think for AoC it's very reasonable to have an orCrash helper to deal with Results locally, instead of having to handle them all at the end. The flip side of that is we want to show off how Results compose, since it's something most people probably haven't seen before.

view this post on Zulip Oskar Hahn (Nov 25 2023 at 14:58):

Here is a repo a friend of my build for AoC. It's creates one application and the day has to provided via cli arg. It currently contains a day0 as demo.

https://github.com/normanjaeckel/AdventOfCode

I think, I like the solutions better, where every day is an independent application. It makes it easier to share the solution of one day.

It would be nice, if there was a common AoC platform, were the main returns two strings. It would not need any Task.

view this post on Zulip Elias Mulhall (Nov 25 2023 at 15:22):

Oh sure, having an AoC specific platform would be cute. Sometimes the puzzles have a cool visual output so it can be fun to print more than just the solution, but I guess that could be done by building a multiline string

view this post on Zulip Luke Boswell (Nov 26 2023 at 04:43):

Elias Mulhall said:

Similarly this thread came up because drew wanted to build an AoC template where everything is one application and you provide a cli arg for the day you want to run. I think that's a cool idea

So I've made a bit of a start on this and have a basic structure which I think is ok.

https://github.com/lukewilliamboswell/aoc-template

It's currently hardcoded to 2022 day 1, but it will be easy to to add cli args for things like "list all available puzzles" "run a particular puzzle" etc. I've been thinking I could even use some more ansi escape stuff to build selection menus with nice colors etc.

But, looking for feedback on the actual API for implementing a single day. The process would be copy-paste another puzzle solution like S2022D01.roc and rename, then just implement these parts;

solution : AoC.Solution
solution = { year: 2022, day: 1, part1, part2 }

part1 : {} -> Result Str [NotImplemented, Error Str]
part2 : {} -> Result Str [NotImplemented, Error Str]

To add that day's solution to that app there is just a list in cli.roc, so you import the module and then just add it to;

solutions : List AoC.Solution
solutions = [
    S2022D01.solution,
    # add your solution here
]

There should be very little need to modify the cli.roc file and everything will run nicely I think.

view this post on Zulip Luke Boswell (Nov 26 2023 at 04:46):

I'd like to add timing information too, to time how long it takes to run the solution.

view this post on Zulip Luke Boswell (Nov 26 2023 at 07:09):

I'm definitely getting a little carried away here. It's just too much fun building things with Roc.

I've now got both a CLI and a Webserver app using the same Puzzle Solution data.

If anyone is interested in helping I think we can make this a pretty neat template :roc: , and in a day or two I would like to share it on socials in preparation for AoC.

Anyway, here is a demo of web.roc in action. :hearts:

aoc-template-1.gif

view this post on Zulip Oskar Hahn (Nov 26 2023 at 09:46):

Here is the repo, that I will probably use. It contains a very simple platform, that only expects

solution : (Str, Str)

So there is no need to work with tasks.

https://github.com/ostcar/aoc2023

view this post on Zulip Oskar Hahn (Nov 27 2023 at 17:57):

I played around a bit more. I want to return two functions/symbols to the platform, so the platform can time each part individually and tell, how many ms it took. Currently, it is not possible, that the roc-app returns two function. So part1 and part2 have to be combined.

Which version do you like more (line 8 to 11)?

https://github.com/ostcar/aoc2023/compare/return_two_functions#diff-5960de10bfc64baa9315d744c8cf7b38e18e6e5957948dbaaf9dff50f2cfc7c2R8-R11

The left side provides a function, that has an argument [Part1, Part2] that has to be checked.

The right side provides a record with two fields, each is a function with an unused argument.

view this post on Zulip Brendan Hansknecht (Nov 27 2023 at 18:16):

Oh, based on how you are using part 1 and 2, I guess they can just be Str and not {} -> Str

view this post on Zulip Oskar Hahn (Nov 27 2023 at 20:31):

My goal is, to time how long each part took. The current output for my dummy day0 is:

Part1 in 5.311us:
Hello, World! ๐Ÿ•Š ๐Ÿค˜

Part2 in 54.372us:
๐Ÿค˜ ๐Ÿ•Š !dlroW ,olleH

When I change {} -> Str to Str, it is:

Part1 in 141.213us:
Hello, World! ๐Ÿ•Š ๐Ÿค˜

Part2 in 21.451us:
๐Ÿค˜ ๐Ÿ•Š !dlroW ,olleH

So you can see clear, that roc is not lazy. Both parts will be calculated, even if only part1 was requested.

view this post on Zulip Oskar Hahn (Nov 27 2023 at 20:35):

Here is the diff: https://github.com/ostcar/aoc2023/compare/return_two_functions...return_two_values

view this post on Zulip Brendan Hansknecht (Nov 27 2023 at 21:01):

Ah, didn't realize that part of the goal... Makes sense

view this post on Zulip Luke Boswell (Nov 29 2023 at 07:32):

So I've made some good progress with lukewilliamboswell/aoc-template and I think it's almost in a good enough state to share more broadly. My thoughts were posting it to the AoC Reddit as that seems to be what others are doing, and I think Roc will be well placed for this year.

I'm looking for some assistance to test the current cli app. I can't really think of anything further I need to do with it. I'm looking for anything that might be a blocker for people to use this in anger as their primary driver for AoC.

The web app is still a WIP and needs a bit of love before it will actually run the solutions, but that should be reasonably quick to do. The cli app took a bit longer because I got carried away making it graphical.

Anyway, in case you are interested to know what it looks like here is a small demo of it.

example-cli.gif

view this post on Zulip Luke Boswell (Nov 29 2023 at 07:34):

Also any feedback on the design such as colors would be nice too. I've played with it a bit, but it's really challenging to make something look nice. I might have gone overboard with the colors.

view this post on Zulip Anton (Nov 29 2023 at 11:09):

I personally would go with a bare essentials version:

Most people will be familiar with running things with the terminal, e.g. roc S2023/DO1.roc, I would be cautious with trying to replace familiar workflows with a cli or web app.

view this post on Zulip Elias Mulhall (Nov 29 2023 at 15:43):

I generally agree -- for many users I think they'll want a minimal template that fits into their existing workflow, not something that imposes a certain workflow. That said, this is really cool and a neat way to show off how Roc apps are put together. I think this template would be more attractive to people who are planning on doing every AoC puzzle in Roc, vs people who jump around and try different languages on different days.

I don't think providing examples is the way to go. There are existing resource for that which we can point people to.

It seems like we have three contenders for a recommended AoC template format

Would it be too much to enumerate all three of those? We could either have a repo or a gist with the options and basically say "if you want the most standard experience use X, if you want something stripped back use Y, and if you want a full UI use Z."

view this post on Zulip Luke Boswell (Nov 29 2023 at 18:09):

My goal here is to share this with the social media crowd and encourage more people to try out Roc for this AoC.

The template is complete overkill for just solving the puzzles, but my hypothesis is that it will help people to get started who are less familiar with Roc, and once they see how you can make things like this they will be encouraged to learn more and tinker with it. Having a template with cli graphics and web server shows what is possible and how easy it is , and saves people some time if they tinker with it to make something else.

I've been having fun making the template, and I will probably keep evolving it as I go through the puzzles.

Also I am trying to show it is easy to not be locked into just one platform to make useful things.

view this post on Zulip Elias Mulhall (Nov 29 2023 at 19:09):

Hmmmmmm. Ok, so something that makes me hesitate on this approach is that if I'm debugging a particular puzzle solution I will need to recompile my code and then take at least one more step to view the output. For the cli I need to select the correct day from the list, and for the web app I need to switch to my browser (assuming I'm already on the right route). That makes both platforms seem better for viewing completed puzzles than solving new ones, since the feedback loop is not as tight.

I know this is more work, but what if you had three platforms

view this post on Zulip Elias Mulhall (Nov 29 2023 at 19:12):

In general I think isolating each puzzle in its own app is better for debugging and helping new people with errors. Your point about sharing something fancy to get people's attention is def valid.

view this post on Zulip Luke Boswell (Nov 29 2023 at 19:28):

Cool, thank you for looking at this. Ill change cli to tui, and a cli and some more polish/documentation and post it later this evening in preparation for tomorrow's start. :grinning:


Last updated: Jul 06 2025 at 12:14 UTC