Clojurians Log v2
adventofcode
Good morning 🙂
“Oh oh oh” (to read with the voice of Santa Claus) … it seems that the channel is more quiet than usual 😉
might because it’s Monday 😁
This one seems quite a bit harder… 😉
@imre has joined the channel
Today's was definitely harder than the last few days, but not too hard yet. I quite like them like this. A bit challenging but still solvable in under an hour.
Under an hour you say? 😛
I’m lucky I still have time for breakfast
I am going to add Specter and Instaparse to my deps.edn
Instaparse has a good API for parsing and shaping the result data.
I’m going to stack with vanilla Clojure for this AoC
I just woke up, looked at it, it's not a 9am problem.
yeah I'm also generally sticking to vanilla clojure, unless I really end up re-implementing a common library
and solution: https://github.com/lambdaisland/aoc_2020/blob/main/src/lambdaisland/aoc_2020/puzzle07.clj I also talk a bit more about yesterday's puzzle, and answer some questions people asked in the comments.
maybe I missed it, have you mentioned that using io/reader without with-open macro is not a good practice?
Oh that's a good point, I'll mention it tomorrow
curious to what’s wrong? :_
have to stay tuned I guess
find out tomorrow in a new episode
I think its because if you call io/reader without with-open (or explicitly try / catch yourself), then you can be left with an open reader in the case of an exception? But I'm guessing here. If thereis an exception I think with-open calls close on its binding
@andrea.crotti has joined the channel
@pedronsousa has joined the channel
Day 7 using graph library
https://github.com/tschady/advent-of-code/blob/master/src/aoc/2020/d07.clj
and viz for fun:
@gerome.bochmann has joined the channel
Somehow I managed a stack overflow using loop/`recur` 🤷♂️
(count (bag-children "shiny gold" sample-bags))
=> 32
(count (bag-children "shiny gold" bags))
Execution error (StackOverflowError) at (REPL:1).Can anyone help me figure out my stack overflow issue? I realize my code/approach is far from optimal… all the same it bugs me I can’t reason about why this is failing the way it is https://gist.github.com/KennyMonster/4e965505f0a8b592a91dd25b5306023f
you have a recursive call inside a recur form, that’s atypical
i don’t think he does.. he shadowed bag children in the loop binding
oops, missed. I guess that’s a reason to avoid that.
(defn bag-children [color bags]
(let [bags-lookup (into {} (map #(vector (:color %) %) bags))]
(loop [colors-to-walk [color]
bag-children []]
(if (seq colors-to-walk)
(let [contained-bags (mapcat contained-bag-colors-as-seq (:contain (bags-lookup (first colors-to-walk))))]
(recur (into (subvec colors-to-walk 1) contained-bags)
(into bag-children contained-bags)))
bag-children))))
yikes formatting
Nope
I edited his gist since I can’t format in slack apparently
it’s concat
cool, thanks for link
Thanks for taking a look!
I had no idea about concat… I had just assumed it was lazy
or that even if it was eager, it would just utilize too much memory vs a stack overflow
it is lazy, which is why you're getting the stack overflow. consider this
(def x (reduce concat (map #(list %) (range 100000))))
(first x)def will work fine, but as soon as you try to realize the first element it throws. At that point it tries to realize the outer concat, which first needs to realize the concat inside of it, and so forth until it bottoms out. Realizing a lazy-seq concumes a stack frame. It's really just a wrapper around an IFn which implements the Seq interface.I'll talk about this on the stream today, it's one of those surprising clojure gotchas.
I would think my part 2 solution would just take a ton of time/memory
@shawnbrownfield has joined the channel