This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-03-10
Channels
- # aleph (1)
- # aws-lambda (1)
- # beginners (80)
- # boot (20)
- # cider (75)
- # cljs-dev (45)
- # cljsjs (1)
- # cljsrn (11)
- # clojure (428)
- # clojure-dusseldorf (13)
- # clojure-italy (4)
- # clojure-russia (153)
- # clojure-spec (47)
- # clojure-taiwan (1)
- # clojure-uk (62)
- # clojurescript (84)
- # cursive (19)
- # datascript (96)
- # datomic (75)
- # dirac (9)
- # docs (3)
- # emacs (19)
- # jobs (5)
- # jobs-discuss (20)
- # jobs-rus (17)
- # lein-figwheel (5)
- # leiningen (1)
- # liberator (4)
- # luminus (12)
- # off-topic (4)
- # om (31)
- # onyx (102)
- # pamela (1)
- # parinfer (3)
- # pedestal (3)
- # proton (1)
- # protorepl (14)
- # re-frame (54)
- # reagent (22)
- # rum (40)
- # spacemacs (2)
- # specter (8)
- # test-check (5)
- # unrepl (110)
- # untangled (80)
- # vim (3)
- # yada (46)
@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.
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)
in CLJ it will block when writing to *out*
... so your thread will block ... not exactly better but different
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
giving you access to info
error
warn
etc .. just like the browser which doesn't have *err*
in the first place
great .. now everything I said is incorrect. nothing actually uses process.stdout
or stderr
directly
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
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?
@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
@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