To start with, I'll do the two that stick out the most:
1. iOS limits you to 1 timer at a time. On my android phone "Okay google, set a timer for 10 minutes. Okay google, set a timer for 20 minutes" resulted in two timers. iOS will only let you replace the older one. This still bugs me since it changes how I cook a bit.
(1/2)
Unfortunately, just having a faster foldl has not been enough to make day11 complete.
At this point, my day11 solution uses all my ram (64 gigs) for something like 25 "rounds", and part2 requires 10k rounds. I feel like this really might be the point where I have to start improving the interpreter itself since that memory usage is just ridiculous.
I'm going to try and get it to work without interpreter changes a bit more since I do have some ideas to try still...
That realization has let me write a foldl that has a call stack depth of 2, rather than O(n), which honestly has solved the performance issues for half the days so far
https://github.com/euank/advent-of-nickel-2022/blob/dc003f7c/lib.ncl#L43-L48
My main realization since last time was that function calls appear to have a cost based on their call depth, and that dwarfs basically all else once you hit several hundred calls deep.
Which, given that it's a functional language, even just finding the max of an array is typically a `fold` operation recursive to the depth of the array. There's no TCO or anything to make it efficient.
Though, first, as a random aside it turns out they do not yet have exhaustive tests for their stdlib. As shown by an update making a stdlib function reliably error: https://github.com/tweag/nickel/issues/987
Or oops, there was a methodology error in there.
The first one is 2 minutes and ~4GiB of ram, not 2s. I was accidentally leaving part of it un-evaluated.
Still, a darn sight better than the foldl bit.
Ultimately I ended up with this non-foldl max https://github.com/euank/advent-of-nickel-2022/blob/689b48a0b/lib.ncl#L33-L38 ... that ended up being plenty fast.
Learnings from day 8 for advent of code in nickel:
`array.fold` is slow on larger lists in nickel. Very slow.
Time to process day 8's input into a list of ~10k numbers: 2 seconds & ~250MiB of ram
Time to find the max in that list using `array.foldl num.max 0 list`: oomkilled after 2 hours for using >60GiB of ram
I skipped posting these for a couple days since day 3 and 4 were pretty boring.
Day 5 again makes me afraid i may not complete all of them in nickel. My part 1 code took 60GiB of ram (I've only got 64!)
Either way, when AoC is done, I'll go upstream and drop a note about all the functions that weren't in the stdlib, but felt sorta like they could be https://github.com/euank/advent-of-nickel-2022/blob/e9bf74982/lib.ncl
On the bright side, I found my bug and it gave the correct answer.
However, the ~4GiB RSS and ~4 minutes of spinning a core is uh.. I dunno, seems like a lot for basically adding up 2500 numbers.
Done posting about today's AoC
Well, this time it took 4 minutes and produced 10MB of error output, so I think that means I fixed my bug but have one more. What a slow iteration speed.
It's giving C++ a solid run for its money here. I didn't even have to use templates or metaprogramming or whatever, just passed an int to a function that takes a string
I'll try to actually use some types and contracts for later ones. I haven't written any nickel at all before. This is an excuse to learn nickel. I should try and make myself learn the actually interesting features of nickel
I've been saying I'll do advent of code in nickel this year. We'll see if I actually manage all the days.
Anyway, day1 is a gimme:
https://github.com/euank/advent-of-nickel-2022/blob/a78077f5/day01/default.ncl
Learnings so far:
1. Using the nickel in nixpkgs gave me an 'array.sort' that did not in fact sort arrays. nickel built from master solved that
2. sorting ~240 numbers takes nickel 2s (>100s before updating)... this does not bode well for nickel being able to do the later numerical problems.