[ClojureScript] Re: Figwheel.Main error trying to open cljs reload socket
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 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 Object.figwheel$repl$figwheel_require (repl.cljc:94) > at Object.figwheel$repl$figwheel_require (repl.cljc:94) > at Object.figwheel$repl$figwheel_require (repl.cljc:94) > at Object.figwheel$repl$figwheel_require (repl.cljc:94) > at Object.figwheel$repl$figwheel_require (repl.cljc:94) > at Object.figwheel$repl$figwheel_require (repl.cljc:94) > at Object.figwheel$repl$figwheel_require (repl.cljc:94) > figwheel$repl$eval_javascript_STAR__STAR_ @ repl.cljc:372 > (anonymous) @ repl.cljc:384 > G__12572__2 @ core.cljs:10857 > G__12572 @ core.cljs:10843 > (anonymous) @ repl.cljc:474 > goog.events.EventTarget.fireListeners @ eventtarget.js:284 > goog.events.EventTarget.dispatchEventInternal_ @ eventtarget.js:381 > goog.events.EventTarget.dispatchEvent @ eventtarget.js:196 > goog.net.WebSocket.onMessage_ @ websocket.js:426 > > > > > > On Fri, May 3, 2019 at 3:49 PM Alan Thompson wrote: > >> 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 w/o the socket. >> Any clues on what could be causing this? >> >> Alan >> >> -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
[ClojureScript] Re: Bridging core.async / callbacks
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 seconds for demo purposes
(! this second
(>! i-run-before-callback-c [:first {}]
After about 3 seconds you should see this printed:
*x ::: [:first {}]*
*x ::: [:second {}]*
... i.e. even though we scheduled *[:second {}]* before *[:first {}]*, they
appear in the desired order at the end.
On Friday, May 3, 2019 at 1:47:10 AM UTC-7, Tom Locke wrote:
>
> 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 as possible.
>
> But what do we do if the library we are interfacing with relies on some
> effect having happened *before* the callback returns, but our application
> architecture dictates that effect should come from some other process? (go)
> (put!) and (take!) all return immediately.
>
> According to my (hopefully incorrect!) understanding, it's not possible.
>
> It seems to me we need something like ( cljs due to the lack of real threads.
>
> However, could we not have an implementation of ( like this?:
>
> (defn(loop
>(or (poll! c)
>(if (any-process-ready?)
> (do
>(schedule-next-process!)
>(recur))
> (throw "deadlock!")
>
> This is making some uninformed assumptions about the scheduler, but
> presumably there must be:
>
> - Some kind of list of ready (not blocked on channel operations)
> processes
> - The ability to run a ready process until the next scheduling point (or
> until it runs out of processes).
>
> However I believe the scheduler is to be considered private/opaque, so a
> proper "userland" implementation would not be possible.
>
>
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.
[ClojureScript] Re: Figwheel.Main error trying to open cljs reload socket
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 Object.figwheel$repl$figwheel_require (repl.cljc:94) at Object.figwheel$repl$figwheel_require (repl.cljc:94) at Object.figwheel$repl$figwheel_require (repl.cljc:94) at Object.figwheel$repl$figwheel_require (repl.cljc:94) at Object.figwheel$repl$figwheel_require (repl.cljc:94) at Object.figwheel$repl$figwheel_require (repl.cljc:94) at Object.figwheel$repl$figwheel_require (repl.cljc:94) figwheel$repl$eval_javascript_STAR__STAR_ @ repl.cljc:372 (anonymous) @ repl.cljc:384 G__12572__2 @ core.cljs:10857 G__12572 @ core.cljs:10843 (anonymous) @ repl.cljc:474 goog.events.EventTarget.fireListeners @ eventtarget.js:284 goog.events.EventTarget.dispatchEventInternal_ @ eventtarget.js:381 goog.events.EventTarget.dispatchEvent @ eventtarget.js:196 goog.net.WebSocket.onMessage_ @ websocket.js:426 On Fri, May 3, 2019 at 3:49 PM Alan Thompson wrote: > 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 w/o the socket. > Any clues on what could be causing this? > > Alan > > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
[ClojureScript] Figwheel.Main error trying to open cljs reload socket
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 w/o the socket. Any clues on what could be causing this? Alan -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
[ClojureScript] Bridging core.async / callbacks
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 as possible. But what do we do if the library we are interfacing with relies on some effect having happened *before* the callback returns, but our application architecture dictates that effect should come from some other process? (go) (put!) and (take!) all return immediately. According to my (hopefully incorrect!) understanding, it's not possible. It seems to me we need something like (https://groups.google.com/group/clojurescript.
