@darwin linking out of the issue really makes thing hard to follow, but also this just seems like a different issue than 3030 anyway?

we shouldn't pile on - make a separate issue w/ a minimal case and put everything inline so I can easily follow what you're seeing - thanks

dnolen: yes, it is a different issue than 3030. Sure, I understand that this stackoverflow issue will be tricky. Will try to prepare some minimal repro and open a new issue - but the problem is that the issue goes away when I try to fiddle with the code “around”. I experienced it in situations when a go-block got too large, more than 17 forms…

Tested a couple of projects on CLJS master, so far no problems. I haven’t checked code that uses planck + new master yet.

I’m getting errors with planck + master + CLJS master in speculative:

FAIL in (cons-test) (cljs$test$run_block@file:380:88)
expected: (respeced.test/successful? stc-result__85__auto__)
  actual: (not (respeced.test/successful? [{:spec #object[cljs.spec.alpha.t_cljs$spec$alpha20287], :clojure.test.check/ret {:result #object[Error Error: Unable to construct gen at: [:seq] for: :speculative.specs/seqable]}, :sym cljs.core/cons, :failure #object[Error Error: Unable to construct gen at: [:seq] for: :speculative.specs/seqable]}]))

I’ll look into this

I get it. speculative sees the CLJS version ClojureScript 0.0.511587067 and thinks it’s older than 439, so the seqable? predicate didn’t support nil yet and it was patched. I should also include a generator for that custom predicate.

works now.

Tested a largish project from work and all seems good. I’m done testing.

I investigated the stackoverflow issue today a bit more, so far I was unable to reproduce it with some small repro case, also I tried to use cljs.build.api on failing chromex library sources and also didn’t reproduce it, so I tried to attach debugger to compiler JVM (spawned by lein) where the issue is present, also added some debug printing. So far it looks like there is no fundamental issue in compiler - e.g. I expected it enters infinite recursion. It just simply hits the stack depth limit during normal work. The reason seems to be a gigantic (cond ...) generated by core.async to implement its state machine. It looks like with each new cond clause analyzer steps deeper into stack, which could blow with a cond having hundreds of clauses. I believe with this I will be able to craft a repro case.

I noticed CLJS master is still using clojure 1.9. Maybe time to upgrade that as well?

@borkdude ClojureScript master depends on Clojure 1.8. (The pom.xml file controls this.)

ClojureScript master passes with Canary ✅ core.async has been added to Canary

@mfikes Oh, I did clj when I was in the repo and the REPL said 1.9.0 that’s why I thought that 🙂

cljs.user=> (hash-map 1)
{}
cljs.user=> (hash-map 1 2)
{1 2}
cljs.user=> (hash-map 1 2 3)
{1 2}
cljs.user=> (hash-map 1 2 3 4)
{1 2, 3 4}