Fork me on GitHub
#core-async
<
2019-08-01
>
rgm04:08:05

Newb question: I’m trying to prn a value from within a go block in the JVM, just to make sure things are wired up right. Is it ordinary behaviour for no output to happen? I can confirm that the <! in the go block is working by conjing the value onto a vector in an atom and dereffing.

rgm04:08:57

I’m using vim/nrepl/fireplace so I’m wondering if the output is just getting swallowed in that chain someplace.

hiredman05:08:57

In general prn in a go block works like prn in a future

hiredman05:08:13

So if prns in a future get swallowed in your tool chain of choice (ouch, that is rough) then that will often happen with go blocks

rgm10:08:16

Cool, thanks. That might give me a shorter repro for sorting out what’s going on.

Alex Miller (Clojure team)12:08:36

Is that actually right @hiredman ? prn will print to *out*. Futures do binding conveyance but do go blocks? I don’t know off the top of my head

Alex Miller (Clojure team)12:08:29

If not, then printing would go to stdout instead of whatever you rebound to

hiredman15:08:39

Go blocks do binding conveyance, they capture the binding frames in the array and restore them

hiredman15:08:52

The thing I don't recall is if go blocks will run on the current thread up until the first channel operation, which would behave differently from futures

ghadi15:08:31

(what go blocks don't support is changing binding in the middle of execution)

rgm15:08:50

I think I have a fundamental misunderstanding here and would appreciate some help … even from clj this code doesn’t print anything https://gist.github.com/rgm/dff54483f0705918191f48d461b33687

rgm15:08:23

using clean deps with only clojure and core async.

rgm15:08:29

(this is that vim business earlier, except I think I’ve messed up somewhere and it can’t be the vim/fireplace pipeline).

ghadi16:08:36

@rgm looks fine -- it's probably the printing with nREPL

ghadi16:08:10

try sending a value to a "logging" channel that you can view

ghadi16:08:31

or if you're using REBL, you can tap> and the tapped values will show up in REBL

ghadi16:08:52

(nREPL might not capture prints that happen in a background thread)

rgm16:08:10

oh, you’re right … I think it is nrepl… I forgot that my ~/.deps had that included by default.

rgm16:08:18

:face_palm:

ghadi16:08:36

btw, in general printing or other I/O in a go block is a no-no

mkvlr11:08:12

@ghadi is it your recommendation to follow this strictly? So no logging at all in the context of a go-block?

ghadi16:08:46

not explicitly forbidden, but can lead to deadlocks

rgm16:08:09

understood.

rgm16:08:35

@ghadi @hiredman @alexmiller thanks for helping … yep, the prn is getting swallowed by nrepl. Guess I’ll try that same code with prepl out of curiosity (notwithstanding the general idea of don’t-do-IO-in-go-blocks).

mkvlr11:08:12

@ghadi is it your recommendation to follow this strictly? So no logging at all in the context of a go-block?