Fork me on GitHub
#cljs-dev
<
2021-05-13
>
dnolen00:05:20

Ah that’s true, can’t compare versions with sha I think, it’s trying to chose the right logging

dnolen00:05:30

Because closure madness

dnolen00:05:18

So not really a bug but that figwheel makes using shas challenging

dnolen00:05:29

In order to make normal user life easier

raspasov06:05:01

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?

raspasov06:05:57

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...!")))))

dnolen11:05:07

definitely need to create something measurable, I'm pretty skeptical about performance regressions w/ the change

raspasov12:05:11

Yes… Sorry it’s not specific. I’ll post here if I come up with something concrete.

raspasov12:05:48

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.

dnolen14:05:51

@raspasov do you build on REPL start?

dnolen14:05:08

yeah taking so long on the and/or of thing is unfortunate - but honestly I thought it would be harder

dnolen14:05:42

mostly because I had a bad mental model about it

dnolen14:05:10

again the key was that type inference decorates the AST with all the info we need and it is the first pass

dnolen14:05:39

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

dnolen14:05:46

tangentially related - I wonder if the "type-inference" procedure in ClojureScript is really more like abstract interpretation

raspasov14:05:40

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

raspasov14:05:29

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.

dnolen14:05:41

sorry you're just used to the released JAR 🙂

😂 3
dnolen14:05:46

which AOTed compiled

raspasov14:05:57

Ahhhh damn OK lol

dnolen14:05:03

if you use a SHA then you have to compile 25000 lines of Clojure

raspasov14:05:23

I guess because I added the figwheel deps locally via a :local/root / deps.edn

raspasov14:05:28

… it’s not AOTed

raspasov14:05:32

That makes total sense.

raspasov14:05:52

Thanks for that explanation 🙂 I would have never guessed.

raspasov14:05:41

So I guess no problems at all then!

raspasov14:05:33

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 😄

raspasov14:05:56

The lack of short-circuit in (and …)

dnolen14:05:27

the other nasty one is #js will be looking at that next

👍 3
raspasov14:05:34

What is the problem with that?

dnolen14:05:40

just doesn't work reliably

raspasov14:05:56

Ha, I haven’t ran into it…

raspasov14:05:50

Is there a minimal repro or a link for it (just curious how it shows up)?

raspasov14:05:59

Oh, so it’s about #js inside a go I assume, not #js in general?

souenzzo14:05:08

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

dnolen15:05:56

@alexmiller answered - it just looks like they didn't read the Quick Start

dnolen15:05:10

or maybe there is an issue but there's a lot of irrelevant steps

dnolen15:05:40

could not reproduce it following the standard procedure w/o all the various manual steps above