Fork me on GitHub
#shadow-cljs
<
2022-03-26
>
barrell19:03:23

If I have an atom in a web worker namespace, is there any way to inspect this value via the REPL? I’m assuming the repl is connected to the main thread as when I try to execute anything the values are all empty

barrell19:03:41

Or is there some integration with insepct/tap that I can load an atom into it and inspect it at any time?

barrell19:03:53

Oh my god. I can just open up all the defined atoms in a namespace? Consider my mind blown.

barrell19:03:35

If there is anyway to cycle the JS runtime you connect to though, I’d still be keen to know

barrell19:03:50

Or looking through the source code it looks like maybe there is some way to delegate tasks to the worker thread? :thinking_face:

barrell19:03:11

I’m getting close with something like:

(->> (shadow.cljs.devtools.api/repl-runtimes :browser)
     (last)
     :proc-id
     (hash-map :proc-id)
     (shadow.cljs.devtools.api/repl :browser))
This successfully connects to a repl and I can execute arbitrary code (i.e. (+ 1 1)) but I still can’t access any context

barrell19:03:35

(not sure if it’s a red herring though)

barrell19:03:12

Hmm it seems proc-id is actually the same for both repl-runtimes so I’m connecting to the same instance. Can’t figure out how to print the runtime-id (it is not returned from repl-runtimes)

barrell19:03:29

ahaaa so client-id is the runtime-id (small numeric number). Was able to get it working with:

(->> (shadow.cljs.devtools.api/repl-runtimes :browser)
       (last)
       :client-id
       (hash-map :runtime-id)
       (shadow.cljs.devtools.api/repl :browser)))
With this and inspect shadow-cljs is unstoppable!

thheller20:03:51

hehe yeah this API went through some unfortunate renaming cycles since I couldn't settle on a name

thheller20:03:01

thus the mix of :client-id and :runtime-id

barrell06:03:01

No worries, I figured I’d share my findings as I went along so this thread would have all the keywords I ran across 😂