Clojurians Log v2

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

Because closure madness

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

In order to make normal user life easier

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

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

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.

@raspasov do you build on REPL start?

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

mostly because I had a bad mental model about it

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.

@raspasov oh ha

sorry you're just used to the released JAR 🙂

which AOTed compiled

Ahhhh damn OK lol

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

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

… it’s not AOTed

That makes total sense.

Thanks for that explanation 🙂 I would have never guessed.

So I guess no problems at all then!

💥

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 😄

The lack of short-circuit in (and …)

was nasty

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

What is the problem with that?

just doesn't work reliably

Ha, I haven’t ran into it…

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

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

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

@souenzzo I see, thanks!

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

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

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