Clojurians
#cljs-dev
<
2017-03-10
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

shaunlebron08:03:25

@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”))

thheller08:03:03

> 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.

thheller08:03:19

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

thheller08:03:32

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

thheller08:03:06

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)

thheller08:03:20

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

thheller08:03:26

what then happens I do not know

thheller08:03:53

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

thheller08:03:07

which is what I meant above

thheller08:03:47

even *print-fn* does not address this issue

thheller08:03:26

which is why async IO is so painful to work with sometimes :slightly_smiling_face:

thheller08:03:56

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

thheller08:03:06

in java you get an IOException if anything goes wrong

thheller08:03:30

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

thheller08:03:55

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

thheller08:03:59

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

thheller08:03:48

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

thheller08:03:16

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

thheller08:03:03

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

thheller09:03:45

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

dnolen13:03:12

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

shaunlebron16:03:57

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

shaunlebron16:03:51

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

shaunlebron16:03:42

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

thheller16:03:21

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

thheller16:03:40

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

dnolen16:03:28

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

anmonteiro16:03:47

@dnolen it is

dnolen16:03:58

@anmonteiro cool, will take a look later today then

anmonteiro16:03:33

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

dnolen19:03:17

@anmonteiro merged the patches

anmonteiro19:03:26

that’s so cool

anmonteiro19:03:47

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

anmonteiro19:03:20

actually they’re very minor things

anmonteiro19:03:35

CLJS-1956, CLJS-1957 and CLJS-1964

dnolen19:03:36

ok will take a look

dnolen19:03:40

@shaun-mahood merged the Windows patch

shaun-mahood19:03:52

@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

shaun-mahood19:03:01

@dnolen: Awesome, thanks!

dnolen19:03:20

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

anmonteiro19:03:09

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

anmonteiro19:03:44

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