I've got one of those classic... passes all the test cases, but fails with real input for Part 2 :smiling:
I need to go do some things... I figure I may as well share my WIP solution.
https://github.com/lukewilliamboswell/aoc/blob/main/2024/02.roc
There's some logical bug in there, it passes all the tests but doesn't give me the correct answer.
I think today's part 2 just shows how well designed the stdlib is already :heart:
https://github.com/r-bar/advent24/blob/master/day02/p2.roc
I have found import "day2.txt" as day2Text : Str
to be so convenient that I wonder if that language feature was inspired by a previous AoC.
Ah, I think I know what my bug must be, but I'm afk for a few hours :grimacing:
:partying_face:
https://gitlab.com/JanCVanB/aoc-2024/-/blob/main/day-02/part-1/main.roc
https://gitlab.com/JanCVanB/aoc-2024/-/blob/main/day-02/part-2/main.roc
I got mine done too.
I always try to do it in as few passes as possible, which caused this to take a really long time. I got it wrong many times and eventually had to look at some other solutions to figure out my incorrect assumptions.
However I'm pretty happy with the solution and it should be much, much faster than the permutation solutions.
Though I believe in the worst case it's O(n log n) because it would check the last item n times and the first item at most once
https://github.com/faldor20/aoc-template/blob/purity-inference/examples/2024/02.roc
Here is mine: https://github.com/ostcar/aoc2024/blob/main/day02.roc
I also run into the case, that the tests passes but part2 produces a wrong solution. Needed some moments away, to see my mistake.
@Ryan Barth I like how you solved it
Thank you @Oskar Hahn . One of the benefits of doing it that way was with the examples it became very easy to visually debug. Changing the original code from
answer = parseInput input
|> List.map diffLine
|> List.countIf safe
to this and running the example through it
answer = parseInput input
|> List.map diffLine
|> dbg
|> List.countIf safe
gives you this as the output
❯ roc p1.roc -- example.txt
[p1.roc:15] parseInput input
|> List.map diffLine = [[-1, -2, -2, -1], [1, 5, 1, 1], [-2, -1, -4, -1], [2, -1, 2, 1], [-2, -2, 0, -3], [2, 3, 1, 2]]
2
Which is how I managed to be a degenerate and write 0 expects while solving this. Who ever figured out how to produce the context in those dbg
statements is a hero. What a wonderful feature!
That's coo @Ryan Barth , reading your and @JanCVanB solution is what helped me got mine over the line.
Fixed my part 2 ... decided to just make all the permutations and brute force it. :smiley:
https://github.com/lukewilliamboswell/aoc/blob/main/2024/02.roc
part 2
TIMING:
READING INPUT: <1ms
SOLVING PART 1: 6ms
SOLVING PART 2: 6ms
@Luke Boswell
After having a chat with @JanCVanB about how my solution works, I refactored it a little and added an explanation.
For anyone curious
explanation:
Also just in case anyone was wondering, it's a little over twice as fast as the permutation approach
Here is mine: https://github.com/thenikso/advent-of-code-2024-roc/blob/main/02.roc
Really having a lot of fun with Roc!
Don't understand why my solution is not working. It passes with the test data, and I can't get dbg
to work except with roc test
. Anyone know how I can force it?
How are you accounting for the possibility that the first element could be the wrong one? Are you assuming it's always good?
I'm still on puzzle 1. It's always OK
Lol, your posting in Day 2 thread
Oh, Part 1?
Maybe its the way your parsing the reports? Are you losing any data?
Are you using Str.readToEnd
? I hadn't realised I'd left the wrong thing in my example in the template https://github.com/lukewilliamboswell/aoc-template/pull/6
Yeah Day 2, Part 1
I have all 1000 reports. I have expect processed == 1000
I get 4 safe reports
And I'm importing the txt file as a string
And now I'm moving to using walkTry (AWESOME, btw)
We have different puzzle inputs
Maybe, mine failed :-(
And now I'm getting this compiler error when I moved to walkTry:
thread '<unnamed>' panicked at crates/compiler/can/src/exhaustive.rs:214:41:
constructor must be known in the indexable type if we are exhautiveness checking
stack backtrace:
0: rust_begin_unwind
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:645:5
1: core::panicking::panic_fmt
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:72:14
2: core::panicking::panic_display
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:196:5
3: core::panicking::panic_str
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:171:5
4: core::option::expect_failed
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/option.rs:1980:5
5: expect<alloc::vec::Vec<roc_types::subs::Variable, alloc::alloc::Global>>
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/option.rs:894:21
6: index_var
at /Users/anthonybullard/Development/roc/crates/compiler/can/src/exhaustive.rs:214:32
7: reify
at /Users/anthonybullard/Development/roc/crates/compiler/can/src/exhaustive.rs:277:21
8: {closure#0}
at /Users/anthonybullard/Development/roc/crates/compiler/can/src/exhaustive.rs:588:28
Should be crashing like that. If you could make an issue with a repro that would be super helpful
Nope, I'm just not very smart. I've never coded in a language with no syntax highlighting AND no LSP
I just now have one additional report for some reason, but I got the right answer!
TIL: If you import a txt file as a String, better pass it to Str.trim if you are splitting on newlines! :man_facepalming:
Part 2 done as well. I used permutations, but just as a fall back if the original report failed
https://github.com/gamebox/aoc-2024/blob/main/day2/puzzle2/main.roc
Well I was thoroughly stupid about Part 2 and had about 10 very cunning versions which all worked absolutely whizzily on the test data and not on the real data until the light dawned ... and I am afraid I permuted ... but the data was amenable to brute force so ... I need to go back and check some elegant solutions.
Not looking to code golf on something I get 20 minutes a day to do
Anthony Bullard said:
Nope, I'm just not very smart. I've never coded in a language with no syntax highlighting AND no LSP
Hey, we should have lsp and highlighting support for every editor I know of, it's in the install docs on the website. Msg me if you need a hand in getting it setup :)
Eli Dowling said:
Anthony Bullard said:
Nope, I'm just not very smart. I've never coded in a language with no syntax highlighting AND no LSP
Hey, we should have lsp and highlighting support for every editor I know of, it's in the install docs on the website. Msg me if you need a hand in getting it setup :)
Thank you! I’m just being intentionally lazy here. Some people around me have been having the conversation that no LSP will help you learn a new language faster, so I’m trying it out. I’ll probably set up syntax highlighting tomorrow. I’m impressed with myself doing Day2Part2 in about 5 minutes with these conditions :rolling_on_the_floor_laughing:
https://github.com/isaacvando/aoc/blob/main/2024/2.roc
I succumbed to brute force also :smiley:
no LSP will help you learn a new language faster
Just guessing but I don't think that is true for Roc, I expect type on hover and instant error underline to help a lot
Yeah, I strongly disagree. I think being able to constantly look up all the list functions and their signatures by typing List.
is stupidly helpful
Yeah, we are going to see. I think the argument is similar to that for handwriting your notes instead of typing them. Better memory retention when you have to manually consult the documentation and peruse the options, and being forced to recall the names of signatures. Since this AOC is definitely the most Roc I've written in anger, it'll be a good test (though I'm usually a pretty fast learner of PLs not named Pony).
https://github.com/ghigt/advent-of-code/blob/main/2024/roc/02.roc
My two cents:
────────────────────────────────────────────────────────────────────────────────
── EXPECT FAILED in 02.roc ─────────────────────────────────────────────────────
This expectation failed:
62│ expect part1 fixture == Ok "2"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
• If I have an error on the syntax/types in the file, I loose every type definitions on the entire file which complicates even more the resolution :big_smile:
You can get a nicer error message. What you have to do is writing the expect block in more then one line
If you write:
expect
got = part1 fixture
expect = Ok "2"
got == expect
then you get a message, what the values from got
and expect
are.
I really want to improve this so that the first thing works :sweat_smile:
as in, that it just breaks down the final expression and tells you what all the subexpressions' values are
so you don't have to split it up into names
A bit late but I did it :) https://github.com/RobinCamarasa/Advent-of-code/blob/master/2024/day02/RobinCamarasa/main.roc
Robin Camarasa said:
A bit late
https://github.com/alsm/aoc-roc/blob/master/2024/02.roc
I really enjoyed doing that one in roc
Claude's solution:
claude_part2.roc
All I had to do was feed it the roc test
output of its first version and it fixed the failures by itself:
❯ ../roc test claude_part1.roc
── EXPECT PANICKED in claude_part1.roc ─────────────────────────────────────────
This expectation crashed while running:
41│ expect part1 exampleInput == Ok "The number of safe reports is 2"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The crash reported this message:
Integer subtraction overflowed!
Last updated: Jul 06 2025 at 12:14 UTC