Clojurians Log v2

there are a couple other regressions caused by that commit already reported.

https://clojure.atlassian.net/browse/CLJS-3311

https://clojure.atlassian.net/browse/CLJS-3312

hey, beginner here would like to use [hiccup "1.0.5"] in my project. added to :dependencies in shadow-cljs.edn when I try to use html on dynamic arrays, I get this Unable to resolve var: render-html in this context. I know hiccup.core/html is a macro and it uses render-html to render it elements run time, but why is it not able to resolve it.

(defn render-bgrd [elm]
      (let [id (. elm data "id")]
        (str "data:image/svg+xml;base64,"
           (js/btoa (hiccup.core/html [:svg {} [:text {} id ] ])))))

@szalaipeti.vagyok hiccup is a clojure only library. you cannot use it with clojurescript.

thanks, how do people render html/svg runtime in cljs?

If you need to just render and forget, then looking up "clojurescript hiccup" gives https://github.com/teropa/hiccups

Hello! I’m trying to run a computationally intensive Clojure system in Clojurescript and I’m getting the error “The previously used runtime disappeared. Will attempt to pick a new one when available but your state might be gone.” Does that mean I’m hitting a Javascript limit of some kind? I don’t get the error, or it comes later, if I run with less demanding parameters. I’m totally new to the JS ecosystem so would appreciate any pointers!

It's an error from your REPL. "Runtime" is a correctly set up process that executes your CLJS code. REPL has lost its connection to that runtime. One reason it might happen is that you're trying to send something rather big over the REPL's WebSocket connection (e.g. during hot code reload or just a form evaluation). I don't know the exact details but I remember hitting similar issues with a WebSocket (albeit, with a completely different stack) when I tried sending around 10MB of data in one message.

@dfloresgarcia24 OOM is possible - you haven't clarified what enviornment you are trying this in

Thank you! If that is the reason, do you know if there’s anything I could to work around this?

If the problem is indeed with sending large messages over a WebSocket, then there are two obvious solutions: • Reduce the amount of data you send • Don't use WebSockets There's a third possibility - research if it's possible to configure a WebSocket connection to increase that data size limit. I have no clue if that's feasible.

I've used https://github.com/exupero/vdom successfully in the past for a similar use case.

IIRC I did some tests with 100mb websocket messages without issue?

the runtime may just crash? is this node, browser or something else?

or how does your computation take? shadow-cljs kicks runtimes that don't respond after 30sec?

I’m running this in chrome, but it takes less than 30sec for shadow-cljs to kick the runtime

does it reconnect automatically? I really need more information to comment properly.