Just curious! After bailing out pretty quickly in the previous years I’ve decided to go with a “quick and dirty gets the job done”-approach and just write whatever hideous JavaScript gets the job done. First time I managed to get to day six, haha 
The ease of iteration in Observable does actually help me a lot here.
This is my first year trying out AoC, and I also thought that Observable would make it easiest for me. So far it’s been quite fun! Here’s my very no-frills notebook (warning: may spam your console / lag your browser!):
I’ve also noticed a bunch of other solution notebooks (including some neat visualizations) on the front page, you can probably find 'em all by searching for “advent”.
Nice!
Yeah, I feel like I have to switch to a new notebook at some point because I’m sure calculating all the puzzle answers together will add up after ten days or so 
Looking at your solutions my imperative roots are really showing, haha :). I’m just brute-forcing everything with for-loops and arrays.
I guess the guy behind these notebooks is not on the forums yet:
(Maybe make them more discoverable? How about a new subforum for specific notebooks that you can generate with one click, to make discussing them more easy?)
I was wondering if anyone has solved 2015:Day1:1. (Day 7 - Advent of Code 2015).
I don’t get the correct answer and I can’t figure out why.
My implementation: Advent of code (Day 7: Some Assembly Required) / David Rio Deiros / Observable
Thank you,
-drd
I did a few 2015 problems in Observable last December too. My (incomplete, totally undocumented) solutions are here. Looks like I got stuck on day 11 and gave up…
I don’t have time right now to try to debug your day 7 solution, but feel free to ask here if anything confuses you!
I did a bunch of 2018 ones during the actual event and am planning on doing it again this year.
Using Observable for them definitely influenced me to go down some non-traditional paths. For example, when my rectangle collision detection code wasn’t working for one, I just drew all the rectangles and my eyeball found the specific rectangle I cared about and I submitted that as my answer. I ended up solving a couple more visually rather than computationally and several that I used visuals and feedback along the way to inform my direction.
I also haven’t gone back to previous years, but might if I have the time. If I start in on 2015, I’ll check in again. 
Thank you for the replies.
I ended up finding the issue (solution here).
I wasn’t computing the value of the gates as signal was available.
I recursively calculate the value of the gates. In the trivial case, I get to a gate that has a signal in the inputs so I can compute the output. As I move up in the recursion tree, I have more signal available for other gates so I keep computing their output values. When I am at the top of the recursion tree, I have the value of all the gates so I can return the output value of any of the wires.
My recursion kung-fu is weak 
.
It would be cool now to visualize the circuit and see how the different gates update their values as signal flows through the circuit 
.
@visnup It was because of your notebooks that I decided to start doing COA. They are pretty cool, thank you.
Let me know when you start working on the challenges for the new year.
Aw, thanks! Just started the ones for 2019!
This looks like a lot of fun. I’ve started 2019 here:
ok, I could not resist … Here is my somewhat quick and dirty collection:
I’ve been doing them in a different language this year, but I couldn’t resist porting my day 3 code to Observable to draw a picture of the wires:
I had planned to try to style the intersections according to the distance / score but didn’t have any compelling ideas before I ran out of juice.
(On a side note, I managed to solve 2015 day 11 so I’ve added a bunch more solutions to my messy 2015 notebooks (already linked above)).
edit: my day 6 input graph illustrated with imports from some d3 tutorials. For some reason the radial tidy tree chart is failing to resolve though…
That’s a good idea. I’ve split mine up into a collection as well:
https://observablehq.com/collection/@jrunning/advent-of-code-2019
Somehow I find myself trying not to use libraries for solutions. I think it is because it would defeat the point of puzzles, eg. thinking. (well, for some the point is probably finding a solution as quickly as possible).
I’m a few days behind, but I’m trying to use WebAssembly to do these:
I was very happy to use a very simple transform from RLUD to h and v path segments to draw them. 
I was much too lazy to draw the intersections.
I’ve been trying to come up with ways to better visualize the intcode computer running too. Would be pretty fun and informative/helpful to be able to see it do its work, especially when I went a little crazy using async generators to implement the amplifier feedback loop. I’m both proud and appalled by that async generator code.
Those notebooks are really cool, thanks for sharing!
My first solution to day 7 (in Python) cached the array and pointer location and then restarted the programs using that state when necessary. I figured there was a better way using generators, and one mindblowing thing I learned in my second refactoring / golfing pass is that you can actually send values back to generators (in both Python and JS) with something like this inside the generator (JS syntax here):
const nextInput = yield output;
and something like this where the generator is consumed:
const output = generator.next(nextInput);
(Perhaps this is common knowledge, but I was very impressed.)
Thanks also for pointing out your visualization of intcode computation! Have you thought much about visualizing the feedback loop of intcode computers of day 7? That sort of thing has been at the back of my mind since I started playing around with my “notebook stepper”. In particular there ought to be nicer ways of displaying and interacting with the state / history of the embedded Observable runtime there (but probably the current interface needs a complete rewrite first 
).
I had no idea. now I need to see if I can use that feature for something.