Fork me on GitHub
#core-async
<
2022-06-30
>
souenzzo19:06:38

I'm having a wired behavior in core.async:

(...
  (let [send-ch (async/chan)]
    (async/thread
      (log/info :send-ch send-ch)
      (if-let [out-msg (and (some-> send-ch
                              async/<!!))]
        ...
        (recur)))))
;=> [async-thread-macro-1] INFO - {:send-ch #object[clojure.core.async.impl.channels.ManyToManyChannel ...], :line 73}
;=> [async-thread-macro-1] INFO - {:send-ch nil, :line 73}
Initially, send-ch has a value: the async/chan instance But after a loop/recur, send-ch tunrs into nil I didn't even know this was possible in clojure.

souenzzo19:06:37

org.clojure/core.async {:mvn/version "1.5.648"} I can't reproduce it in a simple scenario 😞

jjttjj19:06:35

Are you using let where you mean to use loop? There's no loop in your code

souenzzo19:06:11

recur goes back to async/thread

souenzzo19:06:20

hummm I will try to add a explicit loop

souenzzo19:06:56

Explicit loop works!

jjttjj19:06:26

> recur goes back to async/thread I don't think that's true

-------------------------
recur
  (recur exprs*)
Special Form
  Evaluates the exprs in order, then, in parallel, rebinds
  the bindings of the recursion point to the values of the exprs.
  Execution then jumps back to the recursion point, a loop or fn method.

  Please see 

souenzzo19:06:29

seems that we can't recur to funcions defined with ^:once (async/thread creates a ^:once function)

jjttjj19:06:42

ohhh i see sorry

jjttjj19:06:57

yeah it's a macro that makes a fn, got it now

souenzzo19:06:33

OK. edge behavior, but would be nice to have a warn or something like that

phronmophobic19:06:09

I think relying on a macro you didn't write to wrap your code in a function is probably relying too much on implementation details

lilactown20:06:45

tbh i would have been surprised if that code had worked. i'd be like, "wtf where is this recurring to"