@pat The WebAssembly JS API externs are in the contrib part of the GCC tree at https://github.com/google/closure-compiler/blob/master/contrib/externs/webassembly.js So you can manually grab and use these

wget 
clj -m cljs.main -co '{:externs ["webassembly.js"]}' -O advanced -c wasm.core

Alternatively, instead of string disptach, you could use externs inference, as in

clj -m cljs.main -co '{:infer-externs true}' -O advanced -c wasm.core

ooh thats nice

@mfikes thankyou

theres no way to do this automatically for people downstream is there?

You do automatically get some externs by default. (See https://github.com/google/closure-compiler/blob/50713dceb16b369f8f317e5b49e8a9dec2b47496/src/com/google/javascript/jscomp/DefaultExterns.java#L40-L58) But it is not clear to me how you are supposed to depend on externs in the contrib directory (as they don't appear to ship in any JAR as far as I can tell).

@mfikes ok thanks

Anyone else happen to run into a blocked thread when you dis/re-connect a browser repl in the same JVM?

I have a suspicion that there’s a race condition around acquiring a connection from the connq. I looked around JIRA and nothing jumped out at me.

My theory is, ordinarily: 1) you exit a cljs repl (via :cljs/quit) 2) connq still holds a ref to the now defunct conn 3) you start a new repl, which goes through setup 4) the browser makes its :ready request which calls (.clear connq) 5) repl initialization invokes (evaluate renv "cljs_deps.js" 1 (slurp depsf))

However, if 4 happens after 5, you’ll be given the defunct conn that is still in connq, causing you to hang indefinitely.

Anyway, the question here is: is there a reason we shouldn’t clear the connq on tear-down?

@potetm I tried and may have immediately repro'd what you are describing. (My relevant stack is at https://gist.github.com/mfikes/0e52f0243c3517936ff6dbd24ad40c26) To be honest, I've never tested this sequence, especially given that I overly focused on use cases using cljs.main.

ah jstack! yes!

Interesting that it appears to be parked on resolving the promise.

Not sure that fits w/ my story.

I threw this into https://dev.clojure.org/jira/browse/CLJS-2932

Yeah, not sure what steps you are doing. 🙂

same as you did in your example — but I’d not thought to jstack the proc

so my story was pure conjecture

Ahh. Right. Back around 2004 as a (bad multithreaded) Java dev, I learned the mantra "if it's stuck, provide the stack"

wait no, this does fit — it’s waiting for it’s own promise to be resolved (which, in turn, is waiting for the defunct conn)

I'm not overly familiar with that code. I think David wrote most of it (or at least he touched it last).