This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-20
Channels
- # announcements (2)
- # architecture (5)
- # beginners (118)
- # cider (5)
- # clara (13)
- # cljdoc (8)
- # cljs-dev (49)
- # cljsjs (2)
- # clojure (107)
- # clojure-dev (9)
- # clojure-europe (3)
- # clojure-italy (58)
- # clojure-japan (2)
- # clojure-nl (6)
- # clojure-spec (89)
- # clojure-uk (27)
- # clojurescript (9)
- # core-async (33)
- # cursive (2)
- # datascript (2)
- # datomic (31)
- # duct (4)
- # emacs (1)
- # events (1)
- # figwheel-main (1)
- # fulcro (69)
- # hoplon (7)
- # hyperfiddle (16)
- # incanter (4)
- # instaparse (4)
- # kaocha (1)
- # mount (2)
- # nrepl (19)
- # off-topic (40)
- # onyx (6)
- # other-languages (3)
- # pedestal (2)
- # re-frame (48)
- # reagent (2)
- # reitit (10)
- # ring-swagger (9)
- # shadow-cljs (63)
- # spacemacs (13)
- # sql (8)
Today I had a dream - or nightmare it depends 😃 - what is the Cljs compiler became native up until shelling out to the JVM for the optimization phase? I don't know too much about the internals there but is this gaining something in terms of speed? I know that this would mean the REPL would be a completely separate thing now
so basically restart from scratch to gain a second or so. very doubtful that'd be useful 😉
Yeah of course I am not really aware of the seconds to be gained
Because the GCC step might be now intertwined with other things
Just wanted to say that I really had a dream with that lol kinda funny
@thheller is startup time only 1 second for you? Genuinely asking, never profiled it but mine feels more like 5 before I see "Comping..." in Shadow
no idea. last time I measured it was somewhere closer to 3sec (AOT version). don't care much since server-mode makes it zero 😉
well except in CI
we spoke about this actually, I should probably have a Shadow as a service
now I am launching instance one per folder
it adds up 😄
our CI at the moment completes in 20 minutes and Cljs is losing big time compared to TypeScript 5-7 mins
not a big deal for me, but I need to protect my investment from detractors 😄
yep I know, except that this means to build a Docker image in Azure where we are
and folks here don't have to do that, I don't have time for doing that, so it would be programming in anger 😄
in any case it will happen sooner or later
That sounds quite slow. "Big and slow" projects take like 6 minutes for me, 3min 50sec for unit/integration tests, 1min 30sec for Cljs advanced build and uberjar build, 35sec push to dockerhub (could be optimized to few seconds)
has anyone here been able to compile the Closure Compiler in IntelliJ? I just can't get it compiling properly
our builds only range from 40-80 seconds (multiply that by ten projects) - the most of the time is spent downloading dependencies
what I am saying is that we are already a niche language - everything that you need to add on top of things is seen as "why do I need that, TypeScript doesn't need that"
downloading dependencies: cache - probably stating the obvious. not on CircleCI or anything like that?
@thheller well that might actually be 😄 @borkdude I wish I were on Circle
I opened that issue on shadow but I see no further discussion on how to solve is needed 😄
the three biggest things we did for CI was cache dependencies (node_modules and m2), cache the .shadow-cljs
folder, and make each build run sequentially
Is cljs source maps fully compatible with version 3
of the format? https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit
@roman01la it emits v3 yes. not sure what fully compatible means though. there isn't much to it really.
@roman01la AFAIK yes
Ok, thanks. I got invalid prefix error from Mozilla’s parser but couldn’t reproduce it again
well, “emitting v3” does necessary mean “always produces correct output” and Mozilla’s parser could have bugs, hard to tell
@roman01la the source maps in optimized builds are incomplete since they miss any cljsjs maps. besides that some parts are not properly mapped, especially macro related code so there will be "gaps"
@thheller Tangentially related—do you have an implementation of https://dev.clojure.org/jira/browse/CLJS-2895 in shadow-cljs
?
the 2.5s version was storing the raw source map data directly yes, now its just the vlq encoded mappings which is basically the culled version
I looked at a bunch of maps via https://sokra.github.io/source-map-visualization/ and it all seemed ok with some minor gaps
Cool. Sounds like something along the lines of CLJS-2895 can help general perf. (Source mapping is not horribly expensive, but still feels like an area worth optimizing in some way.)