Whoah, pretty much all the solutions to Dec6/pt1 saw that you could just add all of the distances from each node to the root. I didn't see that so I added each node's orbiter count multiplied by the depth of the node—about an order of magnitude less efficient, but still works:

(defn count-orbits
  ([orbits] (count-orbits orbits 1 :o-COM))
  ([orbits depth node]
   (let [orbiters (get-orbiters-of node orbits)]  ;; (:o-A :o-X)
     (if (seq orbiters)
       (+ (* depth (count orbiters))
          (->> orbiters
               (map (fn [orbiter] (count-orbits orbits (inc depth) orbiter)))
               (reduce +)))
       0))))

Part 2 is a doozy and I love it.

I have no idea how I'm gonna visualize this, though, hahahah

Seriously, though, twists like this are what make me love these challenges. And I'm glad he's steadily building on the same machine this year.

I have real trouble understanding how part 2 is supposed to work… 😢

Can anyone explain part2 without spoilers?

> And I'm glad he's steadily building on the same machine this year. Yes but... I had a bug apparently in my previous code (of the "why did this work before" variety) so that took me a while to debug.

ugh. today's part 2 is going to eat my whole weekend

+1

My part 2 is working for examples but doesnt halt with puzzle input :/

finally finished part 2. solution is horrible though

Note to self: don't try to print infinite lazy seqs

Seemed it wasn't halting actually was trying to print a lazy seq

I can't tell you the number of times I've had to kill cider because I did that in AoC.

Haskell does that better

I did run a bit into nested data structure confusion this round. Curious to see how others did it.

I always make sure to set https://clojuredocs.org/clojure.core/*print-length* and https://clojuredocs.org/clojure.core/*print-level* if I’m printing off large/lazy structures

And TIL

Solution using core.async: https://github.com/transducer/adventofcode/blob/master/src/adventofcode/2019/day7.clj

Interesting @erwinrooijakkers, though it feels core.async is not an exact fit for the problem, as asynchronous operations is not necessary to solve it

Python generators (or ES6 generators in JS) are a better fit - do these have an implementation in Clojure?

Just exhausting all input and continue running tje next amp works also but that is basically a manual yield

Ugh, got part 1 pretty quickly, but for part 2 I had to refactor a large part of the intcode machine. I used core.async too. Will share later.

Hallo Clojurians - for Day 7, I am trying to figure out how can I feed input to the amplifiers. Context, my Intcode interpreter uses (read-line) for opcode 3 which reads from IN (ps: please read this as "star in star", Slack turns it into bold!). I've been exploring binding IN to a Reader that will successively return phase and input on each call to read-line. The default impl. of IN is a LineNumberingPushbackReader that wraps System/in. I want to make my own LineNumberingPushbackReader that closes over phase and input and returns them on succesive calls to read-line. My Clojure is a bit rusty, so I'm not exactly sure about the best way to proceed. Any tips?

Like this?

(with-in-str "line1\nline2"
  [(read-line) (read-line)])
; => ["line1", "line2"]

In the end I am pretty happy with my solution. I always am if I can use the same code for part 1 and 2 (I realize that my code is rather a beginner level… but in the end I get it somehow done 😆). Thanks to @fellshard for the explanation so I could finally understand what was going on! 🙏 <https://github.com/MeikeMertsch/AoC_2019/blob/master/src/christmas/day07.clj>

https://gitlab.com/dmarjenburgh/adventofcode/blob/master/src/adventofcode/year_2019.clj#L144-181

I am still really struggling with day5

I keep running up against this instruction: ("101" "-80" "224" "224")

this seems to be saying "read position -80" which doesn't make sense

I've completely rewritten my code a couple times now. my intcode computer passes day2 and and all test cases I've found so far

all of my diagnostic codes come back 0

Doesn't "101" mean read 1st parameter in immediate mode, so -80 should be interpreted as a value?

AFAICT "101" would be padded to "00101"?

oh foo

> read right-to-left from the opcode

@lilactown I struggled with something similar, and then found a line in the instructions "Parameters that an instruction writes to will never be in immediate mode." - this line seems contradictory to me, but that was the problem with my code!

https://github.com/potetm/advent-of-code/blob/b9b3758ef83dcea200eb93b62e3cbeb7efb4a3b1/src/advent_2019/day_7.clj

yeah I misread the problem, I was reading the modes left-to-right 😵

very frustrating