@thheller looks like these are equivalent (allows printing to stderr in Node)

;; clojure
(binding [*out* *err*] (println “foo”))

;; clojurescript
(binding [*print-fn* *print-err-fn*] (println “foo”))

@shaunlebron yes, that sort of works. however node streams: https://nodejs.org/api/stream.html#stream_writable_write_chunk_encoding_callback

> Returns: <Boolean> false if the stream wishes for the calling code to wait for the 'drain' event to be emitted before continuing to write additional data; otherwise true.

so in theory you could write faster than a stream is able to consume the data

overflowing its buffers. you can totally ignore this and it will most likely work ... until it doesn't.

I think you can easily force the bad behaviour if you launch a node process but don't consume stdout (eg. via ProcessBuilder in java)

this way it can reach the point where the buffers are full quite quickly

what then happens I do not know

in CLJ it will block when writing to *out* ... so your thread will block ... not exactly better but different

which is what I meant above

even *print-fn* does not address this issue

which is why async IO is so painful to work with sometimes 🙂

also there is no way to know a print succeeded without the callback

in java you get an IOException if anything goes wrong

also cljs.nodejs/enable-util-print! uses util.print which has been deprecated for a while now: https://nodejs.org/api/util.html#util_util_print_strings

no idea when they'll remove that but console.* is now the official way to print

giving you access to info error warn etc .. just like the browser which doesn't have *err* in the first place

oh wait nevermind ... enable-util-print! already uses console. I said nothing 😛

great .. now everything I said is incorrect. nothing actually uses process.stdout or stderr directly

so ignore all that .. you are probably good with *print-fn*

interesting .. FWIW I think you are far better off always using js/console... directly

@shaunlebron probably not going to do anything special for Node here

@thheller thanks for the in-depth, didn’t know this.

looks like process.stdout is only sometimes synchronous, and console.log seems to use it so it’s behavior will be same

i’ll make sure the general idea here is documented though, thanks again

@shaunlebron I got curious and checked what it does .. it actually just flat out ignores errors

it will print one error to stderr and then noop all errors 😛

at least that is how I interpreted https://github.com/nodejs/node/blob/master/lib/console.js

@anmonteiro is your patch ready to review, the npm modules one?

@dnolen it is

@anmonteiro cool, will take a look later today then

Doesnt't implement deps.cljs behavior yet, I think it makes sense to implement it in a separate patch

Awesome

@anmonteiro merged the patches

that’s so cool

@dnolen I’ve got some other outstanding tickets if you wanna have a look at some more

actually they’re very minor things

CLJS-1956, CLJS-1957 and CLJS-1964

ok will take a look

@shaun-mahood merged the Windows patch

@dnolen: I think CLJS-1448 is a duplicate of CLJS-1868 as well - just added comment to Jira but current code looks different than in that issue, so may be unnecessary for other reasons too

@dnolen: Awesome, thanks!

@anmonteiro 1956 did you actually run into a problem with those reserved keywords?

@dnolen I didn’t but I suspect we will eventually

but if you don’t want the await keyword yet, we should at least be consistent between cljs.analyzer and cljs.core for self-hosted