[ClojureScript] Re: Figwheel.Main error trying to open cljs reload socket

2019-05-03 Thread Alan Thompson
Found it. Someone had left an old reference to `figwheel/watch-and-reload` lying around Doh! (figwheel/watch-and-reload ; #todo #awt needed? :websocket-url "ws://localhost:3449/figwheel-ws" :on-jsload mount-components) On Fri, May 3, 2019 at 4:00 PM Alan Thompson wrote: > Also

[ClojureScript] Re: Bridging core.async / callbacks

2019-05-03 Thread Rangel Spasov
Here's one idea, basically put "channel on a channel" idea: (defonce main-c (chan 1)) (defn start-main-channel-loop [] ;put channels on the channel in the order that they need to execute (go (loop [] (let [c (! this first (>! callback-c [:second {}]) ;wait 3

[ClojureScript] Re: Figwheel.Main error trying to open cljs reload socket

2019-05-03 Thread Alan Thompson
Also getting this error: repl.cljc:372 REPL eval error RangeError: Maximum call stack size exceeded at cljs$core$_EQ_ (core.cljs:1258) at Object.figwheel$repl$figwheel_require (repl.cljc:90) at Object.figwheel$repl$figwheel_require (repl.cljc:94) at

[ClojureScript] Figwheel.Main error trying to open cljs reload socket

2019-05-03 Thread Alan Thompson
Using figwheel-main, I am getting a strange error: Figwheel: trying to open cljs reload socket socket.cljs:71 WebSocket connection to 'ws://localhost:3449/figwheel-ws' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED As the error message implies, hot reloading doesn't work

[ClojureScript] Bridging core.async / callbacks

2019-05-03 Thread Tom Locke
In the early core.async presentation, Rich argues that we should avoid putting application logic in callback handlers, and instead build the "machine like" parts of our code in the core.async model. To bridge from callback world to core.async we have put! and take! which we should call as soon