This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-10
Channels
- # aleph (4)
- # aws (2)
- # bangalore-clj (2)
- # beginners (84)
- # boot (25)
- # cider (3)
- # cljsrn (3)
- # clojure (57)
- # clojure-italy (5)
- # clojure-losangeles (3)
- # clojure-russia (7)
- # clojure-spec (18)
- # clojure-uk (29)
- # clojurescript (90)
- # cursive (11)
- # data-science (68)
- # datascript (2)
- # datomic (25)
- # duct (3)
- # fulcro (13)
- # graphql (7)
- # immutant (1)
- # jobs (1)
- # leiningen (12)
- # lumo (1)
- # off-topic (51)
- # om (43)
- # onyx (15)
- # parinfer (10)
- # pedestal (4)
- # re-frame (7)
- # reagent (42)
- # ring-swagger (42)
- # rum (1)
- # shadow-cljs (172)
- # spacemacs (10)
- # specter (4)
- # sql (4)
- # test-check (19)
- # unrepl (54)
- # yada (3)
I’m attempting to read a line from stdin for NodeJS. The JS code would be something like:
var readline = require('readline');
process.stdin.setEncoding('utf8');
var rl = readline.createInterface({
input: process.stdin,
terminal: false
});
rl.on('line', readLine);
function readLine (line) {.....}
Whats the approach for reading a line in cljs? Any best practice for reading stdin using nodeJS and clojurescript?
I translated that to this with no luck:
(def readline (js/require "readline")) ;;require nodejs lib
(def process (js/require "process"))
(.setEncoding process.stdin "utf8")
(def rl (.createInterface readline {
:input process.stdin
:terminal false}))
(.on rl "line" readline)
What does this mean: > Backing this one out, goog.string.format defies advanced optimization https://dev.clojure.org/jira/browse/CLJS-324
We use gstring/format
with advanced compilation and it works, but maybe I’m missing something
@rauh Thanks i’ve made the update. I am still working to get the code to work with nodeJS as a single js file:
(ns hello-world.core
(:require [clojure.string :as string] [cljs.nodejs :as nodejs]))
(nodejs/enable-util-print!)
(defn -main [& args]
(let [readline (js/require "readline")
rl (.createInterface readline js/process.stdin js/process.stdout)]
(.on rl "line"
(fn [line]
(def lineVector (clojure.string/split line #" "))
(if (and (< (get lineVector 0) 10)
(< (get lineVector 1) 10))
(+ (get lineVector 0) (get lineVector 0)))))))
(set! *main-cli-fn* -main)
you should turn (def lineVector (clojure.string/split line #" ")
into a let
. def
should only be used at the top-level, never nested like this.
@thheller Thanks, for simplicity sake i’ve removed all of that and replaced it with (fn [line](println line))
I believe the issue is that one of the functions is not getting loaded. I’ll do a closer analysis.
TypeError: a.Zb is not a function
at Function.$d.w (.../main.js:209:47)
@tkolleh thats an :externs
issue, closure renamed the function name. see https://code.thheller.com/blog/shadow-cljs/2017/10/15/externs-the-bane-of-every-release-build.html
@thheller 😀 wow you are too cool for school 😎 that was it I changed to :optimizations :simple
and was able to input stdin.
i'm wondering if i have it incorrectly setup, it takes like a couple of minutes to compile like a hello world thing. I don't remember it being like that before
don’t know much about figwheel but maybe setting :verbose true
and :compiler-stats true
will provide some insight?
actually it looks like it's figwheel:
[risto@miniarch src]$ time lein cljsbuild once backend-dev
Compiling ClojureScript...
real 0m12.402s
user 0m15.432s
sys 0m0.521s
i dont remember it taking anywhere near that long before though, maybe like 20 seconds or something for the jvm
@borkdude My guess is that using goog.string.format
in the standard library is not amenable to DCE. Everybody's final artifact grows by about 1200 bytes uncompressed, 480 bytes compressed, regardless of whether you make use of the capability.
@mfikes Thanks. So it makes sense to switch to https://github.com/funcool/cuerdas for this?
@borkdude I suppose that’s up to you. If you actually make use of goog.string.format
, in your code, then perhaps 480 bytes is worth it. (I don’t know how many bytes would be added if you just used cuerdas.core/format
) Checking…
@borkdude Adding cuerdas as a dep and simply making a call to cuerdas.core/format
adds 47 KB unzipped and 19 KB zipped. Perhaps there is some stuff in that library that is not amenable to DCE.
I agree, that can't be explained by the small amount of code involved in cuerdas.core/format
.
Checking again, but by pasting only cuerdas.core/format
code directly in the mix. (I think it might be because it pulls in edn/read-string
.)
@borkdude By manually pasting in cuerdas.core/format
and all of the functions it depends on, things grow by only 723 bytes uncompressed, 359 bytes compressed. But, by then simply adding [cuerdas.core]
to my :require
vector (without actually using any functionality in it) causes it to explode back out by 47 KB / 19 KB. So there is something in the cuerdas library that is not amenable to DCE.
@borkdude I think I've isolated it to this being pulled in, regardless of whether you want it https://github.com/funcool/cuerdas/blob/master/assets/xregexp/xregexp.js
@mfikes I added your comments to this thread. If you don’t want it there, I can remove it: https://www.reddit.com/r/Clojure/comments/7bo9ro/funcoolcuerdas_the_missing_clojurescript_string/dpmdoei/
Cuerdas adds this foreign-lib: https://github.com/funcool/cuerdas/blob/master/assets/xregexp/xregexp.min.js
Yeah, it is unfortunate that there is no good way to only pull in that foreign lib for the 4 or 5 functions that use it. 😞
Yes, new npm stuff could do it, but only if no lib in app uses foreign libs
hmm, I guess it’s not so nice to force transitive npm deps onto your users as a library
It is, deps.cljs
in a library can define :npm-deps
and if app uses :install-deps true
, those get installed automatically
Though not sure if that is very good idea
If I maintained cuerdas, I'd be motivated to take that foreign lib and somehow make it compatible with Closure or re-write it in ClojureScript.
In mobile, the main concern (IMHO), is launch latency. And :advanced
is good for that. For example an app might take 2 seconds to launch with :advanced
instead of 3 with :simple
on an old device. Library size drives how fast things can be parsed upon launch, so a lot of the same concerns crop up, but to a much lesser import, I suppose.
Speaking of DCE, how does clojure.test.check do? I need a seedable RNG in my clojurescript
Aren't the entire React and ClojureScript deps up around 30 KB each. (Just thinking about how big 19 KB is relative to other things.)
@mfikes Yes, but React is not something I would do without, funcool/cuerdas is totally optional
@borkdude My initial reaction to you clojure.test.check
is to try it and see if DCE works. For example Om had an unintentional bloat, for which there is a ticket. The best way to find out is to try 🙂
is that a lot?
it has to use goog.math.Long
also if 14kb is bad, you might try it again with master -- somebody added a patch that changes the cljs rng code
Not sure if it’s bad, but I only need some basic functionality that might be provided by other smaller libs
How mature is the npm support in clojurescript right now — is it roughly finished/production ready or still being worked on?
@borkdude In a recent podcast (CaSE), right near the very end, David estimated that it may be another year before the current rapid evolution in the ClojureScript tooling and JS ecosystem integration aspects settle down. I'm not directly involved in the NPM stuff, but if I had to guess, he was thinking along the lines of your question when he made that statement.
how does the new es6 stuff in clojurescript transpile? is it still using the closure compiler to do that or is it babel?
(here’s the link if anyone wants to listen: http://www.case-podcast.org/12-clojurescript-with-david-nolen)
I was actually waiting for the episode of defnpodcast with David, but Joy Clark beat them to it 😉
Hi, is there any easy way to figure out where the cljs compiler is spending most of it's time when compiling?
@mfikes, hmm... I've done a little profiling of Clojure with JVM profilers (yourkit, jvisualvm) in the past and wasn't always straight forward to me how to map JVM objects to Clojure ones. Do you think it would be possible to see which namespaces objects are taking up most of the compilers time?
@zalky Usually if there is a hotspot, while it is not straightforward to map things, I've found it relatively clear where the system as a whole is spending its time. This usually involves some digging, of course, oftentimes looking at both the ClojureScript and Clojure compiler's source.
@zalky Are you trying to find general performance issues that the compiler is exhibiting with your codebase? Or are you just trying to see if you have a particular namespace or two that it taking all of the time?
I've been building out a new project, and just pulled in a number of dependencies and while the compile time is within the realm of expectations, I was hoping it would be faster, and I wanted to see if either one of the dependencies I've pulled in is taking more time, or if maybe there's some obvious way I could speed it up.