Re: Why is this not considered to be in a go block?

Good point Moe, given the pasted code. Actually I made an error when trying to simplify the code for this list. The comp fn should have been: kafka-ch (chan 1 (comp (map sse-data) (filter #(matching-event client-filter (.key %) But my mistake was even

Re: Why is this not considered to be in a go block?

On Sat, Aug 27, 2016 at 12:08 AM, mond wrote: > Is that the same thing or have I made a(nother) / different mistake? > > At a glance, it looks like the functions you're passing into map and filter are shaped wrong - (comp (map sse-data) (filter matching-event-client-filter))

Re: Why is this not considered to be in a go block?

The flood gates are open Timothy! and on the back of that, I'm gonna dump some code in here so pls excuse me - it's on GitHub too so maybe look there if it's too heavy for email. I have this code in the go-loop

Re: Why is this not considered to be in a go block?

I wouldn't expect it to work in a `for` comprehension, because that's combining laziness (which uses function thunks under the hood) with the async state machines. In general, you shouldn't do side-effects in a `for`, though I'd be surprised if you couldn't take at the input. This works (let

Re: Why is this not considered to be in a go block?

Doesn't work in a FOR loop either. Thank god for LOOP! :) -kt On Thursday, August 25, 2016 at 7:21:20 PM UTC-4, hiskennyness wrote: > > I am getting an error about >! not being in a go block with this code: > > (go-loop [state :nl > column 0 > last-ws nil >

Re: Why is this not considered to be in a go block?

I'm not sure I've ever addressed this publicly, so I assume now's as good a time as ever. The reason the go block stops at function boundaries, is that changing a function to be "async" changes it return type. With code transforms like these a function that performs a parking take on a channel no

Re: Why is this not considered to be in a go block?

The analysis for the go macro to determine that the fn never escapes the go block is not something core.async does. Because of that functions are sort of a black box to the transforms the go macro does. http://dev.clojure.org/jira/browse/ASYNC-93 is a declined issue regarding this.

Why is this not considered to be in a go block?

I am getting an error about >! not being in a go block with this code: (go-loop [state :nl column 0 last-ws nil buff ""] (let [line-out (fn [c b] (>! out (apply str b (repeat (- col-width (count b ))