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.

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

The core.async example with doseq also hangs.

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?

probably misusing it in some way

core.async works the same in node or browser

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

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

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

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

depends on how you define done

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

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

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

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

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.

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

well first of all the if looks broken

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

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

so if true you just log but never put?

Correct

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

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

and how are you running this?

node extract.js

with shadow-cljs watch or not?

Yep with watch

do you have devtools disabled?

I hadn't realized that kept a REPL connect open

Whoops 😬

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

the behavior there should be the same

Looking back I only started using watchafter I added async things

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

for CLI type scripts I recommend just disabling the devtools

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

Duly noted.

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

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

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

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

@thheller would love that. we’d like to treat most warnings as errors

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

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

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

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

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

@thheller I like a hybrid of some of those

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

hrm

wait that doesn’t allow for the other one

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

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

actually these two are not mutually exclusive

touching :warnings might cause troubles later on the compile