This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-05-13
Channels
- # announcements (8)
- # architecture (11)
- # babashka (159)
- # beginners (112)
- # biff (4)
- # chlorine-clover (4)
- # cider (10)
- # clj-kondo (51)
- # cljs-dev (43)
- # cljsrn (10)
- # clojure (45)
- # clojure-bay-area (5)
- # clojure-europe (11)
- # clojure-france (4)
- # clojure-italy (4)
- # clojure-nl (2)
- # clojure-norway (1)
- # clojure-sweden (1)
- # clojure-uk (8)
- # clojurescript (75)
- # code-reviews (1)
- # community-development (2)
- # conjure (88)
- # cryogen (5)
- # data-science (1)
- # datomic (3)
- # dirac (2)
- # fulcro (4)
- # helix (1)
- # jackdaw (5)
- # kaocha (5)
- # leiningen (2)
- # lsp (49)
- # malli (9)
- # mid-cities-meetup (1)
- # off-topic (8)
- # pathom (3)
- # polylith (19)
- # re-frame (6)
- # releases (3)
- # rewrite-clj (1)
- # shadow-cljs (98)
- # spacemacs (2)
- # tools-deps (6)
- # vim (4)
- # xtdb (6)
Ah that’s true, can’t compare versions with sha I think, it’s trying to chose the right logging
Ok, I made some local changes to figwheel-main and got it to compile. I don’t have a small repro case or exact benchmarks but: Launching a dev figwheel repl does feel substantially slower than before on my current project. Are some of the new CLJS changes expected to potentially affect compilation performance?
On a positive note, yes, the core.async long-standing bugs seem fixed 🙂
(defn go-test-123 []
(a/go
(let [?v :not-a-v]
;this works!
(if (and (vector? ?v) (< 0 (count ?v)))
(println "VECTOR!")
(println "Not a vector...!")))))
definitely need to create something measurable, I'm pretty skeptical about performance regressions w/ the change
Everything feels OK otherwise. I’ve been using the new version for a few hours during dev and all is good. This initial delay in loading the REPL is quite weird.
yeah taking so long on the and/or
of thing is unfortunate - but honestly I thought it would be harder
again the key was that type inference decorates the AST with all the info we need and it is the first pass
seems simple but just didn't see it many months ago when I tried it last, but once I saw that and/or
can go after and it doesn't need to do anything special at all it was quick
tangentially related - I wonder if the "type-inference" procedure in ClojureScript is really more like abstract interpretation
@dnolen
clj -m figwheel.main -b ios -r
It’s weird. It “builds” fast as usual, but then it takes about the same time for the REPL to connect. And I see the java
process going crazy in Activity Monitor.
The laptop fans even turn on, not on M1 yet, lol
After it’s done the REPL connects.
After that, there’s no problems. It’s really not a show stopper because it’s more or less a one time cost. I don’t have to re-build unless I add a new library, or something rare.
It could be something from figwheel as well (not using caches?, something else wrong?), but I don’t know enough about the internals to be able to give an educated guess.
That’s pretty neat that those core.async bugs are fixed. I remember first time I ran into this problem years ago, I thought I was going crazy, it probably took me 1/2 day to figure out where it’s coming for 😄
Just something like (let [x 1] (go #js {:x x}))
will not find x
There is also a wired behavior that if it's a global it works, but not with locals.Don't remember exactly
https://ask.clojure.org/index.php/10602/evaluating-an-ns-form-clojurescript-repl-throws-rangeerror
@alexmiller answered - it just looks like they didn't read the Quick Start