I'm reasonably happy with my solution, took me a w...

# advent-of-code

[Joris PZ]

I'm reasonably happy with my solution, took me a while to figure out why my letters were upside down. In my coordinate system positive Y is upwards, which is the reverse of what the IntCode computer uses. Also, I need to find a more elegant way than closing stdout to signal end of execution, the try-catch is an eyesore.

Code is https://github.com/jorispz/aoc-2019/blob/master/src/commonMain/kotlin/day11/p11.kt

[marstran]

I used channel.receiveOrNull() ?: return , which at least avoids the exception.

[todd.ginsberg]

I used the equivalent of while(!stdout.isClosedForReceive).

[Joris PZ]

Ah, receiveOrNull seems to be what I need, thanks! I used while(!isClosedForReceive) before but that doesn't help in the case when my listener is suspended on a receive() call when the computer closes the Channel.

[Kroppeb]

I use my computer halted field in my while loop. I have no idea why it works as my input channel has unlimited size.
Does the thread always switch coroutine if there is a coroutine waiting for an element to appear in a channel?
I should probably make a more robust system anyway.

[Joris PZ]

A coroutine suspends when you call receive on a Channel with an empty buffer (or no buffer at all), and it won't continue until some other process calls send . Likewise, calling send on a Channel whose buffer is either full or absent suspends the calling coroutine until some other coroutine calls receive . In that sense, Channels are as much a synchronization primitive as they are a messaging solution.

[todd.ginsberg]

Yeah, true. I guess I relied on the fact that my computer closes its output channel when it is halted. So for the last pair of reads, I can grab them, even if the computer is done. I'm liking this coroutine stuff, learning a lot from it!

[Kroppeb]

Oh, when I call receive, the IntComputer keeps the thread until it either halts or asks for input. For safety I added a yield() in my isHalted().