Fork me on GitHub
#core-async
<
2020-04-02
>
yonatanel16:04:17

Can anyone explain what would be the advantage of using take! recursively over a go-loop? Example:

;; avoid using go-loops with aot here
(take! err-ch (fn loop-fn [e]
                (error-fn e)
                (take! err-ch loop-fn)))
The comment on avoiding go-loops with aot is in the original source. Copied from https://github.com/replikativ/superv.async/blob/c9ec3ed4611e84889eb10eab5da753559f7a4703/src/superv/async.cljc#L87

noisesmith16:04:28

take! has a callback as its second arg

noisesmith16:04:33

the callback invokes it again

noisesmith16:04:50

so it's a sort of trampoline - every time the take succeeds, it invokes a new take

noisesmith17:04:44

the advantage is that go blocks compile by doing a transform on their body, I wouldn't be surprised if that interacts poorly with aot with certain core.async versions

noisesmith17:04:06

I don't know of the specific bug (and my alternative would be just never doing aot...)

kenny17:04:41

I'd like to do a pipe and apply a transducer to the values taken from from before putting them to to. pipeline seems to do exactly this. However, I've usually thought of the pipeline* functions in core.async as utilities for doing things in parallel. Is it typical to use pipeline with a parallelism of 1 for this sort of task?

rgm22:04:25

Is there a good reference for how to reliably log to a repl window from a go-loop? I’m using timbre from a mount-managed go-loop and I almost certainly don’t have it hooked up right. I’ve resorted to resetting an atom from within the loop and have an add-watch set up outside the loop.

rgm22:04:24

(the more general teach-me-to-fish-ish question: understanding what exactly is going on with stdout, etc. and the various places it might hide).

noisesmith22:04:54

on the java level, stdout is attached by default to System/out

noisesmith22:04:14

in clojure, the dynamic var *out* is derived by default from Sytem/out

noisesmith22:04:49

but the value of *out* can be modifed, via dynamic binding or just plan redefinition / resetting

noisesmith23:04:22

many loggers intentionally don't use out- try askin our logger to print to *out* instead of its current method?

noisesmith23:04:40

but on the other hand, it might be more elegant to have a go loop that reads a channel and logs every entry it consumes (instead of the logger library handling this ordering via queue for you)

rgm23:04:20

oh, thanks. Ok. I’ll try passing *out*. I’m still learning what’s what with core.async and I’m finding it challenging when I can’t see things happen in a log stream.

rgm23:04:13

Is this the kind of thing I should be doing with (tap> ,,,)?

noisesmith23:04:10

I haven't played with tap - but it would be one way to do this(?)

rgm23:04:13

Ok, I’ll see if that helps too. Now to log *out* and see what it is in various places with wild abandon.

seancorfield23:04:38

@rgm If you're doing this for debugging purposes, I'd reach for tap> first. Then either use Cognitect's REBL or use a second REPL connected into the first one and add a tap listener that just println's the tapped data.

seancorfield23:04:17

(I've used that second approach quite often to get a simple console logging stream running outside my main REPL/editor setup)

rgm23:04:14

by second repl do you mean in an editor, or say connecting a second nrepl via lein connect? (I’m in a lein project)

seancorfield23:04:04

The latter. Just from another terminal window so you can add-tap to get println output in that second REPL.

seancorfield23:04:51

(that way the tap values are printed just to the stdout of that second REPL)

seancorfield23:04:42

Hmm, I just tried that and it doesn't actually work the way I expected with Leiningen... I'm used to doing it with a Socket REPL and it works there. I wonder what Leiningen is doing differently with stdout?

rgm23:04:11

yeah, between lein and fireplace (vim user) it’s not really clear to me where it’s all being swallowed

seancorfield23:04:13

(I haven't used Leiningen for anything for years at this point)

rgm23:04:19

that second repl’s a neat trick though, thanks.

rgm23:04:59

is the idea that tap> calls can just stay in place and they don’t matter if no taps are attached?

seancorfield23:04:56

Yup. They'll just tap into the void if nothing is listening. They have a dropping channel buffer behind them I believe. Maybe 1024 entries?