Fork me on GitHub
#shadow-cljs
<
2019-07-27
>
jaccarmac10:07:40

Hey there, been fiddling with a toy project to learn Shadow and core.async, and I'm somewhat confused by behavior. It's possibly just me not understanding how core.async works.

jaccarmac10:07:35

I'm using a third party JS library in a Node script, and outputting to a Node script. When I use that lib API with callbacks, everything works fine, but when I sub in core.async stuff things still work but Node hangs rather than exiting when the callback completes

jaccarmac10:07:48

The core.async example with doseq also hangs.

jaccarmac10:07:24

Is that just inherent to the way that core.async works when outputting to a script rather than the browser, or am I misusing core.async in some other way?

thheller10:07:42

probably misusing it in some way

thheller10:07:56

core.async works the same in node or browser

jaccarmac10:07:23

I see, esp. when checking the examples I was referring to again.

thheller10:07:36

the only difference in node vs the browser is the "exit" condition of the process

jaccarmac10:07:04

Is there an idiomatic way to exit after the core.async "callback" is done?

thheller10:07:04

since the browser never exits you just might be waiting for something else that keeps the node process alive

thheller10:07:19

depends on how you define done

jaccarmac10:07:24

Or should I just be manually calling into Node exit things?

thheller10:07:45

for example when using a :node-script build with watch the websocket connection used for the watch itself will keep the process alive

thheller10:07:07

so you might want to disable the devtools via :devtools {:enabled false}

thheller10:07:34

shouldn't need to force exit the node process by calling it manually otherwise

jaccarmac10:07:43

Well, I have code examples if you're up for a super-quick look. http://chiselapp.com/user/jaccarmac/repository/junkcode/artifact/932673eaa4187131: Callback-enabled, exits after printing. http://chiselapp.com/user/jaccarmac/repository/junkcode/artifact/31587b684a610646: core.async, doesn't exit after printing.

jaccarmac10:07:51

I'm using watch but only for the compilation part (or so I thought), running the output script manually each time.

thheller10:07:30

well first of all the if looks broken

thheller10:07:39

#(do (if %1
                       (js/console.log %1)
                       (put! data-chan %2))
                     (close! data-chan)))

thheller10:07:52

(if <pred> <then> <else>)

thheller10:07:01

so if true you just log but never put?

jaccarmac10:07:45

(that's not the way things are going to be permanently, was only worried about the happy path)

jaccarmac10:07:05

In the failure case I'm pulling a nil out of the channel at the end thanks to the close, though.

thheller10:07:44

and how are you running this?

jaccarmac10:07:20

node extract.js

thheller10:07:47

with shadow-cljs watch or not?

jaccarmac10:07:59

Yep with watch

thheller10:07:04

do you have devtools disabled?

jaccarmac10:07:07

I hadn't realized that kept a REPL connect open

jaccarmac10:07:24

Whoops 馃槵

thheller10:07:26

dunno why it wouldn't be kept alive with the callback example though

thheller10:07:34

the behavior there should be the same

jaccarmac10:07:42

Looking back I only started using watchafter I added async things

jaccarmac10:07:54

So it was changing two variables when I thought I was only changing one.

thheller10:07:10

for CLI type scripts I recommend just disabling the devtools

jaccarmac10:07:13

Skimmed the docs and mistakenly believed that hot code reloading was only happening if I explicitly setup hooks.

thheller10:07:33

just use shadow-cljs node-repl if you want an actual REPL

anmonteiro17:07:33

Is there a way to have Shadow treat warnings as errors?

anmonteiro17:07:57

if I were dealing with CLJS directly I鈥檇 call cljs.analyzer/with-warning-handlers but that seems to have no effect in shadow

thheller19:07:32

@anmonteiro there is not but happy to add a flag or something

anmonteiro19:07:51

@thheller would love that. we鈥檇 like to treat most warnings as errors

thheller19:07:07

so in CLJS there is currently {:warnings true|false|{<warning-type true/false}}

thheller19:07:25

I could either add {:warnings :error} to treat all warnings as errors

thheller19:07:48

{:warnings {:undeclared-var :error}} to pick specific things that should be errors

thheller19:07:20

or add a "new" key for something like :warnings-as-errors true/false or :warnings-as-errors #{:only :these}

thheller19:07:26

the :warnings-handlers approach seems a bit icky to me and not really user friendly

anmonteiro20:07:23

@thheller I like a hybrid of some of those

anmonteiro20:07:36

{:warnings {:undeclared-var :error}}

anmonteiro20:07:05

wait that doesn鈥檛 allow for the other one

thheller20:07:22

I think I prefer the :warnings-as-errors true for all and with a set for more control

anmonteiro20:07:24

> I could either add {:warnings :error} to treat all warnings as errors > {:warnings {:undeclared-var :error}} to pick specific things that should be errors

anmonteiro20:07:29

actually these two are not mutually exclusive

thheller20:07:33

touching :warnings might cause troubles later on the compile