Clojurians
#cljs-dev
<
2018-10-13
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

mfikes00:10:13

@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
I don't see the contrib externs being shipped in any JAR. If they are then you could depend on such a JAR and then use :externs to specify the path to the file on the classpath.

mfikes00:10:56

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

pat00:10:26

ooh thats nice

pat00:10:12

@mfikes thankyou

pat00:10:54

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

mfikes00:10:16

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

pat00:10:26

@mfikes ok thanks

potetm17:10:50

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

potetm17:10:42

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.

potetm17:10:14

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))

potetm17:10:53

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

potetm17:10:40

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

mfikes17:10:36

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

potetm17:10:21

ah jstack! yes!

potetm17:10:32

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

potetm17:10:37

Not sure that fits w/ my story.

mfikes17:10:57

Yeah, not sure what steps you are doing. :slightly_smiling_face:

potetm17:10:48

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

potetm17:10:57

so my story was pure conjecture

mfikes17:10:28

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

potetm17:10:49

:truestory:

potetm17:10:54

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)

mfikes17:10:29

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